tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Date Mon, 01 Apr 2002 19:58:55 GMT
On Mon, 1 Apr 2002, Patrick Luby wrote:

> Remy and Costin,
> 
> I will reverse the patch since there are enough -1s on this. One 
> question: should we continue to set the "-Djava.ext.dirs=" in the 
> wrapper scripts? This disables the extensions but without any code
> change to Tomcat. Or do we want to revert back to the original
> scripts where the extensions are enabled by default?

I don't think we should disable ext/  - we can recommend people to 
not use it ( unless they know what they're doing ). 

If someone chooses to use ext/, he expect it to work - because that's 
what the java doc says. 

I'm -0, since we do disable CLASSPATH in the script.

In general I think it's better to minimize the number of special settings
in the command line. The .sh/.bat is just one way to start tomcat, 
there are implications when you embed it, start it with wrapper or 
from other apps, etc. 

If you really want to have fun with the startup, it would be better to  
remove more 'special' behaviors from .sh/.bat and clearly documenting 
what remains - i.e. the java options and classpath that are required
to start tomcat.


Costin


 


> 
> Patrick
> 
> Remy Maucherat wrote:
> 
> >>>Fine, but your change creates problems (Jasper does not work on JDK 1.4
> >>>unless you delete common/endorsed/xerces.jar). I don't know why at this
> >>>time, but it should be fixed ASAP.
> >>>
> >>>(Note: I don't care too much about this functionality ... Adding another
> >>>
> > CL
> > 
> >>>layer is dangerous and makes CL slower; unless other people think this
> >>>
> > is
> > 
> >>>useful I don't think we should add the feature)
> >>>
> >>>Remy
> >>>
> >>>
> >>>
> >>I think I found the problem. In JDK 1.4, the StandardClassLoader's
> >>
> >>loadClass() method appears to be unconditionally delegating to its
> >>
> >>parent classloader even when setDelegate is set to false. This
> >>appears to be caused by changes to the URLClassLoader class in JDK
> >>1.4.
> >>
> > 
> > I had missed that it was attempting to change the delegation model
> > (apparently, Costin didn't, that's why he was complaining, I suppose ;-)).
> > I'm -1 for the patch then; please revert it. The use case is clearly not
> > worth introducing non-compliant behavior; I fully agree with Costin here: if
> > the ext mechanism is broken, then it's up to the JDK to fix it.
> > 
> > Remy
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
> > 
> 
> 
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message