RMI classloader issues in TC - second time
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. TRIALERROR -- 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
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 loader element to turn delegation to true. Any assistance is appreciated, David Henry - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
RE: Classloader issues
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]
Classloader issues
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
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]
Re: Classloader Issues: ServletContext... method not found
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.* % HTML HEAD TITLEClasspath Diagnostic/TITLE /HEAD BODY H2Classpath Diagnostic/H2 Classes will be loaded from the following locations, in the order shown below: % final String DELIMITER = System.getProperty(path.separator); StringTokenizer st; String path; % P H3Boot Classes/H3 OL % path = System.getProperty(sun.boot.class.path); st = new StringTokenizer(path, DELIMITER); while (st.hasMoreTokens()) { String token = st.nextToken(); out.println(getFileLink(token)); } % /OL P H3Extension Classes/H3 OL % path = System.getProperty(java.ext.dirs); st = new StringTokenizer(path, DELIMITER); while (st.hasMoreTokens()) { String token = st.nextToken(); out.println(enumerateJars(token)); } % /OL P H3Application Classes/H3 OL % path = System.getProperty(java.class.path); st = new StringTokenizer(path, DELIMITER); while (st.hasMoreTokens()) { String token = st.nextToken(); out.println(getFileLink(token)); } % /OL P H3WEB-INF Classes/H3 OL % path = application.getRealPath(/WEB-INF); if (path == null) out.println(N/A + BR); 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())); } % /OL /BODY /HTML %! 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(A HREF=\); sb.append(name); sb.append(\); sb.append(name); sb.append(/A); } else { sb.append(name); sb.append( (does not exist)); } sb.append(BR); 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/class or not loading the servlet.jar package at all. I've run the servlet many many time correctly and for some reason it has just stopped working. If anyone has any knowledge
Re: classloader issues using ../common/lib vs. ../shared/lib
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
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?
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?
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: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]