That won't help with the jars embedded in the war bundle, they are already in the same classloader.
I think the problem is likely to be that jetty/jasper/* doesn't know how to scan bundles-with Bundle-Classpath for resources. If you want to try to convince jetty to do this I'd recommend using xbean-finder. A more likely solution might be to copy the tld files into WEB-INF/classes/META-INF and hope that jetty/jasper/myfaces finds them there. thanks david jencks On Mar 6, 2011, at 12:40 PM, Achim Nierbeck wrote: > Hi Dan, > > one workaround for the tlds in another bundle (not your own war bundle) > is to add a > require bundle in the manifest entry of your war-bundle to the one > providing the tlds. > This way your "merge" the classloader of those two bundles and the tlds > provided by the > "external" bundle are seen as tlds of the war bundle. (hope I made that > clear :) ) > > Greetings, Achim > >> hi Achim >> >> Ouch, I have a long way to go. >> >> do you know the exact place of code to get tld scanning working for >> embedded war file? >> >> Or is it better to make JSF feature to be consumed by JSF app? not >> sure if this would work without tld scanning working >> >> >> Thanks >> >> -Dan >> >> On Sat, Mar 5, 2011 at 11:49 AM, Achim Nierbeck <[email protected]> >> wrote: >>> Hi Dan, >>> >>> There is only tld scanning for tlds in the corresponding bundle/war, but no >>> tld scanning in bundles which are imported >>> http://issues.ops4j.org/browse/PAXWEB-86 >>> >>> So there is some sort of scanning for tlds. >>> >>> But for JSF there is also http://issues.ops4j.org/browse/PAXWEB-255 >>> where the values of a form aren't working. >>> >>> Greetings, Achim >>> >>> >>> Hi Achim, >>> >>> According this post >>> http://karaf.922171.n3.nabble.com/Apache-Karaf-amp-WAR-JSF-td2465980.html#a2472594, >>> you posted a small example JSF 1.x example war file working wth Karaf. >>> >>> In that war file, you see myfaces-impl's tld files get copy to war's >>> WEB-INF/classes/META-INFO, and then you add the copied tld classpath >>> to MANIFEST's bundle-classpath >>> >>> isn't it some type of tld scanning ? >>> >>> At this moment, i am going down that route with hope to get my >>> standalone JSF war working 'further'. Still struggling to get my >>> MAFIFEST file generated. >>> >>> Thanks >>> >>> -D >>> >>> >>> >>> >>> >>> On Sat, Mar 5, 2011 at 9:13 AM, Achim Nierbeck <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> no pax-web does no pecific tld scanning, if some enhancements are needed >>> please file a issue there :) >>> Regarding the jasper part, that is included inside the pax-web-jsp bundle. >>> This one does export it. >>> >>> Regards, Achim >>> >>> I'd guess that neither jetty-7 nor pax web implement tld scanning so it >>> works in osgi, but I certainly haven't looked into it. tld scanning has >>> certainly caused problems in pre-osgi geronimo in the past. >>> >>> BTW where does jsp support come from? I don't see any jasper bundles >>> listed anywhere in the features.xml.... maybe I missed something. >>> >>> thanks >>> david jencks >>> >>> On Mar 4, 2011, at 9:30 PM, Dan Tran wrote: >>> >>> sorry about the noise, but I found another fact here: >>> >>> StartupServletContextListener is defined under >>> myface-impl-xxx.jar/META-INF/myfaces-core.tld and jsf tags are under >>> some other tld files under same location. >>> >>> This means karaf web container does not automatically load tld files >>> under JSF implementation META-INF resources( both myfaces and mojarra >>> see the same thing here ). This explains why >>> the initial listener is loaded which causes FacesServlet init >>> failures and JSF tag loading issues >>> >>> What should I do next to get Karaf to fix this issue? >>> >>> Thanks >>> >>> >>> >>> On Fri, Mar 4, 2011 at 9:17 PM, Dan Tran<[email protected]> wrote: >>> >>> I found the same exact issue with a simple myface 2.0.x example war >>> file >>> http://repo2.maven.org/maven2/org/apache/myfaces/commons/myfaces-commons-examples20/1.0.1/myfaces-commons-examples20-1.0.1.war >>> >>> The error spits out from myface seems to give some hint >>> >>> 21:06:14,178 | WARN | raf-2.2.0/deploy | /mfe >>> | .eclipse.jetty.util.log.Slf4jLog 50 | 193 - >>> org.eclipse.jetty.util - 7.2.2.v20101205 | unavailable >>> java.lang.IllegalStateException: No Factories configured for this >>> Application. This happens if the faces-initialization does not work at >>> all - make sure that you properly include all configuration settings >>> necessary for a basic faces application and that all the necessary >>> libs are included. Also che >>> ck the logging output of your web application and your container for >>> any exceptions! >>> If you did that and find nothing, the mistake might be due to the fact >>> that you use some special web-containers which do not support >>> registering context-listeners via TLD files and a context listener is >>> not setup in your web.xml. >>> A typical config looks like this; >>> <listener> >>> >>> <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> >>> </listener> >>> >>> at >>> javax.faces.FactoryFinder.getFactory(FactoryFinder.java:172)[243:mfe:0.0.0] >>> at >>> javax.faces.webapp.FacesServlet.init(FacesServlet.java:112)[243:mfe:0.0.0] >>> >>> >>> >>> Even if I add the listener to my web.xml, then I ran into jsf tag >>> loading problem. >>> >>> I also attempt the debug the issue with both myfaces and mojarra, both >>> indicate a bunch of jsf factories are not inititialized and there for >>> javax.faces.webapp.FacesServlet bails out >>> >>> Look like this is karaf/felix class loader problem >>> >>> -D >>> >>> >>> >>> >
