[jira] [Updated] (MYFACES-3989) MalformedURLException when javax.faces.FACELETS_LIBRARIES contains line feed
[
https://issues.apache.org/jira/browse/MYFACES-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Kieselhorst updated MYFACES-3989:
Status: Patch Available (was: Open)
MalformedURLException when javax.faces.FACELETS_LIBRARIES contains line feed
Key: MYFACES-3989
URL: https://issues.apache.org/jira/browse/MYFACES-3989
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.8
Reporter: Dennis Kieselhorst
Priority: Minor
Fix For: 2.2.9
Attachments: MYFACES-3989.patch
If javax.faces.FACELETS_LIBRARIES is specified in several lines
{code:xml}
context-param
param-namejavax.faces.FACELETS_LIBRARIES/param-name
param-value/WEB-INF/tags/popup/popup.taglib.xml;
/WEB-INF/tags/component/component.taglib.xml/param-value
/context-param
{code}
FacesConfigurator will fail with a MalformedURLException:
{noformat}
ERROR o.a.m.c.FacesConfigurator - Could not read resource
/WEB-INF/tags/component/component.taglib.xml
java.net.MalformedURLException:
/WEB-INF/tags/component/component.taglib.xml
at
org.eclipse.jetty.webapp.WebAppContext.getResource(WebAppContext.java:351)
at
org.mortbay.jetty.plugin.JettyWebAppContext.getResource(JettyWebAppContext.java:338)
at
org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1325)
at
org.apache.myfaces.context.servlet.ServletExternalContextImplBase.getResource(ServletExternalContextImplBase.java:127)
at
org.apache.myfaces.config.FacesConfigurator.getResourceLastModified(FacesConfigurator.java:293)
at
org.apache.myfaces.config.FacesConfigurator.getLastModifiedTime(FacesConfigurator.java:398)
at
org.apache.myfaces.config.FacesConfigurator.update(FacesConfigurator.java:469)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:231)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1484)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at
com.deutscheboerse.comxerv.common.util.LoggedInUserFilter.doFilterInternal(LoggedInUserFilter.java:33)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MYFACES-3989) MalformedURLException when javax.faces.FACELETS_LIBRARIES contains line feed
Dennis Kieselhorst created MYFACES-3989:
---
Summary: MalformedURLException when javax.faces.FACELETS_LIBRARIES
contains line feed
Key: MYFACES-3989
URL: https://issues.apache.org/jira/browse/MYFACES-3989
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.8
Reporter: Dennis Kieselhorst
Priority: Minor
If javax.faces.FACELETS_LIBRARIES is specified in several lines
{code:xml}
context-param
param-namejavax.faces.FACELETS_LIBRARIES/param-name
param-value/WEB-INF/tags/popup/popup.taglib.xml;
/WEB-INF/tags/component/component.taglib.xml/param-value
/context-param
{code}
FacesConfigurator will fail with a MalformedURLException:
{noformat}
ERROR o.a.m.c.FacesConfigurator - Could not read resource
/WEB-INF/tags/component/component.taglib.xml
java.net.MalformedURLException:
/WEB-INF/tags/component/component.taglib.xml
at
org.eclipse.jetty.webapp.WebAppContext.getResource(WebAppContext.java:351)
at
org.mortbay.jetty.plugin.JettyWebAppContext.getResource(JettyWebAppContext.java:338)
at
org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1325)
at
org.apache.myfaces.context.servlet.ServletExternalContextImplBase.getResource(ServletExternalContextImplBase.java:127)
at
org.apache.myfaces.config.FacesConfigurator.getResourceLastModified(FacesConfigurator.java:293)
at
org.apache.myfaces.config.FacesConfigurator.getLastModifiedTime(FacesConfigurator.java:398)
at
org.apache.myfaces.config.FacesConfigurator.update(FacesConfigurator.java:469)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:231)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1484)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at
com.deutscheboerse.comxerv.common.util.LoggedInUserFilter.doFilterInternal(LoggedInUserFilter.java:33)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOBAGO-1463) Define ordering in the faces-config.xml files.
Florian Paul created TOBAGO-1463: Summary: Define ordering in the faces-config.xml files. Key: TOBAGO-1463 URL: https://issues.apache.org/jira/browse/TOBAGO-1463 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Facelets Affects Versions: 2.0.7 Reporter: Florian Paul Priority: Minor The faces-config.xml files should be in an ordering, to ensure usage of secured commands of the tobago-security extension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1462) Input Suggest: no selection on click
Volker Weber created TOBAGO-1462: Summary: Input Suggest: no selection on click Key: TOBAGO-1462 URL: https://issues.apache.org/jira/browse/TOBAGO-1462 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.7 Reporter: Volker Weber Assignee: Udo Schnurpfeil reproducable on [http://www.irian.biz/tobago-example-demo-2.0.x] @ [~lofwyr] this demo is a 2.0.0 version, but i dont think this is fixed in trunk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: How is org.apache.myfaces.webapp.WebConfigParamsLogger.java generated?
Hey Mike, Yes I'm all set. The issue was resolved here: https://issues.apache.org/jira/browse/MYFACES-3977 Thanks, Paul Nicolucci From: Mike Kienenberger mkien...@gmail.com To: MyFaces Development dev@myfaces.apache.org Date: 04/28/2015 12:50 PM Subject:Re: How is org.apache.myfaces.webapp.WebConfigParamsLogger.java generated? Paul, Did you ever make any progress on this issue? On Thu, Mar 19, 2015 at 4:14 PM, Paul Nicolucci pnico...@us.ibm.com wrote: Hello All, How is the org.apache.myfaces.webapp.WebConfigParamsLogger.java generated? I ask because it seems that the following is logged when javax.faces.STATE_SAVING_METHOD is set to Client rather than client: [WARNING ] Wrong value in context init parameter 'javax.faces.STATE_SAVING_METHOD' (='Client'), using default value 'server' However the value for javax.faces.STATE_SAVING_METHOD should not care about case. I see that in javax.faces.application.StateManager.java when the parameter is actually used a equalsIgnoresCase is used when reading the parameter. I think an update is needed to ensure incorrect information is not logged to a user. Thoughts? Thanks, Paul Nicolucci
[jira] [Commented] (MYFACES-3984) Unable to add an ELResolver programmatically when application includes flows defined with xml
[ https://issues.apache.org/jira/browse/MYFACES-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519694#comment-14519694 ] Mike Kienenberger commented on MYFACES-3984: Can you discuss this issue and the two possible solutions on the dev@myfaces.apache.org mailing list? Perhaps you could also provide a patch demonstrating which approach you believe works best. Unable to add an ELResolver programmatically when application includes flows defined with xml - Key: MYFACES-3984 URL: https://issues.apache.org/jira/browse/MYFACES-3984 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.8 Reporter: Sami Korhonen Current implementation of Application interfaces caches CompositeELResolver internally. According to Application interface definition ELResolvers may be added until application receives first request. This means that, if ELResolver is retrieved before first request, Application implementation does not behave correctly. There are several ways to resolve this issue. One solution is to create a lazy initializing ELResolver when Application (Impl) is instantiated. This lazy ELResolver should be initialized on first actual call. Second possible solution also requires creating ELResolver instance when Application is instatiated. In this solution you add new ELResolvers after reading configuration files. In order to support MyFaces specific sorting feature, you are required to cache and sort entries in another structure before registering them to Application's ELResolver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
An empty tag in a custom tag-lib causes an Exception
Good afternoon, I posted this as a bug here: https://issues.apache.org/jira/browse/MYFACES-3988 At the request of Mike I am resposting the question here to elicit some feedback. Here were his other comments: Also, is your Glassfish/Wildfly container using Mojarra as the JSF implementation? If nothing else, MyFaces could provide a configuration parameter which would ignore empty render type tag contents and continue onward. Do you mind submitting a patch to provide such behavior? To answer Mike's questions: I tested this on Glassfish 4.1 using Mojarra 2.2.7: [2015-04-29T15:18:19.896-0400] [glassfish 4.1] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=87 _ThreadName=Thread-26] [timeMillis: 1430335099896] [levelValue: 800] [[ Initializing Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7@13362) for context '']] Using my simple test a text box is displayed using Mojarra, but it isn't displayed with MyFaces. For reference, here is my original post: While developing a custom tag library we added an empty renderer-type tag like this: tag tag-namemyinput/tag-name component component-typemy.test.MyInput/component-type renderer-type/renderer-type /component /tag This causes the following exception: Caused by: java.lang.Exception: Value Cannot be Empty at org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl $LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl $FragmentContentDispatcher.dispatch(Unknown Source) ... This appears to be expected based on the code in TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears to be thrown on elements which are used in another spot. If any of them are empty they will throw the above exception. Wildfly/Glassfish does not have the same behavior, so my assumption is they just ignore it. Should the MyFaces code be modified to just continue on without the exception, based on the reference implementation? I can quickly create something if so, I just wanted to bring this up to the community at large since I don't know the reasoning behind the difference of the implementations. Christopher Meyer Software Developer (919) 543-9782 T/L: 441-9782
SimpleDateFormatter test failures for Tomahawk under Java 8
I was building Tomahawk under OpenJDK 8, and I noticed the following issue:
yyy returns 1987 but expects 87
y returns 1987 but expects 87
Commented out those test data sets got me past the failures, but I'm
not sure if that is the approach we need to take. I guess I'd say
that we really don't care about yyy and y, but only yy and
.
Also, it's unclear to me whether all three of these files need to be
changed, or only the first one -- are the core12 and core20 files
generated from core or separately maintained?
Index:
core/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
Index:
core12/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
Index:
core20/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
Index:
core/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
===
---
core/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(revision 1676764)
+++
core/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(working copy)
@@ -95,9 +95,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+//yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
@@ -146,9 +146,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+//yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
Index:
core12/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
===
---
core12/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(revision 1676764)
+++
core12/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(working copy)
@@ -95,9 +95,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+//yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
@@ -146,9 +146,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+//yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
Index:
core20/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
===
---
core20/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(revision 1676764)
+++
core20/src/test/java/org/apache/myfaces/dateformat/TestSimpleDateFormatter.java
(working copy)
@@ -95,9 +95,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+ // yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
@@ -146,9 +146,9 @@
String[] data =
{
, 1987,
-yyy, 87,
+//yyy, 87,
yy, 87,
-y, 87,
+//y, 87,
, March,
MMM, Mar,
MM, 03,
[jira] [Updated] (TOMAHAWK-1675) Deprecated API using in the graphicImageDynamic example
[ https://issues.apache.org/jira/browse/TOMAHAWK-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Kienenberger updated TOMAHAWK-1675: Resolution: Fixed Fix Version/s: 1.1.15-SNAPSHOT Assignee: Mike Kienenberger Status: Resolved (was: Patch Available) Applied the patch (with formatting changes). Thanks! Deprecated API using in the graphicImageDynamic example --- Key: TOMAHAWK-1675 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1675 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples Affects Versions: 1.1.15-SNAPSHOT Reporter: Pavel Samolysov Assignee: Mike Kienenberger Priority: Minor Fix For: 1.1.15-SNAPSHOT Attachments: GraphicImageDynamicTextBean.java.patch I tried to build myfaces from scratch and have got a problem: tomahawk/sandbox/examples does not compile with Java 8 because it uses the com.sun.image.codec.jpeg package is deprecated. I fixed this error by change to the ImageIO API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRINIDAD-2522) ThreadLocalResetter in GlobalConfiguratorImpl null in case of shared trinidad jars
Volker Malzahn created TRINIDAD-2522: Summary: ThreadLocalResetter in GlobalConfiguratorImpl null in case of shared trinidad jars Key: TRINIDAD-2522 URL: https://issues.apache.org/jira/browse/TRINIDAD-2522 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: Windows 7, JBoss 7, Java 7 Reporter: Volker Malzahn Issue: when deploying an ear file with trinidad jars in shared lib directory and 2 (or more) embedded war files which use Trinidad sometimes user gets following NullPointerException: 11:24:08,569 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (http-/0.0.0.0:1084-7) java.lang.NullPointerException at org.apache.catalina.connector.Response.toAbsolute(Response.java:1676) at org.apache.catalina.connector.Response.encodeURL(Response.java:1194) at org.apache.catalina.connector.ResponseFacade.encodeURL(ResponseFacade.java:354) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at org.springframework.security.web.context.SaveContextOnUpdateOrErrorResponseWrapper.encodeURL(SaveContextOnUpdateOrErrorResponseWrapper.java:114) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at com.sun.faces.context.ExternalContextImpl.encodeResourceURL(ExternalContextImpl.java:544) at org.apache.myfaces.trinidad.util.ExternalContextURLEncoder.encodeResourceURL(ExternalContextURLEncoder.java:69) at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:102) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedResourceURI(CoreRenderer.java:1103) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:128) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:679) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeEnd(HeadRenderer.java:97) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:538) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1210) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1826) Reason for this NPE: URLEncoderFactory has static variable _local which stores a thread local which points to URLEncoder to be used. If that thread local isn't cleared at the end of a request an old URLEncoder (more concrete an old ExternalContextURLEncoder) may be used at one of the next requests which has a reference to an old ExternalContext which causes the NPE in ((HttpServletResponse) response).encodeURL(url). Trinidad has ThreadLocalResetter in GlobalConfiguratorImpl (stored in _threadResetter) which has responsibility to clean up thread locals at the end of each request. But _threadResetter could be null in scenario ear file with trinidad jars in shared lib directory and 2 (or more) embedded war files which use Trinidad. Reason: - GlobalConfiguratorImpl has static map _CONFIGURATORS which is filled in GlobalConfiguratorImpl.getInstance(), key is Thread.currentThread().getContextClassLoader(). I.e. we have multiple GlobalConfiguratorImpl instances if we have multiple ContextClassLoaders. - GlobalConfiguratorImpl ._threadResetter is initialized in GlobalConfiguratorImpl.__setThreadLocalResetter() which is called by ThreadLocalResetter.init() which is called by static method ThreadLocalUtils._getThreadLocalManager(String) which stores result in its static map _threadLocalManagers (independently of current ContextClassLoader). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRINIDAD-2522) ThreadLocalResetter in GlobalConfiguratorImpl null in case of shared trinidad jars
[ https://issues.apache.org/jira/browse/TRINIDAD-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519543#comment-14519543 ] Mike Kienenberger commented on TRINIDAD-2522: - Would you be willing to create a patch with a solution for this issue? ThreadLocalResetter in GlobalConfiguratorImpl null in case of shared trinidad jars -- Key: TRINIDAD-2522 URL: https://issues.apache.org/jira/browse/TRINIDAD-2522 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: Windows 7, JBoss 7, Java 7 Reporter: Volker Malzahn Issue: when deploying an ear file with trinidad jars in shared lib directory and 2 (or more) embedded war files which use Trinidad sometimes user gets following NullPointerException: 11:24:08,569 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (http-/0.0.0.0:1084-7) java.lang.NullPointerException at org.apache.catalina.connector.Response.toAbsolute(Response.java:1676) at org.apache.catalina.connector.Response.encodeURL(Response.java:1194) at org.apache.catalina.connector.ResponseFacade.encodeURL(ResponseFacade.java:354) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at org.springframework.security.web.context.SaveContextOnUpdateOrErrorResponseWrapper.encodeURL(SaveContextOnUpdateOrErrorResponseWrapper.java:114) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at javax.servlet.http.HttpServletResponseWrapper.encodeURL(HttpServletResponseWrapper.java:114) at com.sun.faces.context.ExternalContextImpl.encodeResourceURL(ExternalContextImpl.java:544) at org.apache.myfaces.trinidad.util.ExternalContextURLEncoder.encodeResourceURL(ExternalContextURLEncoder.java:69) at org.apache.myfaces.trinidadinternal.config.URLEncoderExternalContext.encodeResourceURL(URLEncoderExternalContext.java:102) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at javax.faces.context.ExternalContextWrapper.encodeResourceURL(ExternalContextWrapper.java:132) at org.apache.myfaces.trinidad.render.CoreRenderer.renderEncodedResourceURI(CoreRenderer.java:1103) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:128) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:679) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeEnd(HeadRenderer.java:97) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:538) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1210) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1826) Reason for this NPE: URLEncoderFactory has static variable _local which stores a thread local which points to URLEncoder to be used. If that thread local isn't cleared at the end of a request an old URLEncoder (more concrete an old ExternalContextURLEncoder) may be used at one of the next requests which has a reference to an old ExternalContext which causes the NPE in ((HttpServletResponse) response).encodeURL(url). Trinidad has ThreadLocalResetter in GlobalConfiguratorImpl (stored in _threadResetter) which has responsibility to clean up thread locals at the end of each request. But _threadResetter could be null in scenario ear file with trinidad jars in shared lib directory and 2 (or more) embedded war files which use Trinidad. Reason: - GlobalConfiguratorImpl has static map _CONFIGURATORSwhich is filled in GlobalConfiguratorImpl.getInstance(), key is Thread.currentThread().getContextClassLoader(). I.e. we have multiple GlobalConfiguratorImpl instances if we have multiple ContextClassLoaders. - GlobalConfiguratorImpl ._threadResetter is initialized in GlobalConfiguratorImpl.__setThreadLocalResetter() which is called by ThreadLocalResetter.init() which is called by static method ThreadLocalUtils._getThreadLocalManager(String) which stores result in its static map _threadLocalManagers (independently of current ContextClassLoader). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3988) An empty tag in a custom tag-lib causes an Exception
[ https://issues.apache.org/jira/browse/MYFACES-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519560#comment-14519560 ] Mike Kienenberger commented on MYFACES-3988: Would you mind reposting your question on dev@myfaces.apache.org so it can be discussed? Also, is your Glassfish/Wildfly container using Mojarra as the JSF implementation? If nothing else, MyFaces could provide a configuration parameter which would ignore empty render type tag contents and continue onward. An empty tag in a custom tag-lib causes an Exception Key: MYFACES-3988 URL: https://issues.apache.org/jira/browse/MYFACES-3988 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Christopher Meyer Priority: Minor While developing a custom tag library we added an empty renderer-type tag like this: tag tag-namemyinput/tag-name component component-typemy.test.MyInput/component-type renderer-type/renderer-type /component /tag This causes the following exception: Caused by: java.lang.Exception: Value Cannot be Empty at org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl$LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) ... This appears to be expected based on the code in TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears to be thrown on elements which are used in another spot. If any of them are empty they will throw the above exception. Wildfly/Glassfish does not have the same behavior, so my assumption is they just ignore it. Should the MyFaces code be modified to just continue on without the exception, based on the reference implementation? I can quickly create something if so, I just wanted to bring this up to the community at large since I don't know the reasoning behind the difference of the implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-3988) An empty tag in a custom tag-lib causes an Exception
[ https://issues.apache.org/jira/browse/MYFACES-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519560#comment-14519560 ] Mike Kienenberger edited comment on MYFACES-3988 at 4/29/15 3:30 PM: - Would you mind reposting your question on dev@myfaces.apache.org so it can be discussed? Also, is your Glassfish/Wildfly container using Mojarra as the JSF implementation? If nothing else, MyFaces could provide a configuration parameter which would ignore empty render type tag contents and continue onward. Do you mind submitting a patch to provide such behavior? was (Author: mkienenb): Would you mind reposting your question on dev@myfaces.apache.org so it can be discussed? Also, is your Glassfish/Wildfly container using Mojarra as the JSF implementation? If nothing else, MyFaces could provide a configuration parameter which would ignore empty render type tag contents and continue onward. An empty tag in a custom tag-lib causes an Exception Key: MYFACES-3988 URL: https://issues.apache.org/jira/browse/MYFACES-3988 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.8 Reporter: Christopher Meyer Priority: Minor While developing a custom tag library we added an empty renderer-type tag like this: tag tag-namemyinput/tag-name component component-typemy.test.MyInput/component-type renderer-type/renderer-type /component /tag This causes the following exception: Caused by: java.lang.Exception: Value Cannot be Empty at org.apache.myfaces.view.facelets.compiler.TagLibraryConfigUnmarshallerImpl$LibraryHandler.endElement(TagLibraryConfigUnmarshallerImpl.java:395) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) ... This appears to be expected based on the code in TagLibraryConfigUnmarshallerImpl. From what I can see the exception appears to be thrown on elements which are used in another spot. If any of them are empty they will throw the above exception. Wildfly/Glassfish does not have the same behavior, so my assumption is they just ignore it. Should the MyFaces code be modified to just continue on without the exception, based on the reference implementation? I can quickly create something if so, I just wanted to bring this up to the community at large since I don't know the reasoning behind the difference of the implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOBAGO-1464) Remove ActionListenerImpl
Dennis Kieselhorst created TOBAGO-1464: -- Summary: Remove ActionListenerImpl Key: TOBAGO-1464 URL: https://issues.apache.org/jira/browse/TOBAGO-1464 Project: MyFaces Tobago Issue Type: Task Affects Versions: 2.0.7 Reporter: Dennis Kieselhorst Priority: Minor ActionListenerImpl is not needed anymore. JSF 2 exception handlers should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
