Re: jakarta-tomcat-connectors/jk will no longer build
Costin, Costin Manolache wrote: No, the tomcat4 package shouldn't compile with tomcat5. I think we need a way to distinguish tomcat4 from tomcat5 in the conditions. Or a flag that is set by the tomcat5 build ( probably better ). I added a "org.apache.ajp.tomcat5" package in jakarta-tomcat-connectors/jk. This package contains no classes as the "org.apache.ajp.tomcat4" classes will need to be ported so that they do not use the HttpRequestBase class. Also, I made jakarta-tomcat-connectors/jk/build.xml handle concurrent building of the "tomcat4" and "tomcat5" packages when both Tomcat 4.x and Tomcat 5 are present. This was what was causing my build to break: build.xml was automatically detecting my Tomcat 4 build even when I had "catalina.home" set to my Tomcat 5 build. So, everything now builds fine except that the Ajp13 connector will not work with Tomcat 5 since there are no "tomcat5" classes at this time. Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
jakarta-tomcat-connectors/jk will no longer build
Remy, Since the org.apache.catalina.connector.HttpResponseBase was removed from jakarta-tomcat-catalina, a clean Tomcat 5 build now breaks when compiling jakarta-tomcat-connectors/jk. Does HttpResponseBase need to be added back?: Thanks, Patrick [javac] Compiling 44 source files to /export/pluby/tomcat/jakarta-tomcat-connectors/jk/build/classes [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:75: cannot resolve symbol [javac] symbol : class HttpRequestBase [javac] location: package connector [javac] import org.apache.catalina.connector.HttpRequestBase; [javac] ^ [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:86: cannot resolve symbol -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] SSLSocket, CLIENT-AUTH, and JDK1.4
Bob,
You can check the JVM version more accurately using the
"java.specification.version" system property. It will always be "1.4"
for J2SE 1.4.x so you can do the following:
if ("1.4".equals(System.getProperty("java.specification.version")))
...
Patrick
Bob Herrmann wrote:
> Before I commit this diff, I would like some eyes. This fixes a problem
> with JSSE doing request for CERTS on an already established SSL Socket.
>
> I am concerned that this change may not pass the sniff test as I check a
> System.getProperty("java.vm").startsWith("1.4") to see if the extra
> jiggle is needed on the SSLSocket - but my instincts tell me that is
> colorfully kludgey. Ideas?
>
> Index: util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
> ===
> RCS file:
>
>/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
> retrieving revision 1.1
> diff -u -r1.1 JSSESupport.java
> --- util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java4 Oct
> 2002 20:03:10 - 1.1
> +++ util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java7 Oct
> 2002 20:15:14 -
> @@ -66,6 +66,8 @@
> import java.security.cert.CertificateFactory;
> import javax.net.ssl.SSLSession;
> import javax.net.ssl.SSLSocket;
> +import javax.net.ssl.HandshakeCompletedListener;
> +import javax.net.ssl.HandshakeCompletedEvent;
> import java.security.cert.CertificateFactory;
> import javax.security.cert.X509Certificate;
>
> @@ -127,6 +129,9 @@
> session.invalidate();
> ssl.setNeedClientAuth(true);
> ssl.startHandshake();
> + if ( System.getProperty("java.version").startsWith("1.4") ){
> + synchronousHandshake(ssl);
> + }
> session = ssl.getSession();
> jsseCerts = session.getPeerCertificateChain();
> if(jsseCerts == null)
> @@ -198,5 +203,44 @@
> }
> return buf.toString();
> }
> +
> +/**
> + * JSSE in JDK 1.4 has an issue that requires us to do a read() to
> + * get the client-cert. As suggested by Andreas Sterbenz
> + */
> +private static void synchronousHandshake(SSLSocket socket)
> +throws IOException {
> +InputStream in = socket.getInputStream();
> +int oldTimeout = socket.getSoTimeout();
> +socket.setSoTimeout(100);
> +Listener listener = new Listener();
> +socket.addHandshakeCompletedListener(listener);
> +byte[] b = new byte[0];
> +socket.startHandshake();
> +int maxTries = 50; // 50 * 100 = example 5 second rehandshake
> timeout
> +for (int i = 0; i < maxTries; i++) {
> +try {
> +int x = in.read(b);
> +} catch (SocketTimeoutException e) {
> +// ignore
> +}
> +if (listener.completed) {
> +break;
> +}
> +}
> +socket.removeHandshakeCompletedListener(listener);
> +socket.setSoTimeout(oldTimeout);
> +if (listener.completed == false) {
> +throw new SocketTimeoutException("SSL Cert handshake
> timeout");
> +}
> +}
> +
> +private static class Listener implements HandshakeCompletedListener
> {
> +volatile boolean completed = false;
> +public void handshakeCompleted(HandshakeCompletedEvent event) {
> +completed = true;
> +}
> +}
> +
> }
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [VOTE] [4.0.5] [4.1.12] Security releases
Remy, Here's my votes. Patrick Tomcat 4.0.5 release +1 [X] Yes, I approve this release -1 [ ] No, because: Tomcat 4.1.12 Stable release +1 [X] Yes, I approve this release -1 [ ] No, because: -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: jakarta-servleapi-5
Bob, Good idea. Here's my vote. > > [ ] Create new jakarta-servletjsp-examples > > [ ] Move examples into another exiting repository [?fill this in?] > > [X] Change access to jakarta-servletapi-5 to allow all tomcat committers > > [ ] Leave it all alone > Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5] Session.logout()
Bob, You are correct that browsers keep passing the user/pass with each request. As for getting the browser to rechallenge, that is very tricky and would be hacky at best. I would expect that when Basic authentication is used and the last request caused Session.logout() to called, the next request (which will contain a valid user/pass), will effectively log the user in. Trying to make Basic authentication act exactly like FORM authentication is probably not realistic as the display of user/pass input screen is browser dependent. Effectively, the user is silently logging back in with the next visit. I believe that this still complies with the spec. I suspect that the real problem may be that the bug submitter's interpretation of the spec may be a bit inaccurate. Patrick Bob Herrmann wrote: > The JSP spec 2.4 gives us Session.logout(), what do we do when using > Basic authentication? Once challenged, the web browser keeps passing > the user/pass (right?) so any ideas about how to get the browser to > re-challenge the end user? (change the domain?) > > > Cheers, > -bob > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
Remy, Remy Maucherat wrote: > > +1 from me. > > If we do that, that would mean commons-daemon is not going anywhere: > - the interfaces will go away > - the launcher code is supposed to end up in Ant > > If the launcher doesn't end up in Ant, then IMO we should create > commons-launcher. > Since it will take a while to migrate all of the functionality in the launcher to Ant, we should plan on the commons-launcher code being around a while. So, +1 for creating a separate "commons-launcher" repository. Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: VOTE: Restoring Tomcat examples: Which workspace?
Remy, Remy Maucherat wrote: > > I just got a bit lazy after finishing the repackaging in j-s-5, and > thought I would do it the next day :-D > I don't think it is lazy to put this off. Instead, I think we are all trying to tackle higher priority issues first. Speaking of higher priority issues, I would vote for resolving the getHeaders() problem since they are causing Watchdog failures. Are you and Costin comfortable with Steve Downey's latest proposal (headers are split on "," for only the headers explicitly defined in the HTTP/1.1 specification)? Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [VOTE] New committer: Jean-Francois Arcand
All, Jean-François Arcand has received several +1's and no -1's. So, Jean-François, congratulations! Can someone create an account for Jean-François Arcand? Thanks, Patrick Patrick Luby wrote: > I would like to propose that we add Jean-François Arcand as a Tomcat > committer. I believe he has submitted enough patches to show that he > will be a positive contributor to Tomcat 5. > > Thanks, > > Patrick > -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Watchdog aggregation of headers may be incorrect
Remy, Remy Maucherat wrote: > > No, this is not correct. > > You are allowed to do that only if the application knows it makes sense > to do so (ie, only when it call getHeaders). > > Some code to do that should be added in the adapter. This makes more sense than my original thoughts since the Watchdog failures are only happening in tests that invoke the getHeaders() method. > > No, this musn't be done there, as it would screw up many headers. Please > read the chapter on multivalued headers in the HTTP/1.1 spec. > Which class do you suggest that this conversion be done? I agree that putting where I suggested is not the right place. Thanks, Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Watchdog aggregation of headers may be incorrect
Steve, Your assessment is correct: an aggregate header like: header1: val1, val2 should be converted to this for the HttpRequest: header1: val1 header1: val2 Tomcat 4 used to do this conversion correctly but then it stopped doing the conversion a few months ago. This should be fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? Can anyone point Steve to where this header parsing of the ServerSocket input stream is being done? Patrick Steve Downey wrote: > Watchdog now merges headers, by design. ie (from the checking message) > Modified logic to send duplicate headers as one aggregated header vs. two > headers: > > header1: val1 > header1: val2 > >-will now be- > > header1: val1, val2 > > Due to this, it looks like a couple of tests are failing. GetHeadersTest and > HttpServletRequestWrapperGetHeadersTest. > > GetHeadersTest looks for two Accept-Language headers, en-us and ga-us. It does > work if they are sent as > Accept-Language:en-us > Accept-Language:ga-us > > But, being sent as: > Accept-Language:en-us, ga-us > > it is presented to the servlet as ONE header, with the value "en-us, ga-us" > > However, I'm not sure that it shouldn't be. Parsing a multivalued header is > not only diffcult, it seems to depend on which header is being parsed. > Certainly full interpretation is very dependent on the header, e.g. > Accept-Language: da, en-gb;q=0.8, en;q=0.7 > Date: Wed, 15 Nov 1995 06:25:24 GMT > > The first has three values, the second has one. Interpretation depends on the > name of the header. I don't believe the Request.getHeaders() mechanism should > try and interpret the values after the :. > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] Xerces 2.0.1 also is buggy
Jean-François,
Can you also submit the patch to both BUILDING.txt and build.xml.
build.xml needs to use the "cvsbuild" target to download and build
Xerces since you can't reliably use "downloadgz" for nightly builds
since they disappear of the website after 2 weeks.
Patrick
Jean-francois Arcand wrote:
> Hi,
>
> Xerces 2.0.1 contains a bug that produce the error Remy reports earlier
> this week :-(
> Xerces 2.0.2 contains a bug that produce a StackTraceOverflow :-(
>
> In order to supports schema and dtd, Xerces nightly build is the only
> version that parse properly DTD and schema when validation is on. That's
> a very good reason why we need to have by default validation turned off ;-)
>
> Thanks,
>
> -- Jeanfrancois
>
>
>
>
> Index: build.properties.default
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
> retrieving revision 1.29
> diff -u -r1.29 build.properties.default
> --- build.properties.default 16 Aug 2002 17:03:19 - 1.29
> +++ build.properties.default 16 Aug 2002 23:36:59 -
> @@ -103,12 +103,12 @@
>
>regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
>
>
> -# - Xerces XML Parser, version 2_0_1 -
> -xerces.home=${base.path}/xerces-2_0_1
> +# - Xerces XML Parser, version 20020815 or latter -
> +xerces.home=${base.path}/xml-xerces
> xerces.lib=${xerces.home}
> xercesImpl.jar=${xerces.lib}/xercesImpl.jar
> xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
> -xerces.loc=http://xml.apache.org/dist/xerces-j/old_xerces2/Xerces-J-bin.2.0.1.tar.gz
> +xerces.loc=xml-xerces
>
>
> # --
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [PROPOSAL] Refactored mapper
Remy, Remy Maucherat wrote: > It now looks doable with the standalone Tomcat. It may still be > unimplementable through Apache, though. > > My wish would be that only physical resources can be used as welcome > files, so that the spec is implementable through a native webserver. > (Quite frankly, the use case for the rest is very limited, and very > confusing; plus it would impose a complex wording in the spec - still > not right in that version) I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying "if I can't find any of the listed static welcome files, start looking for anything that can serve up a response". OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the "/" resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example "/index.html" as a welcome file and then then the webapp developer forget to put a "index.html" file in the webapp. Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin,
I took a look at InspectionUtils.guessInstall() and it looks OK.
However, it has one limitation: it looks at the classpath to guess the
install directory. This works in most cases, but does not work when the
InspectionUtils class is loaded in a classloader. Since both the
commons-launcher and some J2EE servers load Tomcat's Bootstrap class via
a classloader, InspectionUtils.guessInstall() may not work correctly.
The way I worked around this in commons-launcher was to invoke the
getResource() resource on the class e.g. Bootstrap.class.getResource("/"
+ Bootstrap.class.getName() + ".class") to get the classpath element
that this main class was loaded from. This works even if another
application is loading your application using a classloader.
At this point, I could port this "getResource()" logic into
InspectionUtils or I can put this code directly in Bootstrap.java.
What is your preference?
Patrick
[EMAIL PROTECTED] wrote:
>
> On Thu, 15 Aug 2002, Patrick Luby wrote:
>
> > Costin,
> >
> > [EMAIL PROTECTED] wrote:
> > > Patrick ( if you read this ) - what's the status with the 'guess home' ?
> > > I can use IntrospectionUtils - it has the whole thing in it ( home/base
> > > setting, find in classpath ). We already need IU for jk - it just needs
> > > to be included in bootstrap.jar to do that.
> > >
> >
> > I haven't ported this yet but I can do it very quickly. The question is
> > where should we put it? Originally, I was going to put it in the
> > Bootstrap.getCatalinaHome() method. However, since we are moving towards
> > using CatalinaService, do you think I should put it there?
>
> Probably Bootrstrap is the best place - since it needs to construct the
> classpath to load CatalinaService ( so it needs it ).
>
> If you just include IntrospectionUtil from j-t-c you get it all -
> ( it is used in jk already ). All you need ( besides build.xml changes )
> is:
>
> home= IntrospectionUtils.guessInstall("catalina.home", "catalina.base",
>"bootstrap.jar",
> "org.apache.catalina.startup.CatalinaService");
>
> That will set catalina.home/catalina.base:
> - if only one is set the other will take that value.
> - if none is set, it'll look in CLASSPATH for bootstrap.jar and go one
> level up, or for org/apache... if classes/ is used - and set catalina.home
> fromt that.
>
> You don't need to port it - it is useable directly. ( well, you can
> cut&paste the method if you want, it's independent of the rest )
>
> Costin
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [PROPOSAL] Refactored mapper
Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick [EMAIL PROTECTED] wrote: > > On Thu, 15 Aug 2002, Remy Maucherat wrote: > > > Yes, but welcome files for non physical resources cannot be implemented > > (since you have no way of asking a servlet if it can or cannot process a > > resource). > > I'll implement something which works and which is very close to what t > > spec requires. > > > > Again, I have sent many messages to the spec leads about this issue > > without any result, so I give up ... > > The current specification is not implementable for Apache ( or any other > web server ) - and it breaks every pattern that was used in the web. > > I don't know if we have any representative in the expert group or > what's the procedure that apache follows in voting for JCP specs - > but if this is not resolved I'll do my best to find out. > > I'm also curious to who is representing apache ( if any ) in the > JSP spec - I'm still strugling to understand how the TLD stuff > happened and nobody noticed or complained in any way - the whole > 'config in web.xml' model is now screwed, with any file ( including > jars ) potentially storing config for web applications. > > Costin > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [PROPOSAL] Refactored mapper
[EMAIL PROTECTED] wrote: > The current specification is not implementable for Apache ( or any other > web server ) - and it breaks every pattern that was used in the web. > > I don't know if we have any representative in the expert group or > what's the procedure that apache follows in voting for JCP specs - > but if this is not resolved I'll do my best to find out. I have heard that Pier is in the Expert Group. But I could be wrong. I think the Servlet 2.4 spec is going Public Final Draft this month (not sure exactly when), but you can e-mail the expert group directly at: [EMAIL PROTECTED] Also, the latest draft of the spec is at: http://www.jcp.org/jsr/detail/154.jsp Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [PROPOSAL] Validation/NamespaceAware
Jean-François, I would vote +1 as long as these two HOST attributes are optional attributes. In other words, if they are missing from server.xml, both default to "false". I think that is what you are proposing but I just wanted to make sure. Patrick Jean-francois Arcand wrote: > > Hi, > > based on the mailling list feedback, I would like to propose the > following solution for the XML Parser DTD/Schema validation/namespace > aware problems: > > - Add the following attributes in server.xml under the HOST element: > > xmlValidation="false" > xmlNamespaceAware="false" > > and set them equal to false by default. This way, peoples will be able > to turn it on only if they need it, using the AdminTool or directly in > the server.xml file. > > It will still let the door open for: > > - "have a separate validation program that can be run on a webapp _before_ it is >deployed on tomcat" (Costin) > - keeping validation available when required (Steve) > - etc. > > Thanks, > > -- Jeanfrancois > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin, [EMAIL PROTECTED] wrote: > Patrick ( if you read this ) - what's the status with the 'guess home' ? > I can use IntrospectionUtils - it has the whole thing in it ( home/base > setting, find in classpath ). We already need IU for jk - it just needs > to be included in bootstrap.jar to do that. > I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [VOTE] New committer: Jean-Francois Arcand
Glenn, Glenn Nielsen wrote: > > I would have appreciated if this were stated planely in the VOTE request. > I would not normally vote +1 for commit privs for someone who has only > participated for 16 days in the community. > > +1 Since it is obvious he is assigned to work on the Tomcat 5 RI of Servlet 2.4 and >JSP 2. I admit I did not factor the cumulative time that Jean-François has contributed to Tomcat when I nominated him. Instead, I nominated him purely based on the patches that he has submitted. My view was has he submitted enough patches for us to evaluate his work and potential contributions. Whether or not he is assigned by Sun to work should be irrelevant. If you feel that someone is not ready to be committer, I don't think any of us should feel that we need to give anyone any special consideration by virtue of who their employer is. I am a strong supporter of Tomcat's process for granting commit access: send patches and if we like your work and commitment, we will let you have commit access. Accordingly, if you or anyone feels that a nomination is too hasty, please don't hesitate to say so. Patrick > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[VOTE] New committer: Jean-Francois Arcand
I would like to propose that we add Jean-François Arcand as a Tomcat committer. I believe he has submitted enough patches to show that he will be a positive contributor to Tomcat 5. Thanks, Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [VOTE] Release numbering scheme and test releases
Remy, Here are my votes: +1 [X] Tomcat 5 should use Tomcat 4.1 version numbering scheme and release management -1 [ ] Tomcat 5 should use something else (to be decided later) +1 [ ] Start releasing milestones for Tomcat 5.0 on a regular basis soon -1 [X] No, later Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] Build notes
Costin, [EMAIL PROTECTED] wrote: > On Sun, 11 Aug 2002, Patrick Luby wrote: > > >>commons-digester/logging, etc. I think that this would make the build >>more reliable since Tomcat 5 is dependent on very specific versions of >>Apache dependencies (e.g. Xerces 2.0.1 only). > > > IMHO that's _totally_ unacceptable ( having tomcat5 work only with > xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. > > And having schema validation turned on by default has a strong -1 from > me - if the spec _requires_ schema validation, then implement it at > deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. > > ( in the process we should also move DTD validation to the same > stage and stop doing it on every startup if the xml file didn't change ) > Makes sense. Especially since we use this same technique for JSP page compilation. -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] Build notes
All,
Couldn't we go a step farther and check any Apache dependencies into the
Tomcat cvs repository and remove them from build.properties.default and
build.xml's "download" target? Of course, we can't do this for some 3rd
party dependencies, but we can for stuff like Xerces,
commons-digester/logging, etc. I think that this would make the build
more reliable since Tomcat 5 is dependent on very specific versions of
Apache dependencies (e.g. Xerces 2.0.1 only).
I know that a lot of other Jakarta projects do this. Are there any
problems with this?
Patrick
Jayson Falkner wrote:
> I have been using the same thing. The only downside is the download
> time, but, IMO it would be great to have this included and encouraged
> for use with the Tomcat 5 build file.
>
> Way to go Bob!
>
> Jayson Falkner
> [EMAIL PROTECTED]
>
> Bob Herrmann wrote:
>
>> Yea, I liked your script, this one builds Tomcat 5.
>>
>> BUILDING.TXT could almost just say "All you need is JDK1.4 and Ant1.5
>> then just type 'ant' and a working Tomcat 5 development tree is built.
>> (If you are behind a firewall, you may need to adjust proxy settings.)"
>>
>> This should be cross platform (haven't tested it on Win32.)
>>
>> Cheers,
>> -bob
>>
>>
>>
>>
>>
>>
>>
>>
>> >value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
>>
>>
>>
>>
>>
>> > dir="${base.path}"/>
>>
>>
>>
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>> > cvsRoot="${cvsroot}"
>> dest="${apache.dir}"
>> />
>>
>>
>>
>>
>>
>> > file="${base.path}/LICENSE" />
>>
>> > target="download" />
>>
>> > target="dist" />
>>
>>
>>
>>
>>
>> On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
>>
>>> On August 6, 2002 01:01 pm, you wrote:
>>>
>>>> The main thing missing is a target which sets up the CVS repositories,
>>>> so it's quite close to what we have now. Problem is, I'm not too happy
>>>> at the idea of doing that automatically.
>>>
>>>
>>> Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
>>> it's well documented what it's doing, people should be OK with it.
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >> value=":pserver:[EMAIL PROTECTED]:/home/cvspublic"/>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >> cvsRoot="${cvs.root}"
>>> dest="${apache.dir}"
>>> />
>>> >> cvsRoot="${cvs.root}"
>>> dest="${apache.dir}"
>>> />
>>> >> cvsRoot="${cvs.root}"
>>> dest="${apache.dir}"
>>> />
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <mailto:[EMAIL PROTECTED]>
>>> For additional commands, e-mail:
>>> <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH][Catalina] Use fully qualified URI for locating localschema
Jean-François, Thanks for finding the missing patch to commons-digester. I committed that patch and now Tomcat 5 works with both of your patches to jakarta-servletapi-5 and jakarta-tomcat-catalina. BTW, with your patches, all of the JSP test failures in watchdog are gone and all JSP test pass. Patrick Patrick Luby wrote: > Jean-François, > > I just deleted my CVS repositories, rechecked them out, and reapplied > *both* the jakarta-servletapi-5 and jakarta-tomcat-catalina patches. I > did a build from scratch and I still get the same exception. > > Note: I am using the HEAD of commons-digester. Might there be a > incompatibility in commons-digester? > > Patrick > > Jean-francois Arcand wrote: > >> Patrick, >> >> you also have to apply the catalina pache where it is defined the >> local schema location (Constants.java). I made some change to avoid >> having Xerces resolving with the wrong URI. >> >> Thanks, >> >> Jeanfrancois. >> >> Patrick Luby wrote: >> >>> Jean-François, >>> >>> When I apply this patch and your jakarta-servletapi-5 patch and build >>> with the latest commons-digester, I get the following exception. I >>> seems that with your patches, Xerces no longer looks locally for the >>> XML files. >>> >>> Accordingly, I think we should figure out what is happening before >>> these patches should be applied as these patches make it impossible >>> for anyone running behind a firewall to run Tomcat. >>> >>> Patrick >>> >>> org.xml.sax.SAXParseException: src-import.0: Failed to read imported >>> schema document 'http://www.w3.org/2001/xml.xsd'. >>> at >>> >org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:232) > >>> >>> at >>> org.apache.xerces.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:141) >>> >>> at >>> org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:358) >>> >>> at >>> >org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaWarning(XSDHandler.java:1837) > >>> >>> at >>> org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1298) >>> >>> at >>> org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1240) >>> >>> at >>> >org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:611) >>> >>> at >>> >org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:654) >>> >>> at >>> org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:403) >>> >>> at >>> >org.apache.xerces.impl.xs.XMLSchemaValidator.processJAXPSchemaSource(XMLSchemaValidator.java:2302) > >>> >>> at >>> >org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1632) > >>> >>> at >>> >org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:568) > >>> >>> at >>> >org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:832) > >>> >>> at >>> >org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java:568) >>> >>> at >>> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:796) >>> >>> at >>> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:752) > >>> >>> at >>> >org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:927) > >>> >>> at >>> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1519) > >>> >>> at >>> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) > >>> >>> at >>> >org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529) > >>> >>> at >>> >org.apache.xerces.parsers.StandardParserConfiguration.parse(S
Re: [PATCH][Catalina] Use fully qualified URI for locating localschema
Jean-François, I just deleted my CVS repositories, rechecked them out, and reapplied *both* the jakarta-servletapi-5 and jakarta-tomcat-catalina patches. I did a build from scratch and I still get the same exception. Note: I am using the HEAD of commons-digester. Might there be a incompatibility in commons-digester? Patrick Jean-francois Arcand wrote: > Patrick, > > you also have to apply the catalina pache where it is defined the local > schema location (Constants.java). I made some change to avoid having > Xerces resolving with the wrong URI. > > Thanks, > > Jeanfrancois. > > Patrick Luby wrote: > >> Jean-François, >> >> When I apply this patch and your jakarta-servletapi-5 patch and build >> with the latest commons-digester, I get the following exception. I >> seems that with your patches, Xerces no longer looks locally for the >> XML files. >> >> Accordingly, I think we should figure out what is happening before >> these patches should be applied as these patches make it impossible >> for anyone running behind a firewall to run Tomcat. >> >> Patrick >> >> org.xml.sax.SAXParseException: src-import.0: Failed to read imported >> schema document 'http://www.w3.org/2001/xml.xsd'. >> at >> >org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:232) > >> >> at >> org.apache.xerces.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:141) >> >> at >> org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:358) >> >> at >> >org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaWarning(XSDHandler.java:1837) > >> >> at >> org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1298) >> >> at >> org.apache.xerces.impl.xs.traversers.XSDHandler.getSchema(XSDHandler.java:1240) >> >> at >> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:611) >> >> at >> org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(XSDHandler.java:654) >> >> at >> org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:403) >> >> at >> >org.apache.xerces.impl.xs.XMLSchemaValidator.processJAXPSchemaSource(XMLSchemaValidator.java:2302) > >> >> at >> >org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1632) > >> >> at >> >org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:568) > >> >> at >> >org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:832) > >> >> at >> org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.java:568) >> >> at >> org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:796) >> >> at >> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:752) > >> >> at >> >org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:927) > >> >> at >> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1519) > >> >> at >> >org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) > >> >> at >> >org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529) > >> >> at >> >org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:585) > >> >> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) >> at >> org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148) >> >> at org.apache.commons.digester.Digester.parse(Digester.java:1512) >> at >> org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:573) >> >> at >> org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:711) >> at >> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:247) >> >> at >> >org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Life
Re: [PATCH][Catalina] Use fully qualified URI for locating localschema
lic static final String JspSchemaPublicId_20 =
> -"jsp_2_0.xsd";
> +"http://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd";;
> public static final String JspSchemaResourcePath_20 =
> -"/javax/servlet/jsp/resources/jsp_2_0.xsd";
> +"/javax/servlet/resources/jsp_2_0.xsd";
>
> }
> Index: ContextConfig.java
> ===
> RCS file:
>/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
> retrieving revision 1.7
> diff -u -r1.7 ContextConfig.java
> --- ContextConfig.java8 Aug 2002 18:31:33 - 1.7
> +++ ContextConfig.java10 Aug 2002 14:46:08 -
> @@ -493,10 +493,9 @@
> // to support servlet.jar that does not contains the schema
> if (url != null){
> tldDigester.setSchema(url.toString());
> +tldDigester = registerLocalSchema(tldDigester);
> }
>
> -tldDigester = registerLocalSchema(tldDigester);
> -
> tldDigester.addRuleSet(new TldRuleSet());
> return (tldDigester);
>
> @@ -527,9 +526,8 @@
> // to support servlet.jar that does not contains the schema
> if (url != null){
> webDigester.setSchema(url.toString());
> +webDigester = registerLocalSchema(webDigester);
> }
> -
> -webDigester = registerLocalSchema(webDigester);
>
> webDigester.addRuleSet(new WebRuleSet());
> return (webDigester);
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdowncode
Remy, Remy Maucherat wrote: > > No, I'd rather do something according to the pre-proposal put forward by > Costin that would be a refactoring of the whole startup and > configuration code, rather than an evolution of the current code. I > don't have much interest in trying to improve that code, as I think it's > good enough (ie, it gets the job done). > That makes sense. Trying to rework the startup stuff at the same time before Costin's pre-proposal is implemented would probably cause a lot more problems (or at least later rework) than waiting until after Costin's pre-proposl is implemented. Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Tocmat 5 failing watchdog on all tests
All, After the commits this morning to jakarta-tomcat-catalina, all of the watchdog tests are failing for Tomcat 5. I suspect that this has something to do with Jean-Francois' patch this morning but I cannot be sure as the problem is that Tomcat 5 is throwing exceptions when parsing TLD files. This was not happening when a did a clean checkout and build this morning. So, can those that made commits today take a look at this? Thanks, Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-5 build2.xml
Costin, Costin Manolache wrote: > > It may be a good idea to move the ant tasks/types that you need from > sandbox into oac.launcher. I think they should be in either tomcat > or ant ( preferably). > > Later on, after things stabilise we can propose it for commons proper. > I would like to see the , , and data types and the conditional , , and elements moved to Ant. Also, I should be able to integrate the task attributes into Ant's task. I just won't be able to do it for a few weeks since my employer has squeezed my spare time down to nothing. But I intend to post patches for this code so that it can go in Ant 1.6. The other half of the Launcher code is merely the bootstrapping of ant.jar (which is where the enhanced data types listed above would be). This code be added to Ant 1.6 very easily as all it does is instantiate a ClassLoader and classload ant.jar. This piece of code deserves more explanation. In the launcher, this bootstrapper is called LauncherBootstrap.class and resides in the same directory as the shell script that users use. Then, in Windows batch scripts, you put %0\..;"%PATH%" as the classpath when invoking Java. Since Windows sometimes makes %0 meaningless, %PATH% is used as the classpath. Since LauncherBootstrap.class is an unjarred class in %PATH% (since it is in the same directory as the script), it will get included in the classpath. LauncherBootstrap.class then just loads ant.jar since Java can reliably determine which directory LauncherBootstrap.class was loaded from. In essence, the whole bootstrapping process is a hack to get around the %0 problem on Windows 95, 98, ME, and sometimes 2000. So, it might be useful to include this bootstrapper in Ant so that the Ant batch scripts can find its classes. There were a few other things that are in the Launcher which may be useful if ported to Ant: - Catching of uncaught Errors (e.g. OutOfMemoryError) and gracefully exiting - Syncronized starting and stopping of the build process so that other applications (e.g. commons-daemon) can start Ant and kill Ant directly. - Retrieve localized strings so that we can localize BuildExceptions and and messages. If the Ant committers accept my patches, effectively moving all of the Launcher functionality into Ant 1.6, then I think the commons-launcher portion of commons-daemon can be made obsolete and commons-daemon could just use Ant 1.6 directly. Right now, commons-daemon needs both commons-launcher.jar *and* ant.jar. Let me know what you think of this approach. Thanks, Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] Build notes
Bob, Bob Herrmann wrote: > $ sed -e > 's/^base.path=\/usr\/local$/base.path=\/home\/test\/tc5\/dependson/' > build.properties.default > t > $ mv t build.properties.default You don't want to replace build.properties.default. Instead you want to put your customized file in build.properties. That way, if build.properties.default changes, you will know. Also, using build.properties prevents accidental commits to build.properties.default. Patrick -- ________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-5 build2.xml
Costin,
If it helps, you can exclude org/apache/catalina/launcher/** from the
build if you are not using commons-launcher. This package is only used
by the Launcher's XML files and has no other packages depend on this
package.
Also, I noticed that you are compiling the ${taglibs.home}/standard/src
directory. If it helps, you don't need to do this as the expression
language classes are already compiled and checked into the
jakarta-tomcat-jasper/jasper2/lib/jsp20el.jar.
Patrick
[EMAIL PROTECTED] wrote:
> costin 2002/08/03 20:48:50
>
> Modified:.build2.xml
> Log:
> A more functional build file.
> It now creates a fully functional tomcat ( there are few problems with
> jasper tough ).
>
> Also added a task that starts tomcat from ant - with 1.4 you need
> fork=true ( I'll try to make few changes to ant classloader to avoid
> this ).
>
> I'm also trying 'everything in a jar' model - there are cases when
> you don't need the complex hierarchy.
>
> Note that the generated tomcat.jar is 2.8M, out of which 1.6 is
> tomcat. That's not very bad - if we move backward compat stuff
> into tomcat-compat and split some 'optional' functionality we
> can get well bellow 1M.
>
> ( that includes tomcat33 code - i.e. 300k, most of it not used at
> the moment, only some non-duplicated modules will be ported )
>
> Revision ChangesPath
> 1.3 +120 -3jakarta-tomcat-5/build2.xml
>
> Index: build2.xml
> ===
> RCS file: /home/cvs/jakarta-tomcat-5/build2.xml,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- build2.xml 1 Aug 2002 20:31:15 - 1.2
> +++ build2.xml 4 Aug 2002 03:48:50 - 1.3
> @@ -28,7 +28,7 @@
> value="${basedir}/../jakarta-tomcat-connectors"/>
> -
> +
>
> @@ -44,6 +44,14 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
>
>
> @@ -86,8 +94,25 @@
>
>
>
> -
> +
> +
> +
> +
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>@@ -111,6 +136,40 @@
>
>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
> @@ -129,11 +188,69 @@
>
> name="org/apache/taglibs/standard/lang/jstl/parser/jsp20/ELParser.java" />
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + + description="Create jars" >
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + manifest="resources/catalina-main.manifest">
> +
> +
> +
> +
>
>
> -
> +
> +
> +
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + value="${ant.home}/lib:${java.home}/lib"/>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5] launcher/deamon
Costin, [EMAIL PROTECTED] wrote: > On Sat, 3 Aug 2002, Patrick Luby wrote: > > I also have reservations - I see no reason to require it, at least > not until commons-launcher is stable and released. > > "java -jar tomcat.jar" should be enough ( I almost got it working > for 5.0, and it works very well for 3.3 ). > java -jar has one big problem: how do you set java.endorsed.dirs? This java.endorsed.dirs problem is one of the primary reasons the Launcher forks a child JVM. Since java.endorsed.dirs must be set when you invoke the JVM (setting in main() has no effect), you need to use the -Djava.endorsed.dirs=... command line argument with JDK 1.4. And since setting java.endorsed.dirs in a batch script proved flaky due to the %0 problem in some Windows versions, I had to fork a child JVM. If you find a way around this without forking, let me know because the one thing I don't like about my Launcher implementation is the need to fork a child JVM. > > Have you looked at tomcat(3) Main.java ? It works the same on > windows and unix, and all it needs is 'java -jar'. All logic > to find TOMCAT_HOME is in java. See my JDK 1.4 and java.endorsed.dirs issue above. The java -jar works great on JDK 1.2 and JDK 1.3, but not JDK 1.4 when you need a custom XML parser and, unfortunately, the default JDK 1.4 parser does not have the XML schema support that Tomcat 5 needs so we need to set java.endorsed.dirs. > > Of course, passing JAVA_OPTS is a different story - and I'm not sure > running a java program to set the options and run another program > is a good solution ( the startup time will be pretty big - it > is already too big for my taste ). A more efficient solution is a native program that uses the Java Invocation API to load the JVM and run the target application's main(). I did not go that route only because I did not want to put native C code into Tomcat. But that might be the best course of action in the long run. > > So I think having multiple options is good - the service wrapper ( C ), > the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process. > > If we add most logic inside the starter ( creating CLASSATH, detect > TOMCAT_HOME, etc ) the external starter can be simple enough. > Makes sense. > > I was sugesting 'vote' more as a way to get more people aware of this. > As I mentioned, I didn't know that the launcher will be required or > the BATs will no longer be used. And I suspect other people were > in the same situation. > > If not a vote - at least a spec describing the 5.0 startup mechansim(s), > checked into CVS. > > The problem is not on removing the launcher, but on making sure > other mechanisms are still possible and we keep it optional at > least until commons-launcher has a 1.0 release, enough documentation > and stability > How about this: I revert the build back to the old scripts and those scripts are copied into the distribution's bin directory. Then, if commons-launcher is available, the new scripts (with a different name such as catalina-launcher.sh so that old scripts don't get overwritten) and commons-launcher also get copied into the distribution's bin directory. This way, people can try it out and suggest improvements if they want to, but the old scripts will still be the default. This switch won't take much time to make. Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5] launcher/deamon
)- the bat scripts are not simple, and you _don't_
> have to add dependencies to the build.
>
>
>
>>My recommendation for the community would be to either use the launcher
>>or use scripts and not try to accomodate both. I believe that keeping
>>the old scripts *and* the launcher would cause a lot more maintenance
>>and a more confusion among users.
>
>
> I partially agree - the scripts are well tuned and work, so there's no
> reason to drop them.
They work fine on Unix. On Windows, they work fine *if* you:
1. Always define %CATALINA_HOME% (%0 is not always reliable)
2. You don't have spaces in %CATALINA_HOME% ("for" loops do not work
with spaces on some Windows versions)
3. You don't use any of the %JAVA_OPTS% or %CATALINA_OPTS% environment
varables (batch scripts on some versions of Windows will abort if
there are "=" characters in the environment variable)
4. You don't want stderr to be logged to a file (stderr cannot be
redirected in a DOS shell)
>
> At least in 3.3 we did a lot of simplifications - like 'guessing'
> tomcat.home, etc - so a lot of stuff can be removed.
>
>
>>If the community chooses not to use the launcher, feel free to remove it
>>from the Tomcat 5 build and restore the old scripts.
>
>
> I'm not the 'community' - but I agree with 'choosing' :-)
>
> Make a proposal, have a vote - that's the only way to know what the
> community chooses.
>
The vote to put it in was already made in the Tomcat 5 proposal. So I
think voting on it again is redundant. If someone would like to propose
its removal, I am OK with that and I can even do the removal for them.
Unfortunately, I really don't have much spare time available right now
to push for acceptance of this new piece of code. So, if anyone is
really uncomfortable with this code or they don't think it is ready for
use in Tomcat yet, I will have no hurt feelings if we want it to be
taken out. In fact, I would find that understandable since I have not
been able to find the time to write up the documentation for the tool.
Patrick
> Costin
>
>
>
>>Patrick
>>
>>Costin Manolache wrote:
>>
>>>Patrick ( and all ),
>>>
>>>The 'launcher' is a very good idea - reducing the use of .bat/sh and
>>>having 'keepalive' functionality and a clean startup file are all
>>>great.
>>>
>>>My only requirement is to keep the code clean and minimise
>>>dependencies.
>>>
>>>My understanding of the launcher is that it uses ant file to describe
>>>the paths, conditions, etc. I looked at the code in sandbox - and there
>>>are few issues ( many tasks that duplicate existing functionality in
>>>ant, etc ), and some should be contributed back to ant ( like the
>>>enhancements to Execute ). I support the idea - as long as tomcat code
>>>is kept clean and this is optional.
>>>
>>>Right now we have a mess of launchers / entry points.
>>>
>>>Costin
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><mailto:[EMAIL PROTECTED]> For additional
>>>commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5] launcher/deamon
Costin, I plan to post a patch to Ant for the enhanced data types (e.g. syspropertyset) and the conditional task elements (e.g. sysproperty with "if" and "unless" attributes) back to Ant as I think they would really enhance the Ant task. I just haven't had time yet but I will do so eventually. As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me explain why we put it in the first place: 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no "&" background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of "fit and finish" to Tomcat on Windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. If the community chooses not to use the launcher, feel free to remove it from the Tomcat 5 build and restore the old scripts. Patrick Costin Manolache wrote: > Patrick ( and all ), > > The 'launcher' is a very good idea - reducing the use of .bat/sh and > having 'keepalive' functionality and a clean startup file are > all great. > > My only requirement is to keep the code clean and minimise dependencies. > > My understanding of the launcher is that it uses ant file to describe > the paths, conditions, etc. I looked at the code in sandbox - and > there are few issues ( many tasks that duplicate existing functionality > in ant, etc ), and some should be contributed back to ant ( like the > enhancements to Execute ). I support the idea - as long as tomcat > code is kept clean and this is optional. > > Right now we have a mess of launchers / entry points. > > Costin > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Daemon deps
Costin, After my last e-mail, I realized that there is one build dependency on commons-launcher.jar in jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaLaunchFilter.java. The good news is that Tomcat's main() has no runtime dependency on this class. It only has a build dependency because of the source directory that I put it in. I will move the CatalinaLaunchFilter class to its own separate package so that it can be easily excluded from the build if you are not using the Launcher in your distribution. Patrick [EMAIL PROTECTED] wrote: > On Thu, 1 Aug 2002, Patrick Luby wrote: > > >>Costin, >> >>Remy can probably comment on the commons-daemon.jar dependency. However, >>the commons-launcher.jar dependency is required for the scripts in the >>bin directory. > > > Can you expand a bit ? > > Catalina itself should't depend on any of those - it should be possible > to start it ( or embed it ) by just calling main(). > > If we want to use commons-daemon or launcher - that's fine, but that > shouldn't require deps - launcher or daemon can use introspection. > > My 'favorite' method of starting will be JMX - I know one application > that will use ant tasks to start tomcat, etc. I see no reason to > have hard deps on any of those. > > > Costin > > > >>Patrick >> >>[EMAIL PROTECTED] wrote: >> >>>Would it be possible to remove the dependency on Daemon ? >>> >>>I see no reason why Daemon couldn't use introspection to call >>>start/stop/destroy. >>> >>> >>>Costin >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Daemon deps
Costin, You can invoke Tomcat's main() directly. commons-launcher.jar is only required for the Launcher. The Launcher is really only a substitute for the old shell scripts. Ultimately, the Launcher uses reflection to invoke Tomcat's main() method. So, commons-launcher.jar is only a dependency if you want to distribute the catalina.[sh|bat] scripts in that are in the bin directory. If you are embedding Tomcat 5 (like Sun does with J2EE), you do not need commons-launcher.jar at all. Or, if you want to ship Tomcat with your own customized scripts (like Sun does with JWSDP), you do not need commons-launcher.jar either. Hope that clears things up, Patrick [EMAIL PROTECTED] wrote: > On Thu, 1 Aug 2002, Patrick Luby wrote: > > >>Costin, >> >>Remy can probably comment on the commons-daemon.jar dependency. However, >>the commons-launcher.jar dependency is required for the scripts in the >>bin directory. > > > Can you expand a bit ? > > Catalina itself should't depend on any of those - it should be possible > to start it ( or embed it ) by just calling main(). > > If we want to use commons-daemon or launcher - that's fine, but that > shouldn't require deps - launcher or daemon can use introspection. > > My 'favorite' method of starting will be JMX - I know one application > that will use ant tasks to start tomcat, etc. I see no reason to > have hard deps on any of those. > > > Costin > > > >>Patrick >> >>[EMAIL PROTECTED] wrote: >> >>>Would it be possible to remove the dependency on Daemon ? >>> >>>I see no reason why Daemon couldn't use introspection to call >>>start/stop/destroy. >>> >>> >>>Costin >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-5 build.properties.default
Costin,
If these are required, shouldn't they be added to the BUILDING.txt
instructions and the build.xml's "download" task as well?
BTW, I just did a clean build without your 3 new dependencies and ran
watchdog against it (11 JSP test fail). I noticed that the
jakarta-tomcat-jasper/jasper2 build does not complain that these
dependencies are not available. If they are really required dependencies
of JSP, shouldn't the jasper2 build check for them and put them in its
build output?
Patrick
[EMAIL PROTECTED] wrote:
> costin 2002/08/01 10:30:39
>
> Modified:.build.properties.default
> Log:
> Add properties for log4j ( if you build in 1.3 ) and jaxen/saxpath.
>
> The last 2 are needed by taglibs which is required by jasper2.
> ( the files are checked in taglibs )
>
> Revision ChangesPath
> 1.14 +14 -1 jakarta-tomcat-5/build.properties.default
>
> Index: build.properties.default
> ===
> RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- build.properties.default1 Aug 2002 14:30:36 - 1.13
> +++ build.properties.default1 Aug 2002 17:30:39 - 1.14
> @@ -39,6 +39,7 @@
>
>
># - Default Base Path for Dependent Packages -
> +#base.path=/usr/share/java
>base.path=/usr/local
>
>
> @@ -119,6 +120,18 @@
>activation.home=${base.path}/jaf-1.0.1
>activation.lib=${activation.home}
>activation.jar=${activation.lib}/activation.jar
> +
> +# - Log4j -
> +log4j.home=${base.path}/log4j
> +log4j.jar=${log4j.home}/log4j.jar
> +
> +# - Jaxen ( required by taglibs/standard required by jasper ) -
> +jaxen.home=${base.path}/jaxen-1.0-FCS
> +jaxen.jar=${jaxen.home}/jaxen-full.jar
> +
> +# - Saxpath ( required by taglibs/standard required by jasper ) -
> +saxpath.home=${base.path}/saxpath-1.0-FCS
> +saxpath.jar=${saxpath.home}/saxpath.jar
>
>
># - Commons DBCP, version 20011030 or later -
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Daemon deps
Costin, Remy can probably comment on the commons-daemon.jar dependency. However, the commons-launcher.jar dependency is required for the scripts in the bin directory. Patrick [EMAIL PROTECTED] wrote: > Would it be possible to remove the dependency on Daemon ? > > I see no reason why Daemon couldn't use introspection to call > start/stop/destroy. > > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: New coyote branch
Justy, I verified that Tomcat 5 builds and runs and most of the servlet tests in Watchdog pass with the current Coyote connector. Of course, I don't think any of the changes in the proposed 2.4 spec have been implemented yet. Are there any changes to Coyote that are explicitly or implicitly required by the spec? Or is the problem that API changes to the javax/servlet classes that are required by the new spec will cause Coyote to not build? Thanks, Patrick [EMAIL PROTECTED] wrote: > On Wed, 31 Jul 2002, Peter Lin wrote: > > >> Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like >>jakarta-tomcat-connectors has been branched yet. I checked the archives >>and saw the vote results where it was decided that the HEAD of >>jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would >>be branched. >> >>I'd like to request that this branch be created. Remy? >> >>The reason I ask is that I'm working on a servlet 2.4 servlet request >>events implementation which involves modifying CoyoteRequest.java. > > > What kind of changes ? Coyote should be independent of servlet, > if you need to add something you can add it to the main branch. > > 2.4 should be backward compatible - so it shouldn't change any > behavior. > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] [jakarta-servletapi-5]
Jean-François, These are already in the jakarta-servletapi-5 workspace and will be available in servlet.jar with the patch to jakarta-servletapi-5/build.xml that I posted last night. So, this patch should *not* be applied. Patrick Jean-francois Arcand wrote: > Hi , attached is the remaining XML schema that need to be available locally. > > src/share/dtd/j2ee_1_4.xsd > src/share/dtd/web-app_2_4.xsd > src/share/dtd/jsp_2_0.xsd > src/share/dtd/jsptaglibrary_2_0.xsd > > Thanks, > > -- Jeanfrancois > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[PATCH] jakarta-servletapi-5
Please apply the attached patch. It adds all of the new *.xsd files to the servlet.jar. Also, please cvs remove the following file as it does not appear to be used: src/share/dtd/web-app_2_3.dtd.backup Thanks, Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 Index: build.xml === RCS file: /home/cvspublic/jakarta-servletapi-5/build.xml,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 build.xml --- build.xml 16 Jul 2002 16:38:40 - 1.1.1.1 +++ build.xml 1 Aug 2002 04:24:42 - @@ -71,16 +71,21 @@ - - + + + + + - - + + + + -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] 5.0 jakarta-tomcat-5 building
Bob,
I just committed your patch. As for your questions, your subject was
very clear which repository this goes in. Also, I personally prefer mime
attachments as then I don't need to hack out all of a submitter's e-mail
content.
Thanks,
Patrick
Bob Herrmann wrote:
>
> I had a near flawless build experience building tomcat 5.0.
>
> I only had to reverse the "digester" and "commons-logging" in build.xml
> This is because the "digester" now depends on "commons-logging"
>
> Can someone please patch this in? Thanks.
>
> Cheers,
> -bob
>
> P.S. Should patch files be attached as mime-attachments?
>
> P.P.S. Does my subject line correctly direct this message?
>(Is there supposed to be a [5.0] first or [PATCH] or...)
>
> Index: build.xml
> ===
> RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
> retrieving revision 1.12
> diff -u -r1.12 build.xml
> --- build.xml 30 Jul 2002 22:13:49 - 1.12
> +++ build.xml 31 Jul 2002 02:26:50 -
> @@ -480,16 +480,6 @@
>
>
>
> -
> -
> -
> -
> -
> - - file="${commons-digester.home}/dist/commons-digester.jar"
> - tofile="${commons-digester.jar}"
> -/>
> -
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[PATCH][jakarta-servletapi-5]
Attached is a patch that updates all of the "Servlet 2.3" references to
"Servlet 2.4" and "JSP 1.2" references to "JSP 2.0".
Can someone with commit access to the jakarta-servletapi-5 repository
please commit this patch?
Thanks,
Patrick
--
________
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
? diff.txt
Index: src/share/dtd/web-jsptaglibrary_2_0.dtd
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/dtd/web-jsptaglibrary_2_0.dtd,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 web-jsptaglibrary_2_0.dtd
--- src/share/dtd/web-jsptaglibrary_2_0.dtd 16 Jul 2002 16:38:40 - 1.1.1.1
+++ src/share/dtd/web-jsptaglibrary_2_0.dtd 30 Jul 2002 15:09:11 -
@@ -164,7 +164,7 @@
The listener-class element declares a class in the application that
must be registered as a web application listener bean. See the
-Servlet 2.3 specification for details.
+Servlet 2.4 specification for details.
-->
Index: src/share/javax/servlet/jsp/tagext/TagInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/TagInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TagInfo.java
--- src/share/javax/servlet/jsp/tagext/TagInfo.java 16 Jul 2002 16:38:41 -
1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/TagInfo.java 30 Jul 2002 15:09:11 -
@@ -131,7 +131,7 @@
}
/**
- * Constructor for TagInfo from data in the JSP 1.2 format for TLD.
+ * Constructor for TagInfo from data in the JSP 2.0 format for TLD.
* This class is to be instantiated only from the TagLibrary code
* under request from some JSP code that is parsing a
* TLD (Tag Library Descriptor).
@@ -381,7 +381,7 @@
}
-// == JSP 1.2 TLD Information
+// == JSP 2.0 TLD Information
/**
Index: src/share/javax/servlet/jsp/tagext/TagVariableInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/TagVariableInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TagVariableInfo.java
--- src/share/javax/servlet/jsp/tagext/TagVariableInfo.java 16 Jul 2002 16:38:41
- 1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/TagVariableInfo.java 30 Jul 2002 15:09:11
+-
@@ -62,7 +62,7 @@
*
* This object should be immutable.
*
- * This information is only available in JSP 1.2 format
+ * This information is only available in JSP 2.0 format
*/
public class TagVariableInfo {
Index: src/share/javax/servlet/jsp/tagext/VariableInfo.java
===
RCS file:
/home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/jsp/tagext/VariableInfo.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 VariableInfo.java
--- src/share/javax/servlet/jsp/tagext/VariableInfo.java16 Jul 2002 16:38:41
- 1.1.1.1
+++ src/share/javax/servlet/jsp/tagext/VariableInfo.java30 Jul 2002 15:09:11
+-
@@ -78,7 +78,7 @@
*
* If a Fully Qualified Class Name is provided, it should refer to a
* class that should be in the CLASSPATH for the Web Application (see
- * Servlet 2.3 specification - essentially it is WEB-INF/lib and
+ * Servlet 2.4 specification - essentially it is WEB-INF/lib and
* WEB-INF/classes). Failure to be so will lead to a translation-time
* error.
*
@@ -87,7 +87,7 @@
* the class name must be that of a public class in the context of the
* import directives of the page where the custom action appears (will
* check if there is a JLS verbiage to refer to). The class must also
- * be in the CLASSPATH for the Web Application (see Servlet 2.3
+ * be in the CLASSPATH for the Web Application (see Servlet 2.4
* specification - essentially it is WEB-INF/lib and
* WEB-INF/classes). Failure to be so will lead to a translation-time
* error.
@@ -122,7 +122,7 @@
*
*
*
- * The JSP 1.2 specification defines the interpretation of 3 values:
+ * The JSP 2.0 specification defines the interpretation of 3 values:
*
*
* NESTED, if the scripting variable is available between
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] mbean-names [logging]
Bob,
Bob Herrmann wrote:
>
> Just so I get an idea of the scale of changes.. Tomcat has a lot of code
> that uses a pattern like this;
>
> private void log(String message) {
> Logger logger = null;
> if (container != null)
> logger = container.getLogger();
> if (logger != null) {
> logger.log(getName() + "[" + container.getName() + "]: "
>+ message);
> } else {
> String containerName = null;
> if (container != null)
> containerName = container.getName();
>
> System.out.println(getName() + "[" + containerName
>+ "]: " + message);
> }
> }
>
> Would the 5.0 logging look more like this ?? ( I am just changing the
> System.out calls to instead defer to a commons-logging logger. )
>
> private void log(String message) {
> Logger logger = null;
>
> if (container != null)
> logger = container.getLogger();
>
> if (logger != null) {
> logger.log(getName() + "[" + container.getName() + "]: "
>+ message);
> } else {
> String containerName = null;
> if (container != null)
> containerName = container.getName();
>
> //import org.apache.commons.logging.Log;
> //import org.apache.commons.logging.LogFactory;
>
> Log log = LogFactory.getLog( containerName );
>
> log.info( getName() + "[" + containerName
>+ "]: " + message);
> }
> }
>
> (Note that commons-logging is going to record the log method (and not
> the caller's) method in the logging output)
>
+1 for this type of change. Even though commons-logging will record the
log method, IMHO this is an incremental improvement over using
System.out directly.
Patrick
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: JDK 1.4 Logging
Bob, That would work. I forgot that Remy now puts out a JDK 1.4 build of Tomcat and using the build flags would allow it to be picked up by users of the JDK 1.4 builds. Patrick Bob Herrmann wrote: > Humm... How about this instead (not that I am lazy)? > > $ cvs diff -u catalina/build.xml > Index: catalina/build.xml > === > RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v > retrieving revision 1.124 > diff -u -r1.124 build.xml > --- catalina/build.xml29 Jun 2002 01:00:04 - 1.124 > +++ catalina/build.xml22 Jul 2002 16:31:07 - > @@ -801,6 +801,8 @@ > unless="jdk.1.3.present"/> > unless="jdk.1.3.present"/> > + + unless="jdk.1.4.present"/> > unless="compile.jmx"/> > name="org/apache/naming/factory/DbcpDataSourceFactory.java" > > > On Mon, 2002-07-22 at 12:28, Patrick Luby wrote: > >>Bob, >> >>This is a useful piece of code. However, your patch can't go into Tomcat >>as it will only compile with JDK 1.4. The standard builds of Tomcat that >>are downloadable from the jakarta.apache.org are built using JDK 1.3 and >>should be run without crashing Tomcat on JDK 1.2. >> >>So, if you would like this in Tomcat (and I think it would be a nice >>optional logger implementation), I think that you need to do the following: >> >>1. Remove all of the following import statements and replace them with >>reflection calls so that the JDK 1.3 compiler can compile this class: >> >>import java.util.logging.Logger; >>import java.util.logging.Level; >>import java.util.logging.Formatter; >>import java.util.logging.Handler; >>import java.util.logging.LogRecord; >> >>2. Catch any ClassNotFound and MethodNotFound exceptions that will occur >>when the code is run on JDK 1.2 or 1.3. >> >>Patrick >> >> >> >> >>Bob Herrmann wrote: >> >>>Hi. I am trying to get Tomcat to log to JDK1.4's logging. >>> >>>I tried implementing a "o.a.c.logging.Logger" subclass that forwarded >>>calls to commons-logging Log. This was unsatisfying because the >>>commons-logger unrolls the stack and logs the "class.method" of my >>>logger, not my logger's caller. >>> >>>I was tempted to change the commons-logger to allow for specifying >>>a class and method on all its methods, but that would be a large >>>change the commons-logger (involving changes and decisions about >>>how this new information should be pushed down and handled with >>>the other loggers it supports.) There is also some issues mapping >>>tomcat verbosity levels, to common-logger log levels and then to JDK >>>Logger levels. >>> >>>So I punted and implemented the code below. It is a >>>"o.a.c.logging.Logger" which writes directly to JDK 1.4 Logging. >>>It allowed me to unroll the stack in a way that fits well with >>>tomcat (ignoring stack frames calling with method log() or method >>>internalLog() which are uninteresting.) And allowed me to map >>>verbosity to JDK Levels. >>> >>>Cheers, >>>-bob >>> >>> >>> >>> >>> >>> >>>/* >>> * $Header: $ >>> * $Revision: $ >>> * $Date: $ >>> * >>> * >>> * >>> * The Apache Software License, Version 1.1 >>> * >>> * Copyright (c) 1999 The Apache Software Foundation. All rights >>> * reserved. >>> * >>> * Redistribution and use in source and binary forms, with or without >>> * modification, are permitted provided that the following conditions >>> * are met: >>> * >>> * 1. Redistributions of source code must retain the above copyright >>> *notice, this list of conditions and the following disclaimer. >>> * >>> * 2. Redistributions in binary form must reproduce the above copyright >>> *notice, this list of conditions and the following disclaimer in >>> *the documentation and/or other materials provided with the >>> *distribution. >>> * >>> * 3. The end-user documentation included with the redistribution, if >>> *any, must include the following acknowlegement: &
Re: JDK 1.4 Logging
public methods of the component are utilized.
> *
> * @exception LifecycleException if this component detects a fatal error
> * that prevents this component from being used
> */
> public void start() throws LifecycleException {
>
> // Validate and update our current component state
> if (started)
> throw new LifecycleException( "alreadyStarted");
> lifecycle.fireLifecycleEvent(START_EVENT, null);
> started = true;
>
> }
>
>
> /**
> * Gracefully terminate the active use of the public methods of this
> * component. This method should be the last one called on a given
> * instance of this component.
> *
> * @exception LifecycleException if this component detects a fatal error
> * that needs to be reported
> */
> public void stop() throws LifecycleException {
>
> // Validate and update our current component state
> if (!started)
> throw new LifecycleException("notStarted");
> lifecycle.fireLifecycleEvent(STOP_EVENT, null);
> started = false;
>
> }
>
>
> }
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Cygwin Path for Tomcat 4.0.4
Boon, I have committed your patch to both the HEAD and 4.0 branch of Tomcat. Patrick Boon Hian Tek wrote: > Hi, > > I am not sure if everyone else's configuration for cygwin is different. > But I had to change the catalina.sh so that it converts the > CATALINA_BASE to windows format path before it will work. > > > # For Cygwin, switch paths to Windows format before running java > if $cygwin; then > JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"` > CATALINA_HOME=`cygpath --path --windows "$CATALINA_HOME"` > CLASSPATH=`cygpath --path --windows "$CLASSPATH"` > JSSE_HOME=`cygpath --path --windows "$JSSE_HOME"` > fi > > > > # For Cygwin, switch paths to Windows format before running java > if $cygwin; then > JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"` > CATALINA_HOME=`cygpath --path --windows "$CATALINA_HOME"` > CATALINA_BASE=`cygpath --path --windows "$CATALINA_BASE"` > CLASSPATH=`cygpath --path --windows "$CLASSPATH"` > JSSE_HOME=`cygpath --path --windows "$JSSE_HOME"` > fi > > > Regards, > > Boon > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Split the repo's
All, Patrick Luby wrote: > I tend to agree with Jon on this issue. When I voted for a > java-servletapi-5 repository, I made the - I think reasonable - > assumption that the java-servletapi-5 repository would only contain the > JSR-154 code. After all, the java-servletapi-4 repository has, for as > long as I can remember, only contained javax.servlet.* classes. > Oops. The javax.servlet.jsp.* packages have been in jakarta-servlet-4 for a long time. In any case, I tried seeing if this issue could be solved by merely moving the javax.servlet.jsp.* packages over to the jakarta-tomcat-jasper repository. Unfortunately, that breaks the jakarta-taglibs code that jakarta-tomcat-jasper depend on. I suspect that there are other projects that may expect the javax.servlet.jsp.* package to be in servlet.jar as well. :( So, even though I don't like the current structure and I think it would be cleaner to have the javax.servlet.jsp.* packages separated from the javax.servlet.* packages, separating them may cause a lot of pain for others who have come to depend on the current structure. I feel that I should take this into my vote and, hence, I am changing my vote to: [X] I don't want the API's split into separate repo's [ ] I don't care [ ] I want the API's split into separate repo's. Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Split the repo's
Jon Scott Stevens wrote: > > [ ] I don't want the API's split into separate repo's > [ ] I don't care > [X] I want the API's split into separate repo's. > > -jon > I tend to agree with Jon on this issue. When I voted for a java-servletapi-5 repository, I made the - I think reasonable - assumption that the java-servletapi-5 repository would only contain the JSR-154 code. After all, the java-servletapi-4 repository has, for as long as I can remember, only contained javax.servlet.* classes. My feeling is that the jakarta-tomcat-jasper code should have the java-servletapi-[4|5] repositories as a dependency but no JSP code should actually be checked into the java-serlvetapi-[4|5] repository. I am OK with the jakarta-tomcat-jasper build can extract all of the javax.servlet.* classes and put them into its own jar. However, JSR-154 requires no dependencies on JSR-152. Hence, putting JSP code in the Servlet repository forces a dependency that should not be there. Patrick -- _________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: New branches and repositories
Craig, These modules are not accessible to the "anoncvs" user. Is there anything we need to do to make that work? Thanks, Patrick "Craig R. McClanahan" wrote: > > The new repositories (jakarta-servletapi-5, jakarta-tomcat-5, and > jakarta-tomcat-catalina) have been set up with just a LICENSE file checked > in. > > Craig > > On Fri, 12 Jul 2002, Remy Maucherat wrote: > > > Date: Fri, 12 Jul 2002 10:52:22 +0200 > > From: Remy Maucherat <[EMAIL PROTECTED]> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > > To: Tomcat Developers List <[EMAIL PROTECTED]> > > Subject: New branches and repositories > > > > So it looks like the vote result (nearly everyone who voted +1 to the > > 5.0 proposal voted, and there's a clear majority for the winning > > choices) is: > > > > A) Use new jakarta-servletapi-5 (a root will need to create it) > > > > B) Use new jakarta-tomcat-catalina (a root will need to create it) > > > > C) Use HEAD of jakarta-tomcat-connectors (I will create the branch for > > Coyote 1.0) > > > > D) Use new jakarta-tomcat-5 (a root will need to create it) > > > > E) Use HEAD of jakarta-tomcat-jasper (I will create the branch for the > > current Jasper2 code) > > > > Remy > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [5.0] [VOTE] New branches and repositories
Remy, Below are my votes. I like the idea of using repositories without versions numbers for the Catalina, Jasper, and Tomcat code. It always seemed to me to be a pain to create a new CVS repository every time there is a new release instead of just creating a branch for the old release. Patrick Remy Maucherat wrote: > > > A) Servlet 2.4 & JSP 2.0 API > 1. [X] Use new jakarta-servletapi-5 > 2. [ ] Use the HEAD of jakarta-servletapi > 3. [ ] Other: > > B) Catalina 2.0 > 1. [X] Use new jakarta-tomcat-catalina > 2. [ ] Use new jakarta-tomcat-5.0 > 3. [ ] Use the HEAD of jakarta-tomcat-4.0 > 4. [ ] Other: > > C) Coyote 2.0 > 1. [X] Yes, use the HEAD of jakarta-tomcat-connectors > 2. [ ] No, use: > > D) Tomcat 5.0 > 1. [ ] Use new jakarta-tomcat-5.0 > 2. [ ] Use the HEAD of jakarta-tomcat-4.0 > 3. [X] Use the HEAD of jakarta-tomcat > 4. [ ] Other: > > E) Jasper 2.0 > 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper > 2. [ ] No, use: > > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Use TreeControl in apps?
Carsten, I am no licensing expert, but I believe that the Apache license allows you to use to any of the Tomcat source code (including the TreeControl). Patrick Carsten Burghardt wrote: > Hi, > > I'm currently looking for a nice tree control to integrate in a struts > project. Is it possible to integrate the TreeControl from the Tomcat > 4.1-admin webapp? I didn't find any other good one... > > Regards, > > Carsten Burghardt -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Another proposal for java.ext.dirs
Costin, [EMAIL PROTECTED] wrote: > Are you sure we need all this ? The .sh/.bat is already too complex. > > A simple check ( in java ) for the things that we care about should be > more than enough, adding another config option and env variable is too > much. > I have to admit that using the scripts is a messy way to handle this problem. I am still trying to find a way to get the java.endorsed.dirs property out of the scripts. > The intent of the ext/ is to simplify the user's life - so they don't have > to set CLASSPATH. It doesn't work out in most cases. > I agree. It is one of those tradeoffs: you can customize your JDK, but it may not work with your applications. > > If we want to disable it - fine, but I don't like making the user's life > even harder by forcing him to remember and set yet another env variable. > I expect the 'regular' user will use ext/, most advanced users are well > aware of the problems and they already know how to deal with that. > > I remain -0 - if you really think this is a problem that must be solved, > I won't veto it. I don't think I will commit this proposed change. After thinking about it, I don't think a hacky script change is a real solution. Since this a problem that affects nearly all Java applications (ant complained when I forgot to delete the jaxp.jar that I put in my jre/lib/ext directory), I am starting to think that this may be a problem where the cure is more painful than the problem. Patrick > > Costin > > > On Mon, 1 Apr 2002, Patrick Luby wrote: > > >>All, >> >>I admit my previous method for protecting Tomcat from conflicting system >> extensions proved to be a bit flawed. However, I still would like to >>add some protection against these conflicts since this tends to be a >>difficult to diagnose problem for a lot of new Tomcat users. On the >>other hand, I don't think we want to prevent knowledgable users from >>using their installed extensions to support their installation. >> >>So, here is what I propose. Note that I am in favor of checking the >>installed extensions so this proposal should be complimentary to any >>checking that might be implemented in the Tomcat code: >> >>1. Add the following to each Java execution line in the wrapper scripts: >> >>Unix: >> -Djava.ext.dirs="$JAVA_EXT_DIRS" >>Windows: >> -Djava.ext.dirs="%JAVA_EXT_DIRS%" >> >>2. Add the following lines in setclasspath.bat and setclasspath.sh: >> >>Unix: >> if [ -z "$JAVA_EXT_DIRS" ]; then >> echo "Disabling installed Java extensions. Set the" >> echo "JAVA_EXT_DIRS environment variable to the following >>value" >> echo "to enable installed Java extensions:" >> echo "$JAVA_HOME/jre/lib/ext" >> fi >>Windows: >> if not "%JAVA_EXT_DIRS%" == "" goto gotJavaExtDirs >> echo Disabling installed Java extensions. Set the >> echo JAVA_EXT_DIRS environment variable to the following value >> >> echo to enable installed Java extensions: >> echo %JAVA_HOME%\jre\lib\ext >> :gotJavaExtDirs >> >>3. If the user does not defined JAVA_EXT_DIRS (the default case), the >>java.ext.dirs property is set to "" and the above status message is >>printed. Then, if the user defines JAVA_EXT_DIRS, the existing >>behavior is enabled. >> >>Since new Tomcat users primarily use the installed scripts, this is a >>good way to protect Tomcat without preventing other custom scripts or >>launchers from enforcing a different standard. >> >>Does this sound like a reasonable approach? It would be nice to have >>this property setting in the Bootstrap.java class, but unfortunately, >>you must set the java.endorsed.dirs property when the JVM is started as >>it is immediately put in the JVM's bootstrap classpath. >> >>Thanks, >> >>Patrick >> >> >>Patrick Luby Email: [EMAIL PROTECTED] >>Sun Microsystems Phone: 408-276-7471 >>901 San Antonio Road, USCA14-303 >>Palo Alto, CA 94303-4900 >> >> >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Another proposal for java.ext.dirs
All, I admit my previous method for protecting Tomcat from conflicting system extensions proved to be a bit flawed. However, I still would like to add some protection against these conflicts since this tends to be a difficult to diagnose problem for a lot of new Tomcat users. On the other hand, I don't think we want to prevent knowledgable users from using their installed extensions to support their installation. So, here is what I propose. Note that I am in favor of checking the installed extensions so this proposal should be complimentary to any checking that might be implemented in the Tomcat code: 1. Add the following to each Java execution line in the wrapper scripts: Unix: -Djava.ext.dirs="$JAVA_EXT_DIRS" Windows: -Djava.ext.dirs="%JAVA_EXT_DIRS%" 2. Add the following lines in setclasspath.bat and setclasspath.sh: Unix: if [ -z "$JAVA_EXT_DIRS" ]; then echo "Disabling installed Java extensions. Set the" echo "JAVA_EXT_DIRS environment variable to the following value" echo "to enable installed Java extensions:" echo "$JAVA_HOME/jre/lib/ext" fi Windows: if not "%JAVA_EXT_DIRS%" == "" goto gotJavaExtDirs echo Disabling installed Java extensions. Set the echo JAVA_EXT_DIRS environment variable to the following value echo to enable installed Java extensions: echo %JAVA_HOME%\jre\lib\ext :gotJavaExtDirs 3. If the user does not defined JAVA_EXT_DIRS (the default case), the java.ext.dirs property is set to "" and the above status message is printed. Then, if the user defines JAVA_EXT_DIRS, the existing behavior is enabled. Since new Tomcat users primarily use the installed scripts, this is a good way to protect Tomcat without preventing other custom scripts or launchers from enforcing a different standard. Does this sound like a reasonable approach? It would be nice to have this property setting in the Bootstrap.java class, but unfortunately, you must set the java.endorsed.dirs property when the JVM is started as it is immediately put in the JVM's bootstrap classpath. Thanks, Patrick Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
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? 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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Remy, 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. BTW, I can eliminate the use of a separate classloader and put the jre/lib/ext directory in the existing catalinaLoader and sharedLoader instances. However, to do this, I need to change the getClassPath() method in JspEngineContext.java so that it returns a classpath that is consistent with the classloaders' search order. Right now, the getClassPath() method (which is used for all JSP compilation) returns a classpath in the exact opposite order of the order used by the sharedLoader classloader. I originally put the extra classloader in to work around this getClassPath() bug. However, given the JDK 1.4 differences in the classloader delegation behavior, I think it would be better for me to fix the getClassPath() problem and move the jre/lib/ext directory into the existing catalinaLoader and sharedLoader instances like we do for the endorsed directories. Costin, Does this sound reasonable to you? Thanks, Patrick -- ____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
eClassLoader(unpacked, packed2, null);
>> +ClassLoaderFactory.createClassLoader(unpacked, packed2,
>> + extLoader);
>> +
>> +// Need to have the commonLoader only delegate to the parent
>> +// class loader only after searching its own repositories. This
>> +// allows the commonLoader's repositories to take priority over
>> +// the JDK's installed extensions.
>> +((StandardClassLoader)commonLoader).setDelegate(false);
>>
>> unpacked[0] = new File(getCatalinaHome(),
>> "server" + File.separator + "classes");
>> @@ -155,6 +171,7 @@
>> sharedLoader =
>> ClassLoaderFactory.createClassLoader(unpacked, packed,
>>commonLoader);
>> +
>> } catch (Throwable t) {
>>
>> log("Class loader creation threw exception", t);
>>
>>
>>
>> 1.4 +18 -5
>jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Tool.java
>>
>> Index: Tool.java
>> ===
>> RCS file:
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Tool.java,v
>> retrieving revision 1.3
>> retrieving revision 1.4
>> diff -u -r1.3 -r1.4
>> --- Tool.java 18 Dec 2001 02:50:30 - 1.3
>> +++ Tool.java 1 Apr 2002 00:13:23 - 1.4
>> @@ -1,7 +1,7 @@
>> /*
>> - * $Header:
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Tool.java,v
> 1.3 2001/12/18 02:50:30 patrickl Exp $
>> - * $Revision: 1.3 $
>> - * $Date: 2001/12/18 02:50:30 $
>> + * $Header:
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Tool.java,v
> 1.4 2002/04/01 00:13:23 patrickl Exp $
>> + * $Revision: 1.4 $
>> + * $Date: 2002/04/01 00:13:23 $
>>*
>>*
>>*
>> @@ -116,7 +116,7 @@
>>*
>>*
>>* @author Craig R. McClanahan
>> - * @version $Revision: 1.3 $ $Date: 2001/12/18 02:50:30 $
>> + * @version $Revision: 1.4 $ $Date: 2002/04/01 00:13:23 $
>>*/
>>
>> public final class Tool {
>> @@ -214,6 +214,14 @@
>> log("Constructing class loader");
>> ClassLoaderFactory.setDebug(1);
>> }
>> +// Put the JDK's installed extensions in the parent class loader.
>> +// Presumably, the "java.ext.dirs" property has already been set
>> +// to a zero length string.
>> +File[] extFile = new File[1];
>> +extFile[0] = new File(System.getProperty("java.home"),
>> +"lib" + File.separator + "ext");
>> +ClassLoader extLoader =
>> +ClassLoaderFactory.createClassLoader(null, extFile, null);
>> ArrayList packed = new ArrayList();
>> ArrayList unpacked = new ArrayList();
>> unpacked.add(new File(catalinaHome, "classes"));
>> @@ -240,7 +248,12 @@
>> ClassLoaderFactory.createClassLoader
>> ((File[]) unpacked.toArray(new File[0]),
>>(File[]) packed.toArray(new File[0]),
>> - null);
>> + extLoader);
>> +// Need to have the classLoader only delegate to the parent
>> +// class loader only after searching its own repositories. This
>> +// allows the classLoader's repositories to take priority over
>> +// the JDK's installed extensions.
>> +((StandardClassLoader)classLoader).setDelegate(false);
>> } catch (Throwable t) {
>> log("Class loader creation threw exception", t);
>> System.exit(1);
>>
>>
>>
>> 1.9 +3 -2 jakarta-tomcat-4.0/jasper/src/bin/jasper.bat
>>
>> Index: jasper.bat
>> ===
>> RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.bat,v
>> retrieving revision 1.8
>> retrieving revision 1.9
>> diff -u -r1.8 -r1.9
>> --- jasper.bat 30 Jan 2002 22:13:50 - 1.8
>> +++ jasper.bat 1 Apr 2002 00:13:23 - 1.9
>> @@ -15,7 +15,7 @@
>> rem JAVA_OPTS (Optional) Java runtime options used when the "start",
>> rem "stop", or "run" command is executed.
>> rem
>> -rem $Id: jasper.bat,v 1.8 2002/01/30 22:13:50 patrickl Exp $
>> +rem $Id: jasper.bat,v 1.9 2002/04/01 00:13:23 patrickl Exp $
>> rem ---
>>
>> rem Guess JASPER_HOME if not defined
>> @@ -46,6 +46,7 @@
>> for %%i in ("%JASPER_HOME%\common\lib\*.jar") do call
>"%JASPER_HOME%\bin\cpappend.bat" %%i
>> for %%i in ("%JASPER_HOME%\shared\lib\*.jar") do call
>"%JASPER_HOME%\bin\cpappend.bat" %%i
>> set CLASSPATH=%CLASSPATH%;%JASPER_HOME%\shared\classes
>> +for %%i in ("%JAVA_HOME%\jre\lib\ext\*.jar") do call
>"%JASPER_HOME%\bin\cpappend.bat" %%i
>>
>> rem Parse arguments
>> if ""%1"" == ""jspc"" goto doJspc
>> @@ -65,6 +66,6 @@
>> goto setArgs
>> :doneSetArgs
>>
>> -%_RUNJAVA% %JAVA_OPTS% %JASPER_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%"
>-classpath "%CLASSPATH%" -Djasper.home="%JASPER_HOME%" org.apache.jasper.JspC
>%CMD_LINE_ARGS%
>> +%_RUNJAVA% %JAVA_OPTS% %JASPER_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%"
>-Djava.ext.dirs="%JAVA_EXT_DIRS%" -classpath "%CLASSPATH%"
>-Djasper.home="%JASPER_HOME%" org.apache.jasper.JspC %CMD_LINE_ARGS%
>>
>> :end
>>
>>
>>
>> 1.9 +6 -2 jakarta-tomcat-4.0/jasper/src/bin/jasper.sh
>>
>> Index: jasper.sh
>> ===
>> RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v
>> retrieving revision 1.8
>> retrieving revision 1.9
>> diff -u -r1.8 -r1.9
>> --- jasper.sh 30 Jan 2002 22:13:50 - 1.8
>> +++ jasper.sh 1 Apr 2002 00:13:23 - 1.9
>> @@ -14,7 +14,7 @@
>> # JAVA_OPTS (Optional) Java runtime options used when the "start",
>> # "stop", or "run" command is executed.
>> #
>> -# $Id: jasper.sh,v 1.8 2002/01/30 22:13:50 patrickl Exp $
>> +# $Id: jasper.sh,v 1.9 2002/04/01 00:13:23 patrickl Exp $
>> # -
>>
>> # OS specific support. $var _must_ be set to either true or false.
>> @@ -68,6 +68,9 @@
>> CLASSPATH="$CLASSPATH":"$i"
>> done
>> CLASSPATH="$CLASSPATH":"$JASPER_HOME"/shared/classes
>> +for i in "$JAVA_HOME"/jre/lib/ext/*.jar; do
>> + CLASSPATH="$CLASSPATH":"$i"
>> +done
>>
>> # For Cygwin, switch paths to Windows format before running java
>> if $cygwin; then
>> @@ -82,7 +85,8 @@
>>
>> shift
>> exec "$_RUNJAVA" $JAVA_OPTS $JASPER_OPTS \
>> --Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
>> +-Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" \
>> +-Djava.ext.dirs="$JAVA_EXT_DIRS" -classpath "$CLASSPATH" \
>> -Djasper.home="$JASPER_HOME" \
>> org.apache.jasper.JspC "$@"
>>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: servlet.jar, /ext, MANIFEST.MF
Christopher, I just committed the changes to the jakarta-tomcat-4.0 HEAD branch. Can you give it a try? With these changes, Tomcat should load its own bundled jar and class files before any of the jar files in the JDK's installed extensions are loaded. I tested this by putting servlet.jar in my JDK's jre/lib/ext directory and then inserted a broken version of the javax.servlet.http.HttpServlet class (my broken version extended Object and had no methods) into the jar so that if the servlet.jar in the JDK's jre/lib/ext directory is used, Tomcat will throw tons of exceptions. Let me know if you find any problems with my changes. Thanks, Patrick Christopher K. St. John wrote: > Patrick Luby wrote: > >>I can't help but think that there might be a way to point Tomcat >>to its bundled jars without losing access to any non-conflicting >>extensions. >> > > > That would be better. (but the servletapi still should have > the appropriate version info :-) > > > >>... have the class loaders in Bootstrap.java add the jars in >>the JVM's jre/lib/ext directory to the end of its search list. >> > > > Hmm. To match the spec, I think there would need to be a new > classloader on top of all of those. Something like: > >ExtClassLoader (pithed) >| >AppClassLoader (as normal) >| > Catalina /ext (new: loads /ext classes) >| > Common(as normal) > ... > > Which means that stuff loaded from the classpath won't have > access to extensions, so that's still not quite right. Since > Tomcat closely controls what's on the classpath I'm not sure > how much of an issues that is, but it's definitely a bit > different than normal. > > I'd settle for just having Tomcat print an error message if > there was a conflict, but if the classloader hacks can be > made to work that would obviously be better. > > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: JSP won't load but servlets do
Raphael, The real problem is this: java.lang.NoClassDefFoundError: sun/tools/javac/Main This means that the tools.jar file is not in Tomcat's classpath. Tomcat will look for this file in the %JAVA_HOME%\lib directory. If there is no tools.jar file in that directory, your problem is one of the following: 1. %JAVA_HOME% is set to the JDK's "jre" subdirectory - If this is the case, reset %JAVA_HOME% to the parent directory of your current %JAVA_HOME%. 2. %JAVA_HOME% points to a JRE installation - If this is the case (i.e. if there is no javac.exe command in your %JAVA_HOME%\bin directory) you need to install the full Java 2 SDK since Tomcat needs the javac compiler. Patrick Raphael Di Cicco wrote: > Hi, > > I have installed a Jakarta Tomcat web server on a Windows 2000 server > machine. > To do that I have installed the JDK 1.3.1 and added the environment > variable. > Then I installed Tomcat 4.0.2 and added the environment variable. > > I can properly load the server main page by going to http://localhost:8080/ > in this page I can test any servlet example : they are all working > > But when I try to use any JSP example I have an exception(http 500) : > > > type Exception report > > message Internal Server Error > > description The server encountered an internal error (Internal Server > Error) that prevented it from fulfilling this request. > > exception > > javax.servlet.ServletException: sun/tools/javac/Main > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:485) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > > >org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) > > at > > >org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) > > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) > > at > > org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) > > at . > > > root cause > > java.lang.NoClassDefFoundError: sun/tools/javac/Main > at > org.apache.jasper.compiler.SunJavaCompiler.compile(SunJavaCompiler.java:136) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:272) > at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552) > at > > >org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:177) > > at > > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:189) > > > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) > > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > > > It used to work well before and I don't see anything wrong with my install, > do you ? Is it because I am using Windows 2000 where I used to run Windows NT > ? > > Thanks for your help > Raphael > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: servlet.jar, /ext, MANIFEST.MF
Christopher, Let me try this out later this week. I will let you know if the hack works. Also, even if the hack does not check the version info of servlet.jar, I see know harm in adding it. Patrick "Christopher K. St. John" wrote: > > Patrick Luby wrote: > > > > I can't help but think that there might be a way to point Tomcat > > to its bundled jars without losing access to any non-conflicting > > extensions. > > That would be better. (but the servletapi still should have > the appropriate version info :-) > > > ... have the class loaders in Bootstrap.java add the jars in > > the JVM's jre/lib/ext directory to the end of its search list. > > Hmm. To match the spec, I think there would need to be a new > classloader on top of all of those. Something like: > >ExtClassLoader (pithed) >| >AppClassLoader (as normal) >| > Catalina /ext (new: loads /ext classes) >| > Common(as normal) > ... > > Which means that stuff loaded from the classpath won't have > access to extensions, so that's still not quite right. Since > Tomcat closely controls what's on the classpath I'm not sure > how much of an issues that is, but it's definitely a bit > different than normal. > > I'd settle for just having Tomcat print an error message if > there was a conflict, but if the classloader hacks can be > made to work that would obviously be better. > > -- > Christopher St. John [EMAIL PROTECTED] > DistribuTopia http://www.distributopia.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: servlet.jar, /ext, MANIFEST.MF
Christopher, "Christopher K. St. John" wrote: > That seems a bit hostile. The majority of stuff that could > go into /ext is harmless. Ignoring it punishes users who > correctly install the "right" extensions. You have a good point. Using "-Djava.ext.dirs=" is an all or nothing approach and may be too limiting. > My proposal was based on idea that if you can't solve a > hard-to-diagnose problem, you ought to at least make it > obvious. I'd be worried that ignoring /ext solves one > such problem but replaces it with another. I can't help but think that there might be a way to point Tomcat to its bundled jars without losing access to any non-conflicting extensions. Since Tomcat constructs its own class loader to load its bundled jars (including servlet.jar), one possible solution would be to set the "-Djava.ext.dirs=" in the scripts and then have the class loaders in Bootstrap.java add the jars in the JVM's jre/lib/ext directory to the end of its search list. This way, any conflicting extensions would be loaded after the bundled jars. We use a similar mechanism to work around the endorsed dirs mechanism with JDK 1.4. Does this seem to have potential? If it works, Tomcat would be able to isolate itself from conflicting extensions (i.e. we could eliminate the problem instead of just printing an error message) while still accessing the installed extensions (e.g. JSSE, etc.). Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: servlet.jar, /ext, MANIFEST.MF
Christopher, "Christopher K. St. John" wrote: > But wouldn't that mean that "legitimate" exetensions were > ignored? > Yes, they would be ignored. Although this is a limitation, it might be a reasonable one when you consider all the potential problems that can be caused by putting XML parsers, JSSE implementations, etc. that are different than the ones that Tomcat expects in your jre/lib/ext directory. Patrick _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: servlet.jar, /ext, MANIFEST.MF
Christopher, There is an easier solution, although it has limits. Since the Tomcat binaries include servlet.jar, we can put "-Djava.ext.dirs=" as an argument in the Tomcat scripts. This argument causes the JVM to ignore any jars in its jre/lib/ext directory so that there is no conflict between the jars shipped with your application (Tomcat in this case) and the jars in your JVM's jre/lib/ext directory. I think that this solution may also eliminate the vexing problem where the JSSE jars are in jre/lib/ext as well. Does this sound like a reasonable solution? If so, I can implement this in the Tomcat scripts with minimal effort. Patrick "Christopher K. St. John" wrote: > > The JDK documentation indicates that servlet.jar, as an > official optional package, should be placed in the > /lib/ext directory. [1] However, the Tomcat 4 documentation > (well, the mailing list) indicates that servlet.jar should > not be placed in /lib/ext. [2] > > Catalina should be able to detect problems using > java.lang.Package methods to query the version of the > provided javax.servlet packages. > > It looks like this would require: > > 1) jakara-servletapi-4 to provide a manifest with the > appropriate version information. > > 2) Catalina to check the version information at some > point, perhaps optionally. > > Is this a reasonable thing to do? I admit to a cosiderable > amount of confusion over the balance between theory > [3],[4],[5] and practice. Any feedback/clarification > greatly appreciated. > > [1] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html > 4th paragraph of the Introduction uses servlet.jar as an > example of something that definitely belongs in /ext. I'm > not trying to argue about it, I'm just pointing out that > the documentation conflicts with common practice. I've > gotten into arguments with people who insist it's ok because > of the extensions spec says, specifically, that it is. > > [2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5523, > ref "Additional Comments", also: > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg15098.html > ref para starting "TOMCAT-USER gets 10 or so messages a week". > > [3] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html > > [4] >http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html > > [5] SRV.9.7.1 "Dependencies On Extensions". Yes, I know, > it isn't quite the same thing. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: bug in catalina.sh
Fabien,
Since the "$@" is necessary to preserve quoting of arguments with spaces in
them, changing it to $@ is not a really good solution. First off, which Unix
platform are you using? I know that the "$@" works on Solaris and Linux and Mac
OS X.
Also, have you tried using "${@}"? Most platfroms don't require the curly braces
to preserve quoting, but maybe yours does.
Patrick
Fabien Nisol wrote:
>
> Hello,
>
> I noticed a bug in catalina.sh that make some of us have problem starting
> tomcat. The common error is that a message
>
> usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ] [
> -debug ] [ -nonaming ] { start | stop }
>
> is printed in $CATALINA_HOME/logs/catalina.out
>
> I began to look at this problem and I finally found the bug:
>
> The problem is that at every line where catalina is started ("$_RUNJAVA
> ..."), command line arguments that are passed to the catalina.sh script are
> passed using "$_RUNJAVA" "$@" (quotes
> included) ... The problem : When only one argument is passed to the VM , in
> Catalina.main(String args[]), args are { "" , } and not {
> } ... ( starting catalina.sh start means starting "java
> "" start", not "java start") ...
>
> big problem in Catalina.arguments(String[] args) where the argument ""
> (empty string) is not recognised and issues an error on stdout...
>
> I think the problem could be corrected by replacing all "$@" (with quotes)
> occurence by $@ (without quotes) in catalina.sh
>
> Are you ok with this or am I missing something??
>
> Fabien Nisol
> java Developer/Analyst consultant
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] Allow configurable JPDA transport in catalina.bat
Christopher, I have committed this patch and have ported it to the catalina.sh script for Unix platforms as well. Patrick Christopher Elkins wrote: > > Hi, all. > > The patch below allows the JPDA transport used in "jpda start" to be set via > an environment variable. Unfortunately, not all debuggers support the shared > memory transport (e.g., JSwat), so these changes make it possible to use > the socket transport without having to modify catalina.bat locally. > > Moreover, this patch cleans up the slightly inaccurate comment for > JPDA_ADDRESS and includes my previous patch to fix a typo (with the subject > "[PATCH] Typo in catalina.bat"). > > -- > Christopher Elkins > > Index: catalina.bat > === > RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v > retrieving revision 1.25 > diff -u -r1.25 catalina.bat > --- catalina.bat11 Feb 2002 20:26:24 - 1.25 > +++ catalina.bat19 Mar 2002 17:20:17 - > @@ -27,7 +27,10 @@ > rem (JSSE) installation, whose JAR files will be added to the > rem system class path used to start Tomcat. > rem > -rem JPDA_ADDRESS(Optional) Java runtime options used when the "jpda start" > +rem JPDA_TRANSPORT (Optional) JPDA transport used when the "jpda start" > +rem command is executed. The default is "dt_shmem". > +rem > +rem JPDA_ADDRESS(Optional) JPDA address used when the "jpda start" > rem command is executed. The default is "jdbconn". > rem > rem $Id: catalina.bat,v 1.25 2002/02/11 20:26:24 patrickl Exp $ > @@ -87,7 +90,10 @@ > > if not ""%1"" == ""jpda"" goto noJpda > set JPDA=jpda > -if not "%JPDA_ADDRESS%" == "" got gotJpdaAddress > +if not "%JPDA_TRANSPORT%" == "" goto gotJpdaTransport > +set JPDA_TRANSPORT=dt_shmem > +:gotJpdaTransport > +if not "%JPDA_ADDRESS%" == "" goto gotJpdaAddress > set JPDA_ADDRESS=jdbconn > :gotJpdaAddress > shift > @@ -174,10 +180,10 @@ > goto end > :doJpda > if not "%SECURITY_POLICY_FILE%" == "" goto doSecurityJpda > -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug >-Xrunjdwp:transport=dt_shmem,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% >-Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" >-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" >-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION% > +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug >-Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n >%DEBUG_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" >-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" >-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION% > goto end > :doSecurityJpda > -%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% >-Xrunjdwp:transport=dt_shmem,address="%JPDA_ADDRESS%",server=y,suspend=n %DEBUG_OPTS% >-Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" >-Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" >-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" >-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION% > +%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% >-Xrunjdwp:transport=%JPDA_TRANSPORT%,address="%JPDA_ADDRESS%",server=y,suspend=n >%DEBUG_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" >-Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" >-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" >-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION% > goto end > > :end > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] Typo in catalina.bat
Christopher, Good catch. I just committed your patch to the HEAD and tomcat_40_branch branches. Patrick Christopher Elkins wrote: > > Hi, all. > > The patch below fixes a typo in catalina.bat. > > -- > Christopher Elkins > > Index: catalina.bat > === > RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v > retrieving revision 1.25 > diff -u -r1.25 catalina.bat > --- catalina.bat11 Feb 2002 20:26:24 - 1.25 > +++ catalina.bat19 Mar 2002 16:57:33 - > @@ -87,7 +87,7 @@ > > if not ""%1"" == ""jpda"" goto noJpda > set JPDA=jpda > -if not "%JPDA_ADDRESS%" == "" got gotJpdaAddress > +if not "%JPDA_ADDRESS%" == "" goto gotJpdaAddress > set JPDA_ADDRESS=jdbconn > :gotJpdaAddress > shift > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: setting up tomcat to accept client certificate
Kunal, This is exactly how the code is supposed to work: the certificate is *not* fetched from the client if the parameter is set to 'false'. Patrick kunal kaviraj wrote: > > Hi All, > Whenever I try to set the parameter clientAuth="true" in the server.xml to > accept client certificate from the user, after restarting Tomcat starts up > well, but then I get 'Cannot find server' error when I try to access the > https sites. But the http sites work perfectly. > But when this parameter is set to 'false' https and http both works > perfectly, though the client is not asked for certificate. > The server certificate I am using has been generated by keytool. > The client certificate is a third party one. > I am using Tomcat standalone version 4.0.1 with jdk1.3.1 > I have downloaded the jsse1.0.2 and put the 3 jar files in the jdk ext path. > Any pointer will be really helpful. > Thanks > Kunal > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Newbie: Basic Question
Bhai, The problem is that you have a '\' character at the end of %CATALINA_HOME%. Instead of the following: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ set CATALINA_HOME to the following: C:\Programs\jakarta-tomcat-4.0.3-src\dist Patrick Bhai wrote: > > > > Hi, > > > > > > I have downloaded the tomcat source from TC web and have built it and > also created a distribution. But on my Win2K machine when I do "catalina > start" from the CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME > and the CATALINA_BASE, it appears to open a new command window, which it > closes instantaneously. The port 8080 on my machine is not in use and > looking at the task manager it does not appear that the java instance is > running. > > > > > > Is there some other setting that I have to do other than setting the > java home and catalina home in order to run the distribution/build. my > catalina home is set to c:\...jakarta-tomcat-src\dist where ant created the > distributables. > > > > > > Please point me in the right direction. > > > > > > Thanks. > > > Bhai, > > > > It is hard to tell what is going on without capturing what is appearing in > the > > window that pops up. Try running "catalina run". This will keep all output > in > > the same window so that you can see the errors. > > > > Patrick > > Hello Patrick, > > That ran and I could see the output which I have pasted below. > > C:\Programs\jakarta-tomcat-4.0.3-src\dist\bin>catalina run > Using CATALINA_BASE: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ > Using CATALINA_HOME: C:\Programs\jakarta-tomcat-4.0.3-src\dist\ > Using CATALINA_TMPDIR: C:\Programs\jakarta-tomcat-4.0.3-src\dist\\temp > Using JAVA_HOME: C:\j2sdk1.4.0 > Exception during startup processing > java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina > at > org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas > sLoader.java:1127) > at > org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClas > sLoader.java:992) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:218) > > It cannot find the catalina.class file that is present in the catalina.jar > within the dist/servers/catalina.jar file. Can you help me out. > > Thanks. > > Bhai. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Newbie: Basic Question
Bhai, It is hard to tell what is going on without capturing what is appearing in the window that pops up. Try running "catalina run". This will keep all output in the same window so that you can see the errors. Patrick Bhai wrote: > > Hi, > > I have downloaded the tomcat source from TC web and have built it and also created a >distribution. But on my Win2K machine when I do "catalina start" from the >CATALINA_HOME\bin, it echoes the JAVA_HOME and CATALINA_HOME and the CATALINA_BASE, >it appears to open a new command window, which it closes instantaneously. The port >8080 on my machine is not in use and looking at the task manager it does not appear >that the java instance is running. > > Is there some other setting that I have to do other than setting the java home and >catalina home in order to run the distribution/build. my catalina home is set to >c:\...jakarta-tomcat-src\dist where ant created the distributables. > > Please point me in the right direction. > > Thanks. > > Bhai -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Remy, +1 for all. Patrick Remy Maucherat wrote: > > There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to > start with some limited changes at first. Most of these proposed changes are > Coyote-related (hence the subject of the message), and all involve some > refactoring / API additions. > > A) URI decoding refactoring. To avoid doing some URI decoding in many places > in the pipeline, a decodedURI field (with associated getter/setter) should > be added in the HttpRequest interface, and used in the Catalina pipeline. > This also has the advantage to guarantee that no double URI decoding occurs > (which can lead to URI-based security attacks). > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old > connector, which has many shortcoming (slow performance on output, HTTP > handling limitations and extreme complexity). Initial tests results and > benchmarks with Coyote are extremely positive so far. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > C) Add better lifecycle handling in the resources. A start method is needed > (which could be called 'allocate' to mirror the 'release' method), because > it is currently not possible to restart a stopped context. In the 4.0 > branch, the patch introducing the 'release' method must either be reverted, > or these proposed changes must also be ported to 4.0. > Thanks to Jean-Francois Clere for the report and debugging of this problem. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT* > be used for any new connector development. To make this more obvious, I'd > like to deprecate all classes in this package and subpackages. The binaries > will also be packaged in a separate JAR file (tentatively named > catalina-legacy.jar). This package will continue to be maintained on a case > by case basis. The facades will not be deprecated, and two new helper > objects will be introduced to handle the need for "fake" req/resp when > requesting a JSP precompilation with a load-on-startup (see bug 4518 for > more details). > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor > interface. Otherwise, the processor has no way to cleanly handle logging. > commons-logging is already used by other j-t-c components. At the moment, > the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this > needs to be improved. When I originally designed most of the base > interfaces, commons-logging didn't exist yet, and I didn't feel like adding > yet another logging interface. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > +1 for everything. Thanks for voting / commenting :) > > Remy > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Install bug tomcat4.0 on Mac Osx
Paulo, I think you may have found the the problem. For those interested in using Mac OS X, the following must be done or you will run into the Mac Classic 31 character filename limit: 1. Unpack using the Mac OS X tool gnutar command line tool only. Don't let your browser do the unpacking as sometimes Netspace or IE will automatically unpack the download file using a Mac OS 9.x tool. 2. Unpack to a HFS+ disk. If you have unpack to a HFS formatted disk, you will run into the 31 character limit. Patrick Paulo Gaspar wrote: > > > -Original Message- > > From: Karim Qazi [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, March 06, 2002 12:39 AM > > To: [EMAIL PROTECTED] > > Subject: Install bug tomcat4.0 on Mac Osx > > > > > > I downloaded the release jakarta-tomcat-4.0-20020303.tar.gz and when > > unpacking this release, the servlet > > examples/WEB-INF/classes/SetCharacterEncodingFilter.class > > > > Is unpacking as SetCharacterEnclodingFilter.clas. > > > > This is causing the examples not to function correctly. > > > > Thought you'd like to know this. > > > > Karim Qazi > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Remy, Remy Maucherat wrote: > > Ok, I'll send then an email. > And would participate in the project ? If it allows me to start Tomcat and all of the other tools (e.g. jspc, etc.) without shell or batch scripts, count me in. Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Pier, Pier Fumagalli wrote: > > IMO, it's a waste of time... You shouldn't call setuid from Java, but the > native code launching the VM should call appropriate methods at appropriate > moments of the lifecycle... As I said before: > > 1) CreateJavaVM > 2) call Tomcat->initialize() (bind to ports) > 3) set uid/euid/gid/egid/groups > 4) call Tomcat->start() (accept connections) > 5) wait for signal > 6) call Tomcat->stop() > 7) exit process... > > All the code is already in place... Just need to be tied together... I agree. I got your sample code to work on Mac OS X 10.1 and, just for kicks, had Java invoke the callback that was registered. Since you have separated out the port binding into Tomcat->initialize(), you are also correct that I don't need to call the callback function from Java. I admit my thinking was still limited to the existing constraints of the StandardServer.start() method instead of the new bootstrap classes. Next thing I will do is take a look at the bootstrap classes and test out your recommendation. > RegisterNative _is_ JNI... JNI is developed on two layers, call C from Java > (maybe using System.loadLibrary()), and that's what everyone knows. > > Call Java from C (a little bit less known, but way more powerful)... > > We need a JVM invocation API, not a Java callback mechanism, IMO... We used the JVM invocation API when I was working on StarOffice. However, I never ran into the RegisterNative method. Although we don't need it for the setuid() calls, I think it might come in handy sometime. > That's the beauty of JNI, you can do things that you won't even believe they > exist, like "compiling" (loading) a class when NOT all its methods are > there... It's the beauty of a Class seen as an Instance of an object (and > IMO the biggest advantage over things like SmallTalk)... JG thought it out > good... > I admit that I kept expecting there to be more work to do. But you keep surprising me with what you have already implemented. Thanks for having the patience to walk me through this. Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Pier, I took a quick look at the code and found the RegisterNative function. This looks like an interesting feature. I also found the same function in your daemons code. The picture is becoming much clearer. Let me try to get it working in the next few days with the callback function set to invoke setuid() and have the callback invoke (via Java reflection since it won't be there on Windows or standalone start. If I can get this to work, I will post the patches first so that all can inspect. Now that I understand this approach, it basically seems to work through the same logical steps (from a Tomcat Java code) perspective as invoking the callback function via JNI. In your approach, the function is preloaded for Java (no System.loadLibrary() required) and the Java code invokes the function like any other method (it just happens that the method doesn't exist at compile time but only at runtime). Thanks, Patrick Pier Fumagalli wrote: > > Pier Fumagalli <[EMAIL PROTECTED]> wrote: > > > Few hours... > > Yeah, whatever... Trivial... > > Pier > > >Part 1.2Type: Macintosh File > >Part 1.3Type: Macintosh File > > Name: make.sh >make.shType: Bourne Shell Program (application/x-sh) > Encoding: base64 > >Part 1.5Type: Plain Text (text/plain) -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin,
[EMAIL PROTECTED] wrote:
>
> 1. I think combining the wrappers ( any of them ) with the
> platform-specific native code used inside tomcat is _bad_.
> One of the good things about tomcat is that it can be started/mebedded
> in many different ways. Creating a small jni library is quite trivial -
> MacOS may be different, but I'm sure they provide a way and we can
> support it ( if we want in-process and unix sockets there we'll
> have to do it anyway - that's jni based ). Keep them separated -
> it's more flexible.
I have already wrote a quick test on Mac OS X. It works just like all other
platforms. The only difference is that you need to link your shared library with
"-bundle" and name it lib.jnilib instead of lib.so. After that,
System.loadLibrary("") will load the library. You don't even need to link to
any of the JVM's libraries to do this.
>
> 2. The 'normal' way to do this, used by all unix daemons, by
> all other java servers ( including JavaWebServer and any other
> containers except tomcat ) is to use a (jni) call to chuid.
> It works, it's tested and clean.
> I'm sure this can be obfuscated or done using whatever callbacks
> mechanism ( opening all the resource in the wrapper, etc) , but doing it
> in the natural way is better IMHO.
This is why I was pursuing this approach for the last 2 days. I have seen this
type of code way back when I was porting the Java Web Server's JNI code to
HP-UX, AIX, and DEC Unix a few years back. Also, I believe that Apache follows
this same logic path (although it doesn't need JNI to get to the C function, of
course).
Patrick
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Remy, Remy Maucherat wrote: > > At the moment, it is only a NT service, I think. The exe wrapper can (and > probably should) do both. I will admit that I am no Windows expert, but can't you just have a main() function that invokes start service code. Shutdown would be a little trickier as you need to send it a signal or some other event. Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: > > > That wouldn't work - if the UID is changed before starting tomcat, then > it can't listen on port 80. > > The uid must be changed after it start listening, like any unix program > does. And the wrapper/invocator is just one way to start tomcat - I like > the flexibility on startup. > This is very true and was the reason I was pursuing the "public native" method approach. But Pier mentioned and passing a callback function to the JVM when he starts it. Maybe Pier could elaborate on this process? Basically, for Pier's callback approach to work, the callback function would need to be tied to invocation of the StandardServer.initialize() method. I haven't used any callbacks like he describes so I am curious about the mechanics. -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Remy, Remy Maucherat wrote: > > I agree with Pier here. I think we should only try to implement daemon > fnctionality using the appropriate wrapper. Implmenting it with standard > Tomcat using scripts is a nasty hack. > Somehow, Patrick doesn't seem to like my BootstrapService (which works > perfectly well; it's even been in use for a long time through the NT service > which ships with the Windows installer) :-( > I admit it: I was trying to implement a hack. I am definitely warming up to the idea of jumping straight into Pier's scripts. After all of this discussion, it doesn't seem to be so much work to switch to a native launcher to implement the setuid() stuff. Plus, I agree with Remy that the use of shell scripts to launch Tomcat is a bit nasty. I like the idea of using Pier's launcher (I assume the Windows native code has a native launcher as well?) to be able to start Tomcat via a double-click on an executable and no MS-DOS window on Windows. Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Pier, Pier Fumagalli wrote: > > Patrick... System.loadlibrary (or however is called), does the exact > opposite of what we need... We ship a binary that will load the JVM library, > we don't rely on the JVM binary to load a library... Maybe I should clarify what I am trying to do. I am trying to enable the use of setuid() within the existing Tomcat startup process (i.e. shell scripts). I definitely like your native launcher and the more I look at it, the more I like its sophisticated function. I just want to make the setuid() call available even if I haven't startup Tomcat using your native launcher. The way to do that is to use the Java->JNI method of creating a shared library that contains a function with a name that matches a demangled version of a "public native" Java method. Then, when Tomcat is started via a script (as it does now), the StandardServer class can do the following: - Invoke System.loadLibrary() - Bind all of the ports (if you are root, you can bind to ports <= 1024) - If we are root, invoke a "public native" method that Java maps to the C function contained in the shared library. The C function would contain the setuid() C call to change the Java process to a non-root user The above method effectively does the same thing as your native launcher. The only difference is that I thought it might be a may to get your setuid code into the standard Tomcat installations much sooner since my proposed approach is compatible with the existing Tomcat configuration and startup. I think the only changes to support my proposed approach in your native code are the following: - Add a "public static native" method in DaemonLoader.java - Create a DaemonLoader.h file using javah - Implement the setuid() calls for the function defined in DaemonLoader.h in DaemonLoader.c. Specifically, I could just move the child process' code in the checkuser function here so that there is not duplication of code. - Add compiling and linking of DaemonLoader.c into a shared library that the Java System.loadLibrary() call can handle. - Add calling of this "public static native" method from Tomcat's StandardService.initialize() method (i.e. after all ports have been bound). > > Also, if you need to do some callbacks from Java into our native C code, the > easiest thing is to register those right after invoking CreateJavaVM in JNI > (and it works), rather than relying on an external library... > I was thinking that once we have the above method implemented, we could try replacing the existing scripts with the native launchers. At that point, the System.loadLibrary() call in Tomcat could be removed since the native launcher could register the JNI C function that the "public native" method maps to. What do you think of the above approach? Thanks, Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Pier, Pier Fumagalli wrote: > > "unique process"??? It's a DYLD "NSAddModule" call to the JVM library, and > CreateJavaVM is called CreateJavaVMImpl... Doesn't look that "unique"... It is unique if you want Java code to invoke a C function via JNI. On Mac OS X, you need to name the shared library *.jnilib instead of *.dylib if you want to invoke a "public native" Java method so that System.loadLibrary() will work. The use of NSAddModule works fine but is only accessible via C code with exists only in the parent process. Once you are with Tomcat (i.e. binding ports as root), you are limited to accessing C functions via System.loadLibrary() and invoking the "public native" Java method. Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Remy, Remy Maucherat wrote: > jsvc and the Daemon code don't use the normal Bootstrap class, but rather > use BootstrapService, which is the one which implements the Service/Daemon > interface. This shouldn't call StandardServer.await, but rather will only > call the start and stop method. > > So doing the setuid change during the daemon init method should work, since > that's where the connectors are initialized. > > Or did I get something wrong ? await() is invoked in the Catalina.start() method. So, if you start standalone (as Unix /etc/rc.d scripts do), Tomcat will invoke Catalina.start(). Patrick _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: > > That would be after all connectors have opened the ports, but before _any_ > user code gets executed ( including the context init which trigers loading > of on-startup servlets ). In Tomcat 4.x, the last port opened is in StandardServer.await() - this is the shutdown port. The bad news is that all of the connectors are started before this call. Hence, I suspect that there is, currently, a small window for user code to get executed before the setuid would be called in StandardServer.await(). Looks like the Tomcat 4.x code in Catalina.start() will need to be reworked. However, after a quick review of the code, I don't think it is that much work. All of the connectors bind to their ports in their initialize() method and no user code, AFAIK, is executed in this method. After all connectors are intialized(), only then are the connectors started. So, I am thinking that all I need to do is move the shutdown port binding out of StandardServer.await() and into StandardServer.initialize(). Since StandardServer.initialize() invokes initialize() on all of the connectors, I can put the setuid code at the end of the StandardServer.initialize() method. Of course, this is how I think it will work so I definitely need to try it out. Maybe later this week I will have some time to try this out and make sure that it actually works. Thanks, Patrick -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: > > On Tue, 19 Feb 2002, Patrick Luby wrote: > > My point was that after you drop the root priviledges, there's no way > to get them back. > > I just double checked the manual, at least on linux. Hmmm. I picked this up from the Solaris man pages. It is probably best for me to focus my efforts on finding a good place in Tomcat 4.x to setuid to a non-root user like Apache does instead of pursuing this probably platform specific use of setuid. -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Henri, There should be no requirement for Tomcat to start as root. However, some may want to run Tomcat on a port < 1024. In such cases, you need to start as root but most site admins want the process to setuid to a non-root user for security reasons. Patrick GOMEZ Henri wrote: > > >Well, of course the process would have to be started as root > >and the setuid to a > >non-root user happens at the start of the process. Then, the > >JNI calls allow you > >to invoke setuid to switch back to the "saved uid" which is > >root (since that is > >the uid of the parent process). The only issue that think that may be > >problematic is multi-threading since all threads get switched > >back to root momemtarily. > > Did there is a reason to have Tomcat 3.3/4.0 started as root ? > > Since they listen on port > 1024, there is really no need for > them to be run as root. > > But for site admins task, having a signal handling in Tomcat is > a real need to handle task like log rotate for example. > > +1000 to have such interface in TC 3.3/4.0 > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: > If you have the time, writing this code as part of j-t-c/jk/native2/jni > would be great :-) There are many things still missing there, like in-process > support for 4.x and build procedure for other platforms ( we have > ant-based support for libtool, win, netware - not sure if Mac supports > libtool ). > Mac OS X has libtool, it is just the location of the JNI libraries at link time and the need to create a shared library with a .jnilib extension (instead of a .dylib extension like regular shared libraries :-( ). These should be fairly minor. > It's better to write the native code using APR, it avoids all the ifdefs > and system specific code, and it's tested already in apache. > I agree, I remember all of the special #ifdefs for the location of all of the headers for Mac OS X. > > Costin > -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Costin, [EMAIL PROTECTED] wrote: > > How easy would it be if that was possible ? For both hackers and > developers :-) If we keep this as a "public static void" method, these could be used by any codebase (as long as they pulled in the .jar and shared library files). > > Changing the uid to root is certainly impossible AFAIK ( at least on > unix, on NT everything is possible, but I hope not this one ). > Well, of course the process would have to be started as root and the setuid to a non-root user happens at the start of the process. Then, the JNI calls allow you to invoke setuid to switch back to the "saved uid" which is root (since that is the uid of the parent process). The only issue that think that may be problematic is multi-threading since all threads get switched back to root momemtarily. The reason I am proposing this tricky approach is that, at least in Tomcat 4.x, the ServerSocket binding is not all in one place in the code or, AFAIK, right at the beginning of main(). Hence, it looks like it will be impractical to do all of the socket binding and then setuid to the non-root user without moving a lot of code around. I will continue to look at this, however, because of the threading issue . > The other part is possible and I think it's a very good solution. My only worry here is how much resistance there would be for native executables to launch Tomcat and/or other tools. Of course, one could also launch Java directly so maybe this will make this idea more palatable. > > Costin > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Jean-Frederic, jean-frederic clere wrote: > That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native). > Where is the chmod()? > The idea of making setuid() and setgid() from the JVM is also possible - I will > try it - I was thinking that since all ServerSocket binding is that we could implement this as a static native method so that both Tomcat 3.x and 4.x could load the shared library and invoke the calls as close as possible to the actual point that a ServerSocket object binds to the socket. In Tomcat 4.x, I believe that this point is in the createSocket() method of each ServerSocketFactory class. If you don't have time, let me know and I can try this later this week. BTW, I have access to Linux, Solaris, and Mac OS X machines (the latter from my last job porting StarOffice to Mac OS X). So let me know where I can help out as I am intimately familiar with the unique process of getting JNI code to link on Mac OS X. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _____ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Pier, Hmmm. I could only find the setuid() calls in the parent process that launches Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat could use to temporarily switch the user back to root immediately before binding a ServerSocket object and then switching the user back immediately after. Maybe that code already exists somewhere else? If so, let me know where it is and I will definitely use it. BTW, I like the native startup executable that you wrote. I made a proposal to this list last week about replacing our many shell scripts (which are causing alot of nasty problems on Windows) with a launcher that uses properties files to launch Tomcat or the other related tools. I had originally thought about having a Java read the properties which would then launch Tomcat. However, you native code, especialy with its support for signals and chrooting may be a better option. Sure, I would need the native code to read some properties files to get classpath and other configurable items, but then I could directly invoke Java to run the Tomcat classes. Thanks, Patrick Pier Fumagalli wrote: > > "Patrick Luby" <[EMAIL PROTECTED]> wrote: > > > Remy, > > > > This is great news! > > > > I scanned through the Unix code and noticed that it uses the chmod'ing > > executables with setuid bits instead of performing a JNI call to the setuid() > > and seteuid() C functions before and after binding of a ServerSocket (i.e. the > > place you should need root access if you are binding to ports 1 through 1024). > > This type of approach eliminates the need for a controller and slave process. > > Then it's not my code... My code was written using setuid() and seteuid()... > Actually, the copy I have here also supports CHROOTING of the whole JVM > process, and real/effective group switching (as we say in Italy, "'na botte > de fero"). > > Pier > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [Daemon] New commons component
Remy, This is great news! I scanned through the Unix code and noticed that it uses the chmod'ing executables with setuid bits instead of performing a JNI call to the setuid() and seteuid() C functions before and after binding of a ServerSocket (i.e. the place you should need root access if you are binding to ports 1 through 1024). This type of approach eliminates the need for a controller and slave process. If there is interest out there, I can work up a proposal for implementing this type of setuid functionality. I has been a year or two since I did my last JNI coding, but I should be able to dig up some setuid code that I have done in the past. Thanks, Patrick Remy Maucherat wrote: > > Hi, > > I've added a new component to the commons subproject (in the sandbox), which > is designed to allow Java programs to run as native operating system daemons > (services under Windows NT). > Because of its nature, this component contains a significant amount of > native code. > > This component API and Unix code was developed by Pier Fumagalli as part of > the Tomcat 4 project, but is fully generic and not tied in any way to > Tomcat, so other server side applications may find it useful. > > The NT service code and related utilities were written by Jean-Frederic > Clere. > > Thanks, > Remy > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Java home autodiscovery add-on
Henri,
GOMEZ Henri wrote:
> Yes bin/setclasspath.sh does many things and could be used.
>
> My advice it that the name is too generic and should be renamed
> when you install TC 3.x/4.x in a FHS way, ie execs in
> /usr/bin, datas in /var/tomcat4 or /usr/share/tomcat4.
>
> May be renamed to setcatalinacp.sh ?
I must admit that have all these *.sh files hanging around in the bin directory
annoys even me even though I created them. I have been thinking about (but never
enough time to implement) getting rid of these scripts entirely and replacing
them with a small Java class that does the following:
- The standard scripts, e.g. catalina.sh consist only of:
Resolve true location of $0 (existing code already does this)
Find java (almost any will do for this script)
java -classpath `basedir "$0"` \
org.apache.catalina.launcher.Launch "${@}"
- This new "Launch" class then can parse both the command line arguments and
a new properties file (e.g. conf/tomcat.properties) to figure out all of the
stuff that is currently in the scripts as environment variables (e.g.
classpath, JAVA_HOME, CATALINA_OPTS, System properties, etc. After parsing
all the command line arguments and properties (which are currently done by
the scripts), this "Launch" class would fork another Java process with the
real $JAVA_HOME that the user has configured with all of the applicable
classpath, System properties, and command line arguments.
So what advantage is there to this? Although there is no change in the
functionality of the scripts, it would solve some of the following problems:
1. Windows has many problems in its handling of environment variables such as
%0 is always meaningful, some versions don't allow an '=' in an environment
variable value (particularly vexing for Java programs), some versions have
limited environment space, the 'for' command cannot handle paths with spaces
in them, etc. Using the above method, I have made the "Launch" do the work
that the script is doing now.
Since Java has not problems with the above when values are put in properties
file, a lot of these Windows problems go away. More important, we would now
have a _platform_independent_ way to configure settings for Tomcat since
Java properties don't require quoting or other items that are different on
Windows and Unix (even paths can be represented in a platform independent
manner if we so choose).
2. If implemented properly, the "Launch" class can use any Java found in your
path to bootstrap itself (OK, I will need at least Java 1.1). I can use a
JRE or JDK. Since "Launch.class" would invoke the real Java that I want to
use based on a property in the "conf/tomcat" properties file, this means
that we can bootstrap ourselves enough to:
- Provide more meaningful error messages than we can do with shell script
"if" and "echo" statements, particularly on Windows
- Provide (someday) localized error messages
- Use your Java searching algorithm for the "Find a java" part of each
script. This will allow us to bootstrap Java without causing changes to
which Java Tomcat actually runs with (i.e. Christopher's concern).
3. Last, but not least, make the launching of Tomcat completely independent
of the user's environment variables. The 2 big advantages that I see are:
- System integration is easier where environment variables are difficult
to use (e.g. you can put an icon in the Windows
Start->Programs menus, you can start Tomcat from /etc/inittab, you
can make Tomcat an NT service, etc.)
- On Windows, we can log stdout and stderr to a log file (like it already
does on Unix) instead of printing the output to a MS-DOS window (it is
difficult to redirect stderr in Windows batch scripts)
Is something worth pursuing for Tomcat 4? I am willing to volunteer the effort.
Especially since it will make the Windows startup more in line with the Unix
startup. For the record, I prefer Unix (any flavor) over Windows. However, I
realize that making Tomcat work reliably on Windows is important as there are a
lot of Windows users of Tomcat out there.
>
> Excellent information that -Djava.endorsed.dirs. Could you give us an
> example of it if for example we want to use xerces-2.0.0 and xalan-2.3.0
> with Sun JDK 1.4.0-rc1 ?
>
In theory, with the current -Djava.endorsed.dirs setting, you could drop your
favorite xerces and xalan jars in common/endorsed (HEAD branch) or common/lib
(4.0.2 branch) and Tomcat will use those. Of course, you need to remove any
existing conflicting jars from those locations first and Tomcat may have
problems with some XML parser versions (i.e. bugs in Tomcat or the XML parser).
Patrick
>
> --
> To u
Re: Java home autodiscovery add-on
Henri,
GOMEZ Henri wrote:
>
> What about adding this part in tomcat.sh (TC 3.3) and
> catalina.sh/jasper.sh to help them discover JAVA_HOME on
> at least Linux systems ?
>
> +if [ -z "$JAVA_HOME" ]; then
> +# Search for java in PATH
> +JAVA=`which java`
> +if [ -z "$JAVA" ] ; then
> +JAVA_BINDIR=`dirname ${JAVA}`
> +JAVA_HOME="${JAVA_BINDIR}/.."
> +fi
> +# Default clean JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/usr/lib/java" ] && JAVA_HOME="/usr/lib/java"
> +# Default IBM JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/opt/IBMJava2-13" ] && JAVA_HOME="/opt/IBMJava2-13"
> +# Another solution
> +[ -z "$JAVA_HOME" -a -d "/usr/java/jdk" ] && JAVA_HOME="/usr/java/jdk"
> +# madeinlinux JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/usr/local/jdk1.2.2" ] &&
>JAVA_HOME="/usr/local/jdk1.2.2"
> +# Kondara JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/usr/lib/java/jdk1.2.2" ] &&
>JAVA_HOME="/usr/lib/java/jdk1.2.2"
> +# Other commonly found JAVA_HOMEs
> +[ -z "$JAVA_HOME" -a -d "/usr/jdk1.2" ] && JAVA_HOME="/usr/jdk1.2"
> +# Default Caldera JAVA_HOME
> +[ -z "$JAVA_HOME" -a -d "/opt/java-1.3" ] && JAVA_HOME="/opt/java-1.3"
> +# Add other locations here
> +if [ -z "$JAVA_HOME" ]; then
> +echo "No JAVA_HOME specified in ${TOMCAT_CFG} and no java found, exiting..."
> +exit 1
> + fi
>
In Tomcat 4.0.2 and later, the above code would, I believe, fit into the
bin/setclasspath.sh script. This script, which already checks that your
$JAVA_HOME contains a java, javac, and jdb command, would extend that
functionality. BTW, setclasspath.sh is source by all the executable Unix scripts
(e.g. catalina.sh, jasper.sh, etc.).
Something that the Tomcat 3.3 developers may want to take a look at in
setclasspath.sh is the setting of $JAVA_ENDORSED_DIRS environment variable. This
variable is used to construct a "-Djava.endorsed.dirs=" argument when
invoking Java in each of teh executable Unix scripts (Windows does the same in
setclasspath.bat). This property provides the ability for Tomcat to override the
default parser and other special classes that are bundled with JDK 1.4 with the
classes that are bundled with Tomcat. This eliminates the need for users to need
to copy jar files into their JDK's lib/endorsed directory (which would affect
all other Java applications).
>
> => TC 4.0.2 conf :
>
> # tomcat /etc/rc.d script example configuration file
> # Use with version 1.07 of the scripts or later
>
> # Where your java installation lives
> # JAVA_HOME=/usr/java/jdk
> JAVA_HOME="/opt/IBMJava2-13"
>
> # You can pass some parameters to java
> # here if you wish to
> #JAVACMD="$JAVA_HOME/bin/java -Xminf0.1 -Xmaxf0.3"
>
> # Where your tomcat installation lives
> # That change from previous RPM where TOMCAT_HOME
> # used to be /var/tomcat.
> # Now /var/tomcat will be the base for webapps only
> CATALINA_HOME="@@@TCHOME@@@"
> JASPER_HOME="@@@TCHOME@@@"
> CATALINA_TMPDIR="@@@TCHOME@@@/temp"
>
> # What user should run tomcat
> TOMCAT_USER="tomcat4"
>
> # You can change your tomcat locale here
> #LANG=en_US
>
> # If you wish to further customize your tomcat environment,
> # put your own definitions here
> # (i.e. LD_LIBRARY_PATH for some jdbc drivers)
> # Just do not forget to export them :)
>
Many may not know this, but the above configuration file already exists in
Tomcat 4.0.2 and later. The configuration files are:
Windows: bin/setenv.bat
Unix: bin/setenv.sh
These files, by default, do not exist. However, if the user creates the above
file, they can override any environment variables that they like.
Something that the Tomcat 3.3 developers may want to take a look at is that each
Unix script in Tomcat 4.0.2 and later now resolves CATALINA_HOME independently
of the user's environment. This even works if the user invokes a softlink to the
script (pretty handy if you want to put a softlink to startup.sh and shutdown.sh
in /usr/bin on your system). This, and putting "JAVA_HOME=" in the
setenv.sh file, allows you to run Tomcat 4.0.2 or later from an /etc/rc.d or
/etc/inittab entry.
I have found a way to do this on Windows NT, 2000, and XP, but I have not had
enough time to refine it enough so that it won't break Windows 95, 98, and ME.
Patrick
--
_
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [4.0.2] [VOTE] Final release
[X] +1 - I support this release and I will help [ ] +0 - I support this release [ ] -0 - I do not support this release, because: Patrick Remy Maucherat wrote: > > Hi, > > I'd like to propose to release the current code in the 4.0 branch as Tomcat > 4.0.2 Final. > This release includes lots of bugfixes and improvements, especially in the > connectors area, which feature a dramatic improvement over what was > available in Tomcat 4.0.1 (this alone justifies making a release IMO, given > the amount of problems people are experiencing with the versions packaged in > Tomcat 4.0.1). > > The remaining should-fix bugs resolution will be postponed until a later > release. None of them were regression problems. > > The jakarta-tomcat and jakarta-tomcat-connectors repositories will be tagged > with "tomcat_402". The tomcat-warp / tomcat-util / warp source will be > synced with the sources in the jakarta-tomcat-connectors repository. > > The binaries will be packaged and be made available for verification by > other committers this week-end, and the release announcement will be posted > early next week (Monday seems appropriate). > As discussed yesterday, the binaries will include a minimal distribution > designed to be run on JDK 1.4. > > > [ ] +1 - I support this release and I will help > [ ] +0 - I support this release > [ ] -0 - I do not support this release, because: > > > > Remy > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] for catalina.bat
Stephen, You appear to be patching against a very old version of catalina.bat. Please take a look at the most recent version that has "setlocal" in it. Also, I noticed that you are eliminating the check for the NT when setting the _STARTJAVA environment variable. This is necessary as Windwos 95, 98, and ME cannot handle a "title" argument with start. For now, I vote -1 on the patch since this patch is incompatible with the current scripts. Patrick Stephen Paulsen wrote: > > --- catalina.orig.bat Fri Feb 1 13:39:47 2002 > +++ catalina.batFri Feb 1 13:47:34 2002 > @@ -26,11 +26,12 @@ > > rem - Save Environment Variables That May Change > -- > > -set _CATALINA_BASE=%CATALINA_BASE% > -set _CATALINA_HOME=%CATALINA_HOME% > -set _CLASSPATH=%CLASSPATH% > -set _CP=%CP% > - > +rem -- set _CATALINA_BASE=%CATALINA_BASE% > +rem -- set _CATALINA_HOME=%CATALINA_HOME% > +rem -- set _CLASSPATH=%CLASSPATH% > +rem -- set _CP=%CP% > +REM - Prevent environment changes from reaching outside this script > --- > +setlocal > > rem - Verify and Set Required Environment Variables > --- > > @@ -57,7 +58,8 @@ > > rem - Prepare Appropriate Java Execution Commands > - > > -if not "%OS%" == "Windows_NT" goto noTitle > +REM -- Why skip title for WinNT? `start "Your Title" ' works fine > on NT > +rem -- if not "%OS%" == "Windows_NT" goto noTitle > set _STARTJAVA=start "Catalina" "%JAVA_HOME%\bin\java" > set _RUNJAVA="%JAVA_HOME%\bin\java" > goto gotTitle > @@ -124,14 +126,16 @@ > rem - Restore Environment Variables > --- > > :cleanup > -set CATALINA_BASE=%_CATALINA_BASE% > -set _CATALINA_BASE= > -set CATALINA_HOME=%_CATALINA_HOME% > -set _CATALINA_HOME= > -set CLASSPATH=%_CLASSPATH% > -set _CLASSPATH= > -set CP=%_CP% > -set _LIBJARS= > -set _RUNJAVA= > -set _STARTJAVA= > +rem -- set CATALINA_BASE=%_CATALINA_BASE% > +rem -- set _CATALINA_BASE= > +rem -- set CATALINA_HOME=%_CATALINA_HOME% > +rem -- set _CATALINA_HOME= > +rem -- set CLASSPATH=%_CLASSPATH% > +rem -- set _CLASSPATH= > +rem -- set CP=%_CP% > +rem -- set _LIBJARS= > +rem -- set _RUNJAVA= > +rem -- set _STARTJAVA= > :finish > +REM ----- End the effect of `setlocal'. Restore the previous environment. > - > +endlocal > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.bat setclasspath.sh
All, I have added the required java.endorsed.dirs property to support JDK 1.4 (note: this has no effect with JDK 1.3). Although I verified that several servlets and JSP pages work without exceptions runing Tomcat both with and without -security, my testing was limited. So, those of you using JDK 1.4, please test it out and let me know if you find any problems. Thanks, Patrick [EMAIL PROTECTED] wrote: > > patrickl02/01/30 15:01:50 > > Modified:catalina/src/bin setclasspath.bat setclasspath.sh > Log: > Set java.endorsed.dirs property to common/lib so that the XML parser in common/lib >overrides the parser bundled with JDK 1.4. This behavior is needed for Tomcat to >behave under JDK 1.4 like it currently behaves in JDK 1.3 > > Revision ChangesPath > 1.2 +2 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat > > Index: setclasspath.bat > === > RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- setclasspath.bat 15 Jan 2002 02:55:38 - 1.1 > +++ setclasspath.bat 30 Jan 2002 23:01:50 - 1.2 > @@ -1,7 +1,7 @@ >rem --- >rem Set CLASSPATH and Java options >rem > -rem $Id: setclasspath.bat,v 1.1 2002/01/15 02:55:38 patrickl Exp $ > +rem $Id: setclasspath.bat,v 1.2 2002/01/30 23:01:50 patrickl Exp $ >rem --- > >rem Make sure prerequisite environment variables are set > @@ -31,7 +31,7 @@ >set JAVA_OPTS= > >rem Set the default -Djava.endorsed.dirs argument > -set JAVA_ENDORSED_DIRS= > +set JAVA_ENDORSED_DIRS=%BASEDIR%\bin;%BASEDIR%\common\lib > >rem Set standard CLASSPATH >rem Note that there are no quotes as we do not want to introduce random > > > > 1.2 +2 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh > > Index: setclasspath.sh > === > RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- setclasspath.sh 15 Jan 2002 02:55:38 - 1.1 > +++ setclasspath.sh 30 Jan 2002 23:01:50 - 1.2 > @@ -1,7 +1,7 @@ ># - ># Set CLASSPATH and Java options ># > -# $Id: setclasspath.sh,v 1.1 2002/01/15 02:55:38 patrickl Exp $ > +# $Id: setclasspath.sh,v 1.2 2002/01/30 23:01:50 patrickl Exp $ ># - > ># Make sure prerequisite environment variables are set > @@ -30,7 +30,7 @@ >JAVA_OPTS= > ># Set the default -Djava.endorsed.dirs argument > -JAVA_ENDORSED_DIRS= > +JAVA_ENDORSED_DIRS="$BASEDIR"/bin:"$BASEDIR"/common/lib > ># Set standard CLASSPATH >CLASSPATH="$JAVA_HOME"/lib/tools.jar > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Craig, "Craig R. McClanahan" wrote: > > Patrick, the Tomcat 4.0.x equivalents of "$CATALINA_HOME/shared/classes" > and "$CATALINA_HOME/shared/lib" are "$CATALINA_HOME/classes" and > "$CATALINA_HOME/lib", respectively. You'll need the "lib" directory as > well in the 4.0 branch. > I have "$CATALINA_HOME/lib" in the jasper.* scripts in the tomcat_40_branch and use "$CATALINA_HOME/share/lib" in the HEAD branch. However, the jasper.* scripts haven't had the "classes" directory in their CLASSPATH for some time now. Are these needed by the Jasper compiler? If so, I will add them. Thanks, Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: OUT OF ENVIRONMENT SPACE
Ratnesh, >From your error, you are probably using Windows 95, 98, or ME. If so, you need to add the following line to your autoexec.bat file and reboot your machine: SHELL=C:\COMMAND.COM /E:4096 /P Also, remove any existing "SHELL=" lines from that file. BTW, this is clearly a support question and such questions, in the future, should be posted to the [EMAIL PROTECTED] list. This list is for development issues, not support questions. Patrick Ratnesh Dubey wrote: > > After setting the variables for TOMCAT_HOME and JAVA_HOME I am still getting > the error for "Out of environment space". I have tried the following: > 1. Increase the memory for startup.bat and shutdown.bat. > 2. I tried to increase the memory for MSDOS prompt but got an error for > faulty directory path. > I was wondering how I could get rid of it. This is an emergency please > advise ASAP! > Thanks > Ratnesh > > >From: [EMAIL PROTECTED] > >Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: cvs commit: jakarta-tomcat-4.0/jasper build.xml > >Date: 29 Jan 2002 02:42:25 - > > > >craigmcc02/01/28 18:42:25 > > > > Modified:.BUILDING.txt build.properties.sample > >catalina build.xml > >jasper build.xml > > Log: > > Make it possible to build the HEAD branch of Tomcat 4 against the newest > > Xerces 2.0.0beta4 distribution (which uses two files, > >"xmlParserAPIs.jar" > > and "xercesImpl.jar"), or against an older distribution (which uses one > > file, "xerces.jar"). The choice of which implementation to use is > >defined > > by setting one or the other of the following sets of properties: > > > > * For Xerces 1.3.1 up through and including 2.0.0beta3, > > set "xerces.jar" to point to the full pathname of that file. > > > > * For Xerces 2.0.0beta4 or later, set "xmlParserAPIs.jar" and > > "xercesImpl.jar" to point to the full pathnames of the > > corresponding files. > > > > If you have both sets of properties defined (which will be common if you > > are building lots of packages that depend on a "xerces.jar" property), > >the > > 2.0.0beta4 (or later) version of Xerces will be the one used for the > >Tomcat > > build, and will also be the parser that is copied in to the common/lib > > directory. > > > > At the moment, I would lean against porting this mechanism to the 4.0.2 > > release, because it appears we will release 4.0.2 before Xerces 2.0 is > > finalized. IMHO, Tomcat 4.0.2 should be built against, and include, the > > stable Xerces 1.4.4 release. > > > > Revision ChangesPath > > 1.23 +13 -2 jakarta-tomcat-4.0/BUILDING.txt > > > > Index: BUILDING.txt > > === > > RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v > > retrieving revision 1.22 > > retrieving revision 1.23 > > diff -u -r1.22 -r1.23 > > --- BUILDING.txt24 Jan 2002 15:31:44 - 1.22 > > +++ BUILDING.txt29 Jan 2002 02:42:25 - 1.23 > > @@ -1,4 +1,4 @@ > > -$Id: BUILDING.txt,v 1.22 2002/01/24 15:31:44 remm Exp $ > > +$Id: BUILDING.txt,v 1.23 2002/01/29 02:42:25 craigmcc Exp $ > > > > > > Building The Tomcat 4.0 Servlet/JSP Container > > @@ -74,7 +74,7 @@ > > it can be used with the
Re: [4.0.2] Bug list
Remy, Can I add integrate of the wrapper script from the HEAD branch to the list? The scripts should be fully compatible with the 4.0.2 branch code and they provide a few of the features noted in the documentation but missing from Windows: - Running in debug mode - Running in jwpda mode - Running with spaces in any of the path names I realize the 4.0.2 branch is really only doing maintenance work now, but it would be nice to put these scripts in if the opportunity arises (i.e. a 4.0.3 release comes out at some point). This also resolves Bugzilla bug 6108. Thanks, Patrick Remy Maucherat wrote: > > > On Tue, 29 Jan 2002, Kevin Seguin wrote: > > > > > 5647 has a patch associated with it that looks pretty good. > > > > > > i'm not even sure i understand 5483 yet :) > > > > There are 2 issues: > > - extracting the language from the Accept-Language: header. > > That should be implemented in tomcat ( and the servlet container ) - > > as with the charset detection, that's at a higher level than the > > connector. > > > > - serving the 'right' page based on the accept-language header. > > I believe there is a patch for 3.x, not sure if it was ever ported. > > In the context of Apache+tomcat, all static files will support > > the language header, using the apache convention and settings. > > I'm not sure this is the same as the standalone impl ( apache > > is based on extensions, index.html.en, while in 3.x it's based > > on dirs en/index.html - but I haven't checked ). > > Regadless of what's happening for static pages, there is no > > rule defined for jsps AFAIK, the jsp itself should use one of the > > existing taglibs or whatever to get the right language. > > > > A workaround - for jsps - is to use the header directly. For static > > files apache should deal with that without problems. > > > > A bigger problem, which is not easy to fix in jk1.x, is charset > > detection and setting, especially for the jni connector. That's going > > to improve a lot in jk2 and o.a.jk, almost the same code used > > for 3.3 will be used there too. > > > > I would mark this bug as LATER for now. > > Ok, thanks for the detailed explanation. I'll post it in bugzilla, and mark > the bug as LATER. > > Thanks, > Remy > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
[VOTE] New Committer: Manveen Kaur
All, I would like to propose Manveen Kaur as a committer. She has provided a significant number of patches for the adminstration webapp and I think her contributions will be a big benefit to Tomcat. Please vote, Thanks, Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [PATCH] for jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
Adrian, ¡Muchas gracias! Acabo de comitar tu patch. Patrick Adrian Almenar wrote: > > Its just a patch for better understanding in spanish. > > Cheers, > > Adrian Almenar > Systems & Development Department > Conectium Limited > > --- > Name: >ApplicationResources_es.properties.diff >ApplicationResources_es.properties.diffType: unspecified type >(application/octet-stream) > Encoding: quoted-printable > >Part 1.3Type: Plain Text (text/plain) -- _________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [VOTE] New Watchdog Committer: Ryan Lubke
+1 Patrick "Craig R. McClanahan" wrote: > > NOTE: I'm posting this here because Watchdog was originally contributed > to Apache along with Tomcat, and the Tomcat developer community will be > substantially helped by Ryan's proposed efforts. > > I would like to nominate Ryan Lubke ([EMAIL PROTECTED]) as a committer on > the Watchdog project. Ryan works on the servlet and JSP compliance tests > for J2EE servers, and has volunteered to bring the Watchdog tests up to > date with respect to testing for Servlet 2.3 and JSP 1.2 compliance. This > will assist Tomcat developers in ensuring that Tomcat stays compliant with > these specifications, as well as other container developers. > > Over the past few weeks, Ryan has posted several patches and improved > tests here (on TOMCAT-DEV). I'd like him to be able to commit these > directly. > > Votes, please? > > Craig McClanahan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
