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).
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.
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).
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.
Maybe there's an easy way out, or a totally different approach - any
ideas are welcome...
Best regards,
Harald
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
