[JBoss JIRA] (JBSEAM-5053) javax.ejb.ConcurrentAccessTimeoutException: JBAS014360
by Gus Gu (JIRA)
Gus Gu created JBSEAM-5053:
------------------------------
Summary: javax.ejb.ConcurrentAccessTimeoutException: JBAS014360
Key: JBSEAM-5053
URL: https://issues.jboss.org/browse/JBSEAM-5053
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.Final
Environment: JBoss AS 7.1.1, Seam 2.3.0.Final
Reporter: Gus Gu
Fix For: 2.3.1.CR1
Hi there,
I am not sure this exception is caused by JBoss AS 7.1.1 or Seam 2.3.0. The following codes works fine in Seam 2.2 and JBoss 4.2.3.
How to reproduce: just add @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) to ArtistHomeImpl.java in the seam-discs example:
@Name("artistHome")
@Stateful
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class ArtistHomeImpl extends EntityHome<Artist> implements ArtistHome
{
Caused by: javax.ejb.EJBException: javax.ejb.ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@109fe782 - could not obtain lock within 5000 MILLISECONDS
at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:282) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:188) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at com.mycom.controller.forum.home.ForumHome$$$view6.getCategory(Unknown Source) [proj-ejb.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_26]
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:76) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.ejb.RemoveInterceptor.aroundInvoke(RemoveInterceptor.java:43) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) [jboss-seam.jar:2.3.0.Final]
at org.jboss.seam.intercept.ClientSideInterceptor.invoke(ClientSideInterceptor.java:54) [jboss-seam.jar:2.3.0.Final]
at org.javassist.tmp.java.lang.Object_$$_javassist_seam_19.getCategory(Object_$$_javassist_seam_19.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_26]
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302) [jboss-el-api_2.2_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.jboss.el.parser.AstPropertySuffix.getValue(AstPropertySuffix.java:53) [jboss-el.jar:1.0_02.CR6]
at org.jboss.el.parser.AstValue.getValue(AstValue.java:67) [jboss-el.jar:1.0_02.CR6]
at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) [jboss-el.jar:1.0_02.CR6]
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.1.7-jbossorg-2.jar:]
... 72 more
Caused by: javax.ejb.ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@109fe782 - could not obtain lock within 5000 MILLISECONDS
at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:117) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:211) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:274) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
... 117 more
--
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
11 years, 6 months
[JBoss JIRA] (SEAM-141) Update News on Main Site for SeamFramework.org
by Dennis Mitchell (JIRA)
Dennis Mitchell created SEAM-141:
------------------------------------
Summary: Update News on Main Site for SeamFramework.org
Key: SEAM-141
URL: https://issues.jboss.org/browse/SEAM-141
Project: Seam 3 Distribution
Issue Type: Feature Request
Reporter: Dennis Mitchell
When I consider adopting a particular framework or technology, I often look at recent activity on the main website for the framework or technology. The most recent news posting for seamframework.org is 10 June 2010 -- over two years ago. (And the posting title seems a little defensive in nature -- kind of like "We know that you might tend to overlook a framework as seemingly complex as this, but we suggest that you take a closer look.") Please post something new in your news section -- let your window shoppers know that you are actively engaged in creating news-worthy progress in what can/should be regarded as the leading application framework for enterprise java.
--
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
11 years, 6 months
[JBoss JIRA] Created: (SEAMCONFIG-48) EAR contained WAR's beans.xml not processed
by Mike Mosiewicz (JIRA)
EAR contained WAR's beans.xml not processed
-------------------------------------------
Key: SEAMCONFIG-48
URL: https://issues.jboss.org/browse/SEAMCONFIG-48
Project: Seam Config
Issue Type: Bug
Affects Versions: 3.0.0.Final
Environment: JBoss AS 7
Reporter: Mike Mosiewicz
Assignee: Stuart Douglas
I have the EAR app containing one ejb jar and one war. I placed seam-config.jar in EAR's lib directory. My beans.xml are discovered by weld as follows:
15:21:36,588 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/mongodb-seam-0.0.1-SNAPSHOT.jar/META-INF/beans.xml"
15:21:36,591 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-persistence-api-3.0.0.Final.jar/META-INF/beans.xml"
15:21:36,592 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-security-api-3.0.0.Final.jar/META-INF/beans.xml"
15:21:36,594 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-servlet-3.0.0.Final.jar/META-INF/beans.xml"
15:21:36,597 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-solder-3.0.0.Final.jar/META-INF/beans.xml"
15:21:36,601 DEBUG [org.jboss.weld] (MSC service thread 1-3) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/commerce-ejb-0.0.1-SNAPSHOT.jar/META-INF/beans.xml"
15:21:36,603 DEBUG [org.jboss.weld] (MSC service thread 1-11) Found beans.xml: "/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/public-war.war/WEB-INF/beans.xml"
It seems that for ejb and other library jars the extension is executed but not for war. Like this:
15:21:54,173 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-security-api-3.0.0.Final.jar/META-INF/beans.xml
15:21:54,177 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/commerce-ejb-0.0.1-SNAPSHOT.jar/META-INF/beans.xml
15:21:54,195 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-servlet-3.0.0.Final.jar/META-INF/beans.xml
15:21:54,196 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/mongodb-seam-0.0.1-SNAPSHOT.jar/META-INF/beans.xml
15:21:54,197 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Reading XML file: vfs:/C:/servers/jboss-as-web-7.0.0.Final/standalone/deployments/laura.ear/lib/seam-solder-3.0.0.Final.jar/META-INF/beans.xml
15:21:54,204 INFO [org.jboss.seam.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-10) Adding XML Defined Bean: pl.proinet.seam.mongo.MongoResolver
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (JBSEAM-5050) seam:fragment doesn't skip rendering ui:include when seam:fragment rendered attribute is false
by Murat HAZER (JIRA)
Murat HAZER created JBSEAM-5050:
-----------------------------------
Summary: seam:fragment doesn't skip rendering ui:include when seam:fragment rendered attribute is false
Key: JBSEAM-5050
URL: https://issues.jboss.org/browse/JBSEAM-5050
Project: Seam 2
Issue Type: Bug
Components: JSF Integration
Affects Versions: 2.3.0.Final
Reporter: Murat HAZER
seam:fragment doesn't skip rendering ui:include when seam:fragment rendered attribute is false
<seam:fragment rendered="#{false}">
<ui:include src="myPage.xhtml" />
</seam:fragment>
normally nothing should be initialized related with myPage.xhtml bu all beans are initialized. In seam 2.2.2.Final this works as expected
--
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
11 years, 6 months
[JBoss JIRA] Created: (JBSEAM-4728) NPE involving o.j.s.mock.AbstractSeamTest.Request.init() and o.j.s.ui.facelet.RendererRequest.cleanup()
by Flavio Costa (JIRA)
NPE involving o.j.s.mock.AbstractSeamTest.Request.init() and o.j.s.ui.facelet.RendererRequest.cleanup()
-------------------------------------------------------------------------------------------------------
Key: JBSEAM-4728
URL: https://jira.jboss.org/browse/JBSEAM-4728
Project: Seam
Issue Type: Bug
Components: Mail, Test Harness
Affects Versions: 2.2.0.GA
Environment: java version "1.6.0_22"
Seam 2.2.0.GA
Reporter: Flavio Costa
Assignee: Pete Muir
I'm trying to come up with a solution to integrate Wiser (http://code.google.com/p/subethasmtp/wiki/Wiser) and Seam Mail (so that I can create tests asserting that the e-mail is actually sent) but I stumbled into a problem.
Seam Mail uses the "o.j.s.ui.facelet.RendererRequest" which sets up some mock objects to be able to render a XHTML in a String and send the e-mail.
This works fine in production, I can call it several times during a single request. It works like a charm.
The problems happens when trying to test the given method using SeamTest and its infrastructure.
What happens is, during o.j.s.mock.AbstractSeamTest.Request.init() it creates a new MockFacesContext and saves it so that whenever you call FacesContext.getInstance() or MockFacesContextFactory.getFacesContext() this same instance will be returned.
That's ok... for now.
Things get messier now.
Below code is extracted from RendererRequest.init()
.....
originalFacesContext = FacesContext.getCurrentInstance();
facesContext = RendererFacesContextFactory.instance().getFacesContext(request, response);
....
Problem here is that, due to AbstractSeamTest.Request.init() 'originalFacesContext == facesContext' and when RendererRequest.cleanup() is eventually called 'facesContext.release()' what happens is:
(Extracted from MockFacesContext.release())
setCurrentInstance(null);
MockFacesContextFactory.setFacesContext(null);
The next time someone calls MockFacesContext.getInstance() or MockFacesContextFactory.getFacesContext() they will return null and eventually this will result in a NPE.
Which is exactly what happens with me due to the fact that I call "Renderer.instance().render("mail.xhtml")" multiple times inside a method.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months