[JBoss-user] [EJB/JBoss] - strange deployment oddity
Hi People, I have a strange issue happening currently in my deployment. I've been given the task to perform some in-container tests of a message driven bean on our server. I'll just clarify that by in container, I mean that client requests to the MDB must come from inside the container. Originally these test were required to ensure that JBoss could handle JMS well but now it's moved more onto questions of the beans stability. In order to test this, I decided to create a new EAR file which would lookup the queue and make requests to it. The oddity isn't really anything to do with MDB's, the problem I am facing is that for some reason, the code executing in the message bean has problems when I've deployed my test EAR file to the server. The problems I have are kind of hard to pin down whilst remaining pretty black box about the component I have been set to test. One thing which does seem to fix it however, and as strange as this is, is to remove the test EAR from a running JBoss and put it back in, restart, and everything works as normal. My only explanation is that the ordering of classes loaded in the EARs is causing a conflict, this could be because they contain some common JAR files from our project. So, my question to you readers out there are what could be some likely causes... - static variables (they're a big no no, and i'm pretty sure the code i'm testing uses them to excess without understanding the implications) - ??? Any hints would be grateful, bruciadmin View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3857939#3857939 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3857939 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB/JBoss] - Re: Potential Bug when looking up on localhost
Thanks heaps, This was the problem (the first answer with the JVM property). It seems that when I was upgrading the installations and transferring the customizations we'd made to 3.2.3 startup scripts, I made a silly mistake with customizing the JAVA_OPTS variable. Instead of the usual windows property setting, set VAR=VALUE, I suffered an attack of windows/unix dislexia and put in VAR=VALUE. What this meant was that the rmi variable not being set, which is exactly what you thought it was. Sorry for posting this as a bug, I guess I'll be eating some bad tasting humble pie for a week or more. Cheers, David L View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3839348#3839348 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3839348 --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB/JBoss] - Potential Bug when looking up on localhost
Hi There,
I hope this is the right place to post this, I think I've found a bug with the naming
component of JBoss 3.2.4. I've tested with JDK 1.4.2_02 and 1.4.2_04. This problem
was not in the previous version we were using (3.2.3) and was discovered initially
upon upgrade. The problem seems to manifest when I configure the JBoss servers JNDI
bound interface to the loopback (localhost).
It appears that JBoss itself is working, but the lookup is failing (the client code,
not the server). Every attempt to lookup the home interface results in the following:
javax.naming.CommunicationException [Root exception is java.rmi.ConnectException:
Connection refused to host: 192.168.X.X; nested exception is:
java.net.ConnectException: Connection refused: connect]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:647)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at
au.com.distillery.iqore.utilities.ejb.test.JNDILookupTest.testJNDILookup(JNDILookupTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:392)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:276)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:167)
Caused by: java.rmi.ConnectException: Connection refused to host: 192.168.1.26; nested
exception is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528)
... 18 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at java.net.Socket.(Socket.java:309)
at java.net.Socket.(Socket.java:124)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
... 23 more
For a long time I tested various scenarios, and everything points to an error on the
client. I've tested this against a fresh jboss installation with only one change to
the configuration (the bind interface for JNDI is localhost). I eventually got
annoyed enough to write a simple testcase which I've included below.
public class JNDILookupTest extends TestCase
{
public void testJNDILookup() {
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
ht.put(Context.PROVIDER_URL, jnp://localhost:1099);
CommandManagerHome home = null;
try {
ctx = new InitialContext(ht);
String lookupClassName = CommandManagerHome.class.getName();
home = (CommandManagerHome) ctx.lookup(lookupClassName);
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
ctx.close();
} catch (Exception e) { }
}
assertTrue(home != null);
}
}
Please help or confirm the issue, a workaround isn't hard to implement (just don't use
localhost) but I would rather not.
Thanks,
David L
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3839033#3839033
Reply to the post :
