[JBoss JIRA] Created: (EJBTHREE-2197) Two WARs containing no-local-view EJBs with same name fails to deploy
by Nicklas Karlsson (JIRA)
Two WARs containing no-local-view EJBs with same name fails to deploy
---------------------------------------------------------------------
Key: EJBTHREE-2197
URL: https://jira.jboss.org/browse/EJBTHREE-2197
Project: EJB 3.0
Issue Type: Bug
Reporter: Nicklas Karlsson
Both try to bind to the same JNDI name causing the second WAR to fail deployment:
13:49:05,276 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/AS/jboss-6.0.0-SNAPSHOT/server/default/deploy/LTK.war$Kirjautumistoiminnot state=Create: javax.naming.NameAlreadyBoundException: no-interface
at org.jnp.server.NamingServer.bind(NamingServer.java:209) [:5.0.5.Final]
at org.jnp.server.NamingServer.bind(NamingServer.java:167) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:652) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:613) [:5.0.5.Final]
at org.jboss.util.naming.Util.bind(Util.java:105) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.util.naming.Util.bind(Util.java:91) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.ejb3.nointerface.impl.jndi.SessionAwareNoInterfaceViewJNDIBinder.bindNoInterfaceView(SessionAwareNoInterfaceViewJNDIBinder.java:118) [:]
at org.jboss.ejb3.nointerface.impl.jndi.NoInterfaceViewJNDIBinderFacade.onStart(NoInterfaceViewJNDIBinderFacade.java:127) [:]
at sun.reflect.GeneratedMethodAccessor336.invoke(Unknown Source) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.Alpha8]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha8]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha8]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0-SNAPSHOT]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBAS-9060) SFSB isn't disassociated from a transaction
by Carlo de Wolf (JIRA)
SFSB isn't disassociated from a transaction
-------------------------------------------
Key: JBAS-9060
URL: https://issues.jboss.org/browse/JBAS-9060
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: 7.0.0.Beta1
Reporter: Carlo de Wolf
Assignee: Carlo de Wolf
Priority: Critical
Fix For: 7.0.0.Beta2
{noformat}
javax.ejb.EJBException: EJB 3.1 FR 4.6 Stateful instance Mock for StatefulSessionComponentInstance, hashCode: 1035719231 is already associated with tx TX1 (current tx TX2)
at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:60)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBAS-9257) BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method
by Antonio Montanana (JIRA)
BridgeLogger implementation of Logger does not support Level.OFF or null as parameter values for setLevel method
----------------------------------------------------------------------------------------------------------------
Key: JBAS-9257
URL: https://issues.jboss.org/browse/JBAS-9257
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.M2
Reporter: Antonio Montanana
Assignee: David Lloyd
Deploying our application on the JBoss 6.0.0 application server we encounter the following NullPointerException (NPE) also logged in the
log\server.log file:
2011-03-17 12:52:18,269 ERROR
[filenet_error.engine.com.filenet.engine.tasks.TaskManager]
(TaskManager$RootTask_RootTask_ScheduledPoolExecutor_9)
TaskManager$RootTask:RootTask running with error , with message null:
java.lang.NullPointerException
at org.jboss.logmanager.log4j.LevelMapping.getLevelFor(LevelMapping.java:65) [:6.0.0.Final]
at org.jboss.logmanager.log4j.BridgeLogger.setPriority(BridgeLogger.java:199) [:6.0.0.Final]
at org.jboss.logmanager.log4j.BridgeLogger.setLevel(BridgeLogger.java:194) [:6.0.0.Final]
at com.filenet.engine.util.Logger.removeTraceLoggerLevel(Logger.java:377)
...
The com.filenet.engine.util.Logger.removeTraceLoggerLevel method executes the following two lines of code:
org.apache.log4j.Logger traceLogger = getLog4JTraceLogger(subsystem, traceFlag);
traceLogger.setLevel(null);
Note the setLevel method is passing in a null parameter value (supported by org.apache.log4j.Logger.setLevel) to remove the specified logging level. We've verified that the JBoss LevelMapping.getLevelFor method throws the NPE as a result of the null parameter value passed into setLevel (changing the parameter value to another level (e.g. Level.DEBUG) eliminates the exception). The setLevel(null) code executed with no exceptions in JBoss 5.1.0 and earlier versions of the server and is supported by org.apache.log4j.Logger.setLevel.
It appears that the logging mechanism has changed significantly in JBoss 6.0, there is now a BridgeLogger class that extends the
org.apache.log4j.Logger class providing the implementation of the setLevel method. That implementation appears to have omitted
support for "null" as a parameter value and causes the NPE. Further testing indicates that the Level.OFF value is also not supported either - leaving no way to remove the logging level.
We would like to see support for "null" and Level.OFF added to the BridgeLogger extension of Logger.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBAS-8781) Can't parse JSF TLD
by Stan Silvert (JIRA)
Can't parse JSF TLD
-------------------
Key: JBAS-8781
URL: https://issues.jboss.org/browse/JBAS-8781
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: 7.0.0.Alpha1
Reporter: Stan Silvert
Assignee: Remy Maucherat
WAR to reproduce is attached.
15:32:07,764 ERROR [org.jboss.as.server.deployment] (pool-3-thread-1) Caught exc
eption handling update (param is 10cd5140-b773-49da-97ab-0fb055b56141): java.lan
g.RuntimeException: Failed to process deployment chain.
at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe
ploymentStartStopHandler.java:203)
at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl
oymentStartStopHandler.java:87)
at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl
oymentStartStopHandler.java:71)
at org.jboss.as.model.ServerDeploymentStartStopHandler.redeploy(ServerDe
ploymentStartStopHandler.java:117)
at org.jboss.as.model.ServerModelDeploymentFullReplaceUpdate.applyUpdate
(ServerModelDeploymentFullReplaceUpdate.java:68)
at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl
e.applyUpdate(ServerUpdateController.java:430)
at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl
e.access$200(ServerUpdateController.java:400)
at org.jboss.as.server.mgmt.ServerUpdateController.applyUpdates(ServerUp
dateController.java:189)
at org.jboss.as.server.mgmt.ServerUpdateController.executeUpdates(Server
UpdateController.java:142)
at org.jboss.as.server.mgmt.deployment.ServerDeploymentManagerImpl$2.run
(ServerDeploymentManagerImpl.java:218)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:886) [:1.6.0_18]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:908) [:1.6.0_18]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_18]
Caused by: org.jboss.as.deployment.unit.DeploymentUnitProcessingException: Faile
d to parse "/C:/projects/as7trunk/jboss-as/build/target/jboss-7.0.0.Alpha2/bin/c
ontent/mojarra2.0-bundled.war/WEB-INF/lib/jsf-impl-2.0.3-b05.jar/META-INF/html_b
asic.tld"
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl
dParsingDeploymentProcessor.java:118)
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processTlds
(TldParsingDeploymentProcessor.java:97)
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processDepl
oyment(TldParsingDeploymentProcessor.java:77)
at org.jboss.as.deployment.chain.DeploymentChainImpl.processDeployment(D
eploymentChainImpl.java:50)
at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe
ploymentStartStopHandler.java:201)
... 12 more
Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.met
adata.web.spec.BodyContentType.
JSP
at java.lang.Enum.valueOf(Enum.java:196) [:1.6.0_18]
at org.jboss.metadata.web.spec.BodyContentType.valueOf(BodyContentType.j
ava:32)
at org.jboss.as.metadata.parser.jsp.TagMetaDataParser.parse(TagMetaDataP
arser.java:111)
at org.jboss.as.metadata.parser.jsp.TldMetaDataParser.parse(TldMetaDataP
arser.java:200)
at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl
dParsingDeploymentProcessor.java:116)
... 16 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[JBoss JIRA] Created: (JBMESSAGING-1456) Messages stuck in being-delivered state in cluster
by Justin Bertram (JIRA)
Messages stuck in being-delivered state in cluster
--------------------------------------------------
Key: JBMESSAGING-1456
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456
Project: JBoss Messaging
Issue Type: Bug
Reporter: Justin Bertram
Assignee: Tim Fox
Priority: Critical
Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes.
JBoss setup:
-2 nodes of JBoss EAP 4.3 CP02
-commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit
-MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms)
Client setup:
-both nodes have a client which is a separate process (i.e. not inside JBoss)
-clients are Spring based
-one client produces and consumes, the other client just consumes
-both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml
-both clients publish to and consume from "queue/testDistributedQueue"
-clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions
Symptoms of the issue:
-when running the clients I watch the JMX-Console for the "queue/testDistributedQueue"
-as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often
-after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0
-I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does
-after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck"
-a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue"
-a "killall -3 java" doesn't produce anything from the clients so I know their dead
-nothing is in any DLQ or expiry queue
-the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console
-rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them)
Other notes:
-nothing else is happening on either node but running the client and running JBoss
-this only appears to happen when a clustered connection factory is used. I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months