Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 2017-03-13 10:18 GMT+01:00 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 > > Am Montag, 13. März 2017 08:36:54 UTC+1 schrieb 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 >> >> >> 2017-03-13 7:46 GMT+01:00 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 >>> >>> Am Samstag, 11. März 2017 22:03:15 UTC+1 schrieb 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 2017-03-11 21:47 GMT+01:00 Stephan Siano : > Hi Achim, > > I created pull request https://github.com/ops4j/org.o > ps4j.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 > > Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: >> >> Hi Stephan, >> >> sounds great. >> I think PAXWEB-993 is fine as, those are findings on fixing that. >> >> regards, Achim >> >> >> 2017-03-11 9:59 GMT+01:00 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: 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 : > Hi, > > I have tried to enable the JSF based integration tests with the > tomcat web container. These tests fail becasue the war-jsf war doe
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 Am Montag, 13. März 2017 08:36:54 UTC+1 schrieb 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 > > > 2017-03-13 7:46 GMT+01:00 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 >> >> Am Samstag, 11. März 2017 22:03:15 UTC+1 schrieb 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 >>> >>> >>> 2017-03-11 21:47 GMT+01:00 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 Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: > > Hi Stephan, > > sounds great. > I think PAXWEB-993 is fine as, those are findings on fixing that. > > regards, Achim > > > 2017-03-11 9:59 GMT+01:00 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: >>> >>> 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 : >>> 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.Exp
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 2017-03-13 7:46 GMT+01:00 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 > > Am Samstag, 11. März 2017 22:03:15 UTC+1 schrieb 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 >> >> >> 2017-03-11 21:47 GMT+01:00 Stephan Siano : >> >>> Hi Achim, >>> >>> I created pull request https://github.com/ops4j/org.o >>> ps4j.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 >>> >>> Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: Hi Stephan, sounds great. I think PAXWEB-993 is fine as, those are findings on fixing that. regards, Achim 2017-03-11 9:59 GMT+01:00 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: >> >> 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 : >> >>> 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.jav >>> a:165)[104:org.ops4j.pax.tipi.tomcat-embed-core:8.0.14.1] >>> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.jav >>> a: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 cl
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 Am Samstag, 11. März 2017 22:03:15 UTC+1 schrieb 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 > > > 2017-03-11 21:47 GMT+01:00 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 >> >> Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: >>> >>> Hi Stephan, >>> >>> sounds great. >>> I think PAXWEB-993 is fine as, those are findings on fixing that. >>> >>> regards, Achim >>> >>> >>> 2017-03-11 9:59 GMT+01:00 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: > > 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 : > >> 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.serv
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
Hi Stephan, cool did take a look at it. Just some comments but nothing important. Feel free to merge any time. regards, Achim 2017-03-11 21:47 GMT+01:00 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 > > Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: >> >> Hi Stephan, >> >> sounds great. >> I think PAXWEB-993 is fine as, those are findings on fixing that. >> >> regards, Achim >> >> >> 2017-03-11 9:59 GMT+01:00 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: 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 : > 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.jav > a:165)[104:org.ops4j.pax.tipi.tomcat-embed-core:8.0.14.1] > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.jav > a: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].StandardCo > ntext[[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.TomcatServerWrappe > r$2$1.call(TomcatServerWrapper.java:903) > at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrappe > r$2$1.call(TomcatServerWrapper.java:899) > at org.ops4j.
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 Am Samstag, 11. März 2017 17:26:25 UTC+1 schrieb Achim Nierbeck: > > Hi Stephan, > > sounds great. > I think PAXWEB-993 is fine as, those are findings on fixing that. > > regards, Achim > > > 2017-03-11 9:59 GMT+01:00 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: >>> >>> 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 : >>> 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.Co ntextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60) at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrapper$2.start(TomcatServerWrapper.java:897) at org.ops4j.pax.web.s
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
Hi Stephan, sounds great. I think PAXWEB-993 is fine as, those are findings on fixing that. regards, Achim 2017-03-11 9:59 GMT+01:00 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: >> >> 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 : >> >>> 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.jav >>> a:165)[104:org.ops4j.pax.tipi.tomcat-embed-core:8.0.14.1] >>> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.jav >>> a: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].StandardCo >>> ntext[[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.TomcatServerWrappe >>> r$2$1.call(TomcatServerWrapper.java:903) >>> at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrappe >>> r$2$1.call(TomcatServerWrapper.java:899) >>> at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithCl >>> assLoader(ContextClassLoaderUtils.java:60) >>> at org.ops4j.pax.web.service.tomcat.internal.TomcatServerWrappe >>> r$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(Http >>> ServiceProxy.java:444) >>> at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisito >>> rWC.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$WebA >>> ppDependencyListener.register(
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 > > : > >> 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$WebAppDependencyList
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 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 > > : > >> 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.
Re: [PAXWEB-993] JSF Integration Tests with Tomcat
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 : > 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
