JBossDeveloper

I have checked out the CP branch, and installed in into JBoss AS 4.2.1GA. (It seems to work, so I guess it is the right version?) But I need to install JBoss Messaging as well, as all my ESB-projects use it. Which version should I pick of JBoss Messaging?

(The document product/install/Deployment.txt seems to be fairly outdated. It says that the ESB Server has been tested with JBoss AS version 4.0.4.GA, but http://labs.jboss.com/file-access/default/members/jbossesb/freezone/docs/4.2.1GA/manuals/pdf/GettingStarted.pdf mentions JBoss AS 4.2.1..)

Regards, Haagen

Where can I see which versions of different libraries you are using? I tried to deploy the quickstart "native_client", but ended up with this error:

BUILD FAILED
C:\opensource\jbosslabs\esb-source\product\samples\quickstarts\conf\base-build.xml:459: **** DEPLOYMENT FAILED... Sorry, this Quickstart requires a modified JBoss Webservice container, please refer to the 'Configuring Webservice Integration' section
of the Administration Guide.

When I run the quickstarts I get the following error:

Caused by: javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.apache.juddi.registry.rmi.Inquiry (no security manager: RMI class loader disabled)]
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:730)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:589)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)
 at org.apache.ws.scout.transport.RMITransport.send(RMITransport.java:80)
 ... 29 more
Caused by: java.lang.ClassNotFoundException: org.apache.juddi.registry.rmi.Inquiry (no security manager: RMI class loader disabled)
 at sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:531)
 at java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:628)
 at java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:294)
 at sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:238)
 at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1500)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1463)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
 at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:654)

"beve" wrote:
Hi Haagen,

could you tell me which quickstart you ran when you got that Exception?
Are you building and running from the main trunk?

Thanks,

Daniel

System.setProperty("java.security.policy", "client.policy");
 if (System.getSecurityManager() == null)
 System.setSecurityManager(new RMISecurityManager());

[echo] Runs Test ESB Message Sender
 [java] 15:01:47,951 WARN [main][MarshalFactory] Found marshaller fully qualified class name within locator parameters, but was unable to load class: org.jboss.jms.wireformat.JMSWireFormat

I forgot to say; I was building from http://anonsvn.jboss.org/repos/labs/labs/jbossesb/branches/JBESB_4_2_1_GA_CP
I updated some days ago.

NB. My concern here is not really being able to build the ESB from svn. My concern is not understanding why messages are being resent, and being able to control that behaviour.

Regards, Haagen

I find the following code in ServiceInvoker.post():

Message replyMessage;
 EPR epr;
 // Iterate over all the EPRs in the list until delivered
 while ((epr = loadBalancer.chooseEPR(serviceClusterInfo)) != null) {
 try
 {
 replyMessage = eprInvoker.attemptDelivery(message, epr);
 if (replyMessage != null) {
 // We've delivered it, we're done!
 return replyMessage;
 } else {
 logger.info("Unresponsive EPR: " + epr+" for message: "+message.getHeader());

 serviceClusterInfo.removeDeadEPR(epr);
 }
 }
 catch (MalformedEPRException ex) // so we can differentiate failure modes, since returning null is limiting
 {
 logger.info("Invalid EPR for service: ignoring for message: "+message.getHeader());

 serviceClusterInfo.removeDeadEPR(epr);
 }
 }
 }

Yes, of course it has been delivered, I'm not trying to say that it hasn't. My point is that is has been more than just delivered - it has also been picked up again. I'm refering to this code in the attemptDelivery-method:

if (courier.deliver(message)) {
 if (synchronous) {
 // JBESB-1016 replyToEPR has to be non-null or we'd have dropped out by this point!

 // do we need to do this for synchronous calls? Vagueries of Couriers?

 courier.setReplyToEpr(replyToEPR);
 return courier.pickup(timeout);
 } else {
 return message;
 }
 }