[JBoss JIRA] Created: (JBAS-3654) The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
by Sakthi Samabsivam (JIRA)
The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
----------------------------------------------------------------------------
Key: JBAS-3654
URL: http://jira.jboss.com/jira/browse/JBAS-3654
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3RC2, JBossAS-4.0.3RC1
Reporter: Sakthi Samabsivam
Assigned To: Dimitris Andreadis
When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
for example. I have two ears example1. ear and example2.ear.
I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
So I am wrting this depends tag entry in my example1.ear's WAR compoent jboss-web.xml
<depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
This depends is working till jboss 4.0.1
It fails in 4.0.3 SP1 , 4.0.4 GA
15:52:24,359 WARN [ServiceController] Problem starting service jboss.web.deploy
ment:war=crimeportal.war,id=-1360680885
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
e: (javax.security.jacc.PolicyContextException: Operation not allowed)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
at org.jboss.web.WebModule.startModule(WebModule.java:68)
at org.jboss.web.WebModule.startService(WebModule.java:46)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at org.jboss.system.ServiceController.start(ServiceController.java:446)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy21.start(Unknown Source)
at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:507)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:265)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
at org.jboss.Main.boot(Main.java:187)
at org.jboss.Main$1.run(Main.java:438)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:201)
at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
ossPolicyConfiguration.java:160)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
... 94 more
Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
tion: linkConfiguration from state:inService
at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:196)
... 96 more
15:52:24,359 INFO [EARDeployer] Started J2EE application: file:/C:/jboss/traini
ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBAS-4399) @EJB in JSF ignores mappedName
by Carlo de Wolf (JIRA)
@EJB in JSF ignores mappedName
------------------------------
Key: JBAS-4399
URL: http://jira.jboss.com/jira/browse/JBAS-4399
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Carlo de Wolf
Using mappedName on an @EJB in a JSF managed bean doesn't work.
DefaultAnnotationProcessor ignores mappedName and will then perform a standard field lookup <bean>/<field>, resulting in a NameNotFoundException.
16:12:46,859 ERROR [JBossInjectionProvider] Injection failed on managed bean.
javax.naming.NameNotFoundException: com.genloop.web.Projektabrechnung.Projektabrechnung_v13.beans.screen.Partner_Einzelperson_Screen not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:628)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:590)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.apache.catalina.util.DefaultAnnotationProcessor.lookupFieldResource(DefaultAnnotationProcessor.java:203)
at org.apache.catalina.util.DefaultAnnotationProcessor.processAnnotations(DefaultAnnotationProcessor.java:139)
at org.jboss.web.jsf.integration.injection.JBossInjectionProvider.inject(JBossInjectionProvider.java:104)
at com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:298)
at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:531)
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:82)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45)
at org.apache.el.parser.AstValue.getValue(AstValue.java:86)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101)
at javax.faces.component.UIOutput.getValue(UIOutput.java:173)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:189)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:320)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:200)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:833)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:896)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:137)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:809)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
at com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:244)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBAS-3591) For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on
by Brian Stansberry (JIRA)
For SESSION and ATTRIBUTE don't marshal values if UseRegionBasedMarshalling is on
---------------------------------------------------------------------------------
Key: JBAS-3591
URL: http://jira.jboss.com/jira/browse/JBAS-3591
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR1
Storing session or attributes in the cache as byte[] or MarshalledValue is unnecessary if region based marshalling is used. Doing it greatly increases the memory footprint of distributed sessions.
Need to benchmark the performance impact of this (could be positive or negative), although the memory savings would outweigh all but a major performance loss.
Can't do this in Branch_4_0 is it breaks binary compatibility.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[JBoss JIRA] Created: (JBAS-3914) Thread dumps from ServerInfo MBean do not contain line breaks.
by Darran Lofthouse (JIRA)
Thread dumps from ServerInfo MBean do not contain line breaks.
--------------------------------------------------------------
Key: JBAS-3914
URL: http://jira.jboss.com/jira/browse/JBAS-3914
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-4.0.5.GA
Reporter: Darran Lofthouse
Assigned To: Darran Lofthouse
Fix For: JBossAS-4.2.0.CR1
Thread dumps from ServerInfo MBean do not contain line breaks, as the output HTML and displayed in a browser this is generally not a problem as the browser formats the output using the HTML tags not based on the presence of line breaks.
If users copy the data from the web browser to a text editor as there are no line breaks in the original output the data is pasted to the text editor without breaks which causes everything to be on one line.
The ouput thread dumps should have line breaks added to get round this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JGRP-528) NAKACK: spurious retransmission requests
by Bela Ban (JIRA)
NAKACK: spurious retransmission requests
-----------------------------------------
Key: JGRP-528
URL: http://jira.jboss.com/jira/browse/JGRP-528
Project: JGroups
Issue Type: Task
Affects Versions: 2.5
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
Every now and then, spurious retransmission requests are received:
NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)]
It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message.
This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads).
Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys
by Vadim Kopichenko (JIRA)
Ejb timers fire before the ear completely deploys
-------------------------------------------------
Key: JBAS-4083
URL: http://jira.jboss.com/jira/browse/JBAS-4083
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2, Scheduling/Timers
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Environment: WinNT, Sun JDK 1.5
Reporter: Vadim Kopichenko
Assigned To: Scott M Stark
Consider the following usecase.
The is an ear containing several ejb modules.
One of them has a ejb2.1 timed cmp entity bean.
If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed.
This breaks application logic.
The problem happens both while server starts/stops and while hot ear's redeployment.
It would be much better if timers began to fire after the application had completely deployed.
I've also experienced a similar problem with undeployment.
Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment.
I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue.
Please, try also to investigate if this can be avoided.
PS
Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0
by Vali Dumitru (JIRA)
Class Cast Exception - when using CometProcessor - Jboss 4.2.0
--------------------------------------------------------------
Key: JBWEB-84
URL: http://jira.jboss.com/jira/browse/JBWEB-84
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows
Reporter: Vali Dumitru
Assigned To: Mladen Turk
I have a servlet that implements CometProcessor interface. Whenever I try to access it I get :
java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398)
at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
What is this? Is there a workaround?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBAS-4382) EnterpriseContext lock counting is not synchronized
by Adrian Brock (JIRA)
EnterpriseContext lock counting is not synchronized
---------------------------------------------------
Key: JBAS-4382
URL: http://jira.jboss.com/jira/browse/JBAS-4382
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Reporter: Adrian Brock
Assigned To: Scott M Stark
Fix For: JBossAS-4.2.0.GA
The lock counting in org.jboss.ejb.EnterpriseContext is not synchronized.
The lock ivar is not even volatile.
This variable needs replacing with synchronized method blocks or an oswego concurrent SynchronizedInt.
This bug could either cause passivation to be invoked when it shouldn't or vice versa.
Additionally, even with this fix, the usage in StatefulSessionInstanceInterceptor needs replacing with something more atomic!
if (!ctx.isLocked())
{
//take it!
ctx.lock();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months