[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2558) HTTP BASIC authentication support is broken
by Alan Feng (JIRA)
HTTP BASIC authentication support is broken
-------------------------------------------
Key: JBSEAM-2558
URL: http://jira.jboss.com/jira/browse/JBSEAM-2558
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.1.GA, 2.0.1.CR2, 2.0.1.CR1, 2.0.0.GA
Environment: JBoss AS 4.2.2GA, Seam 2.0.0GA
Reporter: Alan Feng
The class org.jboss.seam.web.AuthenticationFilter, which provides HTTP BASIC authentication support, throws exception and never performs the authentication.
If the user access the site the first time and the page accessed is protected by HTTP BASIC authentication, a NPE will occur from the AuthenticationFilter.processBasicAuth() method.
In addition, the AuthenticationFilter.processBasicAuth() method does not invoke the identity.authenticate() method to actually perform the authentication, although it parses the BASIC authentication headers properly.
Please see the related forum post for detailed description of the problem and the proposed fixes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2556) NPE in AuthenticationFilter during Basic authentication
by Artem Pleskatsevich (JIRA)
NPE in AuthenticationFilter during Basic authentication
-------------------------------------------------------
Key: JBSEAM-2556
URL: http://jira.jboss.com/jira/browse/JBSEAM-2556
Project: JBoss Seam
Issue Type: Bug
Components: Framework
Environment: JBoss AS 4.2.1.GA, Seam 2.0.0.GA
Reporter: Artem Pleskatsevich
If I try to access a servlet that has basic HTTP authentication, I get the following exception:
13:25:58,775 ERROR [ExceptionFilter] handling uncaught exception
java.lang.NullPointerException
at org.jboss.seam.web.AuthenticationFilter.processBasicAuth(AuthenticationFilter.java:158)
at org.jboss.seam.web.AuthenticationFilter.doFilter(AuthenticationFilter.java:118)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2554) org.jboss.seam.pdf.DocumentData needs to be serializable
by Norman Richards (JIRA)
org.jboss.seam.pdf.DocumentData needs to be serializable
--------------------------------------------------------
Key: JBSEAM-2554
URL: http://jira.jboss.com/jira/browse/JBSEAM-2554
Project: JBoss Seam
Issue Type: Bug
Components: PDF
Reporter: Samuel Mendenhall
Assigned To: Norman Richards
Fix For: 2.0.1.GA
In a cluster accessing a pdf, the following exception is generated:
java.io.NotSerializableException: org.jboss.seam.pdf.DocumentData
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at java.util.HashMap.writeObject(HashMap.java:1000)
at sun.reflect.GeneratedMethodAccessor810.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1244)
at sun.reflect.GeneratedMethodAccessor812.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at org.jboss.web.tomcat.service.session.SessionBasedClusteredSession.writeExternal(SessionBasedClusteredSession.java:175)
at org.jboss.web.tomcat.service.session.JBossCacheService.externalizeSession(JBossCacheService.java:1027)
at org.jboss.web.tomcat.service.session.JBossCacheService.putSession(JBossCacheService.java:316)
at org.jboss.web.tomcat.service.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:121)
at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1097)
at org.jboss.web.tomcat.service.session.JBossCacheManager.storeSession(JBossCacheManager.java:652)
at org.jboss.web.tomcat.service.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1634) More customizable hot redeployment
by Christian Bauer (JIRA)
More customizable hot redeployment
----------------------------------
Key: JBSEAM-1634
URL: http://jira.jboss.com/jira/browse/JBSEAM-1634
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Reporter: Christian Bauer
Priority: Minor
Attachments: flexible_hot_redployment.patch
The attached patch adds several things:
- ability to specify the hot deployment directory as a servlet context init parameter (seam.HOT_DEPLOY_DIRECTORY)
- ability to access the used RedeployableStrategy from the application context (to get the classloader, etc)
- an additional descriptor (hot-components.xml) that can be used in the hot deploy directory
I use this to boot Seam from an embeddable webserver with a custom parent classloader and to start Embedded JBoss with the same child classloader that Seam is using. I effectively get complete hot redeployment of all Seam components, EJBs, and persistence units.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2101) Improve ConversationStack component by filtering based on view-ids
by Jacob Orshalick (JIRA)
Improve ConversationStack component by filtering based on view-ids
------------------------------------------------------------------
Key: JBSEAM-2101
URL: http://jira.jboss.com/jira/browse/JBSEAM-2101
Project: JBoss Seam
Issue Type: Feature Request
Affects Versions: 2.0.0.CR2
Reporter: Jacob Orshalick
Priority: Minor
The application I am currently developing follows the following Form scenario:
1. User selects a DataModel element for editing which takes them to view editDataModelSelection.xhtml .
2. User makes changes to the DataModelSelection.
3. User selects an associated Object for editing which takes the user to sub-view editAggregateObject.xhtml
4. User makes changes to associated object and submits those changes.
5. This takes the user back to editDataModelSelection.xhtml view where the changes to the associated object are shown updated to the DataModelSelection.
5. User submits the changes to the DataModelSelection which persists both DataModelSelection changes and associated object changes as well.
A conversation is nested when the user accesses view editAggregateObject.xhtml . This allows a user to back-button to the editDataModelSelection.xhtml prior to editing the aggregate object without causing state inconsistencies between what the user sees and what actually persists on submit.
The trouble is the display of breadcrumbs through the ConversationStack. When the user traverses the following path:
view editDataModelSelection.xhtml -> action(editAssociatedObject) conversation nested here
-> view editAggregateObject.xhtml -> action(submitChanges)
-> view editDataModelSelection.xhtml
In this scenario, the breadcrumbs by default are displayed as:
Edit Data Model Selection | Edit Data Model Selection
This makes sense due to the fact that the nested conversation has the same view-id as the outer conversation. This continues the more times the user edits an associated object. The implementation I am using filters ConversationEntries from the ConversationStack based on the view-id so that the breadcrumbs are simply displayed as:
Edit Data Model Selection
regardless of the nested ConversationEntries in this scenario. It is requested that the ConversationStack be filtered based on view-id to provide this as default behavior. Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months