[JBoss JIRA] (SEAMPERSIST-74) Broken dependency for JBossAS 7.1 and Weld 1.1.3
by Juergen Zimmermann (Created) (JIRA)
Broken dependency for JBossAS 7.1 and Weld 1.1.3
------------------------------------------------
Key: SEAMPERSIST-74
URL: https://issues.jboss.org/browse/SEAMPERSIST-74
Project: Seam Persistence
Issue Type: Bug
Affects Versions: 3.1.0.Beta4
Reporter: Juergen Zimmermann
Priority: Critical
I upgraded my JBossAS installation to Jenkins build 1904 which uses Weld 1.1.3 and get now the stacktrace below.
The issue can easily be fixed if you add this line to META-INF/MANIFEST.MF in seam-persistence-api-VERSION.jar:
Dependencies: org.hibernate
The stacktrace:
08:04:22,988 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.seam.persistence.hibernate.SeamManagedHibernateSessionCreated
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:154) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:168) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:331) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.7.0_01]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.7.0_01]
at java.lang.Thread.run(Thread.java:722) [:1.7.0_01]
Caused by: java.lang.NoClassDefFoundError: Lorg/hibernate/Session;
at java.lang.Class.getDeclaredFields0(Native Method) [:1.7.0_01]
at java.lang.Class.privateGetDeclaredFields(Class.java:2308) [:1.7.0_01]
at java.lang.Class.getDeclaredFields(Class.java:1760) [:1.7.0_01]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:99) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:99) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:153) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:48) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:39) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355) [guava-10.0-rc1.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) [guava-10.0-rc1.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153) [guava-10.0-rc1.jar:]
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) [guava-10.0-rc1.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393) [guava-10.0-rc1.jar:]
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:151) [weld-core-1.1.3.Final.jar:2011-11-09 12:17]
... 11 more
Caused by: java.lang.ClassNotFoundException: org.hibernate.Session from [Module "deployment.swe.ear.sweWeb.war:main" from Service Module Loader]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:471)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:421)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:143)
... 29 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (SEAMCRON-6) Can we use @RequestScoped for @Asynchronous methods? How?
by Peter Royle (JIRA)
Can we use @RequestScoped for @Asynchronous methods? How?
---------------------------------------------------------
Key: SEAMCRON-6
URL: https://issues.jboss.org/browse/SEAMCRON-6
Project: Seam Cron
Issue Type: Task
Reporter: Peter Royle
Assignee: Peter Royle
This is one for investigation some time. It came up in this IRC chat:
IRC Transcript:
[11:10am] johnament: request scoped won't be active in a background thread.
[11:10am] PeteRoyle: ah true cos it's threadlocal?
[11:10am] johnament: which?
[11:11am] PeteRoyle: request scoped implementation
[11:11am] PeteRoyle: won't work in a background thread because the implementation of request scope uses threadlocal, is that right?
[11:11am] johnament: its essentially an HTTP request
[11:12am] PeteRoyle: right
[11:12am] PeteRoyle: I think the use case is valid though, do you agree?
[11:13am] johnament: its valid, but it breaks the CDI model, so to say
[11:13am] johnament: because you want to make your contextual objects available outside of your context
[11:14am] PeteRoyle: right yeah that makes sense
[11:14am] PeteRoyle: the request might be over
[11:14am] johnament: the only thing really available is going to be dependent or application scoped
[11:15am] johnament: the bigger question - which request?
[11:15am] PeteRoyle: well the one from which the @Asynch method was called - assuming we could hang onto it
[11:15am] PeteRoyle: hang onto the request that is
[11:16am] PeteRoyle: eg: a controller which @Injects a @RequestScoped Thing, then calls an @Asynchronous method
[11:17am] johnament: the only way it would work is to make request scope extend through your @asynch process is over.
[11:18am] PeteRoyle: The interceptor would have access to the correct @RequestScope. It would need to replicate it into the new thread. Would that be possible do you think?
[11:18am] johnament: i don't know how plausible/possible that even is.
[11:18am] PeteRoyle: yeah. I might leave that as something for investigation later. I'll JIRA it
[11:18am] johnament: jms does this by transporting the event over JMS, but loses the context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (SEAM-126) Seam 3 should be able to run on Java 5 (so it must be build with -source and -target 1.5)
by Geoffrey De Smet (Created) (JIRA)
Seam 3 should be able to run on Java 5 (so it must be build with -source and -target 1.5)
-----------------------------------------------------------------------------------------
Key: SEAM-126
URL: https://issues.jboss.org/browse/SEAM-126
Project: Seam 3 Distribution
Issue Type: Bug
Components: Build Infrastructure
Affects Versions: 3.1.0.CR1
Reporter: Geoffrey De Smet
Priority: Blocker
Fix For: 3.1.0.Final
Seam 3 is compatible with JDK 5 according to
http://seamframework.org/Seam3/GetStarted
(if it wasn't compatible with 1.5, we would have not upgraded from Seam 2 earlier this year).
{code}
Prerequisites
JDK 5 or above
Maven 3.0 or above (to build the source code or run the examples)
Java EE 6-compliant application server (or a servlet container supported by the Weld servlet extension)
{code}
But the seam-security 3.1.0.CR1 has not been build with -target 1.5:
{code}
[ERROR] bad class file: /home/jliu/.m2/repository/org/jboss/seam/security/seam-security-api/3.1.0.CR1/seam-security-api-3.1.0.CR1.jar(org/jboss/seam/security/AuthorizationException.class)
[ERROR] class file has wrong version 50.0, should be 49.0
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (SEAMSECURITY-66) Separated API/IMPL jars do not allow compilation of the SimpleAuthenticator example
by Charles C (JIRA)
Separated API/IMPL jars do not allow compilation of the SimpleAuthenticator example
-----------------------------------------------------------------------------------
Key: SEAMSECURITY-66
URL: https://issues.jboss.org/browse/SEAMSECURITY-66
Project: Seam Security
Issue Type: Bug
Affects Versions: 3.0.0.Final
Reporter: Charles C
The SimpleAuthenticator example is not compilable with the separated API/IMPL jars, but instead must use either the combined jars, or the impl jar must be in the compile scope.
This seems like an incorrect factoring of impl vs api classes if the impl classes are required to compile a simple example of a custom authenticator. In particular, the PasswordCredential, BaseAuthenticator and SimpleUser classes are not available if only the API jar is used as a compile time dependency.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (SOLDER-311) HttpServletRequest cannot be @Inject-ed
by Juergen Zimmermann (Created) (JIRA)
HttpServletRequest cannot be @Inject-ed
---------------------------------------
Key: SOLDER-311
URL: https://issues.jboss.org/browse/SOLDER-311
Project: Solder
Issue Type: Bug
Components: Servlet
Affects Versions: 3.1.0.CR1
Environment: JBossAS 7.1beta1b
Reporter: Juergen Zimmermann
"@Inject HttpServletRequest request;" results in the stacktrace below, when I invoke "request(myusername, mypassword);" using JBossAS 7.1beta1b. I'll attach a testcase as an EAR. Just invoke http://localhost:8080/testcase and you'll see a form where you click the OK button. Then you'll see the stacktrace in the JBoss console.
Stacktrace:
09:11:00,535 Warnung [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http--127.0.0.1-8080-1) #{cust.findCustomer}: org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method: [method] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest(): javax.faces.FacesException: #{cust.findCustomer}: org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method: [method] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:]
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:126) [prettyfaces-jsf2-3.3.2.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397) [jbossweb-7.0.3.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Beta1b.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.Beta1b.jar:]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.3.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.3.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.3.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.3.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.3.Final.jar:]
at java.lang.Thread.run(Thread.java:722) [:1.7.0_02]
Caused by: javax.faces.el.EvaluationException: org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method: [method] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
... 28 more
Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a non-dependent producer method: [method] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()
at org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:217) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:300) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:104) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.proxies.HttpServletRequest$83012492$Proxy$_$$_WeldClientProxy.login(HttpServletRequest$83012492$Proxy$_$$_WeldClientProxy.java)
at testcase.CustomerController.findCustomer(CustomerController.java:43) [classes:]
at testcase.CustomerController$Proxy$_$$_WeldClientProxy.findCustomer(CustomerController$Proxy$_$$_WeldClientProxy.java) [classes:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0_02]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0_02]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0_02]
at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0_02]
at org.apache.el.parser.AstValue.invoke(AstValue.java:196) [jbossweb-7.0.3.Final.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [jbossweb-7.0.3.Final.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.4.Final.jar:]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.4.Final.jar:]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.3-b02-jbossorg-2.jar:]
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:]
... 29 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (JBSEAM-4621) Page Navigation exception after upgrading to JSF 2.0
by Sheng Gu (JIRA)
Page Navigation exception after upgrading to JSF 2.0
----------------------------------------------------
Key: JBSEAM-4621
URL: https://jira.jboss.org/jira/browse/JBSEAM-4621
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.2.1.CR1
Environment: Seam 2.2.1.CR1 + JSF 2.0 Sun
Reporter: Sheng Gu
Priority: Blocker
Fix For: 2.2.1.CR2
Hi there,
After upgrading to JSF2.0, I got the following exceptions. The login.xhtml and login.page.xml codes are listed as follows:
login.xhtml:
<h:commandButton value="LOGIN" action="#{identity.login}"/>
<h:commandButton value="SIGN UP!" action="register" immediate="true"/>
login.page.xml:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="http://jboss.com/products/seam/pages"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.2.xsd">
<end-conversation before-redirect="true" root="true"/>
<navigation from-action="#{identity.login}">
<rule if="#{identity.loggedIn}">
<end-conversation before-redirect="true" root="true"/>
<redirect view-id="/home.xhtml" />
</rule>
</navigation>
<navigation from-action="register">
<begin-conversation join="false"/>
<redirect view-id="/register.xhtml" />
</navigation>
</page>
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:435)
at org.jboss.seam.mock.MockExternalContext.redirect(MockExternalContext.java:528)
at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:220)
at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:185)
at org.jboss.seam.faces.Navigator.redirect(Navigator.java:55)
at org.jboss.seam.faces.Navigator.redirect(Navigator.java:42)
at org.jboss.seam.exception.RedirectHandler.handle(RedirectHandler.java:51)
at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76)
at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70)
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:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (SEAMSECURITY-71) Improve LDAP integration in general
by Thorsten Kunz (JIRA)
Improve LDAP integration in general
-----------------------------------
Key: SEAMSECURITY-71
URL: https://issues.jboss.org/browse/SEAMSECURITY-71
Project: Seam Security
Issue Type: Feature Request
Affects Versions: 3.0.0.Final
Reporter: Thorsten Kunz
As described in the forum thread right now getting LDAP integration to work is quite the project since there a features missing (in Seam Security as well as PicketLink IDM) and there is little to no documentation on how to enable Seam Security to use PicketLink IDM LDAP integration.
It would be very nice if Seam Security would have the same level of LDAP usability that Seam 2 has. At least it should be possible to enable simple LDAP integration by XML configuration only without the need to implement any classes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (SEAMFACES-209) Security integration shows denied pages
by Nicklas Karlsson (JIRA)
Security integration shows denied pages
---------------------------------------
Key: SEAMFACES-209
URL: https://issues.jboss.org/browse/SEAMFACES-209
Project: Seam Faces
Issue Type: Bug
Components: Security
Affects Versions: 3.1.0.Beta2
Reporter: Nicklas Karlsson
I have a @ViewConfig and security annotated page that fails the auth check but the code in SecurityPhaseListener
private void redirectToAccessDeniedView(FacesContext context, UIViewRoot viewRoot) {
// If a user has already done a redirect and rendered the response (possibly in an observer) we cannot do this output
if (!(context.getResponseComplete() || context.getRenderResponse())) {
quietly fails the check and then proceeds to render the page. It should perhaps throw an exception or take some other actions to at least deny the page.
In an unrelated note, I can't see where response output would be produced since I just edited the browser url and pointed it at a forbidden page...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months