2.1 is part of GF 3.1.
PetrJ if you agree I think we should push this to NB7.0
I already worked on it last week, but it seems that there is GF or JSF issue which induce exception by deploying project with used 2.1 libraries on project CP onto GF 3.1 server. In the past I used JSF libraries which were bundled with GF because it wasn't officially released so at least I can try it out with publicly released libraries today again.
BTW, see: http://java.net/jira/browse/JAVASERVERFACES-1973
It's still the same with the released version (it's the same build which I used before 2.1.0-b11). I'm getting this exception by deploying onto GF v3.1FCS:
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class com.sun.faces.application.ServletContextSensitiveSingletonStore
Could also someone else try it, please? Just for assurance.
I can also reproduce the deployment error using the following steps:
1. Register GF 3.1
2. Create new EE 6 Web Project (Ant-based) with GF 3.1 target
3. While creating, check JSF framework, and specify "Create New Library" - specify the Mojarra 2.1 installation as the JSF folder.
4. Run the application
BTW, I think the root cause of the deployment exception is:
Caused by: java.lang.NoSuchMethodException: com.sun.faces.application.ServletContextSensitiveSingletonStore.<init>()
A similar exception happens when using Tomcat 7.0.6:
Next, one other problem with including Mojarra 2.1 in NetBeans is that it looks like it requires Servlet 3.0 container, so it will not work with Tomcat 6. Tomcat 6 is still very widely used.
(In reply to comment #3)
> Next, one other problem with including Mojarra 2.1 in NetBeans is that it looks
> like it requires Servlet 3.0 container
Where did you read that? I cannot find any mention about it in changelog for 2.1 (http://jcp.org/aboutJava/communityprocess/maintenance/jsr314/314ChangeLog.html). I would also not expect a maintenance release to change project dependencies.
Compare this to: http://javaserverfaces.java.net/nonav/rlnotes/2.0.4/releasenotes.html
I see. Thanks. Nevertheless the version of Tomcat bundled with the IDE is 7.0.6 and that one has Servlet 3.0. If some people are still using Tomcat6 then well that's there issue, no? They can either upgrade their Tomcat or stick with JSF 2.0 (which they can download from inet). As you can see I do not feel that concerned about them. :-)
(In reply to comment #3)
> A similar exception happens when using Tomcat 7.0.6:
Btw. I'm not able to reproduce the issue on Tomcat 7.0.4 or 7.0.10. Which make sense as Tomcat does not contain any other JSF impl. I think the problem in GF is likely clash between bundled JSF and one packaged in WAR. How do you do it?
Sorry, not fully understand...how do we do what?
For first time I discovered the issue because I had done locally changes for bundling JSF2.1 into NB but it worked (or better didn't work) in the same way as we are adding new JSF libraries into IDE. So not important how the 2.1 libraries were added to the project but since project has them on CP there is no chance to deploy project on Tomcat7.0.6 or GF3.1. BTW, today I tried it out in Tomcat 7.0.6 as well and I'm facing the same issue as Petr before.
I found also similar issue:
There is attached some patch which could fix these troubles, but I don't think that it would be proper way to patch something manually into release build and then bundle it when it wasn't still confirmed by Ed that it's correct patch (without any regressions). I will comment into the first (GF) issue if the patch could be added into code and could be done new release build like JSF2.1-b12.
(In reply to comment #7)
> Sorry, not fully understand...how do we do what?
Nevermind. I was not able to reproduce it on Tomcat but if you and Petr are and according to mojarra issue other people are as well then everything is OK and I do not need to reproduce it.
Let's postpone implementation of this issue till all problems in GF anf JSF are resolved.
If you would like to reproduce it, try our steps with T7.0.6 or GF3.1FCS. I believe that you will be experiencing the same then.
I got new comments from Ed into http://java.net/jira/browse/JAVASERVERFACES-1973 that it's perhaps duplicate of GlassFish issue and JSF issue. Anyway there are perhaps two problems:
1, deploying to GlassFish FCS (GLASSFISH-15985, JAVASERVERFACES-xxxx)
2, deploying to Tomcat 7.0.6 (JAVASERVERFACES-1937)
Both servers are bundled by NB. From both issues it seems that GF is already fixed in FCS and JSF will not take care for 2.1.0 release and everything will be fixed just for 2.1.1. From these facts I would suggest to wait with JSF2.1 until 2.1.1 release - it would perhaps mean to postpone this issue to NB 7.0.1.
I agree with postponing this.
Ok, changing from DEFECT to TASK so it does not show up on the NB 7 bug dashboard.
(In reply to comment #10)
> I agree with postponing this.
Agree, but not through TASK, just applied the waiver, so it will be on eyes for 7.0.1.
BTW: we changed bundled Tomcat to 7.0.11
I tried again easiest use case (create web app with JSF framework + run) with newly released JSF2.1.1 against:
- GlassFish 3.1.1-b01
- Tomcat 7.0.6
Both cases worked well without exception by deploying now, so when NB7.0.1 will be bundled with GF3.1.1 I think that upgrade of JSF to 2.1.1 could be done.
Mariane, is it allowed to refresh libraries for 7.0.1 release? From previous experiences I'm quite sure that it will require also few changes into JSF Editor, but at least last time all changes were really minor (as far as I can remember there were changes of some parameter types from URL to URI and code around).
Marek, could you take a look on attached patch, please?
It seems that JSF was fixing performance issue (http://java.net/jira/browse/GLASSFISH-14430) and switched on some places of its code from URL to URI classes.
BTW, I assumed that is parsed only bundled JSF library there. Is it so? In another cases I can throw the patch away and start from scratch. Anyway I believe that you can give me the best response. Thanks.
Created attachment 107874 [details]
> BTW, I assumed that is parsed only bundled JSF library there. Is it so? In
> another cases I can throw the patch away and start from scratch. Anyway I
> believe that you can give me the best response. Thanks.
The patch looks ok to me. Thanks.
As for the question: Yes, the facelets libraries parsing code is supposed to run against the bundled jsf implementation, see FaceletsLibrarySupport:247, though it is not very reliable as I look at it now... At least your change won't make any difference so feel free to integrate.
Thanks a lot Marek for your review.
Fixed/integrated as http://hg.netbeans.org/web-main/rev/a292c424227f.
BTW, included version is 2.1.1-b04 (JSF 2.1.1 release) and were tested deployments onto last GF 3.1.1 (b01) and Tomcat 7.0.11.
Integrated into 'main-golden', will be available in build *201104290000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Martin Fousek <firstname.lastname@example.org>
Log: #196456 - upgrade JSF library bundled with NetBeans to version 2.1