[PAXWEB-993] JSF Integration Tests with Tomcat

[Stephan Siano]

Hi,

I have tried to enable the JSF based integration tests with the tomcat web container. These tests fail becasue the war-jsf war does not start.

The first issue I see is that the expression factory cannot be found.

javax.el.ELException: Unable to find ExpressionFactory of type: org.apache.el.ExpressionFactoryImpl
    at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:165)[104:org.ops4j.pax.tipi.tomcat-embed-core:8.0.14.1]
    at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:104)[104:org.ops4j.pax.tipi.tomcat-embed-core:8.0.14.1]


I have looked into the jetty code and they replace the classloader for the context (which is a ResouceDelegatingBundleClassloader for the war) with a newly instantiated ResourceDelegatingBundleClassloader, which uses the pax-web-jetty-bundle classloader as a parent classloader. If I do the same in pax-web-tomcat (with pax-web-tomcat-bundle as a parent classloader) el works, but now I get another error:

org.ops4j.pax.web.pax-web-runtime[org.ops4j.pax.web.service.internal.HttpServiceStarted] : Exception finalizing HttpContext registration
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[[war-jsf-sample]-org.ops4j.pax.web.extender.war.internal.WebAppWebContainerContext]]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$2$1.call(TomcatServerWrapper.java:903)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$2$1.call(TomcatServerWrapper.java:899)
    at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$2.start(TomcatServerWrapper.java:897)
    at org.ops4j.pax.web.service.internal.HttpServiceStarted.end(HttpServiceStarted.java:1137)
    at org.ops4j.pax.web.service.internal.HttpServiceProxy.end(HttpServiceProxy.java:444)
    at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.end(RegisterWebAppVisitorWC.java:398)
    at org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:656)
    at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.register(WebAppPublisher.java:228)
    at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:173)
    at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:129)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
    at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
    at org.ops4j.pax.web.extender.war.internal.WebAppPublisher.publish(WebAppPublisher.java:98)
    at org.ops4j.pax.web.extender.war.internal.WebObserver.deploy(WebObserver.java:217)
    at org.ops4j.pax.web.extender.war.internal.WebObserver$1.doStart(WebObserver.java:172)
    at org.ops4j.pax.web.extender.war.internal.extender.SimpleExtension.start(SimpleExtension.java:59)
    at org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.lambda$createExtension$0(AbstractExtender.java:277)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: 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 check 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:305)
    at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:225)
    at javax.faces.webapp.FacesServlet.init(FacesServlet.java:115)
    at org.apache.catalina.startup.Tomcat$ExistingStandardWrapper.loadServlet(Tomcat.java:868)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$OsgiExistingStandardWrapper$1.call(TomcatServerWrapper.java:289)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$OsgiExistingStandardWrapper$1.call(TomcatServerWrapper.java:284)
    at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
    at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$OsgiExistingStandardWrapper.load(TomcatServerWrapper.java:282)
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4969)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5255)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    ... 29 more

Do you have any idea, what is wrong now?

Best regards
Stephan

[Achim Nierbeck]

Hi Stephan, 

the second exception you also get with Jetty ... never found the reason for it :/

did you check if by any chances the JSF pages actually do work? 

regards, Achim 

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Apache Member

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
blog <http://notizblog.nierbeck.de/>

Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master 

[Marc Schlegel]

Welcome to the club :-)

The second exception seems to occur with MyFaces in all OSGi environments. I can reproduce this also on a IBM Liberty Profile when stopping a WAB with JSF-support.

Regarding the ExpressionFactory: I've also spent some time on this issue and couldnt get it to work yet. We hoped that the issue could be fixed by PAXWEB-929 which required a Manifest-change in MyFaces, but even with the new MyFaces version the problem persists. If I remember correct, there might be a way if we release a new tipi-tomcat-embed-el artifact but this is more or less a lucky guess. Tomcats packages seem to be a total mess...at least to me.

regards

Marc

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephan Siano]

Hi Achim,

The servlet is not working if the jfaces Excepton is thrown during startup of the servlet context.

However, I think I got this running now. There were actually multiple issues that were preventing the tests from running (at least the one I checked for now, I hope the others are easier):
1. el-Support was not running in tomcat. The el-lookup only works if the pax-web-jsp bundle (where the el-Implementation is located) is in the classpath. I copied some code from the jetty implementation that sets a parent classloader to the conecxt and imported the javax.el bundles in the pax-web-tomcat bundles as optional dependencies for that (the same imports as in pax-web-jetty).
2. The jfaces library creates an internal map for the factories. The key for the map is the thread context classloader, so the lookup will fail if the initialization of the factories is done with a different thread context classloader than the initi call, you see the second exception I posted intially. It also means that the operation that is attempted fails (which may be less critical for other operations than the init call). Removing two thread context class loader changes from the code made the servlet finally work. Unfortunately I don't know why these class loader changes were there in the first place, so I might have broken something else in the process (need to have a look about this).
3. The tests themselves also had issues: Tomcat does not support welcome files (so the index.jsp has to be called directly). Furthermore the test comcat server is running with a different port than the itest-jetty server, but the second server call in one of the tests was to the jetty port (so this can never have worked).

If I get this running smoothly, do I cfeate the pull request for PAXWEB-993 (as it also enables the JSF tests, or do I create a new JIRA task (because it actually also fixes JSF support with tomcat).

Best regards
Stephan

Am Freitag, 10. März 2017 16:58:58 UTC+1 schrieb Achim Nierbeck:

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Achim Nierbeck]

Hi Stephan, 

sounds great. 

I think PAXWEB-993 is fine as, those are findings on fixing that. 

regards, Achim 

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephan Siano]

Hi Achim,

I created pull request https://github.com/ops4j/org.ops4j.pax.web/pull/77 for the change. Could you have a look? I am not absolutely sure about the things I am doing to the class loaders (but JSF will not run without these changes).

Best regards
Stephan

[Achim Nierbeck]

Hi Stephan, 

cool did take a look at it. 

Just some comments but nothing important. 

Feel free to merge any time. 

regards, Achim 

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephan Siano]

HI Achim,

concerning your question about the welcome file support: I can confirm that welcom file configurations do not work (at least not configured in web.xml). That's the reason why the majority of the remaining tomcat integration tests do not run.

In the moment, I am a bit at loss, why this does not work. Is there any coding concerning the welcome file support in pax-web-jetty?

Best regards
Stephan

[Achim Nierbeck]

Hi Stephan, 

we will need a new Issue for that then. 

Though I'm wondering if that one slipped till now or if it is some sort of regression. 

regards, Achim 

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephan Siano]

Hi Achim,

I created https://ops4j1.jira.com/browse/PAXWEB-1072 for it.

I don't think it ever worked, there is just no coding for it in TomcatResourceServlet. I will see if I can do something about it.

Best regards
Stephan

[Achim Nierbeck]

Hi Stephan ... 

doh' 

that would explain it ... I'm sorry that Tomcat hasn't received the love it should have ... but thanks for good work :-)

regards, Achim

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.