[JBoss JIRA] (JBSEAM-5047) Transaction lookup fails on Tomcat
by Christoph Brill (JIRA)
Christoph Brill created JBSEAM-5047:
---------------------------------------
Summary: Transaction lookup fails on Tomcat
Key: JBSEAM-5047
URL: https://issues.jboss.org/browse/JBSEAM-5047
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.Final
Reporter: Christoph Brill
Currently org.jboss.seam.transaction.Transaction#getUserTransaction() catches for a NameNotFoundException when doing the lookup for "java:comp/UserTransaction". This fails on Apache Tomcat 7.0.27 because it will throw a generic NamingException.
Please change the code to catch a NamingException instead of NameNotFoundException (which is a child class of NamingException).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4398) RememberMe Issue - Base 64 encoded cookie containing '=' is not processed correctly in some cases
by Peter Goldstein (JIRA)
RememberMe Issue - Base 64 encoded cookie containing '=' is not processed correctly in some cases
-------------------------------------------------------------------------------------------------
Key: JBSEAM-4398
URL: https://jira.jboss.org/jira/browse/JBSEAM-4398
Project: Seam
Issue Type: Bug
Affects Versions: 2.2.0.GA, 2.1.2.GA
Environment: Observed on Windows Vista, JBoss 5.1.0 GA. Problem likely exists on other operating systems and other Tomcat 6 based systems.
Reporter: Peter Goldstein
When attempting to use the RememberMe component in auto-login mode I discovered a bug in the cookie handling of this component.
When attempting to log using an auth token I was encountering repeated failures - the token was simply not being found in the database. After some investigation I discovered that the problem was that the value parameter passed into the query was truncated by one character - the last character was cut off.
I tracked the problem further back, and discovered that the truncated value originated in JBoss' Tomcat. The cookie value being passed in was missing the last two '=' characters.
Some Google searching revealed that this was deliberate - Tomcat 6 in the JBoss 5.1.0 GA configuration enforces strict character rules in the cookie value, which excludes '='.
I'm not sure if Tomcat 6 is 'right' or not, but I do know that either way, this is a trivial issue to address on the Seam side.
All one has to do is replace the '=' from the Base64 encoded token value with another allowed character (say '_' or '-') before placing it in a cookie, and reverse the process when reading a cookie.
I have a patch for this issue on the 2.2.0 GA code. I simply need to know how to submit it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (SOLDER-336) Generic beans test failures on Weld 1.1.9
by Marek Schmidt (JIRA)
Marek Schmidt created SOLDER-336:
------------------------------------
Summary: Generic beans test failures on Weld 1.1.9
Key: SOLDER-336
URL: https://issues.jboss.org/browse/SOLDER-336
Project: Solder
Issue Type: Bug
Components: Generic Beans
Affects Versions: 3.1.0.Final
Environment: AS 7.1.3.Final
Reporter: Marek Schmidt
Assignee: Marek Schmidt
Fix For: 3.2.0.Final
Solder generic beans depend on buggy Weld behaviour and have incorrect assumptions:
1. ProcessObserverMethod::getAnnotatedMethod() is never null
2. BeanManager::getReference doesn't check types
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBSEAM-5046) Metawidget booking example NPE in com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveDynamicActions on AS 7.1.3
by Marek Schmidt (JIRA)
Marek Schmidt created JBSEAM-5046:
-------------------------------------
Summary: Metawidget booking example NPE in com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveDynamicActions on AS 7.1.3
Key: JBSEAM-5046
URL: https://issues.jboss.org/browse/JBSEAM-5046
Project: Seam 2
Issue Type: Bug
Components: Examples
Affects Versions: 2.3.0.Final
Environment: AS 7.1.3, Mojarra 2.1.11-jbossorg-2 20120905-0327, metawidget 2.4
Reporter: Marek Schmidt
The metawidget booking example throws NPE on AS7.1.3
{noformat}
14:47:34,723 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-/127.0.0.1:8080-5) Error Rendering View[/book.xhtml]: java.lang.NullPointerException
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveDynamicActions(FaceletPartialStateManagementStrategy.java:426) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:491) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:89) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at org.jboss.seam.jsf.SeamStateManager.saveView(SeamStateManager.java:89) [jboss-seam.jar:2.3.0.Final]
at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:441) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:88) [jboss-seam.jar:2.3.0.Final]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288) [jboss-jsf-api_2.1_spec-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.11-redhat-1.jar:2.1.11-redhat-1]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.4.Final-redhat-1.jar:2.0.4.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) [jboss-seam.jar:2.3.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.3.Final-redhat-2.jar:7.1.3.Final-redhat-2]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165) [jboss-as-web-7.1.3.Final-redhat-2.jar:7.1.3.Final-redhat-2]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24]
{noformat}
There seems to be a bug between Mojarra and Metawidget.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (JBSEAM-4658) <s:conversationPropagation> better validation of type parameter
by Andrew Wheeler (JIRA)
<s:conversationPropagation> better validation of type parameter
---------------------------------------------------------------
Key: JBSEAM-4658
URL: https://jira.jboss.org/browse/JBSEAM-4658
Project: Seam
Issue Type: Bug
Affects Versions: 2.2.1.CR1
Environment: JBoss AS M3
Reporter: Andrew Wheeler
The examples for <s:conversationPropagation> in section 7.1 of the documentation state that a nested conversation is started with type="nested". If used with a commandLink this causes handleConversationPropagation to begin a null pageflow. The result is that a NullPointerException is thrown.
Section 33.1.1.5 correctly states that type should be "nest".
I suggest that a check is performed on the conversationPropagation control to throw an exception if the wrong type is passed. The documentation should be corrected to be consistent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months