geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: Implementing rfc66 in Geronimo
Date Fri, 15 Jan 2010 02:47:47 GMT
I am thinking that while implementing the WAB extender, how does it use
current deployer ? There might be something need to consider :
1. Current Geronimo deployer is designed for two steps deployment, which
means that it needs to install package to the OSGI environment twice, how to
handler it in the extender ?
2. Where and when we store the configuration datas ? Not sure in the spec,
there is any description about the contain's behavior, or it would analysis
the WAB each time while starting it ?
3 . About the double start, while restarting Geronimo, it should be possible
to use location or artifact, but since WAB could be installed by any other
applications, so location/artifact might not enough.

2010/1/14 Rick McGuire <>

> Rex Wang wrote:
>> 2010/1/14 Jarek Gawor < <>>
>>    Hey all,
>>    I've been looking into implementing rfc66 support in Geronimo a little
>>    bit more. Here are some things that we need to do and my
>>    thoughts/impressions about them:
>>    1. WAR to WAB converter. Installs webbundle: url handler that converts
>>    standard WAR files into Web Application Bundles (WAB). The converter
>>    code was contributed by IBM to Apache Aries but so far it has not been
>>    moved to trunk yet. This code will probably need some updates but I
>>    think we could just mostly use it as it is in Geronimo.
>>    2. WAB extender. Watches for WABs to be started in the framework and
>>    performs the necessary steps to deploy the applications.
>>     a. In Geronimo we will need a custom extender that effectively
>>    invokes Tomcat/JettyWebModuleBuilders to deploy the application. There
>>    might be an extender implementation donated to Aries at some point but
>>    I don't think we will be able to use since it most likely will use the
>>    Tomcat or Jetty API directly to deploy the application. In Geronimo we
>>    build the GBeans which then use Tomcat/Jetty API to set everything up.
>>     b. The biggest issue that I see with Geronimo WAB extender is
>>    updating the WebModuleBuilders (or actually the whole deployment
>>    process) to work with Bundle objects. Right now the deployment process
>>    for the most part assumes it is working with JarFiles.
>> So, what is the standard method to install/deploy a WAB into Geronimo 3.0?
>> From the osgi perspective, that should be the same with installing a normal
>> bundle to framework, and then the extender will track this and help deploy
>> it to geronimo by instantiating some gbeans. Should we support the geronimo
>> deployment process such as deploy a WAB with a external plan?
> One key point with WABs is to remember that a WAB is an OSGi programming
> construct and even though it is running under Geronimo, it should function
> under OSGi rules.  One key point here is any application may install and
> start a WAB bundle using a BundleContext without ever knowing anything about
> the hosting Geronimo server.  That's the key purpose of the
> processes any bundle that has the manifest entries that identify this as a
> WAB and take the steps necessary to deploy this.  The bundle in question
> might not have gone through the Geronimo deployment process first.
>>     c. Rick has some initial extender code in the sandbox that we should
>>    be able to reuse (or at least parts of it) in Geronimo.
>>     d. Things to keep in mind:
>>       1. The specification talks about support for lazy bundles. More
>>    specifically, that a request on static resource of a lazy activated
>>    bundle should not cause the bundle to become fully activated.  This
>>    might be tricky to implement in Geronimo and would require changes to
>>    existing code. However, support for lazy bundles seems to be optional
>>    in the specification.
>>       2. The specification says that “it should be possible for a Web
>>    application bundle to remain installed when its Web Container is
>>    dynamically replaced”. Which I think it means what happens if somebody
>>    deploys WAB, then stops Tomcat container and starts Jetty container
>>    all at runtime. Does the application continue to work? Should Geronimo
>>    support this case? It is an optional feature.
>> Does that indicate each WAB will contain several plans for different
>> containers? That might require a way to distinguish the plans.
>>       3. The extender might need to track somehow which WABs were
>>    already deployed to prevent double start problems. Once some WAB is
>>    deployed and the Geronimo server is restarted, Geronimo will attempt
>>    to start the generated configuration/plugin for the WAB. Starting of
>>    the plugin will also start the actual WAB and then the extender will
>>    see the starting bundle and attempt to deploy the WAB again.
>> Yes, I think the other RFC66 implementation also need to take care of it.
>> Thanks
>> -Rex
>>    3. Annotation and resource discovery.
>>     a. The specification does not describe an exact way of discovering
>>    annotations or resources in a WAB. For example, if WAB imports some
>>    package from another bundle, are all classes in that package scanned
>>    for annotations? What about resources in META-INF directory? Are the
>>    bundles wired to the WAB checked for META-INF resources?  These are
>>    some unanswered questions that we need to keep track of.
>>     b. In certain cases (e.g. servlets 3.0, EJBs, etc.) we will need to
>>    discover all accessible classes in bundle class space that have a
>>    given annotation. For that we will need annotation discovery code that
>>    might need to know how to scan bundles based on Bundle-Classpath and
>>    possibly on Import-Packages, DynamicImport-Package, Require-Bundle,
>>    etc. depending on what the specification will say. The annotation
>>    scanning code might get even more difficult if it needs to support
>>    lazy bundles.
>>     c. Tag library scanning might require similar code as used in
>>    annotation discovery since the tld files can be included in any
>>    directory in a JAR under the META-INF directory. This also depends on
>>    what the final specification will say.
>>    4. JSP Runtime Compilation. Not sure yet what that will require
>>    (if anything).
>>    5. JNDI (RFC 142) integration. Get services from service registry
>>    using JNDI lookup using osgi:service/<interface> name (and therefore
>>    OSGi services could be injected via standard @Resource annotation).
>>    Support for RFC 142 is recommended but not required by RFC 66. This is
>>    an optional item but useful to have. There is RFC 142 implementation
>>    in Apache Aries that seems pretty complete so it just needs to be
>>    integrated in Geronimo.
>>    I think updating the WebModuleBuilders (2.b) will take the most time
>>    and effort. The annotation and resource discovery (3.b and 3.c)
>>    shouldn't be a lot of work but it's still not very well defined in the
>>    specification and that is something we need to keep track of. The good
>>    news is that we can work on all (except maybe the JSP compilation) of
>>    these items at the same time without stepping on each other's feet.
>>    Also, if the specification decides to require support for lazy bundles
>>    that will cause some fairly major changes in Geronimo. For now, I
>>    think we should assume that lazy bundles are optional and assume
>>    fairly simple rules for annotation and resource discovery code (i.e.
>>    scan jars files or directories specified on the Bundle-ClassPath
>>    only).
>>    Comments?
>>    Jarek
>> --
>> Lei Wang (Rex)
>> rwonly AT <>


View raw message