Weblogic 6.0 client classes
Pat Scarborough
Hi, Christian,
So what did you do to correct the problem?
I have several Linux machines running WL server. They all work fine except the
two new ones I set up a couple of weeks ago. I' having the same problem you described
here: I can get an initial context, but can't do a lookup.
Thing is, ALL my /etc/hosts files have the "localhost" entry you described, and
they all work - except the two new boxes.
??? Curious...
Pat
Christian Taubman <ctau...@limebrokerage.com> wrote:
>
>Sorry to clutter the newsgroup but I found the problem and the solution
>
>might be of interest to someone else.
>
>/etc/hosts on linux-server had one line in it:
>127.0.0.1 linux-server localhost.localdomain localhost
>
>The WL server was reading its ip address as 127.0.0.1 rather than going
>
>to the DNS to get it.
>
>Christian
>
>
>Christian Taubman wrote:
>
>>
>> OK, I've narrowed down my problem a little. It only occurs with one
>
>> linux machine I have--unfortunately this is our test weblogic6.0
>> server. Let's call this server linux-server.
>>
>> The remote client creates an InitialContext with PROVIDER_URL set to
>
>> linux-server. That works fine, and I know that the connection is
>> initially established because the weblogic server prints out the info
>
>> message: <Adding address:
>> remote-client.limebrokerage.com/192.168.0.163 to licensed client
>> list>. The remote client then tries to lookup an ejb home using this
>
>> InitialContext. The client has weblogic_sp.jar, weblogic.jar, and
>the
>> ejb home and remote interfaces in its classpath, but it doesn't have
>
>> the weblogic-generated ejb stub classes, so it tries to download these
>
>> from the server. The thing is, it tries to dowload them from
>> 127.0.0.1:7001 rather than linux-server. Since there's no weblogic
>
>> server on the remote machine (and no-one listening on port 7001) the
>
>> connection is refused, the client can't get the stub classes, and the
>
>> client exits.
>>
>> If I run the client on linux-server, it works. If I run a weblogic
>
>> server on the remote client with the same ejb-jar deployed, it works
>
>> because the client is able to sucessfully download the classes from
>
>> 127.0.0.1:7001. It doesn't matter where I run the client. If I run
>
>> the server anywhere else it seems to work (on either linux or winnt).
>>
>> It seems like this is a setup problem on linux-server, either with
>
>> weblogic or something else. Nothing special has been done to the os
>
>> of linux-server--it just has an up2date RedHat7.0 on it. Does anyone
>
>> have any idea what might be causing the client to look to localhost
>
>> for the stub classes? Any WL people out there, how does the client
>
>> decide where to look for these classes?
>>
>> Thanks in advance,
>>
>> Christian
>>
>>
>> Jason Carroll (me) wrote:
>>
>>> No, I'm just running a client in a JVM that's trying to lookup an
>
>>> ejb. It seems very strange to me that this works when the client is
>
>>> on the
>>> same machine as the server, but not generates this error when it's
>
>>> not. I can run the web-based administration console remotely, so it's
>>> possible to open a connection to port 7001. If I put the ejbc generated
>>> classes in the client's classpath it fixes the problem, but I'd rather
>>> not have to do that for all my clients...
>>>
>>> Christian
>>>
>>> Cameron Purdy wrote:
>>>
>>>> WL won't download classes to another WL. Is that what you are seeing?
>>>>
>>>> --
>>>> Cameron Purdy
>>>> Tangosol, Inc.
>>>> http://www.tangosol.com
>>>> +1.617.623.5782
>>>> WebLogic Consulting Available
>>>>
>>>> "Christian Taubman" <ctau...@limebrokerage.com> wrote in message
>>>> news:3A9848...@limebrokerage.com...
>>>>
>>>>> When running my java client on the same machine as the WL6.0 server
>>>>> things work fine. When running the client on a remote machine I
>get a
>>>>> warning on the client side that the HttpClient can't open the
>>>>> connection, and then my InitialContext lookup fails because it can't
>>>>> load the stub class. It seems to me like the client isn't able
>to get
>>>>> the stub classes over the wire from the server for some reason.
> Does
>>>>> anyone know why that might be? Is this even the problem? Here
>is the
>>>>> warning and the exception:
>>>>>
>>>>> java.net.ConnectException: Connection refused
>>>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>>>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:312)
>>>>> at
>>>>> java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:125)
>>>>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:112)
>>>>> at java.net.Socket.<init>(Socket.java:273)
>>>>> at java.net.Socket.<init>(Socket.java:127)
>>>>> at weblogic.net.http.HttpClient.openServer(HttpClient.java:162)
>>>>> at weblogic.net.http.HttpClient.openServer(HttpClient.java:221)
>>>>> at weblogic.net.http.HttpClient.<init>(HttpClient.java:85)
>>>>> at weblogic.net.http.HttpClient.New(HttpClient.java:117)
>>>>> at
>>>>
>>>>
>>>> weblogic.net.http.HttpURLConnection.connect(HttpURLConnection.java:99)
>>>>
>>>>> at
>>>>>
>>>> weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:26
>
>>>>
>>>> 9)
>>>>
>>>>> at
>>>>> weblogic.utils.classloaders.URLSource.getInputStream(URLSource.java:23)
>
>>>>>
>>>>> at
>>>>> weblogic.utils.classloaders.URLSource.getBytes(URLSource.java:33)
>>>>> at
>>>>>
>>>> weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
>
>>>>
>>>> ader.java:247)
>>>>
>>>>> at
>>>>>
>>>> weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
>
>>>>
>>>> java:147)
>>>>
>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
>>>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
>>>>> at java.lang.Class.forName0(Native Method)
>>>>> at java.lang.Class.forName(Class.java:195)
>>>>> at
>>>>>
>>>> weblogic.j2ee.ApplicationManager.loadFromNetwork(ApplicationManager.java:239
>
>>>>
>>>> )
>>>>
>>>>> at
>>>>> weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:134)
>
>>>>>
>>>>> at
>>>>> weblogic.rjvm.ClassTableEntry.getDescriptor(ClassTableEntry.java:37)
>>>>> at
>>>>> weblogic.rjvm.InboundMsgAbbrev.getDescriptor(InboundMsgAbbrev.java:132)
>
>>>>>
>>>>> at
>>>>>
>>>> weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.
>
>>>>
>>>> java:171)
>>>>
>>>>> at
>>>>>
>>>> weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
>
>>>>
>>>> putStream.java:90)
>>>>
>>>>> at
>>>>>
>>>> weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
>
>>>>
>>>> putStream.java:114)
>>>>
>>>>> at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:47)
>>>>> at
>>>>>
>>>> weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:136
>
>>>>
>>>> )
>>>>
>>>>> at
>>>>>
>>>> weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
>
>>>>
>>>> :251)
>>>>
>>>>> at
>>>>>
>>>> weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
>
>>>>
>>>> :225)
>>>>
>>>>> at
>>>>>
>>>> weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(ServerNamingNode_WLStu
>
>>>>
>>>> b.java:121)
>>>>
>>>>> at
>>>>> weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
>>>>>
>>>>>
>>>>> Exception: javax.naming.CommunicationException [Root exception is
>>>>> java.rmi.UnmarshalException: failed to unmarshal class
>>>>> java.lang.Object;
>>>>> nested exception is: java.lang.ClassNotFoundException:
>>>>> MyBeanHomeImpl_WLStub]
>>>>>
>>>>> Christian
>>>>>
>>
>
Pat Scarborough
Ok, now its my turn to clutter up the newsgroup. Apologies to all in advance:
Examining my "localhost" entry in /etc/hosts I found on the "new" (nonworking)
machine the following entry:
127.0.0.1 localhost.localdomain localhost xyz123
..which I replaced with:
127.0.0.1 localhost.localdomain localhost
When I restarted WL server it whined about not being able to find xyz123, and
died. I then added this line:
192.123.456.789 xyz123
..and WL server started and the client was able to connect properly.
Apparently when WebLogic is installed it searches the /etc/hosts file for the
first alias which is *not* "localhost", then stashes that away somewhere to be
used for stubs (or whatever). I found it in bea/registry.xml but changing it
there with a corresponding /etc/hosts entry didn't work. Its probably buried
in a .war file somewhere.
If anyone knows where this value is saved I'd appreciate knowing! I may need
to change it later. This little "feature" has cost us about three weeks downtime.