Rex Wang wrote:


2010/1/14 Jarek Gawor <[email protected] <mailto:[email protected]>>

    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 extender...it 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 apache.org <http://apache.org>

Reply via email to