You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/02/10 20:25:00 UTC
MyFaces in OSGi
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
Re: MyFaces in OSGi problem
Posted by arnold4sho <tu...@hotmail.com>.
Hi
I have problems running JSF in an OSGi environment. I am using jetty web
container and equinox to provide the OSGi functionality. The structure of my
application is as follows:
The first bundle has all the JSF libs, web.xml and a config.xml. It looks as
the following:
webapplication1
----src/main/java
-------de/package
----------Activator.java
----------JSFResolver.java
----src/main/resource
------ WebContent
----------META-INF
-------------face-config.xml
--------------web.xhtml
----------start.xhtml
-----------include.xhtml
----libs (containing all JSF required Jars)
The structure of the second bundle is as follows:
webapplication2
---src/main/java
------de/package
----------Bean.java
---src/main/resource
------META-INF
---------face-config.xml
------WebContent
---------index.xhtml
When running the application of equinox, the webapplication1 is the main
bundle where all the browser requests are sent to. In the second bundle, the
'index.xhtml' file can be retrieved the by first bundle upon request. The
'index.xhtml' in bundle 2 gets its values and properties from the
'Bean.java' in bundle 2. The problem comes when i request the 'index.xhtml',
the Bean.java class is not found. I think this is because the class loader
of bundle1 cannot find it, it has no knowledge of it. So i would like to ask
if anyone knows how to solve this problem. If so please do assist me, i have
tried all the possibilities i had.. I have provided my
http://old.nabble.com/file/p27887378/workspace_current.rar
workspace_current.rar bundles as attatchments.
Is it infact possible to have JSF run on multiple bundles using the same
FaceletsContex? Can i be able to have seperate faces-config.xml files in
each bundle, which can all be connected other faces-config.xml in other
bundles? Can anyone please provide me a solution. Sample code would help.
thanks
Arnold
--
View this message in context: http://old.nabble.com/MyFaces-in-OSGi-tp27536652p27887378.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: MyFaces in OSGi
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Really it could be a big help if you could provide an example about how is
your setup in this case. It is very difficult to reproduce this cases
without a proper example and configuration. I only was able to run myfaces
in osgi using spring dm (which solves all those issues doing some things
nasty from osgi point of view) so I could help better if we have some proper
test case for suppor it. It could be a big help to know the "hacks" to be
done for handle classloading, load resources and so on in a osgi compatible
way.
regards,
Leonardo Uribe
2010/2/22 Jarek Gawor <jg...@gmail.com>
> Hi,
>
> I was wondering if somebody could take a look at MYFACES-2550. Also,
> the published snapshot of MyFaces core is a little old.
>
> Thanks,
> Jarek
>
> On Thu, Feb 11, 2010 at 12:49 PM, Jarek Gawor <jg...@gmail.com> wrote:
> > Thanks for fixing MYFACES-2548! I just opened MYFACES-2550 for the
> > AnnotationConfigurator.getMyfacesImplJarFile() issue.
> >
> > Thanks again,
> > Jarek
> >
> > On Thu, Feb 11, 2010 at 12:19 AM, Jarek Gawor <jg...@gmail.com> wrote:
> >> 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 <ja...@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 <jg...@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
> >>>
> >>>
> >>
> >
>
Re: MyFaces in OSGi
Posted by Jarek Gawor <jg...@gmail.com>.
Hi,
I was wondering if somebody could take a look at MYFACES-2550. Also,
the published snapshot of MyFaces core is a little old.
Thanks,
Jarek
On Thu, Feb 11, 2010 at 12:49 PM, Jarek Gawor <jg...@gmail.com> wrote:
> Thanks for fixing MYFACES-2548! I just opened MYFACES-2550 for the
> AnnotationConfigurator.getMyfacesImplJarFile() issue.
>
> Thanks again,
> Jarek
>
> On Thu, Feb 11, 2010 at 12:19 AM, Jarek Gawor <jg...@gmail.com> wrote:
>> 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 <ja...@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 <jg...@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
>>>
>>>
>>
>
Re: MyFaces in OSGi
Posted by Jarek Gawor <jg...@gmail.com>.
Thanks for fixing MYFACES-2548! I just opened MYFACES-2550 for the
AnnotationConfigurator.getMyfacesImplJarFile() issue.
Thanks again,
Jarek
On Thu, Feb 11, 2010 at 12:19 AM, Jarek Gawor <jg...@gmail.com> wrote:
> 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 <ja...@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 <jg...@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
>>
>>
>
Re: MyFaces in OSGi
Posted by Jarek Gawor <jg...@gmail.com>.
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 <ja...@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 <jg...@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
>
>
Re: MyFaces in OSGi
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
maybe bernhard can help as well.
he brought up [1] the topic some months ago.
regards,
gerhard
[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg39068.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/10 Jakob Korherr <ja...@gmail.com>
> 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 <jg...@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
>>
>
>
Re: MyFaces in OSGi
Posted by Jakob Korherr <ja...@gmail.com>.
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 <jg...@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
>