You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Petr Jiricka <pe...@netbeans.com> on 2000/09/21 18:36:42 UTC

jasper.jar and tomcat.jar + non-default classloader

Hi,

I would like to ask your opinions about the following issue: 

jasper.jar depends on tomcat.jar, and tomcat.jar is needed in classpath of
jasper.jar. This does not represent any problem if both these files are in
CLASSPATH, so they are loaded by the system classloader. But if I want to
load these files by another classloader, then the classloader complains when
loaing classes from jasper.jar that classes from tomcat.jar are not found.

This issue can be solved by adding

Class-Path: webserver.jar

into jasper.jar's manifest file. But I am not sure whether this will work on
JDK 1.1 (forgive my ignorance here, I haven't seen JDK 1.1 for ages), and of
course it raises other questions:

1) For this to work, jasper.jar and webserver.jar always have to be
distributed in the same directory
2) The same question could be asked for dependency of jasper.jar and
tomcat.jar on servlet.jar and other files

I guess it is acceptable if whoever wants to use the jar files this way may
repackage the jar files her own manifest, but isn't there a better solution
? Would it be acceptable to use the above manifest in the default build
scripts ?

Thanks
Petr


Re: jasper.jar and tomcat.jar + non-default classloader

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com wrote:

>
> Regarding tomcat->jasper dependency, I hope we'll be able to remove it (
> it isn't supposed to be any )
>

+1.

In the jakarta-tomcat-4.0 tree there are zero code dependencies between Jasper and
Catalina (in fact, the Catalina classes are not even visible on the same class
path), but there is still a dependency on Catalina providing a servlet context
attribute to tell Jasper what the webapp's "class path" is.

>
> Costin
>

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat



[BUG TRACKING] BugRat Drowning (will be DrownedRat)

Posted by Nick Bauman <ni...@cortexity.com>.
A couple of times a day bugrat spins load numbers like 19.45. Queries take
MINUTES to complete. This is on a 500mhz system with 128 MB ram. With
only a couple hundred bug reports, it's becoming unusable.

I haven't had the time to look into it, but I suspect it's one of 2 things
a) Badly written SQL or b) Badly implemented object-to-relational mapping.

Those things indicate things are going to get worse. I have tried a few
things to speed disk access, all yielding only incremental results. I
will soon have to tear apart BugRat's innards to fix the problem. Which
means it might be down on any given weekend coming up.

Just a warning.


Re: jasper.jar and tomcat.jar + non-default classloader

Posted by cm...@yahoo.com.
> 
> jasper.jar depends on tomcat.jar, and tomcat.jar is needed in classpath of
> jasper.jar. This does not represent any problem if both these files are in
> CLASSPATH, so they are loaded by the system classloader. But if I want to
> load these files by another classloader, then the classloader complains when
> loaing classes from jasper.jar that classes from tomcat.jar are not found.
> This issue can be solved by adding
> 
> Class-Path: webserver.jar

+1

I already added Main-Class: to tomcat.jar ( in 3.3, with the new build
mechanism ). ( that means a double click on tomcat.jar will start tomcat,
no need for any scripts on windows, and java -jar tomcat.jar will be
enough on unix ). I think it's ok to add it to 3.2 also - it can't affect
any existing functionality ( you can also add Main-Class to webserver.jar,
again it can't hurt )


Using 1.2 features is ok - for 1.1 people can still use CLASSPATH and we
will support only basic functionality, not all the custom tricks.

Regarding tomcat->jasper dependency, I hope we'll be able to remove it (
it isn't supposed to be any )

Costin