[Design of Messaging on JBoss (Messaging/JBoss)] - Re: org.jboss.test.jbossmq.test cleanup in jboss5
by rachmatowicz@jboss.com
The org.jboss.test.jbossmessaging.test tests consist of all the JMS tests from org.jboss.test.jbossmq.test which (i) did not have any obvious dependencies on JBossMQ and (ii) have been modified in such a way that they can be executed against JBossMQ or Messaging by setting up appropriate configuration files.
The idea was to eventually have one directory of JMS tests, which would exercise only pure JMS functionality, and could be executed against either JMS implementation. At present, only the Messaging implementation is using these tests, as it is the default JMS provider in JBoss 5.
I have a spreadsheet which I used to categorise the JBossMQ, if it is of any interest. There were some JBossMQ tests which are still in a pending state ( not yet included in the jbossmessaging package) as they test XA recovery, and XA recovery was not available in Messaging at the time.
This list of tests from JBossMQ which were not carried over is:
CleanTopicRemovalUnitTestCase
ClientMonitorConnectionRaceUnitTestCase
DestinationFullUnitTestCase
HTTPConnectionUnitTestCase
LargeMessageUnitTestCase
NackWithRollbackUnitTestCase
SelectorParserUnitTestCase
SelectorSyntaxUnitTestCase
UIL2ConnectionUnitTestCase
UIL2InvocationLayerStressTestCase
ExpiryDestinationTestCase
HTTPJBossMQUnitTestCase
ScheduledDeliveryUnitTestCase
UIL2JBossMQUnitTestCase
ReceiversImplStressTestCase
ReceiversImplArrayListStressTestCase
ReceiversImplLinkedListStressTestCase
These all had JBossMQ depenedencies referenced in them. However, it may be that, for some of these tests, aside from some minor dependency on JBossMQ, a similar generic JMS test might want to be developed (e.g. LargeMessageUnitTestCase)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032576#4032576
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032576
17 years, 10 months
[Design of POJO Server] - Re: Implicit container dependencies
by wolfc
"adrian(a)jboss.org" wrote : This has been turned off in JBoss5 (at least for EJB2).
|
| 1) The code was not (is not) portable
|
| 2) Just because remote access to jndi (either another member of the cluster
| or a thirdparty jms provider) is flakey, you don't want it to create a queue
|
| 3) It obscures the most common problem, which is that you mistyped the jndi name
|
I want this functionality. The feature is that if you're running EJB3 with JBoss Messaging, EJB3 will create a queue for you if needed.
1. We only do it when running JBoss Messaging, so it's not ment to be portable.
2. We don't stuff anything in JNDI, we ask JBoss Messaging for a queue.
It's similar to JBCTS-541, only there j2ee-mods is asking for a queue. I don't see a problem in that. Either admin, j2ee-mods or EJB3 deployer is creating a queue.
BTW. I want to get JBCTS-541 out of the way. Shall I create a new DestinationManager which hooks into ServerPeer?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032567#4032567
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032567
17 years, 10 months