ops4j-issues
commented
8 years ago Marc Schlegel commented
Wrapping the call to context.addListener(listener) with a try-catch makes webapp-struts available because the deployment now does not fail.
JasperInitializer line 108
// add any listeners defined in TLDs
for (String listener : scanner.getListeners()) {
try {
context.addListener(listener);
}catch(RuntimeException e){
if(e.getCause() instanceof ClassNotFoundException){
log.error("Could not add listener to context: {}", e.getMessage());
}else{
throw e;
}
}
}But that's just solving the symptom. The problem is that the generic solution with the TLDs does not take classes into account that might not be imported/wired.
A possible solution might be the osgi-capability-model: only when a webapp requires the capability "jsf" it gets the tld added from the bundle providing the capability "jsf". But this would require that the providers must enhance their metadata with a "standard" capability...
Marc Schlegel created PAXWEB-953
I have two webapp-bundles, one uses JSF, the other Struts. The struts-bundle wont start because it cannot find org.apache.myfaces.webapp.StartupServletContextListener
Reason: org.ops4j.pax.web.jsp.TldScanner scanns all bundles for Tag-Libraries. The result is mapped to each webapp.
Now myfaces-impl contains myfaces_core.tld which registers a listener org.apache.myfaces.webapp.StartupServletContextListener. This listener is needed for webapp-jsf, but not for webapp-struts. When webapp-struts is trying to add the listener, it fails with ClassNotFoundException, which is correct.
log
This issue should be reproducible without Struts. All it takes is a valid jsf-webapp and a simple jsp-webapp.
Affects: 4.2.4 Fixed in: 4.2.5, 6.0.0 Votes: 0, Watches: 2