<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-1096] Implicit object scope implementations narrower than specification mandates Created: 04/May/12  Updated: 06/May/12  Resolved: 06/May/12

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mcdowell Assignee: Ed Burns
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1


Tags: jsf scope implicit-objects
Participants: Ed Burns and mcdowell

 Description   

Cross-reference: http://java.net/jira/browse/JAVASERVERFACES-2410

JSR 314 states:

"It is an error for a managed bean created through this facility to have a property that points at an object stored in a scope with a (potentially) shorter life span."

It then goes on to imply that (for example) the expression #{sessionScope} should resolve to a session scope instance. However, the sessionScope instance resolves to a Map instance member of the FacesContext in the reference implementation. The FacesContext is request scope. To keep a reference to the sessionScope variable in a session bean causes a scope leak.

The problem applies to any of the documented artifacts with a scope broader than request.

Given the way that dependency injection is typically used (i.e. injecting #{sessionScope.foo}, this is arguably a problem with the specification rather than the implementation.

It is possible to use an abstraction layer to mitigate this issue: http://illegalargumentexception.blogspot.co.uk/2012/01/jsf-managed-beans-without-jsf.html#noFacesProxyScopes



 Comments   
Comment by Ed Burns [ 06/May/12 11:29 PM ]

Here is how #{sessionScope} works.

ImplicitObjectELResolver returns facesContext.getExternalContext().getSessionMap().

That method returns an Map implementation with these methods, among others:

@Override
public Object get(Object key) { Util.notNull("key", key); HttpSession session = getSession(false); return ((session != null) ? session.getAttribute(key.toString()) : null); }

private HttpSession getSession(boolean createNew) { return request.getSession(createNew); }

private final HttpServletRequest request;

public SessionMap(HttpServletRequest request, ProjectStage stage) { this.request = request; this.stage = stage; }

Similar implementations exist for other Map methods.

So while it is true the instance returned is a request scoped instance, the data stored and retrieved using it is entirely session scoped.

If you can conclusively prove otherwise, please reopen this issue and we'll fix it on the basis of this new information.





Support view actions that execute before tree is built w/ navigation support (JAVASERVERFACES_SPEC_PUBLIC-758)

[JAVASERVERFACES_SPEC_PUBLIC-968] Improve Event Handling Created: 14/Apr/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL, Facelets/VDL
Affects Version/s: 2.2
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: kenpaulsen Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: jsf event el
Participants: alexsmirnov, kenpaulsen and lamine_ba

 Description   

I would like to propose we improve support for <f:event> to accept body content which describes how the event should be handled. I have an implementation of this that uses EL (plus some flow control constructs: if/foreach/etc) that I could demonstrate and contribute. My implementation allows for a page author to do something like this:

<f:event type="preRenderComponent">
<![CDATA[
if (requestScope.a < mybean.b) { mybean.doSomething(requestScope.a); logbean.log("did something"); }
]]>
</f:event>

Source code is available at: http://java.net/projects/jsftemplating/sources/svn/show/trunk/src/java/com/sun/jsft?rev=1507

-Ken

-Ken



 Comments   
Comment by alexsmirnov [ 14/Apr/11 07:26 AM ]

It's bad idea to mix markup and Java on the same file. No IDE support, hard to test and maintain.

Comment by lamine_ba [ 14/Apr/11 01:32 PM ]

I have voted for this issue even if Ken Paulsen and I, don't have the same goal. I'm totally agree with alexsmirnov's comment. It's a bad idea to mix markup and Java on the same file especially in the perspective of a web designer. But I see good things in this idea and I'm sure there is another way to achieve it.

Comment by kenpaulsen [ 14/Apr/11 01:49 PM ]

I agree as well. However, minimal simple tasks in the context of an event fill an important gap. Complex logic absolutely does NOT belong in a markup (xhtml) file.

Comment by lamine_ba [ 15/Apr/11 08:23 AM ]

Totally agree with you Ken, sometimes the bad thing can be the good thing. It depends only on the context of your problem and there is nothing stopping us to make the two opposite approaches to coexist but only at the condition to find the right balance. As far as I'm concern, I had a hard time to know that the Event Handling is managed by the Application class. And in my opinion, the Event Handling deserves its own class to be manageable, understandable and extensible. Could we create an EventHandler class to enforce loose coupling and high cohesion? For me, things should be intuitive, you think and you get...





[JAVASERVERFACES-3149] Accepted languages parsing fails when values have empty Strings between them Created: 18/Jan/14  Updated: 27/Mar/14  Resolved: 29/Jan/14

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.27
Fix Version/s: 2.1.28

Type: Bug Priority: Minor
Reporter: napartar Assignee: Manfred Riem
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Kubuntu rekonq as browser


Tags: jsf mojarra
Participants: Manfred Riem and napartar

 Description   

This problem happens to me when I try to browse to any view of a JSF application using Kubuntu's rekonq browser. I debugged it and saw the exact concrete problem at MultiViewHandler class:

@org.junit.Test
public void jsfTest() { // Firefox parseAcceptedLang("es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3"); // Kubuntu's rekonq parseAcceptedLang("es, en-US; q=0.8, en; q=0.6"); }

// Return a list of proritized languages
// Example:
// acceptedLang = "zh-Hant;q=0.7,en-us,fr;q=0.8,en;q=0.6,de"
// return {en-us, de, fr, zh-Hant,en}
private List<String> parseAcceptedLang(String acceptedLang) {
List<Float> qvalues = new ArrayList<Float>();
List<String> pList = new ArrayList<String>();

String[] strArray = acceptedLang.split(",");
for (String str : strArray) {
if (str.isEmpty()) { continue; }
String[] keyValue = str.split(";");
Float qval = 1.0f; // default value
if (keyValue.length > 1) { qval = Float.parseFloat(keyValue[1].substring(2)); }
int index;
for (index = 0; index < qvalues.size(); index++) { if (qval > qvalues.get(index)) break; }
pList.add(index, keyValue[0]);
qvalues.add(index, qval);
}

return pList;
}

The parseAcceptedLang method is supposed to receive no blank space splitted values. When something like second case arrives, the error is the following:

java.lang.NumberFormatException: For input string: "=0.8"
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1222)
at java.lang.Float.parseFloat(Float.java:422)
at Test.parseAcceptedLang(Test.java:38)
at Test.jsfTest(Test.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

The Float.parseFloat(keyValue[1].substring(2)); method call is prepared to receive a non-whitespaced String and tries to get a substring starting from its second index. If the reaching value contains a white space at the beginning, it crashes. The easy solution would be to use a split by "=" instead.



 Comments   
Comment by napartar [ 20/Jan/14 12:02 PM ]

Just have to add that rekonq version is 1.1. Quite ancient, actually...

Comment by Manfred Riem [ 22/Jan/14 05:06 PM ]

Can you please try it against 2.2.5? Thanks!

Comment by napartar [ 23/Jan/14 07:23 AM ]

Tried also against 2.2.5 but doesn't have that problem. In fact, seems that MultiViewHandler#parseAcceptedLang method doesn't place there anymore.

Comment by Manfred Riem [ 23/Jan/14 04:52 PM ]

Can you use 2.2.5 for your application?

Comment by napartar [ 25/Jan/14 05:39 PM ]

I can also use 2.2.5. But would be interesting to have the 2.1.x branch fixed. I consider it to be a minor problem, because it happens with a minor browser in an old version of it. But the solution also is so straight forward.

Comment by Manfred Riem [ 27/Jan/14 04:07 PM ]

OK, since you are able to use 2.2.5 I like to concentrate on other issues and take care of this if more people want it. Fair enough?

Comment by napartar [ 27/Jan/14 04:16 PM ]

Fair. We've not migrated to 2.2.x yet, however we've no clients using minor browsers. All of them are with IE, Firefox or Chrome so no problem for us. I discovered the problem in our labs with a kubuntu distro and just wanted to report it

Comment by Manfred Riem [ 29/Jan/14 03:09 PM ]

Actually because as you already have stated this only occurs with a browser that is hardly ever used and it works properly in 2.2.x I am closing this as a "Won't Fix".

If the vote count on this issue will ever reach 10 I will reconsider it worth to be fixed.





[JAVASERVERFACES-3025] Cannot output class attribute on JSFified HTML elements Created: 10/Sep/13  Updated: 10/Sep/13  Resolved: 10/Sep/13

Status: Closed
Project: javaserverfaces
Component/s: facelets, renderkit, view handling
Affects Version/s: 2.2.2
Fix Version/s: 2.2.4

Type: Bug Priority: Major
Reporter: kithouna Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish-4.0.1-b04-09_05_2013
Java 1.7.0_21 64 Bit
Windows 7 64 Bit


File Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Tags: jsf class attribute output
Participants: kithouna and Manfred Riem

 Description   

It seems to be impossible to get the class attribute rendered on an HTML element with a JSF attribute.

<div class="foo" jsf:id="bar">Lorem ipsum</div> results in

java.lang.IllegalArgumentException: Setter not found for property class
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2447)
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2327)
at com.sun.faces.facelets.tag.jsf.ComponentRule$LiteralAttributeMetadata.applyMetadata(ComponentRule.java:87)
at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:412)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:175)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:169)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:161)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:980)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

Using <div jsf:styleClass="foo" jsf:id="bar">Lorem ipsum</div>, the attribute is ommitted:

<div id="bar">Lorem ipsum</div>

Trying to output it as a passthrough-attribute <div p:class="foo" jsf:id="bar">Lorem ipsum</div> results in the same exception, slightly different stacktrace:

java.lang.IllegalArgumentException: Setter not found for property class
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2447)
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:2327)
at com.sun.faces.facelets.tag.jsf.ComponentRule$LiteralAttributeMetadata.applyMetadata(ComponentRule.java:87)
at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:412)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:175)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:190)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:169)
at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:210) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this line is added
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:161)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:980)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

Note that passthrough attributes with other names work: <div p:class2="foo" jsf:id="bar">Lorem ipsum</div> results in

<div id="bar" class2="foo">Lorem ipsum</div>



 Comments   
Comment by Manfred Riem [ 10/Sep/13 05:02 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3025, r=rogerk, Make sure a class attribute gets rewritten to styleClass so the mapper works properly with passthrough"
Sending jsf-ri\src\main\java\com\sun\faces\facelets\tag\MetaRulesetImpl.java
Adding test\agnostic\renderKit\passthrough\src\main\webapp\WEB-INF\glassfish-web.xml
Adding test\agnostic\renderKit\passthrough\src\main\webapp\divWithClass.xhtml
Adding test\agnostic\renderKit\passthrough\src\test\java\com\sun\faces\test\agnostic\renderKit\passthrough\Issue3025IT.java
Transmitting file data ....
Committed revision 12514.





[JAVASERVERFACES-2600] Infinite(?) loop in UIComponentBase.publishAfterViewEvents Created: 13/Nov/12  Updated: 21/Feb/13  Resolved: 21/Feb/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Duplicate Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1, Linux, JDK 1.6.0_24


Issue Links:
Related
is related to JAVASERVERFACES-2722 Stuck threads never returns from java... Closed
is related to GLASSFISH-18826 Infinite(?) loop in UIComponentBase.p... Closed
Tags: jsf mojarra 311
Participants: Manfred Riem and moelholm

 Description   

When running performance tests on our application, we recently saw four threads using 100% CPU.
A thread dump reveals the following stack trace:

"http-thread-pool-8080(24)" daemon prio=10 tid=0x0000000054c2e800 nid=0x67a5 runnable [0x000000004e30f000]
java.lang.Thread.State: RUNNABLE
at javax.faces.component.UIComponent.popComponentFromEL(UIComponent.java:1961)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2214)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2210)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1883)
at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:400)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2631)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2603)
at com.sun.faces.facelets.tag.jsf.ComponentSupport.addComponent(ComponentSupport.java:559)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.addComponentToView(ComponentTagHandlerDelegateImpl.java:290)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:769)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

The threads seem to be stuck in UIComponentBase.publishAfterViewEvents. Unfortunately this bug is not consistent, and it's the first time that we've seen it during our performance tests.



 Comments   
Comment by Manfred Riem [ 17/Dec/12 04:13 PM ]

Can you supply us with an example application (with sources) that demonstrates the problem? Can you verify if it is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 17/Jan/13 02:36 PM ]

Lowering priority because of no response

Comment by moelholm [ 01/Feb/13 10:15 AM ]

Our company has the same issue. Under load 'stuck threads' such as these appear. This is highly critical.

The real problem is probably invocations to:

UIComponent.popComponentFromEL

...which seems to never return.

From the JAR (api) file:

Bundle-SymbolicName: javax.faces-api
Extension-Name: javax.faces
Implementation-Version: 2.1
Bundle-Name: JavaServer Faces API 2.1.13 (20120907-1549)
DynamicImport-Package: org.glassfish.flashlight.provider
Bundle-Version: 2.1
Bnd-LastModified: 1347047401742
Bundle-ManifestVersion: 2
Bundle-Description: Mojarra JSF API (javax.faces/2.1) 2.1.13 (20120907
 -1549)
Specificatio

Example one:

"[STUCK] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x0000000107c54800 nid=0x38 runnable [0xfffffffd6d63b000]
   java.lang.Thread.State: RUNNABLE
	at javax.faces.component.UIComponent.popComponentFromEL(UIComponent.java:1934)
	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:880)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786)
	at org.primefaces.component.datatable.DataTableRenderer.encodeRegularCell(DataTableRenderer.java:797)

Example two:

"[STUCK] ExecuteThread: '25' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x0000000109608800 nid=0x57 runnable [0xfffffffd6b63a000]
   java.lang.Thread.State: RUNNABLE
	at javax.faces.component.UIComponent.popComponentFromEL(UIComponent.java:1936)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.popComponentFromEL(ComponentTagHandlerDelegateImpl.java:341)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:214)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:166)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:305)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:364)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:343)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
	at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:147)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:107)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
	at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
	at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:112)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:196)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:180)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:305)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:364)
	at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:343)
	at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
	at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:149)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:838)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:512)
	at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:141)
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at dk.optagelse.web.ftu.filters.FtuUserFilter.doFilter(FtuUserFilter.java:46)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at dk.optagelse.web.filters.CustomCharacterEncodingFilter.doFilter(CustomCharacterEncodingFilter.java:21)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at dk.optagelse.security.SessionTimeoutFilter.doFilter(SessionTimeoutFilter.java:58)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
	at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
	at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
	at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
	at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
	at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
Comment by Manfred Riem [ 21/Feb/13 02:38 PM ]

See associated issue





[JAVASERVERFACES-2594] ResourceBundle isn't getting reloaded. Created: 13/Nov/12  Updated: 18/Sep/13  Resolved: 18/Sep/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.1.20
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Manfred Riem Assignee: Manfred Riem
Resolution: Invalid Votes: 3
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

jdk 1.6.20 ,glassfish V3, windows xp, jsf 2.0


Issue Links:
Related
is related to GLASSFISH-15657 ResourceBundle isn't getting reloaded. Closed
Status Whiteboard:

size_medium importance_small

Tags: glassfish i18n/l10n jsf
Participants: Manfred Riem, mayankmodi and rdelaplante

 Description   

I am using view level resource bundle.

<f:loadBundle var="msg" basename="MyMessages"/>

and I have MyMessages.properties file in classpath directly.

For testing purpose I modify properties file [externally]I have a button that will reload the resource bundle by calling

public String reloadMyBundle() {
try { ResourceBundle.getBundle("MyMessages").clearCache(); ResourceBundle.getBundle("MyMessages").clearCache(Thread.currentThread().getContextClassLoader());//I am not sure which one exactly to use so added all possibilities for testing :p ResourceBundle.clearCache(); ResourceBundle.clearCache(Thread.currentThread().getContextClassLoader()); } catch (Exception ex) { ex.printStackTrace(); }

return null;
}

But it ResourceBundle isn't getting refreshed.
It works with other server.



 Comments   
Comment by Manfred Riem [ 19/Feb/13 02:10 PM ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by mayankmodi [ 28/Feb/13 05:57 AM ]

This issue still persist in Glassfish-3.1.2.2. Is there any patch available?

Comment by Manfred Riem [ 28/Mar/13 01:10 PM ]

Can you try it using a later 2.1 version? Glassfish 3.1.2.2 comes with version 2.1.6. Thanks!

Comment by mayankmodi [ 28/Mar/13 02:36 PM ]

Verified in version 2.1.20 and 2.2.0-m11. Still same issue.

Comment by rdelaplante [ 16/Apr/13 07:00 PM ]

Please increase the priority of this ticket so that it gets fixed in the next release

Comment by mayankmodi [ 21/May/13 10:45 AM ]

Any update on this issue......

Comment by Manfred Riem [ 18/Sep/13 04:55 PM ]

Note while I understand that saying "Invalid" is not really what you want to hear it is the only resolution that I can give to this issue.

1. Modifying files that consist of the logical structure of a web application by directly going to the file system is not documented nor supported.

2. The code you are referring to is code in the core Java runtime to which we delegate completely to do loading of a ResourceBundle backed by a properties file, so it looks like there is a bug in it that you are hitting. Feel free to file an issue at the OpenJDK tracker and refer to this issue.

Closing this issue as "Invalid".





[JAVASERVERFACES-2522] UnsupportedOperationException at renderkit when client write State (MultiViewHandler) Created: 27/Sep/12  Updated: 01/Oct/12  Resolved: 01/Oct/12

Status: Closed
Project: javaserverfaces
Component/s: renderkit, state saving
Affects Version/s: 2.2.0-m05
Fix Version/s: None

Type: Bug Priority: Major
Reporter: PetrJungCZ Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Liferay Portal on Tomcat 7.0.27.
Mojara EL 2.2.4


Tags: UnsupportedOperationException JSF Portlet Liferay
Participants: Manfred Riem and PetrJungCZ

 Description   

With JSF 2.0 the Portlet is working, changing the JSF api and impl to JSF2.2 I got an error.
Could be specific for Portlet bridge, but what was changed, that the render kit has all operations unimplemented? Whould be for JSF2.2 configured something diferently?

Working mojara version
jsf-api-2.1.10.jar
jsf-impl-2.1.10.jar
+
javax.el-2.2.4.jar
liferay-faces-bridge-api-3.1.0-rc2.jar
liferay-faces-bridge-impl-3.1.0-rc2.jar

Error mojara version
jsf-api-2.2.0-m05.jar
jsf-impl-2.2.0-m05.jar

java.lang.UnsupportedOperationException
at javax.faces.context.ExternalContext.getClientWindow(ExternalContext.java:1493)
at javax.faces.context.ExternalContextWrapper.getClientWindow(ExternalContextWrapper.java:509)
at com.sun.faces.renderkit.StateHelper.writeClientWindowField(StateHelper.java:288)
at com.sun.faces.renderkit.ClientSideStateHelper.writeState(ClientSideStateHelper.java:198)
at com.sun.faces.renderkit.ResponseStateManagerImpl.writeState(ResponseStateManagerImpl.java:127)
at com.sun.faces.application.StateManagerImpl.writeState(StateManagerImpl.java:113)
at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:442)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:127)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:329)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:329)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:202)
at com.liferay.faces.bridge.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:45)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:280)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:92)
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:99)
at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:255)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:204)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:593)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:530)
at com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:534)
at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:607)
at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:359)
at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(render_005fportlet_jsp.java:1207)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at com.liferay.portal.servlet.DirectRequestDispatcher.include(DirectRequestDispatcher.java:97)
at com.liferay.portal.servlet.PACLRequestDispatcherWrapper.doDispatch(PACLRequestDispatcherWrapper.java:90)
at com.liferay.portal.servlet.PACLRequestDispatcherWrapper.include(PACLRequestDispatcherWrapper.java:54)
at com.liferay.portal.util.PortalImpl.renderPortlet(PortalImpl.java:5158)
at com.liferay.portal.util.PortalUtil.renderPortlet(PortalUtil.java:1569)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.processPortlet(RuntimePortletImpl.java:165)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.processPortlet(RuntimePortletImpl.java:97)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.doProcessTemplate(RuntimePortletImpl.java:531)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.doDispatch(RuntimePortletImpl.java:394)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.processTemplate(RuntimePortletImpl.java:228)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletImpl.processTemplate(RuntimePortletImpl.java:216)
at com.liferay.portlet.layoutconfiguration.util.RuntimePortletUtil.processTemplate(RuntimePortletUtil.java:113)
at org.apache.jsp.html.portal.layout.view.portlet_jsp._jspService(portlet_jsp.java:507)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:593)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:530)
at com.liferay.portal.action.LayoutAction.includeLayoutContent(LayoutAction.java:468)
at com.liferay.portal.action.LayoutAction.processLayout(LayoutAction.java:735)
at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:249)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:176)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:560)
at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:537)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:294)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)
at com.liferay.portal.servlet.FriendlyURLServlet.service(FriendlyURLServlet.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.strip.StripFilter.processFilter(StripFilter.java:335)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.gzip.GZipFilter.processFilter(GZipFilter.java:123)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:294)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.i18n.I18nFilter.processFilter(I18nFilter.java:241)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.autologin.AutoLoginFilter.processFilter(AutoLoginFilter.java:246)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.sso.ntlm.NtlmPostFilter.processFilter(NtlmPostFilter.java:83)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.sharepoint.SharepointFilter.processFilter(SharepointFilter.java:80)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:163)
at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.processFilter(VirtualHostFilter.java:216)
at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:57)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:187)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:95)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:738)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:167)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:95)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:167)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:95)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:187)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:95)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by Manfred Riem [ 01/Oct/12 02:21 PM ]

Note the method that throws the UnsupportedException is ExternalContext.getClientWindow is new in the 2.2 API. If the PortletBridge does not implement this than that is the reason why it fails.

Comment by Manfred Riem [ 01/Oct/12 02:46 PM ]

Since the PortletBridge is not written with the new APIs in mind I am marking this one as Won't Fix as it is the PortletBridge that needs to be updated.





[JAVASERVERFACES-2479] Datatable does not rerender on Ajax Call from a seleceOneMenu Created: 31/Jul/12  Updated: 07/Aug/12  Resolved: 07/Aug/12

Status: Closed
Project: javaserverfaces
Component/s: ajax
Affects Version/s: None
Fix Version/s: 2.1.12, 2.2.0-m05

Type: Bug Priority: Major
Reporter: malikalamgirian Assignee: rogerk
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle-2479.txt    
Tags: JSF Datatable
Participants: malikalamgirian and rogerk

 Description   

Datatable does not re-render on Ajax Call from an event raised by selectOneMenu when a valueChange is seen through user.

The backing bean DivisionsListBean is SessionScoped.

<h:form id="divisionContactForm">
		<h:selectOneMenu id="DivisionSelectorDropDown"
			value="#{DivisionsListBean.selectedDivisionName}">
			
			<f:selectItems value="#{DivisionsListBean.divisionsNames}"></f:selectItems>
			
			<f:ajax event="change" render="contactsTable" execute="@this"/>
		</h:selectOneMenu>	

		<br />		
		
		<h:dataTable id="contactsTable" 
			value="#{DivisionsListBean.divisionContactList}" 
			var="con">			

			<h:column>
				<f:facet name="header">
					<h:outputText value="Name" />
				</f:facet>

				<h:outputText value="#{con.contactName}" />				

			</h:column>						
			
		</h:dataTable>

	</h:form>


 Comments   
Comment by rogerk [ 07/Aug/12 02:41 PM ]

Test Case proving it works.

Comment by rogerk [ 07/Aug/12 02:43 PM ]

Committed to MOJARRA_2_1X_ROLLING branch:
Adding test/agnostic/ajax/src/main/java/com/sun/faces/test/agnostic/ajax/AjaxTable.java
Adding test/agnostic/ajax/src/main/webapp/selectOneMenuDataTable.xhtml
Adding test/agnostic/ajax/src/test/java/com/sun/faces/test/agnostic/ajax/Issue2479IT.java
Transmitting file data ...
Committed revision 10405.

Comment by rogerk [ 07/Aug/12 02:52 PM ]

Committed to trunk:
Adding test/agnostic/ajax/src/main/java/com/sun/faces/test/agnostic/ajax/AjaxTable.java
Adding test/agnostic/ajax/src/main/webapp/selectOneMenuDataTable.xhtml
Adding test/agnostic/ajax/src/test/java/com/sun/faces/test/agnostic/ajax/Issue2479IT.java
Transmitting file data ...
Committed revision 10406.

Comment by rogerk [ 07/Aug/12 02:53 PM ]

Test checked into 2.1.12 and 2.2-m05.

Comment by rogerk [ 07/Aug/12 02:54 PM ]

Works as designed. See test case.
Also, in your example, you need to fully qualify the id of the table in the render target -
including the form (you did not specify prependId=false).





[JAVASERVERFACES-2434] JSF 2.1.8 character encoding problem during file upload Created: 30/May/12  Updated: 30/May/12  Resolved: 30/May/12

Status: Closed
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.1.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: armen2008 Assignee: rogerk
Resolution: Works as designed Votes: 0
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days
Environment:

Apache Tomcat 7


Tags: JSF encoding primefaces upload jsf2 file admin-gui boundcommandtogglebutton doesnt maven event nested singleton-ejb plastic attendee
Participants: armen2008, Manfred Riem and rogerk

 Description   

If you with file upload have also web form for submitting non english fields, like firstname , lastname and add
<h:form enctype="multipart/form-data"> , you will have character encoding problem.
I added encoding filter but it did not help for all problems.
I used latest mojarra and primefaces version under latest apache tomcat 7. in common file upload jar i found boundary = boundaryStr.getBytes("ISO-8859-1") in FileUploadBase , may be connected with it? This problem must solve finally with JSF versions, because this happens when you add <h:form enctype="multipart/form-data"> .

in the String setters I added
public void setGuardionname(String guardionname) throws UnsupportedEncodingException { guardionname = new String (guardionname.getBytes ("iso-8859-1"), "UTF-8"); this.guardionname = guardionname; }
its help for add form, but during update the same problem.
Also its happened if you have validation like <f:validateRegex pattern="[a-zA-Z]*"/>

How we can solve this finally??

Best Regards,

Armen Arzumanyan



 Comments   
Comment by Manfred Riem [ 30/May/12 01:18 PM ]

The bug you submitted is related to PrimeFaces and how it handles file uploads. So if you have a problem with it you should file the issue with PrimeFaces so they can fix it. A note on h:form you can specify acceptcharset on the form so any child control can have access to the 'List of character encodings for input data that are accepted by the server processing this form.'





[JAVASERVERFACES-2410] Implicit object scope implementations narrower than specification mandates Created: 04/May/12  Updated: 26/Jun/12  Resolved: 04/May/12

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mcdowell Assignee: rogerk
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1


Tags: jsf scope
Participants: mcdowell and rogerk

 Description   

JSR 314 states:

"It is an error for a managed bean created through this facility to have a property that points at an object stored in a scope with a (potentially) shorter life span."

It then goes on to imply that (for example) the expression #{sessionScope} should resolve to a session scope instance. However, the sessionScope instance resolves to a Map instance member of the FacesContext. The FacesContext is request scope. To keep a reference to the sessionScope variable in a session bean causes a scope leak.

The problem applies to any of the documented artifacts with a scope broader than request.

Given the way that dependency injection is typically used (i.e. injecting #{sessionScope.foo}, this is arguably a problem with the specification rather than the implementation.

It is possible to use an abstraction layer to mitigate this issue: http://illegalargumentexception.blogspot.co.uk/2012/01/jsf-managed-beans-without-jsf.html#noFacesProxyScopes



 Comments   
Comment by rogerk [ 04/May/12 08:10 PM ]

Can you file a spec issue for this?

Comment by mcdowell [ 04/May/12 08:41 PM ]

Specification issue: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1096

Comment by rogerk [ 04/May/12 08:43 PM ]

Filed as spec issue per previous comments.





[JAVASERVERFACES-2352] Resouse annotation to obtain DataSourse for MySQL DB cause NullPointerException with Tomcat 7 Created: 25/Mar/12  Updated: 29/Mar/12  Resolved: 29/Mar/12

Status: Closed
Project: javaserverfaces
Component/s: resources
Affects Version/s: 2.1.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: SagiKov Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64bit
Tomcat 7.0.26
mojarra-2.1.7
JRE 6
MySQL 5.5
mysql-connector-java-5.1.18


Tags: jsf resource datasourse mysql
Participants: Ed Burns, Manfred Riem and SagiKov

 Description   

I have a problem to get DataSource while using @Resoruse annotation. When using the following code I get NullPointerException on the line
It's important to mention, that when I change the JSF Framework to myfaces-core-2.0.12-bin, the same code that uses injection works properly.

Connection conn = ds.getConnection();

because DS in null. DS has not been initialized with Resource injection method.

package com.corejsf;

import java.sql.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.naming.*;

@ManagedBean
@RequestScoped

public class CustomerBean {

@Resource(name="jdbc/sufa") private DataSource ds;

public ResultSet getAll() throws SQLException, NamingException {

Connection conn = ds.getConnection();
try { Statement stmt = conn.createStatement(); ResultSet result = stmt.executeQuery("SELECT City FROM Customers"); CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl(); crs.populate(result); return crs; } finally { conn.close(); }
}
}

If I choose not to use injection method, I have no problems. See the following code that sucesfully gets DataSource and returns ResultSet.

package com.corejsf;

import java.sql.*;
import javax.sql.DataSource;
import javax.sql.rowset.CachedRowSet;
import javax.annotation.Resource;
import javax.faces.bean.*;
import javax.naming.*;

@ManagedBean
@RequestScoped
public class CustomerBean {

public ResultSet getAll() throws SQLException, NamingException {

Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/sufa");

Connection conn = ds.getConnection();
try { Statement stmt = conn.createStatement(); ResultSet result = stmt.executeQuery("SELECT City FROM Customers"); CachedRowSet crs = new com.sun.rowset.CachedRowSetImpl(); crs.populate(result); return crs; } finally { conn.close(); }
}
}

The exception I get when I use injection:

java.lang.NullPointerException
at com.corejsf.CustomerBean.getAll(CustomerBean.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:87)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at org.apache.el.parser.AstValue.getValue(AstValue.java:169)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIData.getValue(UIData.java:731)
at javax.faces.component.UIData.getDataModel(UIData.java:1798)
at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:484)
at javax.faces.component.UIData.setRowIndex(UIData.java:473)
at com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:81)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:820)
at javax.faces.component.UIData.encodeBegin(UIData.java:1118)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1777)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1779)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1782)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by SagiKov [ 27/Mar/12 10:44 AM ]

Anyone can help ?

Comment by Ed Burns [ 28/Mar/12 10:29 AM ]

Does MyFaces include its own implementation of something that handles the injection? I know for Mojarra we rely on GlassFish to do the injection and it's possible you need something like OpenWebBeans to provide it when you are running in Tomcat.

Comment by SagiKov [ 28/Mar/12 08:15 PM ]

Hi Ed, MyFaces does not include its own implementation of Resource Injection.
There are several annotations supported by Tomcat 7 like Resource, Resources, PostConstruct, PreDestroy ...
They are implemented in annotations-api.jar, that is a part of Tomcat jars, when you install Tomcat.
So Tomcat do support Resource injection without defining general CDI support by Weld or OpenWebBeans
The point is that when I use JSF Mojarra, this Resource injection handled by Tomcat stop working.
Could it be a bug ?

Comment by Manfred Riem [ 28/Mar/12 08:26 PM ]

MyFaces does implement the injection, see http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/config/annotation/Tomcat7AnnotationLifecycleProvider.java?view=markup

To get it to work now, follow the steps outlined here, http://www.brucephillips.name/blog/index.cfm/2011/3/13/Contexts-and-Dependency-Injection-With-Maven-and-Tomcat-7

Comment by SagiKov [ 28/Mar/12 08:35 PM ]

Thank you so much !
Please close this issue.

Sagi





[JAVASERVERFACES-2277] long html code output in server: java.lang.IllegalStateException: PWC3999: Cannot create a session after the response has been committed Created: 02/Jan/12  Updated: 06/Jan/13  Resolved: 16/Mar/12

Status: Closed
Project: javaserverfaces
Component/s: facelets, renderkit
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.1.8, 2.2.0-m02

Type: Bug Priority: Major
Reporter: montblack Assignee: Manfred Riem
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 3.1.1, jsf 2.0 or 2.1 netbeans 7.1rc2, windows vista


File Attachments: Text File changebundle-test.txt     Text File changebundle.txt    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2031 State saving broken on Tomcat Closed
is duplicated by JAVASERVERFACES-2332 Flash incompatible with HTTP Chunking Closed
is duplicated by JAVASERVERFACES-2215 java.lang.IllegalStateException: Cann... Closed
Related
is related to JAVASERVERFACES-2143 View cannot be restored with Cookies off Closed
Tags: jsf html glassfish-3-1-1
Participants: adrian_e, chinboon, Ed Burns, frederickkaempfer, harrypham, Manfred Riem, montblack and Puls

 Description   

i start a project, i onle have html code 2 pages, a template and a index both xhtml.(download: http://freimanautos.com/bug/Aceites.rar)

when in the file resources/template/prime/masterpage.xhtml i uncoment the line 90:
<!-ui:include src="/resources/templates/prime/side.xhtml" /->

the server output:
GRAVE: Error Rendering View[/index.xhtml]
java.lang.IllegalStateException: PWC3999: Cannot create a session after the response has been committed

i try with many diferents html templay made with artisteer, and whe the template its very long the server crash and it dont show the rest of the components

why?



 Comments   
Comment by Manfred Riem [ 03/Jan/12 02:51 PM ]

Using the attached application I am observing the same behavior. The ServerSideStateHelper is trying to acquire a session, but since the response has already been written it is not allowed to do so. For server-side state saving we need to make sure we get the session before we start writing the response so the server-side state saving has a valid session.

Workaround: make sure you establish a session before hitting this page.

Comment by montblack [ 03/Jan/12 03:17 PM ]

but it's my index page and only had error when i add more html code if i dont have many html code it works fine and i try with 2 diferent html templates, could you tell me where i must establish the seasson?

and sorry for my english i speak spanish

Comment by frederickkaempfer [ 03/Jan/12 03:53 PM ]

You can also try to increase the response buffer size to a larger value in your web.xml, for example:

<context-param>
<param-name>com.sun.faces.responseBufferSize</param-name>
<param-value>100000</param-value>
</context-param>

Comment by Manfred Riem [ 03/Jan/12 05:20 PM ]

Create a simple index.jsp where you create a session and then use it to redirect to the Facelet page.

Comment by montblack [ 04/Jan/12 01:47 PM ]

<context-param>
<param-name>com.sun.faces.responseBufferSize</param-name>
<param-value>100000</param-value>
</context-param>

doesn't work

create a index.jsp work for de index page but if got a email with a link to a page that is not the index, then desn't work.

Comment by Manfred Riem [ 04/Jan/12 02:35 PM ]

Ed, I have attached a changebundle (for 2.1_X) that contains the fix

Comment by Ed Burns [ 11/Jan/12 07:55 PM ]

Because a workaround exists, downgrading this from blocker.

Comment by Ed Burns [ 12/Jan/12 08:40 PM ]

Re-assigning to Manfred.

When I applied your patch, I observed that com.sun.faces.render.OutputScriptStyleTestCase
started failing.

Upon investigation I learned that your change made it so what used to render as this

<link type="text/css" rel="stylesheet" href="/jsf-systest/faces/javax.faces.resource/case9.css"/>

Now rendered as this

<link type="text/css" rel="stylesheet" href="/jsf-systest/faces/javax.faces.resource/case9.css;jsessionid=399d86b3d2c310692a519705ddee"/>

We all agree that this is not the desired behavior.

Comment by Manfred Riem [ 12/Jan/12 10:13 PM ]

Unfortunately this behavior comes to play in how Glassfish does an encodeResourceUrl when the session has just been created (isNew is true). The Resource gets its URL from calling HttpServletResponse.encodeResourceUrl. By default Glassfish seems to have both URL rewriting and cookie handling enabled for a new session.

If JSF resources would not require a session we could use the URL directly instead of pushing it through encodeResourceUrl. Otherwise we are stuck with the behavior of the container at hand.

Comment by Manfred Riem [ 14/Mar/12 04:40 PM ]

Linking this issue as it is the same issue

Comment by Manfred Riem [ 14/Mar/12 09:10 PM ]

Acquire the session early if it server-side state saving is used and the viewroot is NOT flagged transient.

Comment by Manfred Riem [ 14/Mar/12 09:19 PM ]

Applied to 2.1.x branch

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2277, r=rogerk, Acquire the session early if it server-side state saving is used and the viewroot is NOT flagged transient." jsf-ri\src\main\java\com\sun\faces\application\view\FaceletViewHandlingStrategy.java
Sending jsf-ri\src\main\java\com\sun\faces\application\view\FaceletViewHandlingStrategy.java
Transmitting file data .
Committed revision 9765.

Comment by Ed Burns [ 15/Mar/12 12:30 PM ]

Hello Manfred, thanks for committing this, but I'm seeing test breakages as a result of this commit. What is your plan for fixing them? For example:

[junit] junit.framework.AssertionFailedError
[junit] at com.sun.faces.render.OutputScriptStyleTestCase.testOutputScriptStyle(OutputScriptStyleTestCase.java:143)
[junit] at com.sun.faces.htmlunit.HtmlUnitFacesTestCase.runTest(HtmlUnitFacesTest

This assertion is:

assertTrue(text.matches(
"(?s).<head>."+
"<link.* type=\"text/css\".rel=\"stylesheet\". href=\"/jsf-systest/faces/javax.faces.resource/case9.css\"
s*/>.*" +
"</head>.*"
));

And the relevant text in the response is:

<link type="text/css" rel="stylesheet" href="/jsf-systest/faces/javax.faces.resource/case9.css;jsessionid=651b2b2172978f77d6db8bf500c2"/>

You must fix all such occurrences. I had hoped this would have been done atomically with the commit, but at any rate, it must be done.

Comment by Manfred Riem [ 15/Mar/12 02:59 PM ]

I tested it twice locally before committing this and it passed on my machine

Comment by Manfred Riem [ 15/Mar/12 06:08 PM ]

Fixes for broken tests

Comment by Manfred Riem [ 15/Mar/12 06:12 PM ]

Applied to 2.1.x branch, fixes for broken tests

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2277, fixes broken tests"
Sending jsf-ri\systest\src\com\sun\faces\render\OutputScriptStyleTestCase.java
Sending jsf-ri\systest-per-webapp\request-char-encoding-no-session\src\java\com\sun\faces\systest\NoSessionCharEncTestCase.java
Transmitting file data ..
Committed revision 9767.

Comment by Manfred Riem [ 16/Mar/12 05:50 PM ]

Applied to 2.2.x (trunk)

svn commit -m "Fixes http://java.net/jira/browse/JAVASERVERFACES-2277, r=rogerk" jsf-ri\src\main\java\com\sun\faces\application\view\FaceletViewHandlingStrategy.java jsf-ri\systest\src jsf-ri\systest-per-webapp
Sending jsf-ri\src\main\java\com\sun\faces\application\view\FaceletViewHandlingStrategy.java
Sending jsf-ri\systest\src\com\sun\faces\render\OutputScriptStyleTestCase.java
Sending jsf-ri\systest\src\com\sun\faces\systest\RenderKitsTestCase.java
Sending jsf-ri\systest-per-webapp\request-char-encoding-no-session\src\java\com\sun\faces\systest\NoSessionCharEncTestCase.java
Transmitting file data ....
Committed revision 9768.

Comment by Puls [ 18/Mar/12 06:41 AM ]

Hi Manfred, does this fix also fix the flash related problems as reported in JAVASERVERFACES-2332?

Comment by Manfred Riem [ 19/Mar/12 06:17 PM ]

Yes, if I did miss a corner case please file an issue specifically for it. Note the latest 2.1 SNAPSHOT release should include these fixes, so give it a try and let me know.

Comment by Ed Burns [ 20/Mar/12 05:34 PM ]

Have all the testcases that are broken by this fix been fixed?

Comment by Manfred Riem [ 20/Mar/12 05:48 PM ]

As stated by the commit log attached to the issue you can see that is the case. Then the subsequent commit log states the entire bundle was applied to trunk.

Comment by Puls [ 21/Mar/12 10:20 AM ]

Hi Manfred, as you suggested I installed the latest 2.1.8 snapshot I found on Glassfish 3.1.2 (Mojarra 2.1.8 (SNAPSHOT 20120321-0021). The main issue that I reported in JAVASERVERFACES-2332 is not fixed and can still be reproduced using the attached application. The problem is that the flash cookie is not correctly written when HTTP chunking is enabled. I bleive the issue should be reopened.

Comment by adrian_e [ 24/Jul/12 05:29 PM ]

I recommend that this be re-opened. It is still a problem in 2.1.8.

Comment by Manfred Riem [ 24/Jul/12 05:31 PM ]

Please create a new issue and attach an application that reproduces the problem.

Comment by harrypham [ 25/Jul/12 01:06 AM ]

If any create an issue please link the new issue. I still have this problem in 2.1.10

Comment by chinboon [ 06/Jan/13 07:51 AM ]

This issue is still occurring for me, i am using 2.1.16.





[JAVASERVERFACES-2187] f:ajax processes enclosing form only Created: 11/Sep/11  Updated: 24/Feb/12  Resolved: 24/Feb/12

Status: Closed
Project: javaserverfaces
Component/s: ajax
Affects Version/s: 2.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cernicb Assignee: rogerk
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Java 1.6.0_27, Glassfish 3.1.1 build 12, Jsf mojarra 2.1.3


File Attachments: Zip Archive TestJSF.zip    
Tags: jsf ajax process form
Participants: cernicb and rogerk

 Description   

When there is more than one form on the page, f:ajax execute attribute deals with enclosing form components only. Here's an example that doesn't work:

<h:form id="f1">
<h:commandButton id="prev" action="#{test.prev}" value="Previous">
<f:ajax execute=":f2:test" render=":f2:test" />
</h:commandButton>
</h:form>
<h:form id="f2">
<h:inputText id="test" value="#{test.currPage}" />
</h:form>

And this one works:

<h:form id="fok">
<h:commandButton id="prevok" action="#{test.prev}" value="Previous">
<f:ajax execute="testok" render="testok" />
</h:commandButton>
<h:inputText id="testok" value="#{test.currPage}" />
</h:form>

Managed bean "test" is request scoped. In mojarra 1.2 apps this has easily been achieved with help of richfaces 3.x a4j:support tag. This issue is related to JAVASERVERFACES-1719 (f:ajax execute=@all does the same as execute=@form ). There are common situations when there's one main form, and other one handling dialogs or modal panels. Communication between these two forms is highly needed.



 Comments   
Comment by rogerk [ 24/Feb/12 06:54 PM ]

Duplicate of http://java.net/jira/browse/JAVASERVERFACES-2172.





[JAVASERVERFACES-2089] Bound attribute values resolve to NULL during PreRenderViewEvent for nested composite components Created: 30/May/11  Updated: 20/Nov/12  Resolved: 25/Oct/11

Status: Closed
Project: javaserverfaces
Component/s: event processing, expression language, facelets, lifecycle, state saving, view handling
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Rinner23 Assignee: Ed Burns
Resolution: Works as designed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Version: Helios Service Release 2
Build id: 20110218-0911

Mojarra JSF API (javax.faces/2.2) 2.2.0 (20110510- SNAPSHOT)

JSF 2.2.x custom build supplied for issue:
http://java.net/jira/browse/JAVASERVERFACES-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309816#action_309816


File Attachments: Text File 20111021-i_mojarra_2089_test.patch     File 20111024-JAVASERVERFACES-2089-initial-render.tiff     Text File 20111025-i_mojarra_2089-1532-snapshot.patch     Zip Archive i_jsf_2089_war.zip     File jsf-testing.war     Zip Archive jsf-testing.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES-1826 SystemEvent Acid Test Closed
depends on JAVASERVERFACES-2232 REGRESSION: Java top level composite ... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1043 When publishing a ComponentSystemEven... Closed
Status Whiteboard:

size_large importance_medium

Tags: JSF 2 composite component PreRenderViewEvent attributes viewstate 2011
Participants: Ed Burns, kennardconsulting, Manfred Riem, Rinner23, rogerk and temaleva

 Description   

NOTE: This test is performed using a custom build of JSF 2.2.x that was supplied as a fix for the following issue:

http://java.net/jira/browse/JAVASERVERFACES-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309816#action_309816

I am required to use this version as the current 2.0.3 RI does not save state correctly for components dynamically created while processing the PreRenderViewEvent (although, for this particular issue the same problem probably exists in 2.0.3).

Overview:

Page

  • Component1
  • Component2

When processing the PreRenderViewEvent, for custom composite components nested within another custom composite component any data-bound attributes are resolved as NULL. This has impact when attempting to dynamically create new components based on some bound-data that is accessed via the component attributes using this.getAttributes().get(<attr_name>).

The resulting dynamic sub-components DO render correctly and any data bound values are present as expected (values are set via ValueExpressions while creating the dynamic sub-components).

The supplied code is an eclipse project (latest version), please let me know if I need to export the project into an alternate format.

I plan to test against MyFaces implementation later, and have spent some time investigating the issue via JSF source code but have found nothing yet.

Regards,

Matt Sweeney



 Comments   
Comment by Rinner23 [ 30/May/11 02:50 PM ]

FYI The component tree above was supposed to show component2 nested inside component1, like so:

Page
+Component1
++Component2

Matt

Comment by Rinner23 [ 13/Jun/11 07:56 AM ]

UPDATE: Although I have no actual cause, this appears to be occurring when the nested (second level) composite component evaluates the attribute the part "cc" returns as null.

I saw this behavior somewhere inside the getValue(...) method on the 'Node' (I think!).

Matt

Comment by Rinner23 [ 14/Jun/11 12:17 PM ]

FYI: Also same behavior on MyFaces so this is likely a spec issue?

Comment by Rinner23 [ 21/Jun/11 08:23 AM ]

FYI: Leonardo on MyFaces responded to this issue here:

https://issues.apache.org/jira/browse/MYFACES-3168?focusedCommentId=13052594#comment-13052594

It seems it might not be a spec issue at all, as he provides a workaround that would require some small amount of code from the developer of any composite component. I have not tested this yet, but it does seem to make sense (with my limited understanding of the JSF internals).

Regards,

Matthew Sweeney

Comment by kennardconsulting [ 21/Jun/11 04:05 PM ]

Matt,

Can you confirm whether this workaround works on MyFaces and/or Mojarra?

Richard.

Comment by kennardconsulting [ 21/Oct/11 06:29 AM ]

Hi guys,

From further understandings on https://issues.apache.org/jira/browse/MYFACES-3168 it appears this bug needs to be fixed in containers such as 'h:column' (and probably many others too).

Essentially the problem is this: using PreRenderViewEvent as the mechanism to create dynamic components (which is the recommended way) only works for declared attributes if all parents also listen to PreRenderViewEvent and call 'pushComponentToEL' in advance.

I believe this is something that needs fixing in the base classes, or maybe even at the spec level?

Richard.

Comment by Ed Burns [ 21/Oct/11 01:38 PM ]

Richard,

Would it be fair to characterize that we need to alter the timing of when pushComponentToEL is called to take into account the firing of the PreRenderViewEvent?Ed

Comment by Ed Burns [ 21/Oct/11 03:12 PM ]

I see the exception.

java.lang.NullPointerException
at web.components.UIComponent1.processPreRenderViewEvent(UIComponent1.java:67)
at web.components.UIComponent1.processEvent(UIComponent1.java:46)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2239)
at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2060)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:290)
at com.sun.faces.application.ApplicationImp

Comment by Ed Burns [ 21/Oct/11 03:21 PM ]

Ahh, I don't have the patch for 1826 in place.
Let me apply it.

Comment by Ed Burns [ 21/Oct/11 03:30 PM ]

According to Roger, the patch has already been applied to the trunk, so I'm not certain if I should be seeing the NPE at UIComponent1.java#67. Looks like the test was written to illustrate the problem without having an NPE. AM I correct?

Comment by rogerk [ 21/Oct/11 04:10 PM ]

Actually - let me add some clarification..
It appears that issue depends on http://java.net/jira/browse/JAVASERVERFACES-1826.
That issue pertains to a number of system event acid tests.
The fix for all but two of those tests has been checked into Mojarra.
I believe the only two acid tests thar are not working are the input and toggle.
The tests that have been fixed have been tracked by other JIRA issue number.
For example, the "table" test that is working has been fixed and the issue
number for that is http://java.net/jira/browse/JAVASERVERFACES-1969.
So, it may be entirely possible that the fix needed for this issue has not been
put into Mojarra yet.

Comment by kennardconsulting [ 22/Oct/11 08:34 AM ]

"Would it be fair to characterize that we need to alter the timing of when pushComponentToEL is called to take into account the firing of the PreRenderViewEvent?"

Yes, I believe this is a fair characterization. However I am no expert on the JSF internals.

Comment by kennardconsulting [ 22/Oct/11 08:48 AM ]

"Looks like the test was written to illustrate the problem without having an NPE. Am I correct?"

Yes. If you try the test (jsf-testing.zip) using the jsf-api.jar and jsf-impl.jar that Matt included, it does not NPE. It shows two boxes that use PreRenderViewEvent. The outer one's EL works okay, but the inner one does not.

This is slightly different to the h:column example I described, but I believe it is the same bug.

If it helps, I have attached Matt's example as a deployable WAR.

Richard.

Comment by kennardconsulting [ 22/Oct/11 08:50 AM ]

Matt's example as a WAR

Comment by Ed Burns [ 24/Oct/11 09:18 PM ]

The NPE was cause by the regression of JAVASERVERFACES-1988, which I just fixed as JAVASERVERFACES-2232. Phew. Now, back to this one.

I don't see the NPE. Rather, I see some text for which I will attach a screengrab.

Comment by kennardconsulting [ 24/Oct/11 09:29 PM ]

Ed,

This isn't the exact output I see from the attached WAR (it only has 2 'Item0' boxes), but it's close. I'm guessing your screenshot is from after POSTback? That may or may not be a new bug. I didn't write this test case so I'm not sure.

But anyway, regardless of the POSTback button, the problem is that it says 'item attribute is null: false' and then 'item attribute is null: true'. If 2089 was fixed (i.e. if EL resolution worked correctly during PreRenderViewEvent) the second line should read 'item attribute is null: false'.

Regards,

Richard.

Comment by Rinner23 [ 25/Oct/11 01:48 PM ]

Yes there is no NPE in the example because we are testing for null.

Comment by Ed Burns [ 25/Oct/11 03:40 PM ]

RK> (i.e. if EL resolution worked correctly during PreRenderViewEvent)
RK> the second line should read 'item attribute is null: false'.

I suspect it is not because EL resolution doesn't work correctly during
PreRenderView, but rather, that the code that causes the actual "put"
operation on the composite component attributes Map is not being
executed before you are trying to do the corresponding "get".

Comment by Ed Burns [ 25/Oct/11 03:45 PM ]

Also, this is a problem in the sample app: the custom components declare they implement NamingContainer, but actually do nothing to implement NamingContainer. One easy way to implement NamingContainer is to extend from UINamingContainer.

Comment by Rinner23 [ 25/Oct/11 03:48 PM ]

The attribute is actually data bound - for example I was testing with a Session object that had been previously setup. The value is there, you can debug in code and grab the session and see it. The problem is when you try to actually resolved the binding within the component on PreRenderView it has no context. By pushing the component explicitly in that same event you can then evaluate the associated data binding correctly.

If you check the issue on MyFaces JIRA there is probably a clearer explanation =)

On an unrelated note, my current contract comes to an end this week and I'll be moving back to ASP.NET for about 2 years for the next contract. I'll be checking in but probably won't have much time to be working with JSF for a while =(

Comment by Ed Burns [ 25/Oct/11 06:37 PM ]

Just sent this email to the maintainer of the EL code underneath this issue:

>>>>> On Tue, 25 Oct 2011 11:35:39 -0700, Ed Burns <edward.burns@oracle.com> said:

EB> Hello Kin-Man,
EB> While struggling to understand JAVASERVERFACES-2089, I came across a
EB> line of dead code in AstValue.getValue(). In svn version 198 of
EB> AstValue.java (which I have delivered to me in uel-impl-2.2.1-b03), the
EB> line of dead code is

EB> ELResolver resolver = ctx.getELResolver();

EB> I'd chalk this up just to a missing delete keystroke in a source editor
EB> somewhere along the line, were it not for the fact that it seems like
EB> the resolver should, in fact, be consulted.

EB> Can you please confirm if this line should indeed be removed?

Comment by Ed Burns [ 25/Oct/11 07:33 PM ]

The problem: in component1.xhtml, when the reporter says:

<comp:component2 item="#{cc.attrs.item}" />

This causes a ValueExpression to be stored in the attribute map of an
instance of UIComponent2.

When UIComponent2's processPreRenderViewEvent() method is called, the
system can't possibly know what UIComponent instance to use to stand in
for #{cc}. Let me state what I think the reporter wants.

In UIComponent2.processPreRenderViewEvent(), we want to be able to
say, "give me whatever was passed in as the value of the 'item'
attribute in the page in which I was used."

As stated elsewhere in the bug report, the problem can be solved by
manually pushing the cc.

Alternatively, you could use the PreRenderComponentEvent, which, by
definition, will have the cc correctly pushed before calling the
listener.

Attached is a patch that shows this approach. It works as expected.

Comment by kennardconsulting [ 25/Oct/11 09:50 PM ]

Ed,

I agree this probably 'works as designed'. However I believe the design is flawed

The problem is the patch/workaround only applies if you have control over the container component. If your container component is...

<h:dataTable var="internal">
<h:column>
<a:myDynamicComponent value="#{internal}"/>

...then 'myDynamicComponent' cannot access #{internal} during PreRenderViewEvent, nor can you control UIDataTable to call 'pushComponentToEL'.

However, what you said about PreRenderComponentEvent is very interesting. I have never tried this event. Is this a better event to use for dynamic component creation? I try to have an 'authoritative blog entry' on how to do dynamic component creation in JSF 2. This is based on discussions with both the Mojarra and MyFaces team. Here is what they recommended:

http://blog.kennardconsulting.com/2010/10/safely-manipulating-component-tree-with.html

All of the SystemEvent Acid Tests (JAVASERVERFACES-1826) use this same technique. So either:

1. I am wrong to use PreRenderViewEvent for dynamic component creation, and should use PreRenderComponentEvent instead
2. Components that use PreRenderViewEvent can never access EL like #{internal}

Which do you think?

Richard.

Comment by kennardconsulting [ 07/Nov/11 09:09 PM ]

Okay I have done some further experiments. Using PreRenderComponentEvent in the Acid Test (JAVASERVERFACES-1826) does not work well. Nothing gets persisted into the ViewState. I believe PreRenderComponentEvent is triggered too late in the cycle to do dynamic component tree manipulation?

Therefore I believe 2 (above) is correct:

"Components that use PreRenderViewEvent can never access EL like #{internal}"

And by implication:

"Components that use dynamic component tree manipulation can never access EL like #{internal}"

If this is 'works as designed' then I think we need to revisit the design.

Comment by Manfred Riem [ 23/Mar/12 05:05 PM ]

Closing resolved issue out

Comment by kennardconsulting [ 29/Aug/12 07:10 AM ]

Hi guys,

I just hit this bug again while working on a client's code, and noticed Manfred had closed it as 'resolved'?

Why was this considered 'resolved'? It's a real problem for me, stopping me doing things like...

<h:dataTable value="#{companyImport.importFiles}" var="_importFile">
<h:column>
<h:outputText value="#{_importFile.name}:"/>
</h:column>
<h:column>
<m:metawidget value="#{_importFile.import}"/>
</h:column>
</h:dataTable>

...because the m:metawidget cannot 'see' the #{_importFile} var.

Can we please reopen, or at least explain why it is resolved?

Comment by temaleva [ 19/Nov/12 03:57 PM ]

Hi.
I am absolutely agree with Kennrad.
I could not even vote on this issue while it closed.

I use metawidget and other dynamic stuff in my project and also starving from this problem.

Just explain a little bit.

There is also a trivial example which demonstrate this problem.
This code won't work because f: tags are specific to the component, not to the iterated item. At view build time the #{column} isn't available. It's only available during render time.
<p:columns id="#{table_id}_column" value="#{fields}" var="column" columnIndexVar="colIndex" sortBy="#{column}">
<h:outputText value="#{data_request[column.value][0]}">
<f:converter converterId="#{column.converterID}" />
</h:outputText>
</p:columns>

This could only overcome if you have converter list on a build time and this will work:
<p:columns id="#{table_id}_column" value="#{fields}" var="column" columnIndexVar="colIndex" sortBy="#{column}">
<h:outputText value="#{data_request[column.value][0]}" converter="#{converters[column.converterID]}"/>
</p:columns>

So the only solution one could use for metawidget is almost the same: to create a Mapped collection of Items in Bean (simplest case).
So the code should looks like:

<h:dataTable value="#{companyImport.importFileIds}" var="_importFileId">
<h:column>
<m:metawidget value="#{companyImport.importFile[_importFileId][import]}"/>
</h:column>
</h:dataTable>

So An iterator variable accessible only for facelet page itself during render time.
And the question is: How could we use facelet page at all (for dynamic processing) if it's rendered content is not available?

Comment by temaleva [ 20/Nov/12 06:13 AM ]

Sorry, I mean binding of course not value. So this way <m:metawidget binding="#{companyImport.importFile[_importFileId][import]}"/>





[JAVASERVERFACES-1883] AjaxExeptionHandlerImpl has t.printStackTrace() Created: 03/Dec/10  Updated: 26/Jun/12  Resolved: 20/Mar/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: current
Fix Version/s: 2.2.0-m01

Type: Bug Priority: Major
Reporter: dmsinotte Assignee: rogerk
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle-1883.txt    
Status Whiteboard:

size_small importance_small jsf_2_1_1

Tags: jsf impl 3_1-exclude
Participants: dmsinotte and rogerk

 Description   

I had logged this once already but it seems to have gotten lost in the transition to the new tracking system.

The com.sun.faces.context.AjaxExeptionHandlerImpl.handle() method contains a statement:

t.printStackTrace();

which prints out the current exception in the queue to the console. It appears to be a debugging statement that was ported over during a large merge of state saving code at one point. In our case, we have a custom exception handler and when adding it to the queue, the exception triggers this stack trace to be printed out and there doesn't appear to be anything we can do about it.



 Comments   
Comment by rogerk [ 18/Jan/11 11:44 AM ]

triage

Comment by rogerk [ 15/Mar/11 07:32 AM ]

Fix.

Comment by rogerk [ 15/Mar/11 07:33 AM ]

Checked into trunk. Will check into 2.1.1 branch.

Comment by rogerk [ 15/Mar/11 07:38 AM ]

checked into 2.1.1 branch as well.

Comment by rogerk [ 15/Mar/11 07:39 AM ]

reopening temporartily to include status whiteboard

Comment by rogerk [ 15/Mar/11 07:40 AM ]

closing as fixed.





[JAVAEETUTORIAL-16] Bean Validation null string comparison code snippet would throw NPE Created: 22/Dec/10  Updated: 16/Aug/12  Resolved: 11/May/11

Status: Closed
Project: javaeetutorial
Component/s: doc
Affects Version/s: 6.0.5
Fix Version/s: 6.0.7-5

Type: Bug Priority: Major
Reporter: Ian Evans Assignee: devikag
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

http://download.oracle.com/javaee/6/tutorial/doc/gircz.html#gkcrg


Tags: jsf bean validation
Participants: devikag and Ian Evans

 Description   

"In this case, the user input for the field is not required.

if (testString.equals(null)) { doSomething(); } else { doAnotherThing(); }

By default, the doAnotherThing method is called even when the user enters no data, because the testStringelement has been initialized with the value of an empty string."

This code is broken in that if testString actually were null, the code would throw a NullPointerException instead of correctly checking the comparison.

It should be:
if (testString == null) { doSomething(); }
} else { doAnotherThing(); }



 Comments   
Comment by devikag [ 11/May/11 09:19 PM ]

Code snippet modified as per user suggestion.

The chapter(9) is updated and the modified content will be visible after next publication.





[JAVAEETUTORIAL-12] Add lifecycle information to volume 2 Created: 30/Sep/10  Updated: 16/Aug/12  Resolved: 20/Apr/11

Status: Closed
Project: javaeetutorial
Component/s: doc
Affects Version/s: 6.0.4
Fix Version/s: 6.0.5

Type: Bug Priority: Major
Reporter: Kim Haase Assignee: devikag
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12
Tags: JSF lifecycle
Participants: devikag and Kim Haase

 Description   

Michael Amanti made the following suggestion:

The Java EE 6 Tutorial
Chapter 4 "JavaServer Pages Technology"

4'th edition papaerback's page 79...

Subsection "The Lifecycle of the hello Application"
http://download.oracle.com/javaee/6/tutorial/doc/gjaam.html#gjbnc
5'th Paragraph...
"During the execute phase, several actions can take place:

  • The application view is built or restored.
  • The request parameter values are applied.
  • Conversions and validations are performed for component values.
  • Backing beans are updated with component values.
  • Application logic is invoked.

.........................................
I beleive this is the very first location in the tutorial where the
6 Request Processing LifeCycles are referred to.
They should be referred to by their formal names...

1) Restore View
2) Apply Request Values
3) Process Validations
4) Update Model
5) Invoke Application
6) Render Response

Perhaps a 2 columned table would do the trick...
column 1 contain the formal names and column 2 contain the brief descriptions.


We have been planning to keep lifecycle phase details out of volume 1 and
describe them in volume 2 instead.



 Comments   
Comment by devikag [ 20/Apr/11 08:52 PM ]

Detailed information for JavaServer Faces Life cycle has always been planned to be included in Java EE tutorial Volume 2.

Java EE Tutorial Volume 2 online version now provides JSF Life cycle information here:

http://download.oracle.com/javaee/6/tutorial/doc/bnaqq.html





[GRIZZLY-1557] Embedded Grizzly:The FacesServlet cannot have a url-pattern of /*. Created: 30/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

Status: Closed
Project: grizzly
Component/s: http-servlet
Affects Version/s: 2.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: noelgaur Assignee: Unassigned
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: embedded jsf servlet url-pattern
Participants: noelgaur and Ryan Lubke

 Description   

After deploying jsf application on grizzly embedded server navigating to /jsf/ url,
it throws INTERNAL ERROR on browser The FacesServlet cannot have a url-pattern of /*

expected: it should direct to index.xhtml page jsf/index.xhtml page

Same test case can be used as one I provided through email for GRIZZLY#1550 issue.
do let me know if you need test case again?

Initialization code:
=====================
Map<String,String> initmap = new HashMap<String,String>();

initmap.put("javax.faces.PROJECT_STAGE", "Development");
initmap.put("com.sun.faces.forceLoadConfiguration", "true");

ctx.addListener(com.sun.faces.config.ConfigureListener.class);

ServletRegistration reg = ctx.addServlet("Faces Servlet",
javax.faces.webapp.FacesServlet.class);
reg.setInitParameters(initmap);
reg.setAsyncSupported(true);
reg.addMapping(".jsf",".xhtml",".faces","/.xhtml");
ctx.deploy(webServer);

Log:
====
Jul 30, 2013 6:55:12 PM com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra 2.2.0 ( 20130502-2118 https://svn.java.net/svn/mojarra~svn/tags/2.2.0@11930) for context '/jsf'
Jul 30, 2013 6:55:12 PM com.sun.faces.spi.InjectionProviderFactory createInstance
INFO: JSF1048: PostConstruct/PreDestroy annotations present. ManagedBeans methods marked with these annotations will have said annotations processed.
Jul 30, 2013 6:55:14 PM com.sun.faces.lifecycle.ELResolverInitPhaseListener populateFacesELResolverForJsp
INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
Jul 30, 2013 6:55:14 PM org.primefaces.webapp.PostConstructApplicationEventListener processEvent
INFO: Running on PrimeFaces 3.5
Jul 30, 2013 6:55:14 PM org.glassfish.grizzly.servlet.WebappContext initServlets
INFO: [webapp] Servlet [javax.faces.webapp.FacesServlet] registered for url pattern(s) [[*.jsf, *.xhtml, *.faces, /*.xhtml]].
Jul 30, 2013 6:55:14 PM org.glassfish.grizzly.servlet.WebappContext deploy
INFO: Application [webapp] is ready to service requests. Root: [/jsf].
Application started.
For Jersey tryout: http://localhost:9998/heartbeat
For static html tryout: http://localhost:9998/static/index.html
For JSF tryout http://localhost:9998/jsf/index.xhtml
Enter any key to exit
Jul 30, 2013 6:55:29 PM org.glassfish.grizzly.servlet.ServletHandler loadServlet
INFO: Loading Servlet: javax.faces.webapp.FacesServlet
Jul 30, 2013 6:55:29 PM org.glassfish.grizzly.servlet.ServletHandler doServletService
SEVERE: service exception:
javax.servlet.ServletException: javax.servlet.ServletException: The FacesServlet cannot have a url-pattern of /*. Please define a different url-pattern.
at org.glassfish.grizzly.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:151)
at org.glassfish.grizzly.servlet.FilterChainImpl.invokeFilterChain(FilterChainImpl.java:106)
at org.glassfish.grizzly.servlet.ServletHandler.doServletService(ServletHandler.java:222)
at org.glassfish.grizzly.servlet.ServletHandler.service(ServletHandler.java:170)
at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:211)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.servlet.ServletException: The FacesServlet cannot have a url-pattern of /*. Please define a different url-pattern.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
at org.glassfish.grizzly.servlet.FilterChainImpl.doFilter(FilterChainImpl.java:147)
... 7 more
Caused by: javax.faces.FacesException: The FacesServlet cannot have a url-pattern of /*. Please define a different url-pattern.
at com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:329)
at com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:153)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
... 8 more



 Comments   
Comment by Ryan Lubke [ 30/Jul/13 04:49 PM ]

This error is coming from the Mojarra runtime. It's there to keep the JSP mapping from being clobbered. However, if you're not using JSP for your views, I don't see why it shouldn't be allowed. I would recommend opening an issue with them [1].

[1] https://javaserverfaces.java.net





[GRIZZLY-1556] Embedded Grizzly: Cannot inject Managed Beans in JSF application. Created: 30/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

Status: Closed
Project: grizzly
Component/s: http-servlet
Affects Version/s: 2.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: noelgaur Assignee: Unassigned
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: embedded jsf servlet grizzly managedbean injection
Participants: noelgaur and Ryan Lubke

 Description   

Unable to inject managed beans in jsf application, in the logs it shows:
[null] The ELResolvers for JSF were not registered with the JSP container.

Same test case can be used as the one provided for GRIZZLY#1550 issue.
Do let me know if you need me to email it again?

Jul 30, 2013 6:55:12 PM com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra 2.2.0 ( 20130502-2118 https://svn.java.net/svn/mojarra~svn/tags/2.2.0@11930) for context '/jsf'
Jul 30, 2013 6:55:12 PM com.sun.faces.spi.InjectionProviderFactory createInstance
INFO: JSF1048: PostConstruct/PreDestroy annotations present. ManagedBeans methods marked with these annotations will have said annotations processed.
Jul 30, 2013 6:55:14 PM com.sun.faces.lifecycle.ELResolverInitPhaseListener populateFacesELResolverForJsp
INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
Jul 30, 2013 6:55:14 PM org.primefaces.webapp.PostConstructApplicationEventListener processEvent
INFO: Running on PrimeFaces 3.5
Jul 30, 2013 6:55:14 PM org.glassfish.grizzly.servlet.WebappContext initServlets

Dependencies:
==============
<dependency>
<groupId>org.glassfish.grizzly</groupId>
<artifactId>grizzly-http-servlet</artifactId>
<version>2.3.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-grizzly2-servlet</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>3.5</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>el-impl</artifactId>
<version>2.2</version>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.3</version>
</dependency>



 Comments   
Comment by Ryan Lubke [ 30/Jul/13 05:47 PM ]

Mojarra will only scan for annotated classes in WEB-INF/classes and WEB-INF/lib.

You'll need to structure your application around that fact.

This means:
1) Using the war packaging type in your pom.xml
2) Ensure that your server's root directory is the base directory of the exploded war (simplest way to do this, is to run the JVM from that directory).





[GLASSFISH-20793] GF4 deployment error when having two web projects under one ear with equal managed bean names Created: 03/Sep/13  Updated: 06/Sep/13  Resolved: 06/Sep/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: replicant77 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win 7 Pro 64Bit
GlassFish Server Open Source Edition 4.0 (build 89)
GlassFish 4.0.1 b04 09/03/2013
jdk1.7.0_21


File Attachments: Zip Archive GLASSFISH-20793_demo.zip    
Tags: jsf glassfish4 weld cdi
Participants: jjsnyder83, Manfred Riem, replicant77 and TangYong

 Description   

We are currently evaluating glassfish 4 for migration of our enterprise projects from glassfish 3.1.2.2. One problem we noticed is that now deployment fails with an ambiguity error message when having two web projects under one ear with equal managed bean names (see stacktrace below). In this case we created two simple jsf web projects contained in the same ear. Both wars contain a managed bean with same managed bean names ('greetingBean'). On GF3.x it works without problems.

@Named
@RequestScoped
public class GreetingBean {

public String getGreeting() { return "Hello from " + getClass().getName(); }

}

-------
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:639)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:488)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
... 36 more
-------



 Comments   
Comment by TangYong [ 03/Sep/13 03:04 PM ]

Component/s should be CDI.

Comment by Manfred Riem [ 03/Sep/13 03:08 PM ]

Reassigning to JJ as this looks like a CDI specific issue.

Comment by TangYong [ 03/Sep/13 03:21 PM ]

Change Component/s into CDI

Comment by TangYong [ 04/Sep/13 04:29 AM ]

I did a demo(attachment) to re-produce the issue.

PL. JJ confirms it.

Notice that the following,

1. Bean in different wars should be allowed to have the same EL name
https://issues.jboss.org/browse/CDI-188

2. Ambiguous name validation should not cross visibility boundaries
https://issues.jboss.org/browse/WELD-1065

From JBOSS Team's reply,
"
It is not portable to have multiple classes of the same name within the deployment. Weld currently does not support this..."

It seems that this issue is not still planned to be fix.

Thanks
Tang

Comment by TangYong [ 04/Sep/13 06:34 AM ]

New Confirmation is as following:

1. The issue can be re-produced using GlassFish 4.0.1 b04 09/03/2013

http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/nightly/latest-glassfish.zip (b04 09/03/2013)

2. The issue does not happen using wildfly-8.0.0.Alpha4
"
15:01:23,451 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-ear.ear
15:01:23,498 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.1.Final
15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment eartwowars-war1-1.0.0.war
15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-war2-1.0.0.war
15:01:23,607 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: eartwowars-ear.ear
15:01:23,638 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.3 (Final)
15:01:23,732 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment eartwowars-ear.ear
15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018210: Register web context: /eartwowars-war1
15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS018210: Register web context: /eartwowars-war2
15:01:24,670 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "eartwowars-ear.ear" (runtime-name : "eartwowars-ear.ear")"

3. GlassFish 4.0.1 b04 and wildfly-8.0.0.Alpha4 all uses weld-osgi-bundle 2.0.3.Final.

So, I can make an initial conclusion that maybe the issue is caused by GlassFish Weld Integration and I raised up Priority of the issue.

Comment by replicant77 [ 04/Sep/13 07:50 AM ]

Interesting to notice is that switching from cdi to jsf managed bean declarations resolves the issue. As we reference these beans in jsf pages, this is a better workaround for us than renaming the bean names.

@javax.faces.bean.ManagedBean
@javax.faces.bean.RequestScoped
//@javax.inject.Named
//@javax.enterprise.context.RequestScoped
public class GreetingBean {

public String getGreeting() { return "Hello from " + getClass().getName(); }

}

Comment by TangYong [ 04/Sep/13 08:16 AM ]

Java EE 7(or Higher) recommended using backing bean(using CDI concept) with JSF rather than ManagedBean. The ManagedBean has been outdated and although the workaround is valid for your current issue, It is hard to say that in the future, once GlassFish does not support ManagedBean, whether you will come back the scene again.

Backing to the issue, I am investigating it and this should belong to Bean visibility problem while building BDAs.

Thanks
Tang

Comment by TangYong [ 04/Sep/13 09:46 AM ]

JJ

The reason for the issue has been found as following,

For an ear with two wars, while deploying the ear, GlassFish Weld Integration created several Bean Managers corresponding to different BDAs. Among them, there is a Bean Manager liking AppBda_XXX-YYY which corresponds to the EAR BDA, and there are also two Bean Managers which correspond to the wars. The important point is that the EAR's Bean Manager's getAccessibleManagers() contains the wars's Bean Managers.

Then, while org.jboss.weld.bootstrap.Validator calls the following,

public void validateBeanNames(BeanManagerImpl beanManager) {
...
for (Bean<?> bean : beanManager.getAccessibleBeans()) { ... }

getAccessibleBeans() will call org.jboss.weld.manager.BeanManagers.buildAccessibleClosure(...),

The buildAccessibleClosure(...) will obtain all contained Bean Managers related to current Bean Manager by using getAccessibleManagers().

So, war1 and war2's beans with the same name will be added Validator's "namedAccessibleBeans" as following,

for (Bean<?> bean : beanManager.getAccessibleBeans()) {
if (bean.getName() != null) { namedAccessibleBeans.put(bean.getName(), bean); }
}

And the exception happened.

Deeply, the issue should be related to Bean Manager's visibility. I think that we should not make war1 and war2's Bean Manager visible to EAR's Bean Manager.

Thanks
Tang

Comment by jjsnyder83 [ 04/Sep/13 01:10 PM ]

I also spoke with the JBoss guys and this should be valid. I will look at it shortly.

Comment by TangYong [ 05/Sep/13 02:11 AM ]

JJ

Fixing place has been confirmed as following,

Class: org.glassfish.weld.DeploymentImpl
Method: addAppBda()
Place to need to fix:
private void addAppBda() {
...
// make all bdas visible to the app Bda. But none have visibility to App Bda
for ( BeanDeploymentArchive oneBda : beanDeploymentArchives ) {
if ( ! oneBda.equals(appBda)) { appBda.getBeanDeploymentArchives().add(oneBda); }
}
}

Whether can remove the above logic and make appBda not contain any child bda?

Thanks
Tang

Comment by TangYong [ 05/Sep/13 02:23 AM ]

I have made an fixing by removing the above logic, then , replaced the weld-integration bundle using self-built version on 4.0.1-b02. While deploying demo(attachment),

E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\bin>asadmin deploy E:\NanjingJUG\GLASSFISH-20793\ear\target\eartwowars-ear.ear
Application deployed with name eartwowars-ear.
Command deploy executed successfully.

[server.log]
...
[2013-09-05T11:19:31.304+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571304] [levelValue: 800] [[
Loading application eartwowars-ear#eartwowars-war1-1.0.0.war at [/eartwowars-war1]]]

[2013-09-05T11:19:31.336+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571336] [levelValue: 800] [[
Loading application eartwowars-ear#eartwowars-war2-1.0.0.war at [/eartwowars-war2]]]

[2013-09-05T11:19:31.398+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571398] [levelValue: 800] [[
eartwowars-ear was successfully deployed in 4,171 milliseconds.]]

Pl. confirming the fix.

Thanks
Tang

Comment by jjsnyder83 [ 05/Sep/13 11:11 AM ]

I have been looking into the issue and tried the same change but it causes a tck failure. I have to remove the app bda completely and at the same time provide a fix for the tck failure. I should have something soon.

Comment by jjsnyder83 [ 05/Sep/13 09:53 PM ]

Ok, I have a fix that I will submit tomorrow.

Comment by jjsnyder83 [ 06/Sep/13 03:07 PM ]

Committed revision 62703





[GLASSFISH-20492] [fishcat] Glassfish latest (1 may) : JSF and @Inject doesn't print output Created: 08/May/13  Updated: 08/May/13  Resolved: 08/May/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b87_RC3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: survivant Assignee: jjsnyder83
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Product Version: NetBeans IDE Dev (Build 201305052300)
Java: 1.7.0_13; Java HotSpot(TM) Client VM 23.7-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_13-b20
System: Windows XP version 5.1 running on x86; Cp1252; fr_CA (nb)
User directory: C:\Documents and Settings\sdionne1\Application Data\NetBeans\dev
Cache directory: C:\Documents and Settings\sdionne1\Local Settings\Application Data\NetBeans\Cache\dev


Tags: fishcat inject cdi ejb jsf
Participants: jjsnyder83 and survivant

 Description   

I use Netbeans to generate a simple sample.

I use a servlet to test @Inject, a CDIManagedBean and a @Stateless EJB.

if I enter the URL :

http://localhost:8080/TestCDI/PerformanceGate

I got this output :

Output from class com.demo.CDIManagedBean at : 519201693741621
Output from class com.demo.EJBManagedBean at : 519201693763646

and I test the JSF page with :

http://localhost:8080/TestCDI/

and got :

from JSF :

I should get something like this

from JSF : Message from Output from class com.demo.CDIManagedBean at : 519347151889153 and Output from class com.demo.EJBManagedBean at : 519347151924821

My JSF is

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
from JSF : #{index.message}
</h:body>
</html>

package com.demo;

import javax.enterprise.inject.Model;
import javax.inject.Inject;

/**
*

  • @author sdionne1
    */
    @Model
    public class Index {

@Inject
CDIManagedBean bean;

@Inject
EJBManagedBean ejb;

public String getMessage(){ return "Message from " + bean.getOutput() + " and " + ejb.getOutput(); //return "test"; }
}


I can provide a 7z file if requested.

here the others files

package com.demo;

/**
*
* @author sdionne1
*/
public class CDIManagedBean {

public String getOutput(){ return "Output from " + CDIManagedBean.class + " at : " + System.nanoTime(); }
}




package com.demo;

import javax.ejb.Stateless;

/**
*
* @author sdionne1
*/
@Stateless
public class EJBManagedBean {

public String getOutput(){ return "Output from " + EJBManagedBean.class + " at : " + System.nanoTime(); }
}


package com.demo;

import javax.enterprise.inject.Model;
import javax.inject.Inject;

/**
*
* @author sdionne1
*/
@Model
public class Index {

@Inject
CDIManagedBean bean;

@Inject
EJBManagedBean ejb;

public String getMessage(){ return "Message from " + bean.getOutput() + " and " + ejb.getOutput(); //return "test"; } }
}

package com.demo;

import java.io.IOException;
import java.io.PrintWriter;
import javax.inject.Inject;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
*

  • @author sdionne1
    */
    @WebServlet(name = "PerformanceGate", urlPatterns = {"/PerformanceGate"})
    public class PerformanceGate extends HttpServlet {

@Inject
CDIManagedBean bean;

@Inject
EJBManagedBean ejb;

/**

  • Processes requests for both HTTP
  • <code>GET</code> and
  • <code>POST</code> methods.
    *
  • @param request servlet request
  • @param response servlet response
  • @throws ServletException if a servlet-specific error occurs
  • @throws IOException if an I/O error occurs
    */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
    Unknown macro: { response.setContentType("text/html;charset=UTF-8"); PrintWriter out = response.getWriter(); try { /* TODO output your page here. You may use following sample code. */ out.println("<!DOCTYPE html>"); out.println(bean.getOutput()); out.println("<br />"); out.println(ejb.getOutput()); } finally { out.close(); } }

// <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on the left to edit the code.">
/**

  • Handles the HTTP
  • <code>GET</code> method.
    *
  • @param request servlet request
  • @param response servlet response
  • @throws ServletException if a servlet-specific error occurs
  • @throws IOException if an I/O error occurs
    */
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException { processRequest(request, response); }

    /**
    * Handles the HTTP
    * <code>POST</code> method.
    *
    * @param request servlet request
    * @param response servlet response
    * @throws ServletException if a servlet-specific error occurs
    * @throws IOException if an I/O error occurs
    */
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException { processRequest(request, response); } }

/**

  • Returns a short description of the servlet.
    *
  • @return a String containing servlet description
    */
    @Override
    public String getServletInfo() { return "Short description"; }// </editor-fold>

}



 Comments   
Comment by jjsnyder83 [ 08/May/13 02:08 PM ]

I need an application with source code that I can deploy in order to help you. Please send it to me: j.j.snyder@oracle.com

Comment by jjsnyder83 [ 08/May/13 06:38 PM ]

It seems that it was a NetBeans issue in that the application that was deployed did not contain the correct artifacts.





[GLASSFISH-19849] how to solve the situation when two JSF-implementations existed Created: 13/Mar/13  Updated: 29/May/13  Resolved: 29/May/13

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: houtang Assignee: Ed Burns
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

every


Tags: jsf
Participants: Ed Burns, houtang and Shing Wai Chan

 Description   

Hi, all:

When I deploy a web application to the GFV3 or GFV4. The server.log shows the error message as "Both MyFaces and the RI are on your classpath. Please make sure to use only one of the two JSF-implementations." , I want to know whether any of you have been met this situation before and tell me how to avoid this error message.

The error message comes out when I deployed the attached web application though the application can be deployed successfully.

I have also attached the server.log.(http://www.java.net/comment/reply/895588#comment-form

Thanks
houtang



 Comments   
Comment by Shing Wai Chan [ 13/Mar/13 03:40 AM ]

Assign to jsf team for further investigation.

Comment by Ed Burns [ 29/May/13 04:08 PM ]

I looked at this BalusC posting on StackOverflow.

http://stackoverflow.com/questions/10290123/myfaces-jsf-impl-with-glassfish-3-1-not-working

That post talks about how to make it so the bundled MyFaces impl takes priority over the one from the container.

It seems you are trying to do the opposite: to make the bundled MyFaces be ignored. If that's true, the only safe way to do that is to not bundle it in the war in the first place.

I hope this is an acceptable resolution. Really, it is not a best practice to bundle things in a WAR unless you actually plan to use them. Doing so can have unintended side-effects.

Comment by Ed Burns [ 29/May/13 04:08 PM ]

I looked at this BalusC posting on StackOverflow.

http://stackoverflow.com/questions/10290123/myfaces-jsf-impl-with-glassfish-3-1-not-working

That post talks about how to make it so the bundled MyFaces impl takes priority over the one from the container.

It seems you are trying to do the opposite: to make the bundled MyFaces be ignored. If that's true, the only safe way to do that is to not bundle it in the war in the first place.

I hope this is an acceptable resolution. Really, it is not a best practice to bundle things in a WAR unless you actually plan to use them. Doing so can have unintended side-effects.





[GLASSFISH-19115] Unable to access public schema for FacesConfig schema, facesconfig_2_1.xsd Created: 28/Sep/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: None
Fix Version/s: 3.1.2.2

Type: Bug Priority: Major
Reporter: eraghu Assignee: rogerk
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jsf
Participants: eraghu, ian.trimble, jclingan and rogerk

 Description   

Access to the public schema for FaceConfig, http://java.sun.com/xml/ns/javaee/web-facesconfig_2_1.xsd , results in re-direction to the OTN website. This affects JSF tool support in Eclipse.



 Comments   
Comment by jclingan [ 09/Oct/12 01:18 PM ]

Looking into this ...

Comment by jclingan [ 09/Oct/12 11:09 PM ]

Identified the issue. Working to resolve.

Comment by jclingan [ 09/Oct/12 11:55 PM ]

This issue has been resolved. Sorry for the 'bug'.

Comment by ian.trimble [ 09/Oct/12 11:58 PM ]

Thanks. We appreciate it.

Comment by jclingan [ 10/Oct/12 12:03 AM ]

Resolved.





[GLASSFISH-18992] Bean creation is blocked across all threads until method annotated with @PostConstruct has finished Created: 10/Aug/12  Updated: 22/Oct/12  Resolved: 22/Oct/12

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Vetle Leinonen-Roeim Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2.2


Tags: cdi weld jsf
Participants: jjsnyder83 and Vetle Leinonen-Roeim

 Description   

Bean creation is blocked across all threads until method annotated with @PostConstruct has finished. For more information and how to reproduce it, see WELD-1157: https://issues.jboss.org/browse/WELD-1157

The bug has been fixed in Weld 1.1.9.Final.

To fix this issue, upgrade the Weld version to 1.1.9.Final.



 Comments   
Comment by jjsnyder83 [ 22/Oct/12 02:22 PM ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665. This should be fixed now.





[GLASSFISH-18826] Infinite(?) loop in UIComponentBase.publishAfterViewEvents Created: 22/Jun/12  Updated: 22/Feb/13  Resolved: 13/Nov/12

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Vetle Leinonen-Roeim Assignee: rogerk
Resolution: Duplicate Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1, Linux, JDK 1.6.0_24


Issue Links:
Related
is related to JAVASERVERFACES-2600 Infinite(?) loop in UIComponentBase.p... Closed
Tags: jsf mojarra 311
Participants: chernanq88, cur3n4vjara1, Manfred Riem, rogerk and Vetle Leinonen-Roeim

 Description   

When running performance tests on our application, we recently saw four threads using 100% CPU.
A thread dump reveals the following stack trace:

"http-thread-pool-8080(24)" daemon prio=10 tid=0x0000000054c2e800 nid=0x67a5 runnable [0x000000004e30f000]
java.lang.Thread.State: RUNNABLE
at javax.faces.component.UIComponent.popComponentFromEL(UIComponent.java:1961)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2214)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2210)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2202)
at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1883)
at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:400)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2631)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2603)
at com.sun.faces.facelets.tag.jsf.ComponentSupport.addComponent(ComponentSupport.java:559)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.addComponentToView(ComponentTagHandlerDelegateImpl.java:290)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:769)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

The threads seem to be stuck in UIComponentBase.publishAfterViewEvents. Unfortunately this bug is not consistent, and it's the first time that we've seen it during our performance tests.



 Comments   
Comment by chernanq88 [ 29/Oct/12 10:51 PM ]

I have gotten a very similar issue, the difference is that it happends on a weblogic 10.3.4, i have 4 instances of my application and it was shown only in one.
i use icefaces 3.0.0 but the Thread is Stuck in the same place, the behaviour is the same, the process consumes 100% CPU watching it from the Red Hat process list.

JSF Mojarra 2.1.9
Icefaces 3.0.0
Linux Red Hat
Weblogic 10.3.4
jrockit-jdk1.6.0_29-R28.2.2-4.1.0

this Stuck Thread was gotten when running performance tests and it has been Stuck for 4 days and it does not change its status yet.

"[STUCK] ExecuteThread: '68' for queue: 'weblogic.kernel.Default (self-tuning)'" id=192 idx=0x2fc tid=13408 prio=1 alive, native_blocked, daemon

at javax/faces/component/UIComponent.popComponentFromEL(UIComponent.java:1910)[optimized]

at javax/faces/component/UIComponent.popComponentFromEL(UIComponent.java:1936)[optimized]

at javax/faces/component/UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2218)[optimized]

at javax/faces/component/UIComponentBase.doPostAddProcessing(UIComponentBase.java:1883)[inlined]

at javax/faces/component/UIComponentBase.setParent(UIComponentBase.java:400)[optimized]

at javax/faces/component/UIComponentBase$ChildrenList.add(UIComponentBase.java:2635)[inlined]

at javax/faces/component/UIComponentBase$ChildrenList.add(UIComponentBase.java:2607)[optimized]

at com/icesoft/faces/component/menubar/MenuItems.setParentsRecursive(MenuItems.java:127)[inlined]

at com/icesoft/faces/component/menubar/MenuItems.prepareChildren(MenuItems.java:99)[inlined]

at com/icesoft/faces/component/menubar/MenuItemsRenderer.encodeChildren(MenuItemsRenderer.java:37)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[optimized]

at com/icesoft/faces/component/menubar/MenuBarRenderer.encodeChildren(MenuBarRenderer.java:100)

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at javax/faces/component/UIComponent.encodeAll(UIComponent.java:1779)[optimized]

at javax/faces/render/Renderer.encodeChildren(Renderer.java:168)[optimized]

at org/icefaces/impl/renderkit/RendererWrapper.encodeChildren(RendererWrapper.java:49)

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[inlined]

at com/icesoft/faces/renderkit/dom_html_basic/GridRenderer.encodeChildren(GridRenderer.java:191)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[inlined]

at com/icesoft/faces/renderkit/dom_html_basic/GridRenderer.encodeChildren(GridRenderer.java:191)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[inlined]

at com/icesoft/faces/renderkit/dom_html_basic/GridRenderer.encodeChildren(GridRenderer.java:191)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[inlined]

at com/icesoft/faces/renderkit/dom_html_basic/GroupRenderer.encodeChildren(GroupRenderer.java:79)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:341)[inlined]

at com/icesoft/faces/renderkit/dom_html_basic/GroupRenderer.encodeChildren(GroupRenderer.java:79)[optimized]

at javax/faces/component/UIComponentBase.encodeChildren(UIComponentBase.java:845)[optimized]

at javax/faces/component/UIComponent.encodeAll(UIComponent.java:1779)[optimized]

at javax/faces/component/UIComponent.encodeAll(UIComponent.java:1782)[optimized]

at org/icefaces/impl/context/DOMPartialViewContext.processPartial(DOMPartialViewContext.java:146)[optimized]

at javax/faces/component/UIViewRoot.encodeChildren(UIViewRoot.java:981)[optimized]

at javax/faces/component/UIComponent.encodeAll(UIComponent.java:1779)[optimized]

at com/sun/faces/application/view/FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390)[optimized]

at com/sun/faces/application/view/MultiViewHandler.renderView(MultiViewHandler.java:131)[inlined]

at com/sun/faces/lifecycle/RenderResponsePhase.execute(RenderResponsePhase.java:121)[optimized]

at com/sun/faces/lifecycle/Phase.doPhase(Phase.java:101)[optimized]

at com/sun/faces/lifecycle/LifecycleImpl.render(LifecycleImpl.java:139)[optimized]

at javax/faces/webapp/FacesServlet.service(FacesServlet.java:594)[optimized]

at weblogic/servlet/internal/StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)[optimized]

at weblogic/servlet/internal/StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)[inlined]

at weblogic/servlet/internal/ServletStubImpl.execute(ServletStubImpl.java:300)[optimized]

at weblogic/servlet/internal/TailFilter.doFilter(TailFilter.java:26)[optimized]

at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:56)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311)[optimized]

at org/springframework/security/web/access/intercept/FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116)[inlined]

at org/springframework/security/web/access/intercept/FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/access/ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/session/SessionManagementFilter.doFilter(SessionManagementFilter.java:101)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/authentication/AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/servletapi/SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/savedrequest/RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45)

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/authentication/AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:182)

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/authentication/logout/LogoutFilter.doFilter(LogoutFilter.java:105)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/context/SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/session/ConcurrentSessionFilter.doFilter(ConcurrentSessionFilter.java:125)[optimized]

at org/springframework/security/web/FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)[optimized]

at org/springframework/security/web/FilterChainProxy.doFilter(FilterChainProxy.java:173)[optimized]

at org/springframework/web/filter/DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)[inlined]

at org/springframework/web/filter/DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)[optimized]

at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:56)[optimized]

at weblogic/servlet/internal/RequestEventsFilter.doFilter(RequestEventsFilter.java:27)[optimized]

at weblogic/servlet/internal/FilterChainImpl.doFilter(FilterChainImpl.java:56)[inlined]

at weblogic/servlet/internal/WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)[inlined]

at weblogic/servlet/internal/WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)[optimized]

at weblogic/security/acl/internal/AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)[optimized]

at weblogic/security/service/SecurityManager.runAs(SecurityManager.java:120)[inlined]

at weblogic/servlet/internal/WebAppServletContext.securedExecute(WebAppServletContext.java:2277)[inlined]

at weblogic/servlet/internal/WebAppServletContext.execute(WebAppServletContext.java:2183)[optimized]

at weblogic/servlet/internal/ServletRequestImpl.run(ServletRequestImpl.java:1454)[optimized]

at weblogic/work/ExecuteThread.execute(ExecuteThread.java:207)[inlined]

at weblogic/work/ExecuteThread.run(ExecuteThread.java:176)[optimized]

at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)

– end of trace

Comment by Manfred Riem [ 13/Nov/12 03:24 PM ]

Closing as duplicate, see associated issue for resolution.

Comment by Manfred Riem [ 17/Dec/12 04:13 PM ]

Can you supply us with an example application (with sources) that demonstrates the problem? Can you verify if it is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 17/Jan/13 02:34 PM ]

Lowering priority on JSF side because of no response

Comment by cur3n4vjara1 [ 07/Feb/13 02:37 AM ]

I believe the issue is on these lines:

UIComponent.java
for (UIComponent topComponent = componentELStack.peek();
           topComponent != this;
           topComponent = componentELStack.peek())
      {
          topComponent.popComponentFromEL(context);
      }

Is it possible that this goes on forever if the component is not in the stack, due to UIComponent not being thread safe?
Thanks

Comment by Manfred Riem [ 20/Feb/13 05:47 PM ]

Can you verify if the application in question is using component binding?

Comment by Vetle Leinonen-Roeim [ 22/Feb/13 08:40 AM ]

Yes, our application does use component binding in some places.

We have not had time to do more testing on this issue, but will start performance testing again soon, and let you know if we have more details.





[GLASSFISH-18453] multipart/form-data problem with myfaces extension filter Created: 06/Mar/12  Updated: 29/May/13  Resolved: 29/May/13

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: dani_drio Assignee: Ed Burns
Resolution: Works as designed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 3.1.2 build 23, jre 7, ubuntu linux


File Attachments: Zip Archive TestCharset.zip    
Status Whiteboard:

myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

The same application works with glassfish 3.1, 3.0.1

Tags: jsf form encoding multipart
Participants: dani_drio, Ed Burns and kchung

 Description   

myfaces ExtensionsFilter doesn't work with glassfish 3.1.2. A h:form with multipart/form-data with page encoding utf-8 sets h:inputText with wrong charset. As a result the database is corrupted with unreadable chars and the page is reloaded with strange characters. Also no file is upload by the managed bean. Maybe related with issue GLASSFISH-16740?

The same application works with glassfish 3.1, 3.0.1



 Comments   
Comment by kchung [ 10/Mar/12 01:06 AM ]

Are you doing the file upload with servlet 3.0 Request.getPart() or on your own. If it is the latter, you may want to see if the patch in http://java.net/jira/browse/GLASSFISH-18444 fixes your problem.

Otherwise, you'll need to come up with a simple test case for me to work on.

Comment by dani_drio [ 10/Mar/12 11:13 AM ]

Related to the charset problem I attach a simple NetBeans project (TestCharset.zip) with a web app. Only one jsp exists with a simple form. To test:

  • Run the project
  • In the jsp form input type 'ó' and click the 'Send' button.
  • The input now shows 'ó' instead of 'ó'

Now, remove the enctype="multipart/form-data" and the forms works ok.

I tested the patch web-core.jar you suggested but not solve the problem.

Thanks in advance.

Comment by kchung [ 12/Mar/12 07:56 PM ]

The problem has nothing to do with multipart processing in the container. In fact, the following JSP page show the same symptom.

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<html>
<body>

<form method="post" action="form.jsp">
<input type="text" name="name" value="${param.name}" size="12"/>
<input type="submit"/>
</form>

</body>
</html>

The problem is with the character encoding of the POST data. Depending on the browser, the request encoding may not be specified correctly.

If I add the following line after the page directive, it works as expected.

<% request.setCharacterEncoding("UTF8"); %>

Comment by dani_drio [ 13/Mar/12 08:23 AM ]

In my opinion the problem is with the web engine (or something related to JSF). The browser should receive the same headers related to encoding in both cases. If you try this JSF it will not work:

<%@page contentType="text/html" pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<% request.setCharacterEncoding("UTF-8"); %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<f:view>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
<body>
<h:form id="mainForm" enctype="multipart/form-data">
<div>
<h:inputText size="12"/>
</div>
<h:commandButton value="Send"/>
</h:form>
</body>
</html>
<h:messages/>
</f:view>

This JSF has the request.setCharacterEncoding("UTF-8") as you suggested and works properly with older glassfish versions (with o without multipart) and in glassfish 3.1.2 when the multipart is not present. So, has no sense to get different behavior. It makes impossible to work our CMS with multi-language web applications.

Thanks.

Comment by kchung [ 13/Mar/12 11:03 PM ]

In your JSF test, what is the easiest way to display the text from h:inputText. Sorry I don't know JSF too much.

The addition of enctype="multipart/form-data" to h:form seems to do something strange. If I add an action to H:commandButton, it wouldn't even go there!

Comment by dani_drio [ 14/Mar/12 08:42 AM ]

Only needs to press the "Send" button. Because no binding to a managed bean exists JSF will restore the value automatically in the input.

I check the "action" for commandButton and works fine. So, in principle I discard a problem here.

I check the HTTP headers the browser receives with firebug and in both cases, with and without "multipart/form-data", seems to be ok.

It appears the problem is in the process of extracting the parameter values from the multi-part response the server receives. I think the server is assuming incorrectly the response is ISO-8859-1.

Comment by kchung [ 14/Mar/12 07:42 PM ]

Hmm.. I only got a blank in the input after hitting "Send" button. Running glassfish trunk with Internet Explorer 8.

If the problem is just using the wrong char encoding when extracting the request parameters, then inserting a java scriptlet to set the request char encoding should work. The thing that I am not sure of is when the code is executed. With JSF, there may be some timing issue.

It'd be great if you can come up with a test without JSF.

Comment by dani_drio [ 15/Mar/12 08:24 AM ]

I see some light ... I made a test without JSF and works as you says in previous message: it's needed the "request.setCharacterEncoding("UTF-8");" to work in both cases with and without multipart. That is not a surprise, and in the past (when no JSF exists) we forced this in a web filter.

When JSF is used I think mojarra do some "magic" process to set the properly enconding based in the last request or something similar. Googling I see this value is saved in the session attribute "javax.faces.request.charset". If you print the session attributes in the jsp:

<%
for (Enumeration e = request.getSession().getAttributeNames(); e.hasMoreElements(); ) { String att = (String)e.nextElement(); out.println(att + ": " + request.getAttribute(att) + "<br/>"); }
%>

You will see this.

So, mojarra seems to works different that in previous versions, and the worse is the behavior is different with or wihout multipart.

Please, can you change the state of this bug to open?

Tanhks in advance.

Comment by kchung [ 15/Mar/12 04:17 PM ]

reopen and assign to Ed Burns to look into this further.

Comment by kchung [ 27/Mar/12 05:19 PM ]

I've fixed a related issue, http://java.net/jira/browse/GLASSFISH-18453. Can you verify if that also fixes this issue?

Comment by kchung [ 27/Mar/12 05:21 PM ]

Oops. I meant http://java.net/jira/browse/GLASSFISH-18516

Comment by dani_drio [ 27/Mar/12 06:15 PM ]

No, I try the last 4.0 (build 27) and has the same problem.

Comment by kchung [ 29/Mar/12 09:38 PM ]

Build 27 does not include the fix. Try b30.

Comment by dani_drio [ 31/Mar/12 10:35 PM ]

No, b30 does not solve the problem.

Comment by dani_drio [ 10/Sep/12 12:42 PM ]

Causally I found a solution. The problem seems to appear when this combination occurs:

  • the form is multipart
  • the page has a page directive declaring the encoding: <%@page pageEncoding="UTF-8"%>

The solution is:

  • declare in descriptor glassfish-web.xml the param: <parameter-encoding default-charset="UTF-8"/>
  • remove the page directive in all the jsf pages.

This solution also removes from the log the typical warning:

"Unable to set request character encoding to UTF-8 from context xxxx, because request parameters have already been read, or ServletRequest.getReader() has already been called"

regards.





[GLASSFISH-17894] Both JSF 2.1.0 and 2.1.4 embedded and jar mixup Created: 04/Dec/11  Updated: 08/Dec/11  Resolved: 06/Dec/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.2_b12
Fix Version/s: 3.1.2_b13, 3.1.2_b14

Type: Bug Priority: Major
Reporter: fabmars Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7 x86


File Attachments: Text File changebundle.txt    
Tags: jsf build glass fish 3_1_2-review
Participants: Ed Burns, fabmars and rogerk

 Description   

After installation of glassfish-3.1.2-b12-windows.exe, one can see in /glassfish3/glassfish/modules:

  • javax.faces.jar containing both api and impl JSF 2.1.4 (20111107-SNAPSHOT)
  • jsf-impl.jar containing JSF 2.1.0 (2.1.0-b11-FCS)
  • NO jsf-api.jar (so the eclipse glassfish plugin also gets upset)

It was already like that on 3.1.2-b10, the first promoted I tried.
On 3.1.1 there were only jsf-api.jar and jsf-impl.jar, but I heard there were discussions over a new javax jar scheme in 3.1.2.

Workaround: rework the jars manually from the distrib.



 Comments   
Comment by rogerk [ 05/Dec/11 09:28 PM ]

We did switch over to one JSF jar in the modules directory - namely javax.faces.jar.
However, I just downloaded a promoted zip distribution - glassfish-3.1.2-b12.zip
unzipped it, and noticed that under the modules directory there was:
jsf-api.jar
jsf-impl.jar
javax.faces.jar

Comment by rogerk [ 05/Dec/11 09:45 PM ]

From: snjezana.sevozenzerovic@oracle.com
To: roger.kitain@oracle.com
Sent: Monday, December 5, 2011 1:41:25 PM GMT -08:00 US/Canada Pacific
Subject: Fwd: [JIRA] Commented: (GLASSFISH-17894) Both JSF 2.1.0 and 2.1.4 embedded and jar mixup

[I would have commented directly on the issue but for some reason java.net barfs when I try to log in...]

Roger, I think you are missing jsf-api and jsf-impl exclusions in packager/pom.xml file in 3.1.2 branch so old jsf jars get pulled in as transitive dependencies of some external project. I think I already mentioned this to Ed week or so ago but he apparently never updated the file.

Thanks,

Snjezana

Comment by rogerk [ 05/Dec/11 09:46 PM ]

On 12/5/11 4:43 PM, Snjezana Sevo-Zenzerovic wrote:
> Just checked - jsf-api is on the exclude list and I don't see it in freshly built distribution anymore. So, please add jsf-impl to the list, too, make sure you don't see it in the distribution anymore and at point you should be able to close this issue.
>
> Thanks,
>
> Snjezana

Comment by rogerk [ 05/Dec/11 09:47 PM ]

Looks like pilot error -

jsf-ri is listed in list for <packager.artifact.excludes>.
It should probably be listed as jsf-impl

Ed is doing a 2.1.6 integration into 3.1.2 so we'll make sure that is fixed.

Comment by rogerk [ 05/Dec/11 09:54 PM ]

Ed - we need to make sure GlassFish packager/pom.xml file has jsf-impl on <packager.artifact.excludes> list (instead of jsf-ri) for 2.1.6 integration.

Comment by Ed Burns [ 06/Dec/11 02:02 AM ]

Consider this text from the Maven and OSGi packaging and naming guide <http://www.java.net/external?url=http://wikis.sun.com/display/GlassFish/Maven+Versioning+Rules>.

B> - an implementation jar file
B>
B> If the Java specification defines a standalone version of the
B> technology, the implementation jar file will be such a
B> standalone implementation of the specification, and will meet
B> all the compatibility requirements of the specification. The
B> implementation jar file typically includes all the classes from
B> the API jar file, plus whatever implementation classes are needed
B> to produce a complete runtime.

The correct distribution should have only javax.faces.jar, not jsf-api.jar and jsf-impl.jar. I am certain that the mojarra integration done just before the blog entry where I described all this <http://weblogs.java.net/blog/edburns/archive/2011/09/02/jcpjavaee-artifacts-maven-central> was correct and had only the one jar.

Somehow the multiple jars have crept back in. I will fix it.

Ed

Comment by Ed Burns [ 06/Dec/11 02:23 PM ]

Yes, I made this mistake:

svn cat -r 49388 packager/pom.xml | grep jsf-ri
<packager.artifact.excludes>stax-api,stax,junit,jtype,tiger-types,servlet-api,jstl-api,el-api,jsp-api,org.osgi.core,org.osgi.compendium,concurrent,amx-core,amx-core-impl,amx-config,amx-config-impl,amx-j2ee,amx-j2ee-impl,amx-ext-impl,gmbal-api-only,jsf-api,jsf-ri</packager.artifact.excludes>

When I committed revision 49388 on that file, the string "jsf-ri" should have been "jsf-impl".

Fixing this now.

Ed

Comment by Ed Burns [ 06/Dec/11 02:28 PM ]

Ready for review.

Comment by Ed Burns [ 06/Dec/11 08:44 PM ]

Extraneous Mojarra jar in GlassFish zip http://java.net/jira/browse/GLASSFISH-17894

SECTION: Modified files

M packager/pom.xml

Correct error committed by edburns on revision 49388. In the
packager.artifact.excludes list, the string "jsf-ri" should be
"jsf-impl".

r=snjezana
Sending packager/pom.xml
Transmitting file data .
Committed revision 51320.

Comment by fabmars [ 07/Dec/11 11:57 PM ]

jsf-impl.jar is still present in b13.

Comment by fabmars [ 08/Dec/11 12:10 AM ]

and the same for EL





[GLASSFISH-17414] @ViewScoped is not working with Glassfish 3.1.1 Created: 12/Oct/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alexandre Verri Assignee: rogerk
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64 bits, Java 1.6_b26.


Tags: jsf viewscope
Participants: Alexandre Verri and rogerk

 Description   

The @ViewScoped annotation (javax.faces.bean.ViewScoped) is not working.

The example to reproduce is bellow. Click in the UI button and the page will not be refreshed.

@Named("bean")
@ViewScoped
public class BackingBean implements Serializable {

private Long value = new Long(0);

private List<Long> values = new ArrayList<Long>();

public List<Long> getValues() { return values; }

public void addToList() { values.add(value); }

public Long getValue() { return value; }

public void setValue(Long value) { this.value = value; }

}

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
<title>List Edit</title>
</h:head>
<h:body>
<h:form id="form">
Value : <h:inputText value="#{bean.value}" />
<h:commandButton value="Add" action="#{bean.addToList()}" />
</h:form>
<br/>
<h3>Values</h3>
<ui:repeat value="#{bean.values}" var="val">
#{val}
<br/>
</ui:repeat>
</h:body>

</html>



 Comments   
Comment by rogerk [ 18/Oct/11 06:32 PM ]

You are using a CDI managed bean buy the fact that you have annotated your bean with @Named.
If you use the JSF annotation @Managed(name="bean") it will work.
Also see this article:
http://www.verborgh.be/articles/2010/01/06/porting-the-viewscoped-jsf-annotation-to-cdi/





[GLASSFISH-17161] NulllPointerException in GFFileHandler after using FINEST in many log settings. Created: 08/Aug/11  Updated: 18/Jan/12  Resolved: 19/Aug/11

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: wmartinez Assignee: srinik76
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1. Windows 7 professional Spanish


File Attachments: File logging.properties    
Issue Links:
Duplicate
duplicates GLASSFISH-17037 Switching log levels persistently bre... Closed
is duplicated by GLASSFISH-18205 Changing a log level via Admin Consol... Resolved
Tags: logging jsf
Participants: Anissa Lam, srinik76 and wmartinez

 Description   

A fresh install if glassfish 3.1.1. To debug a JSF problem, I changed from INFO to FINEST all the log properties that had JSF, using the web console.
Next day, GF is not starting showing:

---------------
Launching GlassFish on Felix platform
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.server.logging.GFFileHandler.postConstruct(GFFileHandler.java:159)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:701)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:374)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more
Completed shutdown of GlassFish runtime
---------------

Looking at the logging properties, I found out there is only log level indications, with lots of properties like com.sun.enterprise.server.logging.GFFileHandler.file missing. Attached is that properties file.
This is the third installation of glassfish trashed after adjusting the log properties.



 Comments   
Comment by Anissa Lam [ 19/Aug/11 03:32 PM ]

This is duplicate of GLASSFISH-17037.
The workaround is to run a CLI command after adjusting/changing the log levels in console.

%asadmin set-log-levels com.sun.enterprise.server.logging.GFFileHandler=ALL
Specify the --target option for a server instance other than the domain administration server (DAS).





[GLASSFISH-16163] JSF 2.x should not run in 1.x modus when web.xml is declared as Servlet 2.5 Created: 05/Mar/11  Updated: 03/Jun/11  Resolved: 03/Jun/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: balusc Assignee: rogerk
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: glassfish jsf
Participants: balusc and rogerk

 Description   

Source: http://stackoverflow.com/questions/5208390

Glassfish appears to put JSF 2.x in 1.x modus when web.xml is declared as Servlet 2.5. This makes no sense since JSF 2.x is designed to be backwards compatible with Servlet 2.5.

The 1.x modus should only kick in when the `web.xml` is declared as Servlet 2.4.



 Comments   
Comment by rogerk [ 03/Jun/11 06:14 AM ]

Unless I'm missing something here, I cannot reproduce your issue.
We have many JSF 2.0 demo applications with web.xml version declarations of 2.5, and they run and deploy fine - in both JSF 2.0.X and 2.1.X.





[GLASSFISH-15657] ResourceBundle isn't getting reloaded. Created: 22/Jan/11  Updated: 28/Feb/13  Resolved: 13/Nov/12

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: v3.0.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: jigar.m.joshi Assignee: Ed Burns
Resolution: Duplicate Votes: 4
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

jdk 1.6.20 ,glassfish V3, windows xp, jsf 2.0


Issue Links:
Related
is related to JAVASERVERFACES-2594 ResourceBundle isn't getting reloaded. Closed
Status Whiteboard:

size_medium importance_small

Tags: glassfish i18n/l10n jsf
Participants: Ed Burns, jigar.m.joshi, just4look, Manfred Riem and mayankmodi

 Description   

I am using view level resource bundle.

<f:loadBundle var="msg" basename="MyMessages"/>

and I have MyMessages.properties file in classpath directly.

For testing purpose I modify properties file [externally]I have a button that will reload the resource bundle by calling

public String reloadMyBundle() {
try { ResourceBundle.getBundle("MyMessages").clearCache(); ResourceBundle.getBundle("MyMessages").clearCache(Thread.currentThread().getContextClassLoader());//I am not sure which one exactly to use so added all possibilities for testing :p ResourceBundle.clearCache(); ResourceBundle.clearCache(Thread.currentThread().getContextClassLoader()); } catch (Exception ex) { ex.printStackTrace(); }

return null;
}

But it ResourceBundle isn't getting refreshed.
It works with other server.



 Comments   
Comment by jigar.m.joshi [ 07/Feb/11 02:47 AM ]

This isn't particularly related to JSF I think, And Can I have temporary fix to this issue or anything that can help.

Comment by mayankmodi [ 30/May/11 03:25 AM ]

Any updates on this issue!

Comment by just4look [ 11/Sep/11 08:31 PM ]

There are another case for the similar bug.

When updating the locale of FacesContext, the ResourceBundle configured in faces-config.xml wouldn't update.

Comment by Ed Burns [ 12/Sep/11 05:32 PM ]

Attach work estimate.

Comment by Manfred Riem [ 13/Nov/12 03:05 PM ]

Closing duplicate, see associated issue for resolution

Comment by Manfred Riem [ 19/Feb/13 02:11 PM ]

Can you verify if this is still a problem on the latest 2.1 release?

Comment by mayankmodi [ 28/Feb/13 05:49 AM ]

This issue still persist in Glassfish-3.1.2.2. Is there any patch available?





[CARGOTRACKER-28] The JSF pages show errors in NetBeans Created: 07/Aug/13  Updated: 08/Aug/13  Resolved: 08/Aug/13

Status: Closed
Project: cargotracker
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: rcervera Assignee: reza_rahman
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jsf
Participants: Kim Haase, rcervera and reza_rahman

 Description   

The JSF pages contain red icons in the Project Browser when you open the project in NetBeans 7.3.1.

This issue is presumably fixed by using the http://xmlns.jcp.org/jsf namespace instead of the http://java.sun.com/jsf namespace.



 Comments   
Comment by reza_rahman [ 07/Aug/13 06:41 PM ]

Could you kindly include a screenshot? This might be a NetBeans bug.

Comment by Kim Haase [ 07/Aug/13 06:47 PM ]

Actually, I was seeing the red icons this morning too, but not after I cleared out the workspace and did a full svn update. Also, CARGOTRACKER-26 has fixed the namespace issue now.

I don't know what caused the red icons, since the old namespace is still supported.

Comment by rcervera [ 07/Aug/13 07:01 PM ]

You are right Kim, I'm not getting the red icons any more. This is not a bug anymore then.

Comment by reza_rahman [ 07/Aug/13 07:11 PM ]

I am resolving this for now, please close when confirmed. The red lines should not be occurring - at best the old namespace should generate a yellow warning. If it persists, the right thing to do is filing a NetBeans bug, referring to this one.

Strangely, this is not happening for me and I use 7.3.1...

Comment by reza_rahman [ 07/Aug/13 07:20 PM ]

Closing upon confirmation. Please reopen if needed.

Comment by reza_rahman [ 08/Aug/13 04:12 AM ]

I tried with a fresh install and I do indeed see the issue. I'm reopening this bug and filing a NetBeans bug: https://netbeans.org/bugzilla/show_bug.cgi?id=234112. I'll close it when I can confirm that the issue is fixed in NetBeans.

Comment by reza_rahman [ 08/Aug/13 07:21 PM ]

I've confirmed that this has been fixed in the NetBeans 7.4 nightly builds. I made a note in our documentation warning users about NetBeans bugs.





Generated at Fri Apr 25 01:19:59 UTC 2014 using JIRA 4.0.2#472.