I have long wondered how that stupid 'end' Form component shows up when you drop a 'start' Form component on a page.  Just like magic, that little bugger appears out of the ether.  The secret to this one is no longer a secret to you or me.

Shame on me, and please forgive me, I did not write down the exact method I used to find this.  When I am "in the zone" hunting for something like this, shame on me, I rarely document what I did.  Maybe while writing it down here, some of it will come back.

I frequently rely upon Recent Requests in the Sling console.   This one did not require my other blog post trick of increasing the recent request count.  Regardless, I cleared the recent requests, dropped the 'start' component on the page, and checked out what happened behind the scenes.  Try it yourself.

You are going to see a "POST par".  Interesting.  What was it posting?  Click on that link.  About a thrid of the way down you will see something like:

1 (2013-01-18 05:19:44) TIMER_END{0,ServletResolution} URI=/content/xxx/yyy/zzz/jcr:content/par/ handled by Servlet=org.apache.sling.servlets.post.impl.SlingPostServlet

Interesting even more... I looked up the package name for the forms stuff:  com.day.cq.wcm.foundation.forms, took that and the post servlet package: org.apache.sling.servlets.post and created a new logger configuration.  I turned the logging level all the way down to TRACE.  When looking at the WCM API for the Sling POST stuff, I also happened to notice: SlingPostProcessor, and thought, what the hell is that thing?  

Now I am looking back at the Sling console in the configurations section, searching on PostProcessor - nothing.  OK, how bout Post, and just about the last match: "Day CQ WCM Form Paragraph Post Processor"  No kidding... and the pieces start to fall together.

Apparently, the SlingPostServlet service collects all available PostProcessor implementations.  The Servlet acts like an Observable, and the Processors act like Watchers - sort of Pub-Sub-ish.  Not quite, but you get the idea.  OK, maybe 'visitor' is more like it.  When a POST occurs, each one will get a crack at doing something after the POST.  In this case, our PostProcessor is the culprit that is doing not just the creation of the FORM end component, but it actually fixes up some of the other metadata for the form component itself.  Likewise, when a 'start' component is deleted, the corresponding 'end' is deleted by the PostProcessor as well.

Not that I needed to, I run the experiment again.  Logging is set, GO.   All is confirmed, no elves here.

Now, extending the form component...that is another story altogether....