Hi Harald, comments inline
2012/8/9 Harald Wellmann <[email protected]>: > Glad to see that Pax Web 2.1.0 has arrived and we're now heading for 3.x :-) > :) > There are more news which require some change of plans: > > - The release vote for OpenWebBeans 1.1.5 is running. > - The startup sequence of Jetty under Pax Web differs from vanilla Jetty, > which causes problems for the CDI listener. > > OpenWebBeans 1.1.4 had a bug which was a blocker for some non-web features > already implemented in Pax CDI 0.2.0-SNAPSHOT and tested with an OWB > snapshot. > > So once OWB 1.1.5 is out, I think it's best to roll up a Pax CDI 0.2.0 > without any web support (i.e. all modules depending on either Weld or Pax > Web still disabled by a Maven profile). that sounds like a good plan :) > > Web support will then be a target for Pax CDI 0.3.0, which will depend on a > cdi branch of Pax Web 3.x. > > At the moment, I do think the branch will be necessary because of the > startup issue. well if we don't need another branch I'm more then fine. I just want to prevent that trunk goes into a "instable" state. > > Some details on this: I'm trying to hook an adapted version of Weld's plain > old servlet listener into Pax Web by means of a ServletContainerInitializer. > This listener decorates Jetty's ServletHolder to inject CDI beans into > servlets upon instantiation. > > The problem is, by the time the listener gets invoked, the servlets must be > defined but not instantiated, which is not the case at the moment. > > As far as I can see, in vanilla Jetty, a servlet context gets started only > _after_ all servlets, filters and listeners etc. have been registered, > whereas in Pax Web, the context gets started as soon as the first servlet is > registered (provided an HttpService is available). > yeah I've experience the same for the jsf 2.0 + myfaces issues. > I don't see how to change the startup sequence with the existing APIs and > I'm not sure about the impact of such a change on existing functionality. > this is something we really have to be carefull about cause to my understanding the way it works right it's the way specified in the osgi spec. (might be wrong though) will need to read that again > Maybe there's an easy way out, or a totally different approach - any ideas > are welcome... > I was also thinking about not starting the http-context during creation time and starting all at once after all is set. Just something I was thinking aloud :) Though this probably needs a bigger re-design. This has to be done very carefully and probably backed with lots of unit/itests :) regards, Achim > Best regards, > Harald > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/> _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
