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:
>
> 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 
>
>
> 2017-03-10 16:46 GMT+01:00 Stephan Siano <stepha...@sap.com <javascript:>>
> :
>
>> 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
>>
>> -- 
>> -- 
>> ------------------
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com <javascript:>
>>
>> --- 
>> 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+un...@googlegroups.com <javascript:>.
>> 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 
>
>

-- 
-- 
------------------
OPS4J - http://www.ops4j.org - ops4j@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to