I am using weblogic 8.1.5 cluster with 4 instances. And a standalone java application client to call a ejb in weblogic server by t3 protocol.
And i found some strange log in the access.log of the weblogic server.
127.0.0.1 - - [24/Jul/2009:15:48:45 +0800] "GET /bea_wls_internal/classes/cdmvbase@/com/upsscs/cdmv/server/outbound/ejb/_ConveyerSBHome_Stub.class HTTP/1.1" 200 4241
I'm wondering is this http request sent by the java client?
What's the senario of a EJB call via t3 protocol and how this http request happened?
The WebLogic server contains a built-in servlet, called ClasspathServlet, to serve Java resources in a distributed manner. The URL syntax is as follows: http://<servername>:<port>/bea_wls_internal/classes
The bea_wls_internal is a default Web application that is enabled by default. The /classes part of the URL is registered to the internal weblogic.servlet.ClasspathServlet.
*1).* If the URL is set to */bea_wls_internal/classes* , the classes required by the thin J2EE client should be available in the system classpath of the server.
*2).* If the URL is set to */bea_wls_internal/classes/DefaultWebApp@DefaultWeb-App*, the classes required by the thin J2EE client should be in the applications/DefaultWebApp/WEB-INF/classes directory or in the system classpath.
So whatever output you are seeing is actually done by WebLogic to get the classes in the classpath of other nodes as well as the same node.
Jay SenSharma http://jaysensharma.wordpress.com (WebLogic Wonders Are Here)
Thanks for the answer.
But my question is: Is the client using t3 protocol to call EJB will using this servlet?
Cause i found such log in my access.log, but when i try to test locally, using a j2ee client to call EJB via t3. It seems no such http log created in access.log. So could you tell me when will this http request to bea_wls_internal servlet happend?
So i don't know how this log come from, and the stubs should generated by container when EJB deployed/called?
I find some such http get the EJB stub classes log in access.log, some of them return http 200 code, but some of them are return 404 error code. So i don't know why it return 404 error.
When i try to using URLClassLoader to test if the stubs are in weblogic classpath, I didn't found the stub classes.
This is how i think it should work
The access log entry should come when the client VM requests the stub classes over HTTP
After the client VM loads the classes, it should make the t3 call to proceed to your business logic methods
The client VM should not request the stubs again unless you reboot it.
usually the stubs are clusteraware .. so , 404s could be cluster related.. What is the t3 url you are using to access the EJB ?
Thanks maverick, this make sense.
I am using the url of my first cluster instance to access ejb via t3 protocol.
And i have 4 instances in my cluster, they are ip1:port1, ip1:port2 and ip2:port1, ip2:port2
So my connection url like: t3://ip1:port1/...
And seems it worked fine when i test locally. The client will access the ejb in other instances as well.
And when i do the test i didn't find any access log in weblogic console.
If as your said, client VM will get the ejb stubs everytime at the new begining to call the ejb via t3. We should get the access log everytime when we restart the client VM. Am i right?
But the strange thing is i can find some 404 error log in access.log to request stub classes, but i can't reproduce it locally.
The client will check with RMI registry to find out the codebase of the stubs.
The registry might return a clusteraware stub and the client might be hitting different instances in the culster to get the stubs.
Technically this should work.. but i think this is where its failing..
The simplest fix would be to place the stubs on the client class path
Other options you could try
- regenerate the stubs so that they are not clusteraware
- change the t3 url to use the cluster (I doubt that this works.. but you could give it a try)