Hi Jarek,

It would be great if you could file your problems as issues in the jira.
Then I will take a look at them!

Thanks,
Jakob

2010/2/10 Jarek Gawor <[email protected]>

> 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
>

Reply via email to