> 
> > 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 )

-- 
Costin


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

Reply via email to