weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, I use URLClassLoader to create class loaders that manage jars in WEB-INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). Suppose I want to load the following files as resources from a classLoader: - pippo.txt - pippo.jar In the first case I tried the line: classLoader.getResource(pippo.txt) and correctly the returned URL was: file:/ ... /myapp/WEB-INF/classes/pippo.txt where ... stands for $CATALINA_HOME while, trying to get the second file: classLoader.getResource(pippo.jar) tomcat returned the following url: file:/ ... /work/Catalina/localhost/myapp/loader/pippo.jar but the directory ... /work/Catalina/localhost/myapp/loader/ does not contain pippo.jar that is placed in .../myapp/WEB-INF/classes/pippo.jar thanks in advance Simone Pierazzini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, I use URLClassLoader to create class loaders that manage jars in WEB- INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). I comment on the actual problem below, but if you don't mind me asking: why? This is ugly ;) In the first case I tried the line: classLoader.getResource(pippo.txt) and correctly the returned URL was: file:/ ... /myapp/WEB-INF/classes/pippo.txt where ... stands for $CATALINA_HOME while, trying to get the second file: classLoader.getResource(pippo.jar) tomcat returned the following url: file:/ ... /work/Catalina/localhost/myapp/loader/pippo.jar but the directory ... /work/Catalina/localhost/myapp/loader/ does not contain pippo.jar that is placed in .../myapp/WEB-INF/classes/pippo.jar The one in $CATALINA_HOME/work is an unmodified copy, so it should be OK. But there's a bigger point here (actually two): - You cannot rely on a specific scheme (e.g. file:/) or format of the resource URL returned by the classloader, but you can rely on the classloader being able to find and resolve it. Only the latter should matter. If you're relying on the former, change your design. - What's you're doing is tricky at best. Having multiple copies of te same class in the same repository is not a good idea. If you do continue down this path, you should create a custom loader and replace Tomcat's default webapp classloader with your own by registering yours as the Loader element for your Context. Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Simone Pierazzini wrote: Hi, I use URLClassLoader to create class loaders that manage jars in WEB-INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). Suppose I want to load the following files as resources from a classLoader: - pippo.txt - pippo.jar In the first case I tried the line: classLoader.getResource(pippo.txt) and correctly the returned URL was: file:/ ... /myapp/WEB-INF/classes/pippo.txt where ... stands for $CATALINA_HOME while, trying to get the second file: classLoader.getResource(pippo.jar) tomcat returned the following url: file:/ ... /work/Catalina/localhost/myapp/loader/pippo.jar but the directory ... /work/Catalina/localhost/myapp/loader/ does not contain pippo.jar that is placed in .../myapp/WEB-INF/classes/pippo.jar thanks in advance Simone Pierazzini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I never try to use relative paths in getResource. I always do this getResource(/pippo.jar); Also, I usually pick a class in my package that I know will certainly be in my web-app classes folder or one of it's jars. This way the classloader used for my call will know about my objects and classes at it's levelso it doesn't make delegate calls...and I use com.mydomain.mypackage.MyClass.class.getResource instead of using the classloader call though that should not matter Maybe try to prepend a / to that file name. Read the javadoc documentation for the method Class.getResource to understand the / before the name of the file. Anyways, I always use the Class.getResource call as I mentioned above and I never have problemsI also am sure to use the / to make it an absolute classpath. Read those java docs to understand more. Hope you have some luck with that. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
On Wed, 1 Dec 2004 09:47:12 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, I use URLClassLoader to create class loaders that manage jars in WEB- INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). I comment on the actual problem below, but if you don't mind me asking: why? This is ugly ;) yes, I know, but I've to use those jars, and I didn't developed them :( [cut] The one in $CATALINA_HOME/work is an unmodified copy, so it should be OK. But there's a bigger point here (actually two): it should be but it isn't because tomcat does not make a copy, and the returned url is unresolvable. - You cannot rely on a specific scheme (e.g. file:/) or format of the resource URL returned by the classloader, but you can rely on the classloader being able to find and resolve it. Only the latter should matter. If you're relying on the former, change your design. yes of course, I do not rely on a specific schema (unless java.net.URLClassLoader does). - What's you're doing is tricky at best. Having multiple copies of te same class in the same repository is not a good idea. If you do continue down this path, you should create a custom loader and replace Tomcat's default webapp classloader with your own by registering yours as the Loader element for your Context. I use URLClassLoader to create a child of the context classloader, and I don't need anything more. bye Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, yes, I know, but I've to use those jars, and I didn't developed them :( OK ;) Unfortunate, but that happens... it should be but it isn't because tomcat does not make a copy, and the returned url is unresolvable. So you're saying the jar in $CATALINA_HOME/work is physically different than the one in your WEB-INF/lib directory, i.e. Tomcat's copying corrupts the jar? Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
On Wed, 01 Dec 2004 09:49:33 -0500, Wade Chandler [EMAIL PROTECTED] wrote: I never try to use relative paths in getResource. I always do this getResource(/pippo.jar); Also, I usually pick a class in my package that I know will certainly be in my web-app classes folder or one of it's jars. This way the classloader used for my call will know about my objects and classes at it's levelso it doesn't make delegate calls...and I use com.mydomain.mypackage.MyClass.class.getResource instead of using the classloader call though that should not matter asking resources to classes or classloaders is the same thing: absolute paths for classes are relative paths for classloaders so the following lines are equivalent: com.mydomain.mypackage.MyClass.class.getResource(/xx.txt) com.mydomain.mypackage.MyClass.class.getClassLoader().getResource(xx.txt) I pick a class in my package too: if you pick another class you don't know which classloader you 're using (common/shared/ etc.) bye - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
-Original Message- From: Simone Pierazzini [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 9:37 AM To: [EMAIL PROTECTED] Subject: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes Hi, I use URLClassLoader to create class loaders that manage jars in WEB- INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). Wouldn't it be much easier to unjar and re-jar with only the classes you need for each of your jar files? Charlie
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
On Wed, 1 Dec 2004 10:11:49 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, it should be but it isn't because tomcat does not make a copy, and the returned url is unresolvable. So you're saying the jar in $CATALINA_HOME/work is physically different than the one in your WEB-INF/lib directory, i.e. Tomcat's copying corrupts the jar? yes... and no. when you ask for non-jar resources, the returned url points to the correct path (inside context directory, and tomcat doens't need to copy them). When you ask for jar resources, the returned url points to a directory inside $CATALINA_HOME/work, but Tomcat does not copy anything in that path from WEB-INF/classes (you wrote WEB-INF/lib). In my first mail a made an example of what happens. I'll report it here: com.mydomain.mypackage.MyClass.class.getClassLoader().getResource(pippo.txt) returns: file:/ ... /webapps/myapp/WEB-INF/classes/pippo.txt ^ while: com.mydomain.mypackage.MyClass.class.getClassLoader().getResource(pippo.jar) returns: file:/ ... /work/Catalina/localhost/myapp/loader/pippo.jar where ... stands for a path that is $CATALINA_HOME note the difference between the two urls. bye - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, I use URLClassLoader to create class loaders that manage jars in WEB- INF/classes In WEB-INF/classes I have many jars that are incompatible each other (they have different classes with the same name inside). Wouldn't it be much easier to unjar and re-jar with only the classes you need for each of your jar files? those jar contains xml:db database drivers. these drivers implement an interface. my app uses that interface so it can be deployed using different databases. when the application uses just one kind of database I don't need (and don't use) java.net.URLClassLoader, and I don't have jar in WEB-INF/classes when the application uses two kind of database at the same time and their drivers are not compatible with each other, I've to create driver instances inside different class loaders byeT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, yes... and no. when you ask for non-jar resources, the returned url points to the correct path (inside context directory, and tomcat doens't need to copy them). When you ask for jar resources, the returned url points to a directory inside $CATALINA_HOME/work, but Tomcat does not copy anything in that path from WEB-INF/classes (you wrote WEB-INF/lib). Ahh, you're putting a jar file in WEB-INF/classes. I missed that originally. Tomcat copies jars out of WEB-INF/lib into a work directory to prevent locking and for performance gains. But that's a server implementation detail that shouldn't matter. Putting jars in WEB-INF/classes, well, I'm not going to spend time supporting this use-case, but maybe others will. Good luck, Yoav Shapira http:/www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Simone Pierazzini wrote:
On Wed, 01 Dec 2004 09:49:33 -0500, Wade Chandler
[EMAIL PROTECTED] wrote:
I never try to use relative paths in getResource. I always do this
getResource(/pippo.jar); Also, I usually pick a class in my package
that I know will certainly be in my web-app classes folder or one of
it's jars. This way the classloader used for my call will know about my
objects and classes at it's levelso it doesn't make delegate
calls...and I use com.mydomain.mypackage.MyClass.class.getResource
instead of using the classloader call though that should not matter
asking resources to classes or classloaders is the same thing:
absolute paths for classes are relative paths for classloaders so the
following lines are equivalent:
com.mydomain.mypackage.MyClass.class.getResource(/xx.txt)
com.mydomain.mypackage.MyClass.class.getClassLoader().getResource(xx.txt)
I pick a class in my package too: if you pick another class you don't
know which classloader you 're using (common/shared/ etc.)
bye
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Right, thought you were creating your own URLClassLoader instance to
locate your jars dynamically (not getting the current). Barring that
and looking at your post and then looking at one of Yoavs, then my guess
is the ClassLoader in tomcat is for what ever reason doing something like:
if( name.endsWith(.jar) )
{
//resolve to the home work dir.
}
regardless of the directory being lib or classesseems like a bug to
me as any file in the classpath should just be a file as a jar file
should have to be added to the classpath like it's a directory.
Anyways, are the file names hard coded in your app? You can always come
up with your own file name extension to work around the issue I suppose.
A jar is a jar by any other name .zip, .foo, .mar (?) What ever...the
point I guess is the class loader for what ever reason is resolving on
purpose the .jar ext instead of checking first if the file is under lib
or a sub dir. So you should be able to just rename the file ext unless
for some reason you have an app that has to have the .jar on the end.
The jar classes should still work against files with different ext.
Wade
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Right, thought you were creating your own URLClassLoader instance to
locate your jars dynamically (not getting the current). Barring that
and looking at your post and then looking at one of Yoavs, then my guess
is the ClassLoader in tomcat is for what ever reason doing something like:
if( name.endsWith(.jar) )
{
//resolve to the home work dir.
}
I agree
regardless of the directory being lib or classesseems like a bug to
me as any file in the classpath should just be a file as a jar file
should have to be added to the classpath like it's a directory.
I agree
Anyways, are the file names hard coded in your app? You can always come
up with your own file name extension to work around the issue I suppose.
I thought about this possibility too,
I just checked URLClassLoader javadoc and yes, this is a viable
solution. In fact, URLClassLoader interprets every url pointing to non
dir as a JAR regardless to its name.
thanks
Simone
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
Hi, regardless of the directory being lib or classesseems like a bug to me as any file in the classpath should just be a file as a jar file should have to be added to the classpath like it's a directory. I agree That's overly simplified. Unlike the classpath for a normal console application, the directory structure of a webapp has special meanings. See SRV.9.5 in the Servlet Spec, which tells you what to put in WEB-INF/classes and what to put in WEB-INF/lib. If you put jars in WEB-INF/classes, you're at best in questionable territory. If you open a Bugzilla issue for this, don't be surprised to see it closed as invalid or just left unattended. Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird tomcat5.0.30 behaviour with jar in WEB-INF/classes
On Wed, 1 Dec 2004 11:27:01 -0500, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, regardless of the directory being lib or classesseems like a bug to me as any file in the classpath should just be a file as a jar file should have to be added to the classpath like it's a directory. I agree That's overly simplified. Unlike the classpath for a normal console application, the directory structure of a webapp has special meanings. See SRV.9.5 in the Servlet Spec, which tells you what to put in WEB-INF/classes and what to put in WEB-INF/lib. If you put jars in WEB-INF/classes, you're at best in questionable territory. just (re)read the specifications. you should put a jar in WEB-INF/lib only if you want it mounted in the context classloader. you can put classes and any other utility _file_ in /WEB-INF/classes as well as inside any other jar in WEB-INF/lib regardless the extension/semantics of that file. If you open a Bugzilla issue for this, don't be surprised to see it closed as invalid or just left unattended. anyway, I'll not open a bug for this issue bye Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
