December 2012 - seam-issues - Jboss List Archives

[JBoss JIRA] (SEAMPERSIST-80) CMT vanishes when using Servlets and Seam Persistence

by Fab Mars (JIRA)

[ https://issues.jboss.org/browse/SEAMPERSIST-80?page=com.atlassian.jira.pl... ] Fab Mars updated SEAMPERSIST-80: -------------------------------- Attachment: TestEjbWeb.zip the example > CMT vanishes when using Servlets and Seam Persistence > ----------------------------------------------------- > > Key: SEAMPERSIST-80 > URL: https://issues.jboss.org/browse/SEAMPERSIST-80 > Project: Seam Persistence > Issue Type: Bug > Affects Versions: 3.1.0.Final > Environment: Win7, Glassfish 3.1.2.2, Mojarra 2.1.14, Weld 1.1.8, Seam 3.1.0 > Reporter: Fab Mars > Labels: cmt, ejb, seam, servlet, transaction > Attachments: TestEjbWeb.zip > > > When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. > I read carefully these: > http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... > [i]By default seam will attempt to look up java:comp/UserTransaction from JNDI [b](or alternatively retrieve it from the EJBContext if a container managed transaction is active)[/b].[/i] > ==>This is obviously not correct if you try with the attached example. > I tried to use a SMPC, to no avail. > Then I read this https://community.jboss.org/thread/178844 > Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMPERSIST-80) CMT vanishes when using Servlets and Seam Persistence

by Fab Mars (JIRA)

[ https://issues.jboss.org/browse/SEAMPERSIST-80?page=com.atlassian.jira.pl... ] Fab Mars updated SEAMPERSIST-80: -------------------------------- Description: When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. I read carefully these: http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... ??By default seam will attempt to look up java:comp/UserTransaction from JNDI *(or alternatively retrieve it from the EJBContext if a container managed transaction is active)*.?? ==>This is obviously not correct if you try with the attached example. I tried to use a SMPC, to no avail. Then I read this https://community.jboss.org/thread/178844 Without much hope, I tired to use ?cid=#{conversation.id} with the servlet url, to no avail. was: When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. I read carefully these: http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... ??By default seam will attempt to look up java:comp/UserTransaction from JNDI *(or alternatively retrieve it from the EJBContext if a container managed transaction is active)*.?? ==>This is obviously not correct if you try with the attached example. I tried to use a SMPC, to no avail. Then I read this https://community.jboss.org/thread/178844 Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. > CMT vanishes when using Servlets and Seam Persistence > ----------------------------------------------------- > > Key: SEAMPERSIST-80 > URL: https://issues.jboss.org/browse/SEAMPERSIST-80 > Project: Seam Persistence > Issue Type: Bug > Affects Versions: 3.1.0.Final > Environment: Win7, Glassfish 3.1.2.2, Mojarra 2.1.14, Weld 1.1.8, Seam 3.1.0 > Reporter: Fab Mars > Labels: cmt, ejb, seam, servlet, transaction > Attachments: TestEjbWeb.zip > > > When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. > I read carefully these: > http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... > ??By default seam will attempt to look up java:comp/UserTransaction from JNDI *(or alternatively retrieve it from the EJBContext if a container managed transaction is active)*.?? > ==>This is obviously not correct if you try with the attached example. > I tried to use a SMPC, to no avail. > Then I read this https://community.jboss.org/thread/178844 > Without much hope, I tired to use ?cid=#{conversation.id} with the servlet url, to no avail. -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMPERSIST-80) CMT vanishes when using Servlets and Seam Persistence

by Fab Mars (JIRA)

[ https://issues.jboss.org/browse/SEAMPERSIST-80?page=com.atlassian.jira.pl... ] Fab Mars updated SEAMPERSIST-80: -------------------------------- Description: When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. I read carefully these: http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... ??By default seam will attempt to look up java:comp/UserTransaction from JNDI *(or alternatively retrieve it from the EJBContext if a container managed transaction is active)*.?? ==>This is obviously not correct if you try with the attached example. I tried to use a SMPC, to no avail. Then I read this https://community.jboss.org/thread/178844 Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. was: When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. I read carefully these: http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... [i]By default seam will attempt to look up java:comp/UserTransaction from JNDI [b](or alternatively retrieve it from the EJBContext if a container managed transaction is active)[/b].[/i] ==>This is obviously not correct if you try with the attached example. I tried to use a SMPC, to no avail. Then I read this https://community.jboss.org/thread/178844 Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. > CMT vanishes when using Servlets and Seam Persistence > ----------------------------------------------------- > > Key: SEAMPERSIST-80 > URL: https://issues.jboss.org/browse/SEAMPERSIST-80 > Project: Seam Persistence > Issue Type: Bug > Affects Versions: 3.1.0.Final > Environment: Win7, Glassfish 3.1.2.2, Mojarra 2.1.14, Weld 1.1.8, Seam 3.1.0 > Reporter: Fab Mars > Labels: cmt, ejb, seam, servlet, transaction > Attachments: TestEjbWeb.zip > > > When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. > I read carefully these: > http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... > ??By default seam will attempt to look up java:comp/UserTransaction from JNDI *(or alternatively retrieve it from the EJBContext if a container managed transaction is active)*.?? > ==>This is obviously not correct if you try with the attached example. > I tried to use a SMPC, to no avail. > Then I read this https://community.jboss.org/thread/178844 > Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMPERSIST-80) CMT vanishes when using Servlets and Seam Persistence

by Fab Mars (JIRA)

Fab Mars created SEAMPERSIST-80: ----------------------------------- Summary: CMT vanishes when using Servlets and Seam Persistence Key: SEAMPERSIST-80 URL: https://issues.jboss.org/browse/SEAMPERSIST-80 Project: Seam Persistence Issue Type: Bug Affects Versions: 3.1.0.Final Environment: Win7, Glassfish 3.1.2.2, Mojarra 2.1.14, Weld 1.1.8, Seam 3.1.0 Reporter: Fab Mars When Seam Persistence/transaction is installed and calling from a SERVLET an EJB business method that performs em.persist/merge, tranasaction management is gone, thus statements are not executed. I read carefully these: http://docs.jboss.org/seam/3/persistence/latest/reference/en-US/html/pers... [i]By default seam will attempt to look up java:comp/UserTransaction from JNDI [b](or alternatively retrieve it from the EJBContext if a container managed transaction is active)[/b].[/i] ==>This is obviously not correct if you try with the attached example. I tried to use a SMPC, to no avail. Then I read this https://community.jboss.org/thread/178844 Without much hope, I tired to use ?cid=#{conversation.id} witht he servelt URL, to no avail. -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMFACES-242) WELD-001318 AmbiguousResolutionException with Converter having subclass

by Fab Mars (JIRA)

[ https://issues.jboss.org/browse/SEAMFACES-242?page=com.atlassian.jira.plu... ] Fab Mars edited comment on SEAMFACES-242 at 12/30/12 10:37 PM: --------------------------------------------------------------- No feedback to a valid fix proposal and argumentation, after 8 months. was (Author: fabmars): No valid feedback to a valid fix proposal. > WELD-001318 AmbiguousResolutionException with Converter having subclass > ----------------------------------------------------------------------- > > Key: SEAMFACES-242 > URL: https://issues.jboss.org/browse/SEAMFACES-242 > Project: Seam Faces > Issue Type: Bug > Components: CDI Integration, Validation & Conversion > Affects Versions: 3.1.0.Final > Environment: GF 3.1.2 with JDK 1.6.0b29 + SeamFaces 3.1.0 + RichFaces 4.2.0 > Reporter: Fab Mars > > On some page I have <rich:inputNumberSpinner label="Count" value="#{orderLine.quantity}" converter="IntegerOrNullConverter".../> > The converter to use is explicit. But I also extended that converter class twice for other purposes. > When accessing the page I get a WELD-001318 ambiguous dependency. Stacktrace below. > SeamApplicationWrapper#createConverter ends up calling BeanManagerUtils#isDependentScoped which tries to CDI-resolve the the converter type. Naturally weld finds the 3 converters (the one I asked for and the 2 subclasses) and it complains as it should. I strongly believe calling BM#resolve here is wrong. > The same will happen with SeamApplicationWrapper#createValidator. > 1) These methods should deal with only the actual requested type > 2) The use of BeanManagerUtils.getContextualInstance in SeamApplicationWrapper.attemptExtension will also lead to problems. > 3) More generally, I BeanManagerUtils.isDependentScoped isn't selective enough either > Instead of #resolve, another utility method like this may be called: > {code} > public <T> Set<Bean<?>> getExactBeanForType(final Class<T> type) { > Set<Bean<?>> beans = manager.getBeans(type); > for(Bean<?> bean : beans) { > if(type.equals(bean.getBeanClass())) { > return Collections.<Bean<?>>singleton(bean); > } > } > > return Collections.<Bean<?>>emptySet(); > } > {code} > Stacktrace of the issue: > {code} > GRAVE: org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318 Cannot resolve an ambiguous dependency between [Managed Bean [class org.mars.toolkit.jsf.converter.MonthConverter] with qualifiers [@Any @Default], Managed Bean [class org.mars.toolkit.jsf.converter.IntegerOrNullConverter] with qualifiers [@Any @Default], Managed Bean [class org.mars.toolkit.jsf.converter.YearConverter] with qualifiers [@Any @Default]] > at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1013) > at org.jboss.seam.faces.util.BeanManagerUtils.isDependentScoped(BeanManagerUtils.java:74) > at org.jboss.seam.faces.environment.SeamApplicationWrapper.attemptExtension(SeamApplicationWrapper.java:81) > at org.jboss.seam.faces.environment.SeamApplicationWrapper.createConverter(SeamApplicationWrapper.java:60) > at org.jboss.seam.faces.environment.SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.createConverter(SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.java) > at com.sun.faces.facelets.tag.jsf.ValueHolderRule$LiteralConverterMetadata.applyMetadata(ValueHolderRule.java:85) > at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81) > at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129) > at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:113) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:409) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandle.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BeaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelgateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93) > at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346) > at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199) > at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:107) > at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178) > at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395) > at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366) > at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:112) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces. > {code} -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMFACES-242) WELD-001318 AmbiguousResolutionException with Converter having subclass

by Fab Mars (JIRA)

[ https://issues.jboss.org/browse/SEAMFACES-242?page=com.atlassian.jira.plu... ] Fab Mars reopened SEAMFACES-242: -------------------------------- No valid feedback to a valid fix proposal. > WELD-001318 AmbiguousResolutionException with Converter having subclass > ----------------------------------------------------------------------- > > Key: SEAMFACES-242 > URL: https://issues.jboss.org/browse/SEAMFACES-242 > Project: Seam Faces > Issue Type: Bug > Components: CDI Integration, Validation & Conversion > Affects Versions: 3.1.0.Final > Environment: GF 3.1.2 with JDK 1.6.0b29 + SeamFaces 3.1.0 + RichFaces 4.2.0 > Reporter: Fab Mars > > On some page I have <rich:inputNumberSpinner label="Count" value="#{orderLine.quantity}" converter="IntegerOrNullConverter".../> > The converter to use is explicit. But I also extended that converter class twice for other purposes. > When accessing the page I get a WELD-001318 ambiguous dependency. Stacktrace below. > SeamApplicationWrapper#createConverter ends up calling BeanManagerUtils#isDependentScoped which tries to CDI-resolve the the converter type. Naturally weld finds the 3 converters (the one I asked for and the 2 subclasses) and it complains as it should. I strongly believe calling BM#resolve here is wrong. > The same will happen with SeamApplicationWrapper#createValidator. > 1) These methods should deal with only the actual requested type > 2) The use of BeanManagerUtils.getContextualInstance in SeamApplicationWrapper.attemptExtension will also lead to problems. > 3) More generally, I BeanManagerUtils.isDependentScoped isn't selective enough either > Instead of #resolve, another utility method like this may be called: > {code} > public <T> Set<Bean<?>> getExactBeanForType(final Class<T> type) { > Set<Bean<?>> beans = manager.getBeans(type); > for(Bean<?> bean : beans) { > if(type.equals(bean.getBeanClass())) { > return Collections.<Bean<?>>singleton(bean); > } > } > > return Collections.<Bean<?>>emptySet(); > } > {code} > Stacktrace of the issue: > {code} > GRAVE: org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318 Cannot resolve an ambiguous dependency between [Managed Bean [class org.mars.toolkit.jsf.converter.MonthConverter] with qualifiers [@Any @Default], Managed Bean [class org.mars.toolkit.jsf.converter.IntegerOrNullConverter] with qualifiers [@Any @Default], Managed Bean [class org.mars.toolkit.jsf.converter.YearConverter] with qualifiers [@Any @Default]] > at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1013) > at org.jboss.seam.faces.util.BeanManagerUtils.isDependentScoped(BeanManagerUtils.java:74) > at org.jboss.seam.faces.environment.SeamApplicationWrapper.attemptExtension(SeamApplicationWrapper.java:81) > at org.jboss.seam.faces.environment.SeamApplicationWrapper.createConverter(SeamApplicationWrapper.java:60) > at org.jboss.seam.faces.environment.SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.createConverter(SeamApplicationWrapper$Proxy$_$$_WeldClientProxy.java) > at com.sun.faces.facelets.tag.jsf.ValueHolderRule$LiteralConverterMetadata.applyMetadata(ValueHolderRule.java:85) > at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81) > at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129) > at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:113) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:409) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandle.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BeaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelgateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93) > at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:86) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:308) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:367) > at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:346) > at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199) > at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:107) > at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178) > at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395) > at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366) > at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:112) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184) > at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120) > at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98) > at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137) > at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53) > at com.sun.faces. > {code} -- 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

1
0
0 / 0

[JBoss JIRA] (SEAMPERSIST-46) "Ambiguous dependencies for type [Synchronizations]" on GlassFish 3.1

by Pavel S (JIRA)

[ https://issues.jboss.org/browse/SEAMPERSIST-46?page=com.atlassian.jira.pl... ] Pavel S commented on SEAMPERSIST-46: ------------------------------------ have the same issue. using maven, GWT, errai, tomcat, weld, seam-persistence(seam-persistence introduce a bag as is). > "Ambiguous dependencies for type [Synchronizations]" on GlassFish 3.1 > --------------------------------------------------------------------- > > Key: SEAMPERSIST-46 > URL: https://issues.jboss.org/browse/SEAMPERSIST-46 > Project: Seam Persistence > Issue Type: Bug > Affects Versions: 3.0.0.Final > Environment: GlassFish 3.1, Ubuntu 10.10, java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode) > Reporter: Hendy Irawan > Labels: persistence, weld > > After adding @TransactionAttribute to a CDI bean, error occurs: > SEVERE: Exception while loading the app : WELD-001409 Ambiguous dependencies for type [Synchronizations] with qualifiers [@Default] at injection point [[parameter 1] of [method] @Inject public org.jboss.seam.transaction.EntityTransaction.init(Synchronizations)]. Possible dependencies [[Managed Bean [class org.jboss.seam.transaction.SeSynchronizations] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.transaction.TransactionManagerSynchronizations] with qualifiers [@Any @Default]]] > org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [Synchronizations] with qualifiers [@Default] at injection point [[parameter 1] of [method] @Inject public org.jboss.seam.transaction.EntityTransaction.init(Synchronizations)]. Possible dependencies [[Managed Bean [class org.jboss.seam.transaction.SeSynchronizations] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.transaction.TransactionManagerSynchronizations] with qualifiers [@Any @Default]]] > at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162) > at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385) > at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371) > at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:390) > at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190) > at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128) > at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:298) > at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) > at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) > at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) > at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) > at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) > at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) > at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) > at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) > at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) > at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) > at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) > at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) > at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) > at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) > at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) > at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) > at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) > at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) > at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) > at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) > at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) > at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) > at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) > at com.sun.grizzly.ContextTask.run(ContextTask.java:71) > at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) > at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) > at java.lang.Thread.run(Thread.java:662) -- 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

1
0
0 / 0

[JBoss JIRA] (SEAM-138) ...thread is already associated with a transaction!

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/SEAM-138?page=com.atlassian.jira.plugin.s... ] SBS JIRA Integration updated SEAM-138: -------------------------------------- Forum Reference: https://community.jboss.org/message/783547#783547 > ...thread is already associated with a transaction! > --------------------------------------------------- > > Key: SEAM-138 > URL: https://issues.jboss.org/browse/SEAM-138 > Project: Seam 3 Distribution > Issue Type: Bug > Affects Versions: 3.1.0.Final > Environment: Windows, JBPM 5.3.0 Final, Drools 5.4.0 Final, JBOSS 7.0.2 Final > Reporter: Andrea Carpineti > Labels: jta, transaction > > I believe the issue is related to Seam but I'm not completely sure... > Using the JBPM console sometimes we experienced an issue due to which the deployed processes are no longer available. They simply disappear. > Although the issue is not always repro we experienced it mainly after several minutes of use. > Lookin in the {{server.log}} we found the following exceptions: > {quote} > 10:41:15,751 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-localhost-127.0.0.1-8080-76) Exception sending request initialized lifecycle event to listener instance of class org.jboss.seam.transaction.TransactionServletListener: javax.enterprise.event.ObserverException > at sun.reflect.GeneratedConstructorAccessor243.newInstance(Unknown Source) [:1.6.0_31] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_31] > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_31] > at java.lang.Class.newInstance0(Class.java:355) [:1.6.0_31] > at java.lang.Class.newInstance(Class.java:308) [:1.6.0_31] > at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:395) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:390) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:92) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:214) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:628) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.seam.transaction.TransactionServletListener.requestInitialized(TransactionServletListener.java:117) [seam-transaction-3.1.0.Final.jar:] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_31] > Caused by: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:65) > at org.jboss.seam.transaction.UTTransaction.begin(UTTransaction.java:51) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.DefaultSeamTransaction.begin(DefaultSeamTransaction.java:88) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.TransactionServletListener.requestInitialized(TransactionServletListener.java:110) [seam-transaction-3.1.0.Final.jar:] > ... 8 more > Caused by: java.lang.IllegalStateException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.checkTransactionState(BaseTransaction.java:259) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:61) > ... 11 more > 10:41:15,760 WARN [org.jboss.seam.transaction.TransactionServletListener] (http-localhost-127.0.0.1-8080-76) Error starting the transaction: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:65) > at org.jboss.seam.transaction.UTTransaction.begin(UTTransaction.java:51) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.DefaultSeamTransaction.begin(DefaultSeamTransaction.java:88) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.TransactionServletListener.requestInitialized(TransactionServletListener.java:110) [seam-transaction-3.1.0.Final.jar:] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_31] > Caused by: java.lang.IllegalStateException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.checkTransactionState(BaseTransaction.java:259) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:61) > ... 11 more > 10:41:15,762 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-localhost-127.0.0.1-8080-76) Exception sending request initialized lifecycle event to listener instance of class org.jboss.seam.transaction.TransactionServletListener: javax.enterprise.event.ObserverException > at sun.reflect.GeneratedConstructorAccessor243.newInstance(Unknown Source) [:1.6.0_31] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_31] > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_31] > at java.lang.Class.newInstance0(Class.java:355) [:1.6.0_31] > at java.lang.Class.newInstance(Class.java:308) [:1.6.0_31] > at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:395) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:390) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:92) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:214) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:628) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75) [weld-core-1.1.2.Final.jar:2011-07-26 15:02] > at org.jboss.seam.transaction.TransactionServletListener.requestInitialized(TransactionServletListener.java:117) [seam-transaction-3.1.0.Final.jar:] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final] > at java.lang.Thread.run(Thread.java:662) [:1.6.0_31] > Caused by: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:65) > at org.jboss.seam.transaction.UTTransaction.begin(UTTransaction.java:51) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.DefaultSeamTransaction.begin(DefaultSeamTransaction.java:88) [seam-transaction-3.1.0.Final.jar:] > at org.jboss.seam.transaction.TransactionServletListener.requestInitialized(TransactionServletListener.java:110) [seam-transaction-3.1.0.Final.jar:] > ... 8 more > Caused by: java.lang.IllegalStateException: BaseTransaction.checkTransactionState - thread is already associated with a transaction! > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.checkTransactionState(BaseTransaction.java:259) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:61) > ... 11 more > {quote} -- 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

1
0
0 / 0

[JBoss JIRA] (JBSEAM-5034) Allow for seam-gen run arquillian testsuite on generated project structure

by Vaclav Dedik (JIRA)

[ https://issues.jboss.org/browse/JBSEAM-5034?page=com.atlassian.jira.plugi... ] Vaclav Dedik commented on JBSEAM-5034: -------------------------------------- I created two possible fixes: https://github.com/VaclavDedik/jboss-seam/commit/6c62f28e41c0fe3450e4c373... https://github.com/VaclavDedik/jboss-seam/commit/71a0c69017f202577c4991df... So I need someone to decide which is better, the pros and cons of both should be obvious. > Allow for seam-gen run arquillian testsuite on generated project structure > -------------------------------------------------------------------------- > > Key: JBSEAM-5034 > URL: https://issues.jboss.org/browse/JBSEAM-5034 > Project: Seam 2 > Issue Type: Feature Request > Components: Test Harness, Tools > Reporter: Marek Novotny > Assignee: Vaclav Dedik > Priority: Critical > Fix For: 2.3.1.CR1 > > > seam-gen is not right now updated for our Arquillian integration tests. > ./seam test will not pass if you doesn't edit it manually. -- 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

1
0
0 / 0

[JBoss JIRA] (JBSEAM-5065) page context broken on Mojarra 2.1.16

by Marek Schmidt (JIRA)

[ https://issues.jboss.org/browse/JBSEAM-5065?page=com.atlassian.jira.plugi... ] Marek Schmidt commented on JBSEAM-5065: --------------------------------------- Since we don't store conversation id in the page context anymore, maybe the usage of viewMap introduced in JBSEAM-4667 can be reverted now? > page context broken on Mojarra 2.1.16 > ------------------------------------- > > Key: JBSEAM-5065 > URL: https://issues.jboss.org/browse/JBSEAM-5065 > Project: Seam 2 > Issue Type: Bug > Components: Core > Affects Versions: 2.3.0.Final > Environment: AS 7.2.0 snapshot with Mojarra 2.1.16 > Reporter: Marek Schmidt > Assignee: Marek Novotny > Priority: Blocker > Fix For: 2.3.1.CR1 > > > n/t -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues December 2012