Bug 196456

Summary: upgrade JSF library bundled with NetBeans to version 2.1
Product: javaee Reporter: David Konecny <dkonecny>
Component: JSFAssignee: Martin Fousek <marfous>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P2 CC: mfukala, mmirilovic, pjiricka
Version: 7.0   
Target Milestone: TBD   
Hardware: All   
OS: All   
URL: http://download.java.net/maven/2/com/sun/faces/jsf-api/2.1.0/
Whiteboard:
Issue Type: DEFECT Exception Report:
Attachments: patch

Description David Konecny 2011-03-08 22:05:30 UTC
2.1 is part of GF 3.1.

PetrJ if you agree I think we should push this to NB7.0
Comment 1 Martin Fousek 2011-03-09 05:16:03 UTC
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
Comment 2 Martin Fousek 2011-03-09 06:10:53 UTC
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
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5271)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:500)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630)
	at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
	at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
	at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
	at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
	at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
	at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
	at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
...

Could also someone else try it, please? Just for assurance.
Comment 3 Petr Jiricka 2011-03-09 11:02:23 UTC
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>()
	at java.lang.Class.getConstructor0(Class.java:2706)
	at java.lang.Class.getConstructor(Class.java:1657)
	at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:306)
...

A similar exception happens when using Tomcat 7.0.6:

java.lang.InstantiationException: com.sun.faces.application.ServletContextSensitiveSingletonStore
	at java.lang.Class.newInstance0(Class.java:340)
	at java.lang.Class.newInstance(Class.java:308)
	at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:119)
...

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.
Comment 4 David Konecny 2011-03-09 20:00:55 UTC
(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.
Comment 6 David Konecny 2011-03-09 20:40:51 UTC
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?
Comment 7 Martin Fousek 2011-03-10 06:06:59 UTC
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:
http://java.net/jira/browse/JAVASERVERFACES-1937

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.
Comment 8 David Konecny 2011-03-10 19:39:27 UTC
(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.
Comment 9 Martin Fousek 2011-03-11 08:21:21 UTC
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.
Comment 10 David Konecny 2011-03-13 19:49:39 UTC
I agree with postponing this.
Comment 11 Petr Jiricka 2011-03-14 09:35:39 UTC
Ok, changing from DEFECT to TASK so it does not show up on the NB 7 bug dashboard.
Comment 12 Marian Mirilovic 2011-03-18 08:48:53 UTC
(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
Comment 13 Martin Fousek 2011-04-14 13:09:27 UTC
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).
Comment 14 Martin Fousek 2011-04-21 07:53:07 UTC
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.
Comment 15 Martin Fousek 2011-04-21 07:53:47 UTC
Created attachment 107874 [details]
patch
Comment 16 Marek Fukala 2011-04-26 15:44:49 UTC
> 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.
Comment 17 Martin Fousek 2011-04-27 06:52:27 UTC
Thanks a lot Marek for your review. 

Fixed/integrated as http://hg.netbeans.org/web-main/rev/a292c424227f.
Comment 18 Martin Fousek 2011-04-27 07:01:02 UTC
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.
Comment 19 Quality Engineering 2011-04-29 04:41:31 UTC
Integrated into 'main-golden', will be available in build *201104290000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a292c424227f
User: Martin Fousek <marfous@netbeans.org>
Log: #196456 - upgrade JSF library bundled with NetBeans to version 2.1
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo