[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, 11 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, 11 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, 11 months
[JBoss JIRA] Created: (JBCACHE-877) TreeCache usage should not depend on trove.jar
by Galder Zamarreno (JIRA)
TreeCache usage should not depend on trove.jar
----------------------------------------------
Key: JBCACHE-877
URL: http://jira.jboss.com/jira/browse/JBCACHE-877
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Galder Zamarreno
Assigned To: Manik Surtani
Priority: Minor
A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and
even though it only uses plain TreeCache, it gets a
NoClassDefFoundError for trove classes.
2006-11-23 13:19:03,781 ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
This is a TreeCacheAop/PojoCache dependency and therefore,
should be isolated and attempted to be loaded only when
PojoCache used.
--
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, 11 months
[JBoss JIRA] Created: (JBCACHE-772) State transfer not handled properly in case of reconnect
by Brian Stansberry (JIRA)
State transfer not handled properly in case of reconnect
--------------------------------------------------------
Key: JBCACHE-772
URL: http://jira.jboss.com/jira/browse/JBCACHE-772
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.1.0
In createService(), TreeCache set Channel.AUTO_GET_STATE to true. This should only be done if the cache is configured to do an initial state transfer.
That's easy to fix. What's harder to fix is what to do when region-based marshalling is in effect. Probably, something like the following:
1) In viewAccepted, monitor for the case where a view is issue that doesn't include the current node. Set a flag and ??? (throw exceptions when attempts are made to use the cache???)
2) When another view is accepted that once again includes the current node, iterate through the various marshalling regions, inactivating and then reactivating them (reactivation will cause a partial state transfer).
--
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, 12 months