You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2009/10/07 15:51:12 UTC
RFC 66 and Geronimo
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. 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.
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.
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.
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.
Rick
Re: RFC 66 and Geronimo
Posted by Delos <da...@gmail.com>.
I'm just curious about the RFC 66 implementation in Geronimo. Is there any
resources we can learn just like the new framework in trunk?
Thanks!
2009/10/8 Lin Sun <li...@gmail.com>
> Ok, I was under the impression that you need to modify the bundle
> before the bundle is started/starting, thus I was suggesting the url
> handler to do so.
>
> Lin
>
>
> On Thu, Oct 8, 2009 at 10:17 AM, Rick McGuire <ri...@gmail.com> wrote:
> > I'm not trying to implement a new way for Geronimo to convert a WAB
> bundle
> > into Geronimo artifacts
> > that require pre-install conversion. I'm working on an RFC 66 extender
> that
> > recognizes that a WAB
> > bundle has been started and deploys this to the Geronimo hosted container
> > implementing the behavior
> > specified in RFC 66. This means that the only additional metadata in the
> > bundle is the manifest header that
> > specifies the context path. At this point, it is not possible to do a
> > conversion on the bundle, it's too late for that.
> > The deployment needs to be made using the information that available in
> the
> > bundle already without requiring any
> > side metadata such as an external Geronimo deployment descriptor. This
> > essentially requires much of the same
> > decision making as is used for JEE WAR installs, but needs to be done
> using
> > runtime resources rather than by
> > converting this into a static configuration.
> >
> > Rick
> >>
> >> Lin
> >>
> >>
> >
> >
>
--
Best Regards,
Delos
Re: RFC 66 and Geronimo
Posted by Lin Sun <li...@gmail.com>.
Ok, I was under the impression that you need to modify the bundle
before the bundle is started/starting, thus I was suggesting the url
handler to do so.
Lin
On Thu, Oct 8, 2009 at 10:17 AM, Rick McGuire <ri...@gmail.com> wrote:
> I'm not trying to implement a new way for Geronimo to convert a WAB bundle
> into Geronimo artifacts
> that require pre-install conversion. I'm working on an RFC 66 extender that
> recognizes that a WAB
> bundle has been started and deploys this to the Geronimo hosted container
> implementing the behavior
> specified in RFC 66. This means that the only additional metadata in the
> bundle is the manifest header that
> specifies the context path. At this point, it is not possible to do a
> conversion on the bundle, it's too late for that.
> The deployment needs to be made using the information that available in the
> bundle already without requiring any
> side metadata such as an external Geronimo deployment descriptor. This
> essentially requires much of the same
> decision making as is used for JEE WAR installs, but needs to be done using
> runtime resources rather than by
> converting this into a static configuration.
>
> Rick
>>
>> Lin
>>
>>
>
>
Re: RFC 66 and Geronimo
Posted by Lin Sun <li...@gmail.com>.
What I meant was that geronimo has full control of artifact deployment
when user is deploying through the geronimo supported deployment
mechanism. You are right that a bundle can use
BundleContext.install() to install any bundle at any time, but that
doesn't mean it will work or it is supported. Even with RFC 66, a
bundle that uses BundleContext.install() to install a war would fail
only if they use the webbundle: url schema and use it correctly.
On Thu, Oct 8, 2009 at 9:32 AM, Rick McGuire <ri...@gmail.com> wrote:
>
> No, Geronimo does not necessarily have full control of when a WAB bundle is
> installed. Any other bundle can use BundleContext.install() to install any
> bundle at any time, and a compliant RFC 66 implementation needs to be able
> to recognize that a WAB has been installed and react to it.
I believe the RFC 66 impl only needs to recognize a WAB is
starting/stopping (not installed) and react to it.
> The webbundle:
> URL scheme is for installing a WAR (not a WAB) and performs a conversion
> into a WAB bundle that is then processed by the extender when the converted
> bundle is started. The extender only takes control once a bundle containing
> the appropriate header manifest information has been started, at which point
> strategies that rely on altering the content of the bundle will not work.
Right, I agree with what you said here, but I am not proposing to do
something with the extender. I am proposing another url handler which
is invoked when the bundle is installed and before the bundle is
resolved/starting. I don't think what I am proposing has any
conflict which what RFC 66 describes.
Lin
Re: RFC 66 and Geronimo
Posted by Lin Sun <li...@gmail.com>.
Hi, see comments below.
Lin
On Thu, Oct 8, 2009 at 5:48 AM, Rick McGuire <ri...@gmail.com> wrote:
> The URL handler is a different stage of the processing. That gets involved
> at the installation time of the bundle, and
> causes a transform of a standard WAR into a WAB, which then gets processed
> by the extender. Once the WAB has
> been installed and started, that's when the WAB extender kicks in, and at
> that point, there's no opportunity to
> perform the transformation.
I think Geronimo has full control when the bundle/war is installed and
this can be triggered by geronimo's existing deployment mechanisms
(such as hot deployment, command line deployer or admin console
deployment). I kinda think it is best to do this type of geronimo
specific conversion at the install time, because it would be too late
if we do it after the bundle is resolved/started. The web extender
defined by RFC 66 is something that we must implement, but we could do
stuff beyond what is defined for the web extender. :) What I am
proposing is to develop a geronimo url handler that can convert the
war file into the geronimo plugin (or whatever artifact that can be
deployed to geronimo's web server). For example, when a war file is
installed, we can use the following as location identifier of
BundleContext.install(String loc).
webbundle:geronimo:file:///Users/linsun/test1.war?Web-ContextPath=/linsun
This will invoke the webbundle url handler which will convert the war
to a wab for Geronimo. Then it will invoke the geronimo url handler
which will convert the wab to geronimo plugin (or whatever artifact
that can be deployed to geronimo's web server).
Then the bundle is installed and resolved. Then the web extender
defined by rfc 66 kicks in and listens to the bundle events.
> "Should" items are there for a reason and at least an attempt should be made
> to satisfy the language of the specification.
> If it turns out to be impossible, so be it, but the possibility of fully
> implementing that needs to be made.
Right i just want to point that out. :)
Re: RFC 66 and Geronimo
Posted by Lin Sun <li...@gmail.com>.
Hi, Please see comments below, Thanks
Lin
On Wed, Oct 7, 2009 at 9:51 AM, Rick McGuire <ri...@gmail.com> wrote:
> 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.
You are right that the extender gets notified when the bundle is
already resolved and starting/started. However, I wonder if we want
to modify the bundle contents through another URL handler like the
webbundle url handler defined by RFC 66. I think RFC 66 mentions
that the web bundle url handler should work with other url handlers.
For example, we can have a geronimo specific url handler that handles
the modifying of the bundle content to add Geronimo specific
configurations during the installation of the bundle (when
BundleContext.installBundle is invoked) and leverage the webbundle url
handler from the Apache Aries project to do the manifest generation
for the WAR to WAB conversion.
> 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).
I don't think the RFC mandates that, because it is the wording
"should" that is used here, instead of "must". There was someone from
Sun that required the "must" to be removed from the rfc IIRC.
Re: RFC 66 and Geronimo
Posted by Rick McGuire <ri...@gmail.com>.
David Jencks wrote:
>
> 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.
The framework allocates a persistent data area associated with installed
bundles, so there is a location where we might store such information.
That same area is the recommended work area for the container to store
compiled JSPs.
>
> Hopefully this makes a little more sense....
Yes, I think I understand what you're suggesting now. Now I just need
to learn enough details about to actually try implementing it.
>
> thanks
> david jencks
>
>>
>> Rick
>>>
>>> hope this helps...
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Rick
>>>
>>>
>>
>
>
Re: RFC 66 and Geronimo
Posted by David Jencks <da...@yahoo.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
>>
>>
>
Re: RFC 66 and Geronimo
Posted by Rick McGuire <ri...@gmail.com>.
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.
>
>> 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.
Rick
>
> hope this helps...
>
> thanks
> david jencks
>
>>
>> Rick
>
>
Re: RFC 66 and Geronimo
Posted by David Jencks <da...@yahoo.com>.
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?
> 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.
> 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.
...
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).
hope this helps...
thanks
david jencks
>
> Rick