2010/1/18 David Jencks <[email protected]> > > On Jan 18, 2010, at 12:33 AM, Rex Wang wrote: > > > > 2010/1/18 Jarek Gawor <[email protected]> > >> On Thu, Jan 14, 2010 at 9:47 PM, Ivan <[email protected]> wrote: >> > 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 ? >> >> Right now I think the idea is to modify our deployment process to 1) >> work directly with a Bundle object and 2) not to create any additional >> or temporary bundles during deployment and just create a configuration >> object that the extender can load/start/stop. >> > > That makes me to think about if we can make our Geronimo plugins more > extender-like. Such as Ivan said, currently we need deploy a car twice in > order to firstly install all the depending bundles and generate the > config.ser, then using the config to instantiate gbeans. This is very > different to the RFC66 WABs. > Before starting the WAB, extender even does not know the existence of it. A > WAB is considered as a normal bundle with other bundles. So our extender > need track the WAB starting and generate config.ser and instantiate gbeans > all in one step. Hence, what is the standard way to install a war? I see two > approaches as follows: > 1. The current way of making the war a geronimo-lize war before start it. > 2. Convert the war to WAB and deploy the WAB, after start it, extender will > find it and generate geronimo information. That is what RFC66 spec required. > I think we should choose the #2. > > > I am not yet convinced that rfc 66 and #2 are good ways to deploy web apps. > We want to support them but that doesn't mean they are ideal. The main > problem I have with rec66 like methods is that you end up with extra data > needed to start the geronimo plugin-ized WAB that isn't in the WAB. So, you > can't just copy the plugin into another server, you have to go through > deployment via the rfc66 extender on every server. > Sorry, I am not very understand this. Do you indicate the server-farming scenario, which firstly deploy an app and need to farm to other servers?
-Rex > This pretty much negates most of the good points about geronimo plugins. > We might decide this is the direction we want to go in, but we should talk > about it in detail. > > thanks > david jencks > > > > -Rex > > >> >> > 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 ? >> >> We could store that information in the bundle private storage area. If >> the information is already there and the bundle hasn't been updated we >> could reuse the information and skip the deployment. >> >> > 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. >> >> I'm not worried about this now but potentially yes. Maybe this won't >> even be an issue. >> >> Jarek >> >> > >> > 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 >> > >> > > > > -- > Lei Wang (Rex) > rwonly AT apache.org > > > -- Lei Wang (Rex) rwonly AT apache.org
