Thanks for your reply! I still have a concern about lazy activated bundle in current implementation. In BundleTrackerCustomizer, a lazy activated bundle will be deployed twice(deployed->undeployed->deployed), because of the state transition of the bundle. To avoid this, I suggest to create a separated BundleTracker and BundleTrackerCustomizer for lazy-activated Starting bundles. Then original BundleTrackerCustomizer can only deploy and undeploy Active bundle, while the new BundleTrackerCustomizer only deploys the lazy-activated Starting bundles.
Any comments? 2010/1/25 Rick McGuire <[email protected]> > On 1/25/2010 8:06 AM, Delos wrote: > > It's really great news! > > But I have some questions about current implementation.Just want to learn > more from it. > > 1) I found only active and starting bundles are taken into account in > current implementation. What about resolved bundles? > > > That's the requirement of the RFC66 specification. Resolution is a > requirement for a bundle to transition to the active or starting states, but > the extender is not supposed to take action until one of those states is > seen. It's the same way with Blueprint. > > > 2) For lazy activiated bundles, only starting bundles will be deployed.But > in RFC 66, it said "A bundle that has a lazy activation policy should not be > transitioned to the STARTING state by the web extender unless a request is > made that requires a class to be loaded." Does the implementation violate > the document? > > > This is a statement that the extender should not explicitly force the > bundle into a started state, but rather should leave that transition to one > triggered by a class load. If the processing the extender needs to perform > in processing the bundle results in a triggering class load, that's ok. > > > 3) In RFC 66, static content can be requested without starting a WAB. It's > not in the TODO file. Do you have any idea for it? I'm not sure if > configuration of WAB can become accessible before actually it's started. > > > The note about static content is marked as an optional feature. For a lot > of processing, it would not be possible to achieve deployment without > performing a classload. > > > Thanks! > > 2010/1/24 David Jencks <[email protected]> > >> great news! congratulations! >> >> david jencks >> >> >> On Jan 23, 2010, at 6:55 PM, Jarek Gawor wrote: >> >> Hi all, >>> >>> Today I checked in an initial version of the rfc66 extender that can >>> actually deploy WABs with simple servlets and jsps. There is still >>> much work to be done (for example updating the Jasper module builder >>> to work with Bundles) but simple stuff seems to be working. In fact >>> with David's recent JNDI (rfc142) integration work I was able to >>> deploy the Aries blog sample in Geronimo. >>> >>> Here are the steps I took to run the sample: >>> >>> 1) Build latest blog sample in Aries >>> 2) Build latest Geronimo trunk >>> 3) cd plugins/wab/web-tomcat-server/target/assembly (or >>> web-jetty-server if you prefer) >>> 4) Create database for blog sample using blogDB.sql from blog sample: >>> >>> java -cp >>> repository/org/apache/geronimo/bundles/derby-all/10.4.2.0-SNAPSHOT/derby-all-10.4.2.0-SNAPSHOT.jar >>> org.apache.derby.tools.ij >>> <aries>/samples/blog-sample/blog-assembly/target/blogDB.sql >>> >>> 5) Move created blogDB directory to >>> plugins/wab/web-tomcat-server/target/assembly/var/derby >>> >>> 6) Start server: >>> >>> ./bin/geronimo -l >>> >>> 7) Install and start all the blog sample bundles (blog-api-1.0.0.jar, >>> blog-persistence-1.0.0.jar, blog-1.0.0.jar, blog-servlet-1.0.0.jar) >>> using the karaf console. >>> >>> 8) Once you start the blog-servlet-1.0.0.jar bundle, the WAB will be >>> deployed and you should be able to access http://localhost:8080/blog. >>> And if everything is running right you should be able to add new blog >>> entries, etc. >>> >>> Enjoy, >>> Jarek >>> >> >> > > > -- > Best Regards, > > Delos > > > -- Best Regards, Delos
