Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=aHH86X/M71xvV78sMJ6BAGIycSM1/NgStlGkzykk5LydXY05TD2uNeuDVWFbFb2/ttI+uQKky/uWjuqimuB9LbHNUjAPfH2q18XKY4SKUja0K7DT03DLGuQj3loPAHGlNHoxAwn0fYfgOapc1dt/nPYM/fO1C6l3hk/WAuz4+0E=
  ;
Message-Id: <046D158D-4894-4344-8B53-3F4CF33D7A23@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: dev@geronimo.apache.org
In-Reply-To: <4ACCE69F.5020000@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: RFC 66 and Geronimo
Date: Wed, 7 Oct 2009 14:22:03 -0700
References: <4ACC9CD0.2000907@gmail.com>
 <F8558EA9-5CCD-4A12-87EE-5042E6189E60@yahoo.com> <4ACCE69F.5020000@gmail.com>


On Oct 7, 2009, at 12:06 PM, Rick McGuire wrote:

> David Jencks wrote:
>>
>> On Oct 7, 2009, at 6:51 AM, Rick McGuire wrote:
>>
>>> RFC 66 is an extender that recognizes that OSGi bundles that have  
>>> a defined manifest header contain web applications and should be  
>>> deployed to a web container.  The reference implementation uses an  
>>> embedded web container, which is probably not an appropriate  
>>> approach for Geronimo, since that would mean Geronimo would be  
>>> serving up applications from two different web container  
>>> instances.  Ideally, a Geronimo-specific version of this extender  
>>> would have knowledge of the Geronimo configuration and be capable  
>>> of deploying WABs (Web Application Bundles) to the single hosted  
>>> container, and ideally would be capable of handling both Tomcat  
>>> and Jetty containers as targets.
>>>
>>> I started out with the approach of doing a bare-bones  
>>> implementation that had nothing that was not required by the RFC  
>>> 66 draft spec.  WABs are basically standalone web apps, with  
>>> little or no integration with the server environment.
>>
>> Just to clarify, these can have both web.xml and annotations?
>
> I believe so, but the spec does spell out being able to specify  
> metadata complete in the web.xml.
>>
>>> And specifically, there's no web services support layered on top  
>>> of the WAB.  Starting with that assumption, I was able to retask  
>>> the code TomcatWebAppContext class to build a context that should  
>>> allow a WAB to be deployed to a Tomcat container.  The  
>>> TomcatWebAppContext is the GBean that gets added to the module  
>>> configuration by the TomcatModuleBuilder, and most of the items  
>>> passed to the constructor had reasonable defaults I could dummy  
>>> up.  This bit appears fairly manageable, and I'm sure something  
>>> similar can be done for Jetty.
>>> However, there are a number of downsides to this approach.
>>>
>>> 1)  No Geronimo or tomcat-specific configuration is supported.
>>> 2)  No integration with Geronimo security
>>> 3)  No naming context is provided to the servlet environment.
>>>
>>> None of these things are defined or required by RFC 66, but things  
>>> like security annotation processing should be supported.
>>>
>>> So the next step is to adapt some of the code from the  
>>> TomcatModuleBuilder that processes web.xml, geronimo-web.xml, and  
>>> geronimo-tomcat.xml and process these files when the context used  
>>> to deploy the web application is constructed.  At this point, I  
>>> started running into some mismatches in how Geronimo deployments  
>>> are managed and how RFC 66 deployments need to be managed.
>>> A Geronimo deployment essentially gets converted into a plugin  
>>> configuration by unpacking the jar file and creating a plugin  
>>> configuration that is then subsequently started.  Since processing  
>>> is done in two stages, files can be created/altered in the plugin  
>>> tree statically, classes can be loaded, etc, all without impact to  
>>> the runtime processing of the application.
>>>
>>> For a  WAB deployment, the extender become involved after the  
>>> bundle has been installed and started.  At this stage, there's no  
>>> opportunity to modify the bundle contents.  Additionally, there is  
>>> an RFC 66 requirement that if the bundle uses lazy activation, the  
>>> bundle should not get activated until the first request for a  
>>> servlet instance occurs (i.e., no class loading requests until  
>>> deployment).
>>> Going through the TomcatModuleBuilder code, I've found the  
>>> following pain points:
>>>
>>> 1)  Creating the initial context naming context for the deployed  
>>> application.  I'm not really sure what this should be.  A lot of  
>>> that processing gets delegated to other naming builders, so it's  
>>> been a bit difficult to unravel what's really going on here.
>>
>> You should be able to get environment entries and some resources  
>> such as persistence contexts in the jndi tree without much  
>> reference to the outside world.  Datasources and ejbs kind of  
>> require some knowledge of the environment the app is running in.   
>> Currently we use  the directed acyclic graph of plugin ancestors to  
>> search in for outside-the-app resources.  I think this is a good  
>> model but it appears to be different from what rfc 138 is  
>> describing.  I don't know how to resolve this yet.
>>>
>>> 2)  Use of ClassFinder to process the security annotations.  The  
>>> security configuration is processed by searching for security  
>>> annocations on the classes referenced in web.xml.  This has the  
>>> side effect of forcing classes to be loaded from the bundle,  
>>> triggering the early activation.
>>
>> This doesn't involve loading the application classes, just  
>> accessing their byte code as resources.  Does this trigger  
>> activation?  I haven't deciphered the lifecycle enough yet to know.
> AbstractWebModuleBuilder.createWebAppClassFinder() is using  
> classLoader.loadClass() to access each of the servlet, listerner,  
> and filter classes.  This certainly would force the bundle to  
> activate.  If there is another approach that can be used, I'd love  
> to learn it.

Maybe David Blevins can provide more details on how to do this.  I  
thought I heard that the xbean annotation scanning used only the byte  
code and not the classes.
>
>>
>>> 3)  What is the Holder used for and how is the instance  
>>> generated?  This one has been a complete mystery so far, so if  
>>> anybody can give an overview of what's going on with that class,  
>>> it would be most useful.
>>
>> This contains the data for injections.  It's set up by the naming  
>> builders and annotation framework from the annotations and xml  
>> overrides. (actually the annotation processing generates xml, which  
>> is then processed into the data in the holder).
>>>
>>> 4)  Some of the attributes that are set for the  
>>> TomcatWebAppContext are abstract names created as childnames.  For  
>>> a WAB deployment, these items need to be resolved and located at  
>>> runtime, rather than configured as a GBean attribute.  Since I  
>>> don't have a module naming context to work with at that time, I'm  
>>> not sure I understand how to rework this.  See line 389 in  
>>> TomcatModuleBuilder for an example of the type of query I'm  
>>> talking about.  I think all I need here is an example for how to  
>>> convert one of these into a runtime query to get me unblocked on  
>>> this.
>>
>> Those look to me like they are all related to geronimo specific web  
>> app configuration, and I don't see any way to process that without  
>> using the TomcatModuleBuilder.  Since it's all optional, I'm not  
>> sure there would be a problem leaving it out.
>
> It certainly was easy to leave out.  The one specific one that  
> worried me was TomcatRealm.
>>
>> ...
>>
>> I'm not sure if this would be a significantly different approach to  
>> what you have been considering, but I wonder if this might fit  
>> better with the sandbox osgi framework changes.  There I have   
>> ConfigurationActivator that reads the config.ser out of the bundle  
>> into a ConfigurationData and calls some methods on configuration  
>> manager to install it and start stuff up.  I wonder if the extender  
>> you are contemplating could call the appropriate deployers to  
>> generate the ConfigurationData directly and then call the same  
>> ConfigurationManager methods.  This would probably require some  
>> modification to DeploymentContext which currently constructs a  
>> temporary bundle to load the classes needed by the deployers.   
>> Here, we already have the bundle.  I would expect that this kind of  
>> approach would work for any ee app that has been packed into a form  
>> that can be loaded as a bundle: I think this means basically that  
>> there is only one level of jar nesting rather than the 3 levels  
>> possible in an ee app (jar in rar in ear).
> RFC 66 is specifically for creating OSGi aware web bundles, so it  
> assumes an OSGi way of doing things.  Since this is a standardized  
> format, there's no real opportunity to preprocess the bundle into  
> another form.  The processing needs to be that the extender reacts  
> to the bundle getting started and processes manifest and web.xml  
> data in the bundle to deploy it the container.
> Based on what I've seen so far, this is doable, except for a few  
> difficulties such as the sorting out the security and initial  
> context configurations.

Right.  The deployers currently basically copy the contents of the ee  
app into the config, unpacking stuff so its accessible to our  
classloaders, and then construct a bunch of gbean configurations which  
they put into a ConfigurationData object which then gets serialized,  
also into the config.  I'm suggesting that, if we're lucky, the first  
step of copying stuff won't be necessary since osgi can already get at  
everything in one of these bundles, and if we don't have an  
opportunitly to store the configuration data we can just generate it  
on each startup.  Therefore the extender could call the middle step of  
constructing the ConfigurationData object, and then just use the  
ConfigurationManager to start it.  I would like to look around and see  
if there's some way to store the constructed ConfigurationData so we  
don't have to redeploy the app each time it's started.

Hopefully this makes a little more sense....

thanks
david jencks

>
> Rick
>>
>> hope this helps...
>>
>> thanks
>> david jencks
>>
>>>
>>> Rick
>>
>>
>