October 2007 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: XIDFactory in EJB3

by adrian＠jboss.org

I found a reference to this in ejb3/src/resources/standalone/dist/embedded-jboss-beans as well as a reference to the old transaction manager. Is this still used with embedded project? I'm going to remove these references to keep things tidy. If its still used then it needs replacing with the jbossjta config. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094182#4094182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094182

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessageDriven tests in jboss-head

by clebert.suconic＠jboss.com

anonymous wrote : I'd like to fix it generically by changing the "persistenceManager" reference | to redeploy the DataSource, but that also doesn't work with JBoss Messaging. It wouldn't work until yesterday... I was having problems on jboss-as-4.2 and I fixed that. on the snapshot. what will make to 1.4.0.SP1 soon. If you stop/start the datasource, JBossMessaging will be restarted fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094168#4094168 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094168

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessageDriven tests in jboss-head

by adrian＠jboss.org

anonymous wrote : | If you tell me what test you were working before, I will also be taking a look on it. | The restartJMS() test needs to work. Currently it isn't even implemented | package org.jboss.test.messagedriven.test; | ... | public class JMSContainerInvokerQueueMessageDrivenUnitTestCase extends JMSContainerInvokerSimpleMessageDrivenUnitTest | ... | public void testRestartJMS() throws Exception | { | if (isJBossMessaging() == false) | { | Operation[] operations = new Operation[] | { | new SendMessageOperation(this, "1"), | new CheckMessageSizeOperation(this, 1, 0), | new CheckJMSDestinationOperation(this, 0, getDestination()), | new CheckMessageIDOperation(this, 0, "1"), | new StopOperation(this, persistenceManager), | new StartOperation(this, persistenceManager), | new SendMessageOperation(this, "2"), | new CheckMessageSizeOperation(this, 2, 20000), | new CheckJMSDestinationOperation(this, 0, getDestination()), | }; | runTest(operations, defaultProps); | } | else | { | System.out.println("FIXME testRestartJMS for JBoss Messaging"); | } | } | I'd like to fix it generically by changing the "persistenceManager" reference to redeploy the DataSource, but that also doesn't work with JBoss Messaging. The real fix is to have a JMSAdmin class for doing all the deployQueue(), start/stopDelivery(), restartJMSServer() in the testsuite. In fact, this nearly already exists in the Joram tests admin class. anonymous wrote : | Maybe... but we aways have more stuff to do than time available. | This attitude just makes more work for somebody else (like me) who has to come along later and fix the problems. Half a job now, usually means you have to do the twice the job in the long run ;-( Currently the jboss-head testsuite is showing me that the jms api at the jmx level is not backwards compatible with the older 4.2.x version or the jbossmq version in 5.0.x. One obvious example is the JMX name of the DLQ (and all the other hacks in the messagedriven test) | if (isJBossMessaging()) | { | testQueue = ObjectNameFactory.create("jboss.messaging.destination:service=Queue,name=testQueue"); | testTopic = ObjectNameFactory.create("jboss.messaging.destination:service=Topic,name=testTopic"); | testDurableTopic = ObjectNameFactory.create("jboss.messaging.destination:service=Topic,name=testDurableTopic"); | dlqJMXDestination = ObjectNameFactory.create("jboss.messaging.destination:service=Queue,name=DLQ"); | destinations = "jbossmessaging/test-destinations-full-service.xml"; | } | This wouldn't be a problem if we had a better api, e.g. the manage jms over jms I suggested over 2 years ago (which should really be in the jms spec :-). The "long term" goal is to be able to run all the tests against any JMS provider, otherwise how can we say JBoss works fine with WSMQ, etc. let alone expect to support it. You should have your own unit tests, the JBossAS testsuite should be generic, it shouldn't include hacks like the above "c macro" :-) Changing over JBossMessaging while still supporting jbossmq was an ideal opportunity to resolve the problem, one that was sadly missed. It's just another example where expediency leads to broken behaviour, i.e. the testsuite is not fit for purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094160#4094160 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094160

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessageDriven tests in jboss-head

by clebert.suconic＠jboss.com

Adrian, what test are you specifically referring to? anonymous wrote : Like I said originally, these tests should have been changed to use a pluggable | JMSAdmin class rather the hacks that are currently present. :-( we deploy XMLs in most of the destinations, as in some of them we have security attributes... so we need to mock what would happen in production. Maybe... but we aways have more stuff to do than time available. I just wanted to put the testsuite in a runnable state, besides the branch mania on jbossAS kind of sucked some of my time this quarter. If this JMSAdmin thing becomes a priority we can revisit it. Regarding the tests: There are few tests failing because of some config issue. For instance, if you start jboss-all and run the target "tests-jbossmessaging", the testsuite will run okay, but if you start from the main "test" target something is happening. I'm looking into that now. If you tell me what test you were working before, I will also be taking a look on it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094135#4094135 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094135

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Failed to create a new SAX parser

by richard_opalka

No, I haven't seen it yet. Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094123#4094123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094123

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Failed to create a new SAX parser

by thomas.diesler＠jboss.com

yes, that makes no difference. This is with https://svn.jboss.org/repos/jbossws/stack/native/branches/jbossws-native-... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094115#4094115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094115

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Issue with DescriptionGroup emement order and older descript

by scott.stark＠jboss.org

The org.jboss.test.metadata.web.WebApp23UnitTestCase.testVersion is failing in the jboss-metadata project due to how the javaee description group is a seqence of description, display-names, icons: | @JBossXmlModelGroup(name="descriptionGroup", propOrder={"descriptions", "displayNames", "icons"}) | public class DescriptionGroupMetaData implements Serializable | The issue is that when a web.xml that conforms to a web-app_2_3.dtd, which has a different order for these: | <!ELEMENT web-app (icon?, display-name?, description?, ...> | 3 different description groups end up being created, with each one only having a single property set. What is the best way to a override this behavior in the org.jboss.metadata.web.spec.Web23MetaData? Note that this is a problem for a 2.5 web.xml as well since the WebAppMetaData base class only declares a single valued DescriptionGroupMetaData property. Only the last set of in order elements shows up on the One way to fix this would be to make this a List of DescriptionGroupMetaData, and have the simple getIcon()/getDescription()/getDisplayName() accessors look over all DescriptionGroupMetaData for the first non-null result. To keep a single DescriptionGroupMetaData, it needs to be declared as a sequence of choices of the icon, display-name, description elements. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094097#4094097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094097

18 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Error in ejb-jar.xml

by fady.matar

18 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: [sim] language features

by kukeltje

anonymous wrote : | - actions/scripts doe something asychronous. Normaly this happens at the node-enter of some state. The state then waits for the results. This can already be realized by the current features set with a time-distribution for states. | Ah... ok, I missed the time-distribution for states, think I only saw it for tasks...probably a wrong assumption on my side.... anonymous wrote : | Agreed. But reports & result visualization is out of scope for the moment... Agreed ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094085#4094085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094085

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Failed to create a new SAX parser

by heiko.braun＠jboss.com

Yes, i've seen this. Does it also happen when using the build.sh? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094063#4094063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094063

18 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007