myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <jga...@gmail.com>
Subject Re: MyFaces in OSGi
Date Thu, 11 Feb 2010 05:19:15 GMT
Ok, sure. For now I created MYFACES-2548 with a proposed patch. I
might open one more bug for the
AnnotationConfigurator.getMyfacesImplJarFile() issue once I do little
more testing.

Jarek

On Wed, Feb 10, 2010 at 5:51 PM, Jakob Korherr <jakob.korherr@gmail.com> wrote:
> 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 <jgawor@gmail.com>
>>
>> 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
>
>

Mime
View raw message