Am 26.07.2012 22:26, schrieb Achim Nierbeck:
The next major step I'd like to take is to make this work for WABs,
in combination with Pax Web.
just one side node you are starting to make my day since this has
been my top 1 on my wish list, thank you :D
Glad to hear that :-)
To make this work, it might be sufficient for Pax Web to allow a
customizer to
- add a ServletContextListener (or a ServletContextInitializer) -
replace the classloader to be used as web app classloader
either way sound good, but the first one gives me a better "feeling"
about it.
Yes, I meant to say that *both* will be required, but I'm not really
sure at this moment.
One thing though right now we do have a issue with this part of
"automagically" discovering ServletContextInitalizers for the
Initializers of MyFaces. Reason still unknown has to be some
classloader issue which is really hard to trace right now.
It seems I've run into the same issue in my local sandbox, and I think I
can explain it:
The problem is that the javax.servlet JAR is on the application
classpath, at least when running the integration tests under Pax Exam,
so the test probe loads ServletContainerInitializer from the application
classloader whereas the web bundle loads it from the Geronimo Servlet
JAR, which results in a class cast exception. This can be fixed by
adding systemPackage("javax.servlet;version=3.0.0") to the test
configuration.
The question is whether or not a similar situation exists in the Karaf
context where the problem occured. Or if there is any other setup
without Pax Exam exhibiting the problem.
I'm a complete dummy regarding Karaf, so I don't really know how to
reproduce the problem from the brief information in PAXEXAM-382.
After fixing the service lookup, I noticed some more issues:
There is an endless loop caused by inappropriate use of
ServiceLoader.iterator(). Calling this multiple times restarts the
iterator in each iteration.
The next thing is a NullPointerException in
HttpServiceStarted.registerServletContainerInitializer():
sci.getClasses() may be null (see Javadoc).
All in all, I'm having a hard time debugging Pax Web without a decent
OSGi console and without logging (caused by Felix complaining about a
classloader conflict for log4j), so I'd like to add an Equinox profile
to the itest project.
(I locally replaced Felix by Equinox, which not only gave me a console
to work with but also made the logging conflicts vanish...)
All of this is completely independent of Pax CDI, so if noboby objects,
I'd like to commit these changes to master.
Sooner or later, there will be some experimental changes related to Pax
CDI - would it be ok to commit these to a new "cdi" branch in the
official Pax Web repo, or should I clone the repo and work on the clone?
Best regards,
Harald
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
