Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource("META-INF/foo");
if (foo == null) {
foo = getClass().getClassLoader().getResource("META-INF/foo");
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
