[JBoss JIRA] Created: (SEAMFACES-187) Seam faces failes to deployt without Pretty faces on AS7
by George Gastaldi (JIRA)
Seam faces failes to deployt without Pretty faces on AS7
--------------------------------------------------------
Key: SEAMFACES-187
URL: https://issues.jboss.org/browse/SEAMFACES-187
Project: Seam Faces
Issue Type: Bug
Environment: JBoss AS7. Indigo, M2Eclipse
Reporter: George Gastaldi
When deploying a war file with only the dependency below, an error is thrown:
{code:xml}
<dependency>
<groupId>org.jboss.seam.faces</groupId>
<artifactId>seam-faces</artifactId>
<version>3.0.2.Final</version><!--$NO-MVN-MAN-VER$ -->
</dependency>
{code}
{code:java}
18:59:50,935 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.jboss.seam.faces.rewrite.RewriteConfiguration in Module "deployment.exemplo-web.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/seam/faces/rewrite/RewriteConfiguration (Module "deployment.exemplo-web.war:main" from Service Module Loader)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
at org.jboss.modules.Module.loadModuleClass(Module.java:588)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:83) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.NoClassDefFoundError: com/ocpsoft/pretty/faces/spi/ConfigurationProvider
at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24]
at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
... 19 more
Caused by: java.lang.ClassNotFoundException: com.ocpsoft.pretty.faces.spi.ConfigurationProvider from [Module "deployment.exemplo-web.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
... 24 more
{code}
I believe this is due to having a class extending a Pretty faces class that is not on my lib, but that shouldn´t be required
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[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, 2 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, 2 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, 2 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, 2 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, 2 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, 2 months