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 <[email protected]> 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 <[email protected]> > 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 <[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 >> >> >
