[JBoss JIRA] Created: (EJBTHREE-820) Hardcoded Destination Manager Reference
by Juha Lindfors (JIRA)
Hardcoded Destination Manager Reference
---------------------------------------
Key: EJBTHREE-820
URL: http://jira.jboss.com/jira/browse/EJBTHREE-820
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - Patch 1
Environment: JBoss AS 4.0.5.GA + EJB 3.0 RC9 + JBoss Messaging
Reporter: Juha Lindfors
Priority: Minor
When deploying an MDB that has been configured wrongly with a non existing destination the dubious feature that creates a temporary destination automatically fails due to hard coded destination manager reference that no longer exists if JBoss Messaging is used instead of JBossMQ.
MessagingContainer:
protected void createTemporaryDestination(Class type, String jndiSuffix) throws Exception
513 ObjectName destinationManagerName = new ObjectName("jboss.mq:service=DestinationManager");
Apologies, did not check if this issue exists still with the current code in the head/trunk, just needed to write it down before I forget it.
--
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: (JBREM-549) remove dependancy on concurrent.jar within remoting client
by Tom Elrod (JIRA)
remove dependancy on concurrent.jar within remoting client
----------------------------------------------------------
Key: JBREM-549
URL: http://jira.jboss.com/jira/browse/JBREM-549
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: general
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.0.0.CR1 (Boon)
Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id.
java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong
at org.jboss.util.id.UID.<clinit>(UID.java:56)
at org.jboss.util.id.VMID.create(VMID.java:259)
at org.jboss.util.id.VMID.getInstance(VMID.java:223)
at org.jboss.util.id.GUID.<init>(GUID.java:65)
at org.jboss.remoting.Client.<init>(Client.java:133)
at org.jboss.remoting.Client.<init>(Client.java:210)
at org.jboss.remoting.Client.<init>(Client.java:191)
at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80)
--
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: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
by Ron Sigal (JIRA)
Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
----------------------------------------------------------------------------------------------------------------------
Key: JBREM-577
URL: http://jira.jboss.com/jira/browse/JBREM-577
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.GA (Boon)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.0.0.GA (Boon)
This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor.
What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests.
--
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