RMI classloader issues in TC - second time

[Nikola Milutinovic]

Hi all.

I have been mucking around this for some time and have some empirical 
data and a question for the list.


BACKGROUND
---

I'm building a web client for a RMI client/server application. RMI 
server and client are working from command line. Next I built 
JSP/Servlet which uses that RMI client interface to give web GUI to the 
application.


RMI server: "SearchServerStub implements SearchRMI"
RMI Stub: "SearchServerStub_Stub" (I'm running in JDK 1.5.0, thus no 
"*_Skel" class)

RMI client: "SearchClientRMI"

Whenever my Servlet/JSP executes a method of SearchClientRMI, which has 
this in it:


SearchRMI server = (SearchRMI) Naming.lookup( "rmi://localhost/Search" );

I get a ClassCastException: SearchSearverStub_Stub. I have inspected 
this from a debugger (JBuilder) and the class that is returned from 
"Naming.lookup(...)" is SearchServerStub_Stub", which DOES implement 
"SearchRMI".


TRIAL&ERROR
--

Well, fiddling around with the whole setup has given me a situation 
under which this works. If I copy "SearchServerStub_Stub" into 
WEB-INF/classes I do not get the exception.


CONCLUSION
--

I can say with 99% certainty that this is a classloader issue. TC sets 
up a classloader for my web-app which reads from WEB-INF/{classes,lib} - 
that I know. RMI has it's own classloader, as it must - that I also 
know. It looks like the class loaded by one classloader cannot mix with 
a class from another. I believe I have read something like that in one 
JBoss article. In this case my local webapp classloader is first 
queried, I guess, and it loads the requested class from it's classpath. 
In unsuccessful case, the _Stub class was loaded by RMI's classloader 
and thus the difference.


QUESTION
-

Given my situation, what is your recomendation I should do?

I can copy stub classes to the client, but that is awkward and IT IS NOT 
what RMI was intended for. It was intended for transparent and network 
located classloading. If I have to copy RMI stub classes (and, I 
suspect, implementation classes, too) to the client (web application, in 
this case), then I'm better off not using RMI at all. Can someone 
advise? Has anyone been bitten by this?


I think this is mostly intended for the TC developers, not to forget 
JBoss group, too. But, anyone who has insight into this matter is 
welcome. I'm relieved to have a working solution, even if it is a 
patch-quality. I will have to evaluate the applicability of RMI in this 
situation.


It could be that I'm doing something wrong here. Just to note, I'm not 
setting on TC anything RMI specific, like "-Djava.rmi.server.codebase", 
only the security policy (and, boy, does that need being relaxed, I had 
to open connection to TCP ports 1024-65535).


TYIA,
Nix.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Classloader issues in tomcat 4.1.x (SDK1.4.2), using multi-containers

[David Henry]

We are trying to setup a Tomcat Service for our developers.   The intention is that 
our platform is to be consolidated, meaning we will be running multiple Tomcat 
Containers under a single Tomcat installation (in this case 4.1.29).  

We work with a number of scientists who have paid for a 3rd Party application that was 
certified using the LE version of Tomcat.   For various reasons, we do not want to 
manage a seperate Tomcat Platform just for one application.   

The vendor chose to throw a version of the xerces.jar file into their /WEB-INF/lib 
directory.   Since the LE version does not come with any xerces jars in the 
/common/endorsed directory, the application works fine in the LE version, but when we 
try to port it over to our Full Edition, it fails with a java.lang.VerifyError 

We have kept the default jar files in the /common/endorsed directory (xerces.jar, 
xercesImpl.jar, and xmlParser.jar), and other applications are referencing them.   If 
I remove the xerces.jar and xercesImpl.jar from the /endorsed directory, the 
application works, but this is not an acceptable solution, because other applications 
are using these jar's.   

I also cannot modify the vendor's code-base, else it nulls our support 
agreement for the application.   SoI need some 
help :)

Is there a way to force the Container to use the applications xerces.jar file without 
impacting the applications functions?  I thought of two possibilities:  
 
1. modify the -D argument for the endorsed.dirs directory, so that I can seperate out 
their version of the jar file from the install base and not impact other applications. 
  
 
2. use the  element to turn delegation to true.   


Any assistance is appreciated,

David Henry





-
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster.

RE: Classloader issues

[SH Solutions]

Hi

> Have you added the mail's jar file to your WEB-INF/lib or common/lib? If
not, then that's the problem. Tomcat 5 doesn't ship with the mail api.

I have tried adding mailapi.jar, activation.jar, smtp.jar, pop3.jar,
imap.jar to common/lib, WEB-INF/lib and shared/lib. None worked.

Any other hints?

cu
  Steffen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader issues

[Jeanfrancois Arcand]

SH Solutions wrote:

Hi

I experience problems using 5.0.18 that did not occur running 4.0.6, but I
do NOT want to revert to it.
Maybe you could help me:
Actually I have a system that uses classloaders for loading add-in groups.
The two most important functions are:
 protected Class findClass( String className )
   throws ClassNotFoundException
 {
   if ( className.startsWith( "com.companyname." ) )
 return getClass().getClassLoader().loadClass( className );
   byte classData[] = getTypeFromBasePath( className );
   if ( classData == null )
 throw new ClassNotFoundException();
   return defineClass( className, classData, 0, classData.length );
 }
 
 private byte[] getTypeFromBasePath( String typeName )
 {
   return Utils.readFile( classPath + typeName.replace( '.',
File.separatorChar ) + ".class" );
 }

This works that far. It worked completely in tomcat4.0.6.

Now, having switched to 5.0.18 something wired occued:
java.lang.ClassNotFound javax.mail.Address
we used to have mailapi.jar in common (including its dependencies) which
worked well.
Now with 5.0.18 these classes are not found anymore, but nothing was changed
inside the code.
Could you give me any hints?
 

Have you added the mail's jar file to your WEB-INF/lib or common/lib? If 
not, then that's the problem. Tomcat 5 doesn't ship with the mail api.

-- Jeanfrancois

Thanks,
 Steffen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Classloader issues

[SH Solutions]

Hi

I experience problems using 5.0.18 that did not occur running 4.0.6, but I
do NOT want to revert to it.
Maybe you could help me:

Actually I have a system that uses classloaders for loading add-in groups.
The two most important functions are:

  protected Class findClass( String className )
throws ClassNotFoundException
  {
if ( className.startsWith( "com.companyname." ) )
  return getClass().getClassLoader().loadClass( className );
byte classData[] = getTypeFromBasePath( className );
if ( classData == null )
  throw new ClassNotFoundException();
return defineClass( className, classData, 0, classData.length );
  }

  
  private byte[] getTypeFromBasePath( String typeName )
  {
return Utils.readFile( classPath + typeName.replace( '.',
File.separatorChar ) + ".class" );
  }


This works that far. It worked completely in tomcat4.0.6.

Now, having switched to 5.0.18 something wired occued:
java.lang.ClassNotFound javax.mail.Address

we used to have mailapi.jar in common (including its dependencies) which
worked well.
Now with 5.0.18 these classes are not found anymore, but nothing was changed
inside the code.

Could you give me any hints?

Thanks,
  Steffen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Classloader Issues: ServletContext... method not found

[Andrew Hughes - LISAsoft]

I got the problem solved, the java package I have created that it called 
by the servlet was compiling against an old version of 'servlet.jar' 
that some person had put into cvs. Thanks heaps for your advice. What 
you mentioned was actually happening somewhere else in another servlet. 
So you have in fact solved another problem I had to fix.

Thanks to everyone who uses this mailing list, especially those who post 
to it!!!



Shapira, Yoav wrote:

Howdy,
To Andrew: make sure you only have one servlet.jar file in each tomcat
installation.  It is located in the $CATALINA_HOME/common/lib directory
by default.  Don't put another copy in your WEB-INF/lib directories by
mistake ;)
To Christian: can you rigorously prove your JSP correctly shows the
classloading order?  Does it work on non-Sun JVMs?  Does it correctly
account for the precedence of endorsed directories as specified by the
-D argument to java?
Yoav Shapira
Millennium ChemInformatics
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, May 26, 2003 2:35 AM
To: Tomcat Users List
Subject: Re: Classloader Issues: ServletContext... method not found




Hi Andrew,

The following code is the code of a jsp site which list you all the
   

classes
 

loaded by Tomcat and also tellingy out in which order they are loaded.
Maybe this will help you figure out which class are loaded in your
   

case.
 

<%@ page import="java.io.*" %>
<%@ page import="java.util.*" %>


  Classpath Diagnostic


  Classpath Diagnostic
  Classes will be loaded from the following locations, in the order
   

shown
 

below:
  <%
final String DELIMITER = System.getProperty("path.separator");
StringTokenizer st;
String path;
  %>
  
  Boot Classes
  
<%
  path = System.getProperty("sun.boot.class.path");
  st = new StringTokenizer(path, DELIMITER);
  while (st.hasMoreTokens()) {
String token = st.nextToken();
out.println(getFileLink(token));
  }
%>
  
  
  Extension Classes
  
<%
  path = System.getProperty("java.ext.dirs");
  st = new StringTokenizer(path, DELIMITER);
  while (st.hasMoreTokens()) {
String token = st.nextToken();
out.println(enumerateJars(token));
  }
%>
  
  
  Application Classes
  
<%
  path = System.getProperty("java.class.path");
  st = new StringTokenizer(path, DELIMITER);
  while (st.hasMoreTokens()) {
String token = st.nextToken();
out.println(getFileLink(token));
  }
%>
  
  
  WEB-INF Classes
  
<%
  path = application.getRealPath("/WEB-INF");
  if (path == null)
out.println("N/A" + "");
  else {
File WEBINF = new File(path);
File classes = new File(WEBINF, "classes");
out.println(getFileLink(classes.getPath()));
File lib = new File(WEBINF, "lib");
out.println(enumerateJars(lib.getPath()));
  }
%>
  


<%!
private String enumerateJars(String name){
  StringBuffer sb = new StringBuffer();
  File dir = new File(name);
  if (dir.exists()) {
String[] files = dir.list();
if (files != null) {
  for (int i = 0; i < files.length; i++) {
if (files[i].endsWith(".jar")) {
  File file = new File(dir, files[i]);
  sb.append(getFileLink(file.getPath()));
}
  }
}
  }
  else {
sb.append(name);
sb.append(" (does not exist)");
  }
  return sb.toString();
}
private String getFileLink(String name){
  StringBuffer sb = new StringBuffer();
  File file = new File(name);
  if (file.exists()) {
sb.append("");
sb.append(name);
sb.append("");
  }
  else {
sb.append(name);
sb.append(" (does not exist)");
  }
  sb.append("");
  return sb.toString();
}
%>
Christian Schuster

Rudolf Schuster AG
Postfach 277
CH - 3000 Bern 11
http://www.rsag.ch
++41 31 348 05 30


   Andrew Hughes -
   LISAsoft
   <[EMAIL PROTECTED]
   

To
 

   .com.au>  [EMAIL PROTECTED]

   

cc
 

   26.05.2003 08:20

   

Subject
 

 Classloader Issues:
   Please respond to ServletContext... method not
   

found
 

 "Tomcat Users
 List"
   <[EMAIL PROTECTED]
rta.apache.org>




Greetings,

I'm running both tomcat v4.0.4 and 4.1.24. Both of them have now an
error when I try and execute a servlet I have written. I have not
changed any of the lib files but I am now unexplainably receiving the
following exception from tomcat.
/The method getInitParameter(String) is undefined for the type
ServletContext/
The API says it has such a method, however it is obviouly loading
another package/

Re: classloader issues using ../common/lib vs. ../shared/lib

[Bill Barker]

Except for stuff like jdbc drivers, 90% of the time you will see no
difference between common/lib and shared/lib.  The difference is that the
internal Tomcat classes can see what is in common/lib (which the above
mentioned 90% of the time means that they could care less :).

"Mark" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Are there any potential classloader problems with putting .jar files that
> are shared across webapps (ie. junit, cactus, etc) in ../common/lib vs.
> ../shared/lib?
>
> We've been tossing .jars into ../common/lib, but after reading the Tomcat
> classloader how-to it seems that's discouraged, ie. should be done only
> when the classes are needed both by Tomcat and applications such as db
> drivers for JDBC realm and application use. I'm guessing, but does putting
> the .jars in ../shared/lib would spread work out better between
classloaders?
>
> Our application and integration tools are working great, but the fact
we're
> not configured the way the how-to suggests concerns me.
>
> TIA




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

classloader issues using ../common/lib vs. ../shared/lib

[Mark]

Are there any potential classloader problems with putting .jar files that 
are shared across webapps (ie. junit, cactus, etc) in ../common/lib vs. 
../shared/lib?

We've been tossing .jars into ../common/lib, but after reading the Tomcat 
classloader how-to it seems that's discouraged, ie. should be done only 
when the classes are needed both by Tomcat and applications such as db 
drivers for JDBC realm and application use. I'm guessing, but does putting 
the .jars in ../shared/lib would spread work out better between classloaders?

Our application and integration tools are working great, but the fact we're 
not configured the way the how-to suggests concerns me.

TIA


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Custom Realm & ClassLoader issues?

[Craig R. McClanahan]

On 4 Dec 2001, Scott Ganyo wrote:

> Date: 04 Dec 2001 17:06:41 -0500
> From: Scott Ganyo <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Custom Realm & ClassLoader issues?
>
> Hi all,
>
> I've written a custom Realm that I'm attempting to use for
> authentication under Tomcat 4.0.  Within that class I'm using JavaSpaces
> to do the messaging to the authentication service that I wrote.  Each
> piece works independantly, but together they are failing.  What happens
> is this:
>
> 1. Realm: Posts authentication Message to Space.
> 2. Auth Service: Retrieves Message, performs authentication
> 3. Auth Service: Posts auth response Message to Space
> 4. Realm: Retrieves Message
>
> The trouble is that at the point when the Realm retrieves the Entry from
> the Space (4), I get a ClassCastException when I attempt to cast it to a
> Message.  I know it is a Message, though, as I can print it out and
> verify it.  Thus, it seems like it is a ClassLoader issue...?
>

I don't know JavaSpaces at all, but I've seen similar things happen with
RMI programming when you did not have ALL the Jar files you need in the
right class path.  Can you write a stand-alone Java application that
simulates what the Realm does, and have it work correctly?  If so, the
classpath required to make it work might give you some hints about what
has to go into server/lib.

> BTW: I put all Jini jars in the server/lib and my classes in the
> server/classes directory so that my Realm has access to the appropriate
> classes.  Would this be related?  Is there a better way?
>
That's the right way to do things.  (You could also JAR your files from
server/classes into a JAR file in server/lib, but that is essentially
equivalent.)

> Thanks for any suggestions,
>
> Scott
>

Craig


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Custom Realm & ClassLoader issues?

[Scott Ganyo]

Hi all,

I've written a custom Realm that I'm attempting to use for
authentication under Tomcat 4.0.  Within that class I'm using JavaSpaces
to do the messaging to the authentication service that I wrote.  Each
piece works independantly, but together they are failing.  What happens
is this:

1. Realm: Posts authentication Message to Space.
2. Auth Service: Retrieves Message, performs authentication
3. Auth Service: Posts auth response Message to Space
4. Realm: Retrieves Message

The trouble is that at the point when the Realm retrieves the Entry from
the Space (4), I get a ClassCastException when I attempt to cast it to a
Message.  I know it is a Message, though, as I can print it out and
verify it.  Thus, it seems like it is a ClassLoader issue...?

BTW: I put all Jini jars in the server/lib and my classes in the
server/classes directory so that my Realm has access to the appropriate
classes.  Would this be related?  Is there a better way?

Thanks for any suggestions,

Scott



--
To unsubscribe:   
For additional commands: 
Troubles with the list: