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 <[email protected]> > 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> >> > > -- Ivan
