tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime
Date Sun, 11 Feb 2001 21:23:40 GMT
> > This adds another dependency between jasper and tomcat.util ( the first is
> > tomcat.util.log, now tomcat.util.compat ). Since both packages are completely
> > standalone and can be bundled with jasper, I don't think it'll be a problem.
> Comments:
> I don't personally see a problem with Jasper requiring Tomcat, but I do see
> a problem with the other way around. :-)

Tomcat3.3 doesn't have any dependency on jasper in core or utils.
JspInterceptor is the only piece that depends ( via a Liaison - which
takes full advantage of all jasper APIs.).

Jasper has no dependency on tomcat internals, except 2 general-purpose
utils which are shared.

> HOWEVER, I'm not sure what other corporations will think about this. People
> who want to bundle Jasper without Tomcat (ie: IBM) may not like this at
> all...even if the Tomcat stuff is standalone.

Jasper already had a dependency of a "shared" util ( util.log), this fix
just adds a second one ( util.compat ). That means someone integrating
Japser in a different container needs to add the 2 shared utils.

> Maybe a good idea would be to change the build scripts to package the
> jasper.jar file with *everything* it needs to run standalone...even if it
> means duplicating a couple .class files.

The build scripts are already doing something like that - all
"shared utils" are packaged in tomcat_util ( can be renamed
"shared_utils" or soemthing like that ). 

The utils have no external dependencies, and the only thing they have in
common with tomcat is the package name ( org.apache.tomcat.util ).

Someone who needs only jasper can take the utils and jasper package.
( duplicating some of the classes in 2 package may have negative impact on
class loading - it may throw "Sealing" exceptions )


View raw message