Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 9/12/02 23:51 Pier Fumagalli [EMAIL PROTECTED] wrote: Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha! :-) Correction to self... Not 24 pages... 24 notes... (Ok, I have an eyesight test tomorrow morning at 10:20 in SOHO... I know, I know...) ROFL. All of them got fixed aeons ago, and are for *all* releases of Tomcat; a few with JSPs source disclosure (and caused by the servlet container core, not Jasper), some others in the core. BTW, the search engine is a bit stupid, there's a lot less than 24 reports total ... Unbundling Jasper wouldn't help. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jeanfrancois Arcand wrote: OK, seems I don't have any supports to stay with my -1 (seems nobody care about the AdminTool argument :-)). So I will change my mind and vote 0. You don't have to justify anything for that vote, you know ;-) BTW, all of Pier arguments are just false. Don't get fooled by the noise. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 9/12/02 23:58 Costin Manolache [EMAIL PROTECTED] wrote: But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. I swear that _LOVE_ my mates... My friend Tonia, who's apparently better than me in getting out old posts, actually _FOUND_ it! :-) Thank you :-) And for your own viewing pleasure, that's it... (OK, it didn't have the [PROPOSAL] tag, but the wording was in there, c'mon, be flexible! :-) Yes, ok, that's so true... I also vented the idea that _MAYBE_ (but maybe) someone could have reimplemented the Standard* classes, but WHAT THE HELL? All I said I wanted was (quote myself) more or less what Jon does for Scarab... I said that IN JUNE... JUNE for damn sake... And somewhere along this thread when it after degenerated in the usual flame war that always happens when something needs to be done you said If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. And now _I_ am the idiot who makes false statements... Damn... I _knew_ I had a reason to be upset... Tonia, thanks, I owe you two favours for this one (next time I'm in the US!) Pier Original Message Subject: Re: 5.0 proposal Date: Mon, 24 Jun 2002 21:49:51 +0100 From: Pier Fumagalli [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Pier Fumagalli wrote: That's why counts where not right on my side of the border... I don't recall vetoing the proposal... I just complained vehemently that I'd prefer to see 4.0 out of the door and stable rather than a 4.1 and a 5.0... 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4. 4.1 is getting close - and it should be more stable and better than 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3. And 6.0 will probably be better than 5.0. If you are interested in maintaining and improving 4.0.4 - just volunteer as release manager for the branch, you have my +1 on it. I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and kiddies would start crying their butts off because they don't have the manager application, or JSP support :) But if anyone is interested I'd like to explore the opportunity of a Tomcat-HA (high-availability or hard-edition), based on 4.0 without the crap in there, and straightening out the request-response model... Simply, take the Catalina classes, and remove piles of useless stuff (more or less what Jon does for Scarab, but to a greater degree, maybe even reimplementing some of the Standard* classes). I remember perfectly, and this Tomcat-HA was a complete joke. You proposed a new implementation of the Catalina classes, which doesn't make sense given the current Tomcat state (empty promises again, like what we ended up with mod_webapp, which was *the* main reason for many people not to adopt Tomcat 4.x). Here, Costin is proposing a new distribution based on the same binary. Huge difference. Like the httpd, I'd prefer having a full distribution of all safe (yes, Jasper is safe) and generally useful modules. Experienced users can tweak the configuration to their liking, and it is easy to do, but the beginners get an easy to run environment which does what they need (and obviously a lot more, since you'd want the distribution to fill the needs of 95% of users). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
remm2002/12/10 00:43:21
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
Log:
- getCoyoteRequest needs to be used here (JK expects a Coyote Request,
not the facade).
- Fix bug 15201.
Revision ChangesPath
1.13 +6 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CoyoteAdapter.java20 Oct 2002 22:48:49 - 1.12
+++ CoyoteAdapter.java10 Dec 2002 08:43:21 - 1.13
@@ -307,7 +307,8 @@
// Set the SSL properties
if( request.isSecure() ) {
- res.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,request.getRequest());
+ res.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
+ request.getCoyoteRequest());
//Set up for getAttributeNames
request.getAttribute(Globals.CERTIFICATES_ATTR);
request.getAttribute(Globals.CIPHER_SUITE_ATTR);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyotePrincipal.java CoyoteAdapter.java
remm2002/12/10 00:44:05
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
Added: coyote/src/java/org/apache/coyote/tomcat5
CoyotePrincipal.java
Log:
- Port patch.
- Some code seemed to be missing.
Revision ChangesPath
1.6 +20 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- CoyoteAdapter.java26 Nov 2002 11:06:23 - 1.5
+++ CoyoteAdapter.java10 Dec 2002 08:44:05 - 1.6
@@ -281,8 +281,22 @@
// Parse cookies
parseCookies(req, request);
- // Set the SSL properties
- res.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,request.getRequest());
+// Set the SSL properties
+ if( request.isSecure() ) {
+ res.action(ActionCode.ACTION_REQ_SSL_ATTRIBUTE,
+ request.getCoyoteRequest());
+ //Set up for getAttributeNames
+ request.getAttribute(Globals.CERTIFICATES_ATTR);
+ request.getAttribute(Globals.CIPHER_SUITE_ATTR);
+ request.getAttribute(Globals.KEY_SIZE_ATTR);
+ }
+
+// Set the remote principal
+String principal = req.getRemoteUser().toString();
+if (principal != null) {
+request.setUserPrincipal(new CoyotePrincipal(principal));
+}
+
}
1.1
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyotePrincipal.java
Index: CoyotePrincipal.java
===
/*
* $Header:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyotePrincipal.java,v
1.1 2002/12/10 08:44:05 remm Exp $
* $Revision: 1.1 $
* $Date: 2002/12/10 08:44:05 $
*
*
*
* 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:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package
DO NOT REPLY [Bug 15201] - ClassCastException in JkCoyoteHandler.action() with SSL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15201 ClassCastException in JkCoyoteHandler.action() with SSL [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 08:47 --- Fixed in CVS. 4.1.17 will include the fix (great timing, this would have been a must-fix issue, and a serious problem if it had ended in a stable build). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 7:27 AM, Remy Maucherat [EMAIL PROTECTED] wrote: I'd really like to avoid the proliferation of too many distributions. I don't agree with that. There is nothing wrong with giving users choices. There is many things something wrong with many distributions : - Users may be puzzled by seeing too many tomcat distributions. - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 7:32 AM, Henri Gomez [EMAIL PROTECTED] wrote: What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. That does not make me happy. You are missing my point. Read the subject line of this message. I read YOUR SUBJECT LINE, and that's why I feel that a common distribution with modules could be the solution. The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. All we need is a more modular approach of TC 5, which should be able to load modules (JMX/JASPER) if available in classpath. If you take a look at how decent packaging tools like rpm/debian works, they are able to install a PRIMARY PACKAGE and OPTIONAL PACKAGES. For your purpose, scarab for example, you could only stay with the bare minimum TC 5, without installing the rest of TC 5. What about ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... I didn't understand the problem with the admin/manager tools, since they aren't mandatory and very easy to desactivate. If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... JSP ? Pier (a _user_ now) And that's sad. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 8:21 AM, Remy Maucherat [EMAIL PROTECTED] wrote: People cannot agree on everything. Here, we're talking about relatively minor topics. This issue won't end up in a division of the community, but rather in one additional binary distribution based on the same codebase. I can live with that (well, as long as I'm not the one building them all ;-) ). If the lack of consensus spreads to more serious topics (like a 4.2.x branch), then I would agree it could be worrying. Finally, Remy is starting to see the light. All I'm seeing is that I shouldn't pay attention to your posts (I should have learnt that a while ago, I guess) ;-) Is that good enough for you ? I'd really like to avoid the proliferation of too many distributions. I don't agree with that. There is nothing wrong with giving users choices. Sorry, no. You should try to give users as few choices as possible, if you're targetting your software at a broad audience (looking at the download stats, Tomcat has that kind of audience). You never read Joel on software, I suppose ... On the other side of the scale, advanced users who know what they want should be able to tweak the software to the death (that's my opinion; Joel doesn't concieve software for advanced users, appatrently). Tomcat allows that. However, the golden rule is that normal people shouldn't have to care (of course, it's far from perfect, and Tomcat is still way to hard to use for the average Joe, but that's another story, and I believe we're working on it). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] New committer: Filip Hanik
I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Minimal or Modular it's up to you
There was many noise these days about making another release of tomcat (the minimal one covering only JSR154), and another proposal to make a modular Tomcat. It may be because my mother language is french, but I still didn't understand why Tomcat commiters didn't find an arrangement on these 2 proposals which GOES in the same direction. What Jon and Pier want is a minimal distribution of Tomcat 5. What Costin proposed is to make Tomcat 5 more modular, which is very similar to what make Apache HTTP server so successfull. Why didn't merge the both proposal ? - Make a Tomcat distribution which is composed of : - a minimal tomcat core - extension modules. People will be free to install the core, and the modules they want to use (JMX/JASPER/JNDI/JK2). Java is not so bad in introspection and class discovery and should be able to detect what is present and what could be activated. To mimic the HTTPD way, the server.xml could have entries likes these : IfModule JMX Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ /IfModule IfModule JK2 Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ /IfModule The goal will be : - make happy people who need a minimal distribution, for example those who want to embed it on low memory device. - make happy people who want to get the full artillery to play and experiment with. - and in fine attract 'modules' writers, à la HTTPD way, developpers which make Apache 1.x/2.x servers so widely used today. And of course, restore the consensus which was present till the TC 5.0 project was initiated by the commiters who previously spent many times developping each one THEIR OWN vision of servlet container (3.3/4.0). But we're in a real world and since commiters are after all humans, I politely recommand to people who do NOT REALLY WANT TO BE CONSTRUCTIVE and may restart a new Tomcat War, to try to convince others teams making others servlet implementation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 12:49 AM, Henri Gomez [EMAIL PROTECTED] wrote: - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? I already volunteered to manage the distribution that I propose. I have been doing distributions of servlet containers since you guys were in diapers. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 12:53 AM, Henri Gomez [EMAIL PROTECTED] wrote: The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. You are repeating my ideas that I have already said on the list. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
on 2002/12/10 1:19 AM, Henri Gomez [EMAIL PROTECTED] wrote: What Jon and Pier want is a minimal distribution of Tomcat 5. No. What I want is a distribution of a JSR 154 container with nothing more than the RI of JSR 154. Period. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 1:00 AM, Remy Maucherat [EMAIL PROTECTED] wrote: All I'm seeing is that I shouldn't pay attention to your posts (I should have learnt that a while ago, I guess) ;-) Is that good enough for you ? As Pier says: What-EVER! Sorry, no. You should try to give users as few choices as possible, if you're targetting your software at a broad audience (looking at the download stats, Tomcat has that kind of audience). You never read Joel on software, I suppose ... On the other side of the scale, advanced users who know what they want should be able to tweak the software to the death (that's my opinion; Joel doesn't concieve software for advanced users, appatrently). Tomcat allows that. However, the golden rule is that normal people shouldn't have to care (of course, it's far from perfect, and Tomcat is still way to hard to use for the average Joe, but that's another story, and I believe we're working on it). You admit Tomcat is to hard to use. The reason it is to hard to use is because it is bundled with a whole bunch of crap no one needs. I want to get rid of the crap and just let people download something simple. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
Jon Scott Stevens wrote: on 2002/12/10 1:19 AM, Henri Gomez [EMAIL PROTECTED] wrote: What Jon and Pier want is a minimal distribution of Tomcat 5. No. What I want is a distribution of a JSR 154 container with nothing more than the RI of JSR 154. Period. Ok, so just take the tomcat core and don't install/activate the jasper module. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
On 10/12/02 8:40 am, in article [EMAIL PROTECTED], Remy Maucherat [EMAIL PROTECTED] wrote: I remember perfectly, and this Tomcat-HA was a complete joke. You proposed a new implementation of the Catalina classes, which doesn't make sense given the current Tomcat state That's what I was asking... more or less what Jon does for Scarab, but to a greater degree, maybe even reimplementing some of the Standard* classes It's in the archives... Pier :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
On 10/12/02 8:57 am, in article [EMAIL PROTECTED], Henri Gomez [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: Pier (a _user_ now) And that's sad. Not apparently, as I am the reason why noone picked up Tomcat 4 :-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
On 10/12/02 8:40 am, in article [EMAIL PROTECTED], Remy Maucherat [EMAIL PROTECTED] wrote: Like the httpd, I'd prefer having a full distribution of all safe (yes, Jasper is safe) and generally useful modules. Experienced users can tweak the configuration to their liking, and it is easy to do, but the beginners get an easy to run environment which does what they need (and obviously a lot more, since you'd want the distribution to fill the needs of 95% of users). There is one big huge difference... Modules are DSOs, if you don't enable them in your httpd.conf, they don't get loaded, they don't get used Disabling all of them can be done by sed 's/^LoadModule/#LoadModule/g'. If you get a binary distribution... (which, btw, doesn't enable most of them, it just _ships_ them in the same bundle...) If you don't get a binary distribution, when I build, I have a lot of tiny --enable and --disable flags... I can _choose_ what to build, what to install, what goes on my machine... This doesn't happen with Tomcat and it SUCKS ASS. :-) Don't compare yourself to HTTPD, learn from them, that's the only thing you can do... :-) (suggestion from someone who has been around long enough). New signature! :-) Pier -- [...] mod_webapp, which was *the* main reason for many people not to adopt Tomcat 4.x - Remy MaucheratWorks for me - Pier Fumagalli -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 10/12/02 8:40 am, in article [EMAIL PROTECTED], Remy Maucherat [EMAIL PROTECTED] wrote: There is one big huge difference... Modules are DSOs, if you don't enable them in your httpd.conf, they don't get loaded, they don't get used Disabling all of them can be done by sed 's/^LoadModule/#LoadModule/g'. If you get a binary distribution... (which, btw, doesn't enable most of them, it just _ships_ them in the same bundle...) If you don't get a binary distribution, when I build, I have a lot of tiny --enable and --disable flags... I can _choose_ what to build, what to install, what goes on my machine... This doesn't happen with Tomcat and it SUCKS ASS. :-) Don't compare yourself to HTTPD, learn from them, that's the only thing you can do... :-) (suggestion from someone who has been around long enough). Yes, thanks. I don't see how the mechanism is very different from the Java CL and the Tomcat config files. If you don't enable features in conf/server.xml and conf/web.xml, then the classes (which comprises the modules) don't get loaded, and the code is never run. Not all classes get loaded by default, but all binaries are present. This also looks similar. However, there's no convinient way to script enabling/disabling features, but I think that's more because we use XML, and its free form syntax. Otherwise, for example: disable the Jasper module = remove stuff in conf/web.xml. New signature! :-) Great. [...] mod_webapp, which was *the* main reason for many people not to adopt Tomcat 4.x - Remy MaucheratWorks for me - Pier Fumagalli Lol. Yes, we all know webapp works for you (and hopefully other Solaris users). The problem is others. Couldn't you have tried to work with others anyway ? (I did try, and it didn't hurt that much; I don't think Tomcat got worse because of Bill's and Costin's contributions, quite the contrary actually) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
on 2002/12/10 1:46 AM, Henri Gomez [EMAIL PROTECTED] wrote: Ok, so just take the tomcat core and don't install/activate the jasper module. Exactly. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 10/12/02 8:40 am, in article [EMAIL PROTECTED], Remy Maucherat [EMAIL PROTECTED] wrote: Like the httpd, I'd prefer having a full distribution of all safe (yes, Jasper is safe) and generally useful modules. Experienced users can tweak the configuration to their liking, and it is easy to do, but the beginners get an easy to run environment which does what they need (and obviously a lot more, since you'd want the distribution to fill the needs of 95% of users). There is one big huge difference... Modules are DSOs, if you don't enable them in your httpd.conf, they don't get loaded, they don't get used Disabling all of them can be done by sed 's/^LoadModule/#LoadModule/g'. If you get a binary distribution... (which, btw, doesn't enable most of them, it just _ships_ them in the same bundle...) If you don't get a binary distribution, when I build, I have a lot of tiny --enable and --disable flags... I can _choose_ what to build, what to install, what goes on my machine... This doesn't happen with Tomcat and it SUCKS ASS. :-) It's exactly what SHOULD BE DONE in a modular approach of TC 5. A small core with essential functionalities, and a bunch of modules, which will live in modules dir or activated if module-xxx.xml found in conf directory of tomcat. Don't compare yourself to HTTPD, learn from them, that's the only thing you can do... :-) (suggestion from someone who has been around long enough). I learn HTTPD everyday, and yesterday I even correct mod_webapp for Apache 2.0 ! New signature! :-) Pier nananere -- [...] mod_webapp, which was *the* main reason for many people not to adopt Tomcat 4.x - Remy MaucheratWorks for me - Pier Fumagalli -- 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]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 12:53 AM, Henri Gomez [EMAIL PROTECTED] wrote: The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. You are repeating my ideas that I have already said on the list. Yes but add the ability to activate/include modules, which is the Costin idea ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 12:49 AM, Henri Gomez [EMAIL PROTECTED] wrote: - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? I already volunteered to manage the distribution that I propose. I have been doing distributions of servlet containers since you guys were in diapers. Jon, you're a little younger than me so, 'du respect'. BTW, we're not discussing here what has be done in the past but what should be done in the future. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Martin Algesten wrote: This is the soundest idea I've heard so far. Multiple distributions sounds like disaster area to me. I currently think it is hard enough for a new user to decide Tomcat3/Tomcat4.x/Tomcat5 when presented with the choices. If there in addition to that is Tomcat4 lite, Tomcat4 all Tomcat5 lite disaster, don't go there. I want one distribution with --enable --disable for source compilation and if I choose binary I can edit the config files (server.xml or whatever) to remove the options I don't need. Exactly like httpd (sort of)... I really cannot believe I could agree with you on something ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
This is the soundest idea I've heard so far. Multiple distributions sounds like disaster area to me. I currently think it is hard enough for a new user to decide Tomcat3/Tomcat4.x/Tomcat5 when presented with the choices. If there in addition to that is Tomcat4 lite, Tomcat4 all Tomcat5 lite disaster, don't go there. I want one distribution with --enable --disable for source compilation and if I choose binary I can edit the config files (server.xml or whatever) to remove the options I don't need. Exactly like httpd (sort of)... M -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 10:35 To: Tomcat Developers List Subject: Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 ) It's exactly what SHOULD BE DONE in a modular approach of TC 5. A small core with essential functionalities, and a bunch of modules, which will live in modules dir or activated if module-xxx.xml found in conf directory of tomcat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] More Content-Type problems with 304 responses (Tomcat3.3.1)
Hello...
I had a problem a while ago with If-Modified-Since responses 304 always
set the Content-Type to text/plain which consequently pollutes
web-caches that updates their cached entries with the new Content-Type.
E.g. if we request a GIF, the content type in the cache will the first
time be set to image/gif, if a subsequent If-Modified-Since request
makes the cache revalidate against it source Tomcat and tomcat says 304
Not Modified and Content-Type: text/plain, the cache will update its
cached entry to have the wrong content type.
The bug fix that time was to make sure Tomcat 3.3.1 does not set the
content type on a 304 response.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13662
This works as long as tomcat is not behind an Apache 1.3.27 server. That
apache server has got a DefaultType directive which is the type to use
for a requested resource does not have a type.
Well, the patch mentioned above just removed the type for 304 responses,
and consequently apache adds its default type, which arguably is wrong
in apache, but we can do a minor fix it in tomcat to get better
interoperability.
Basically it is fine with the http spec to set the Content-Type in a 304
response as long as it is the correct type (e.g. calling a gif a gif).
The patch submitted moves the check content type block to be before
the answer 304 response block. Which means we always set the content
type, even on a 304 response, but it will be the correct type.
Martin
--- StaticInterceptor.java-2002-11-29 Fri Nov 29 10:06:18 2002
+++ StaticInterceptor.java Tue Dec 10 11:18:12 2002
@@ -323,6 +323,22 @@
}
File file = new File( absPath );
+
+ // Moved to before 304 check since apache 1.3.27 always needs a
+ // Content-Type in order to not set its own DefaultType directive.
+ // It really should be possible to turn this directive off
+ // in apache, but you can't. However always setting the Content-Type
+ // even on a 304 is still compliant with the http spec. As long as
+ // the Content-Type is correct. Martin Algesten, November 2002.
+String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
+
+ if (mimeType == null) {
+ mimeType = text/plain;
+ }
+ if( debug0) log( Serving + absPath);
+
+ res.setContentType(mimeType);
+
// If we are included, the If-Modified-Since isn't for us.
if( ! res.isIncluded() ) {
MessageBytes imsMB=req.getMimeHeaders().getValue(If-Modified-Since);
@@ -343,14 +359,6 @@
}
if( debug0) log( After paranoic checks = + absPath);
-String mimeType=ctx.getMimeMap().getContentTypeFor(absPath);
-
- if (mimeType == null) {
- mimeType = text/plain;
- }
- if( debug0) log( Serving + absPath);
-
- res.setContentType(mimeType);
res.setContentLength((int)file.length());
setDateHeader(res, Last-Modified, file.lastModified());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 10:55 To: Tomcat Developers List Subject: Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 ) I really cannot believe I could agree with you on something ;-) Remy I might have strong opinions and seize every possible opportunity to ram them down others throats, but I am not completely unreasonable ;-) M -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java
remm2002/12/10 04:39:18
Modified:catalina/src/share/org/apache/catalina/cluster
ReplicatedSession.java ReplicationStream.java
SerializablePrincipal.java SessionMessage.java
Log:
- Code cleanup part 2.
Revision ChangesPath
1.2 +143 -143
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster/ReplicatedSession.java
Index: ReplicatedSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster/ReplicatedSession.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ReplicatedSession.java5 Dec 2002 12:25:09 - 1.1
+++ ReplicatedSession.java10 Dec 2002 12:39:18 - 1.2
@@ -72,65 +72,81 @@
import org.apache.catalina.SessionListener;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.session.StandardSession;
+import org.apache.catalina.util.StringManager;
/**
* Title:Tomcat Session Replication for Tomcat 4.0 BR
* Description: A very simple straight forward implementation of
* session replication of servers in a cluster.BR
* This session replication is implemented live. By live
- * I mean, when a session attribute is added into a session on Node A
- * a message is broadcasted to other messages and setAttribute is
called on the replicated
- * sessions.BR
+ * I mean, when a session attribute is added into a session on
+ * Node A a message is broadcasted to other messages
+ * and setAttribute is called on the replicated sessions.BR
* A full description of this implementation can be found under
- * href=http://www.filip.net/tomcat/;Filip's Tomcat Page/aBR
+ * href=http://www.filip.net/tomcat/;Filip's Tomcat
+ * Page/aBR
*
- * Copyright:See apache license
- * Company: www.filip.net
- * @author a href=mailto:[EMAIL PROTECTED];Filip Hanik/a
- * @version 1.0 for TC 4.0
* Description:BR
- * The ReplicatedSession class is a simple extension of the StandardSession class
- * It overrides a few methods (setAttribute, removeAttribute, expire, access) and
has
- * hooks into the JGManager to broadcast and receive events from the cluster.BR
- * This class inherits the readObjectData and writeObject data methods from the
StandardSession
- * and does not contain any serializable elements in addition to the inherited ones
from the StandardSession
+ * The ReplicatedSession class is a simple extension of the StandardSession
+ * class. It overrides a few methods (setAttribute, removeAttribute, expire,
+ * access) and has hooks into the JGManager to broadcast and receive events
+ * from the cluster.BR
+ * This class inherits the readObjectData and writeObject data methods from
+ * the StandardSession and does not contain any serializable elements
+ * in addition to the inherited ones from the StandardSession.
*
+ * @author Filip Hanik
*/
public class ReplicatedSession
extends StandardSession {
-
-private transient Manager mManager = null;
-
+
+
+// - Instance Variables
+
+
+/**
+ * The string manager for this package.
+ */
+protected StringManager sm = StringManager.getManager(Constants.Package);
+
+
+private transient Manager manager = null;
+
+
+// Constructor
+
+
public ReplicatedSession(Manager manager) {
super(manager);
-mManager = manager;
+this.manager = manager;
}
-
+
+
+// - Public Methods
+
+
/**
* Update the accessed time information for this session. This method
* should be called by the context when a request comes in for a particular
* session, even if the application does not reference it.
+ *
* @param notify - if true the other cluster nodes will be notified
*/
public void access(boolean notify) {
super.access();
-//notify javagroups that session has been accessed
-if ( notify )
-{
+// Notify javagroups that session has been accessed
+if (notify) {
SessionMessage msg = new SessionMessage
-(mManager.getContainer().getName(),
+(manager.getContainer().getName(),
SessionMessage.EVT_SESSION_ACCESSED,
-
cvs commit: jakarta-tomcat-catalina/modules - Imported sources
remm2002/12/10 04:42:13 Log: - Moving cluster features to a modules folder. Status: Vendor Tag: ASF Release Tags: initial N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/Constants.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/LocalStrings.properties N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/SerializablePrincipal.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/SessionMessage.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/ReplicatedSession.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/ReplicationStream.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/package.html N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/JGCluster.java N jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/JGManager.java No conflicts created by this import -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cluster Constants.java JGCluster.java JGManager.java LocalStrings.properties package.html ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java
remm2002/12/10 04:44:05 Removed: catalina/src/share/org/apache/catalina/cluster Constants.java JGCluster.java JGManager.java LocalStrings.properties package.html ReplicatedSession.java ReplicationStream.java SerializablePrincipal.java SessionMessage.java Log: - Remove clustering from the main tree. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardWrapper.java
remm2002/12/10 04:47:05
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
- Mark servlets as unavailable when the wrapper is stopped (bug 15077).
Revision ChangesPath
1.44 +9 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- StandardWrapper.java 5 Dec 2002 09:12:37 - 1.43
+++ StandardWrapper.java 10 Dec 2002 12:47:05 - 1.44
@@ -852,7 +852,7 @@
if (jspWrapper != null)
actualClass = jspWrapper.getServletClass();
}
-
+
// Complain if no servlet class has been specified
if (actualClass == null) {
unavailable(null);
@@ -1333,6 +1333,8 @@
// Load and initialize an instance of this servlet if requested
// MOVED TO StandardContext START() METHOD
+setAvailable(0L);
+
}
@@ -1343,6 +1345,8 @@
* @exception LifecycleException if a fatal error occurs during shutdown
*/
public void stop() throws LifecycleException {
+
+setAvailable(Long.MAX_VALUE);
// Shut down our servlet instance (if it has been initialized)
try {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3888 WebappClassLoader: Lifecycle error : CL stopped --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 13:11 --- I tried to remove the directory examples of Tomcat, as suggested in this thread : same behaviour It seems like the lifecycle error occurs each time a .properties file is modified Hope this helps -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java
remm2002/12/10 05:33:22
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
Log:
- Part of the manager patch wasn't reverted (I don't know if it's a problem or not
in the real world; just playing it safe).
Revision ChangesPath
1.14 +13 -23
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ManagerBase.java 30 Nov 2002 12:43:14 - 1.13
+++ ManagerBase.java 10 Dec 2002 13:33:22 - 1.14
@@ -560,7 +560,18 @@
public Session createSession() {
// Recycle or create a Session instance
-Session session = createEmptySession();
+Session session = null;
+synchronized (recycled) {
+int size = recycled.size();
+if (size 0) {
+session = (Session) recycled.get(size - 1);
+recycled.remove(size - 1);
+}
+}
+if (session != null)
+session.setManager(this);
+else
+session = new StandardSession(this);
// Initialize the properties of the new session and return it
session.setNew(true);
@@ -572,6 +583,7 @@
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
+session.setId(sessionId);
}
/*
synchronized (sessions) {
@@ -583,28 +595,6 @@
return (session);
-}
-
-
-/**
- * Get a session from the recycled ones or create a new empty one.
- * The PersistentManager manager does not need to create session data
- * because it reads it from the Store.
- */
-public Session createEmptySession() {
-Session session = null;
-synchronized (recycled) {
-int size = recycled.size();
-if (size 0) {
-session = (Session) recycled.get(size - 1);
-recycled.remove(size - 1);
-}
-}
-if (session != null)
-session.setManager(this);
-else
-session = new StandardSession(this);
-return(session);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Filip Hanik
Remy Maucherat wrote: I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. +1 and +100 to have javagroups as a Jakarta project. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-catalina
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2002-12-10/jakarta-tomcat-catalina.html
Buildfile: build.xml
deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build
deploy-static:
deploy-catalina:
[echo] Target: Catalina - Deploy ...
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=true
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] --- Optional Libraries ---
[echo] dbcp.present=true
[echo] jaas.present=true
[echo] javamail.present=true
[echo] jmx.present=true
[echo] jsse.present=true
[echo] jta.present=true
[echo] junit.present=true
[echo] lang.present=${lang.present}
[echo] launcher.present=${launcher.present}
[echo] launcher.bootstrap.present=${launcher.bootstrap.present}
[echo] ldap.present=true
[echo] modeler.present=true
[echo] pool.present=true
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=true
[echo] regexp.jar.present=true
[echo] servlet-api.jar.present=true
[echo] xerces2.jars.present(except JDK 1.4+)=true
[echo] --- Optional JARs ---
[echo] dbcp.jar.present=true
[echo] jaas.jar.present=true
[echo] javamail.jar.present=true
[echo] jdbc20ext.jar.present=true
[echo] jmx.jar.present=true
[echo] jta.jar.present=true
[echo] junit.jar.present=${junit.jar.present}
[echo] modeler.jar.present=true
[echo] pool.jar.present=true
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.dbcp=true
[echo] compile.jaas=true
[echo] compile.javamail=true
[echo] compile.jmx=true
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=true
[echo] compile.junit=true
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.dbcp.jar=true
[echo] copy.jmx.jar=true
[echo] copy.launcher.jars=${copy.launcher.jars}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=true
[echo] copy.pool.jar=true
build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/bin
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/logs
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/work
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/temp
copy-dbcp.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
copy-jmx.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
copy-launcher.jars:
copy-modeler.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
copy-pool.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
copy-xerces2.jars:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed
build-static:
[copy] Copying 13 files to
Re: [GUMP] Build Failure - jakarta-tomcat-catalina
Index: gump.xml === RCS file: /home/cvspublic/jakarta-tomcat-catalina/gump.xml,v retrieving revision 1.10 diff -u -r1.10 gump.xml --- gump.xml8 Dec 2002 17:01:44 - 1.10 +++ gump.xml10 Dec 2002 13:57:51 - @@ -69,6 +69,7 @@ depend project=jakarta-ant/ depend project=xml-xerces/ depend project=jaf/ +depend project=javagroups/ depend project=javamail/ depend project=jmx/ depend project=jsse runtime=true/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina gump.xml
rubys 2002/12/10 06:12:41 Modified:.gump.xml Log: Add dependency on javagroups. (Is this descriptor being maintained, or should it move back to jakarta-alexandria?) Revision ChangesPath 1.11 +1 -0 jakarta-tomcat-catalina/gump.xml Index: gump.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/gump.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- gump.xml 8 Dec 2002 17:01:44 - 1.10 +++ gump.xml 10 Dec 2002 14:12:41 - 1.11 @@ -80,6 +80,7 @@ depend project=jakarta-servletapi-5-jsp/ depend project=jakarta-regexp/ option project=junit / +depend project=javagroups / work nested=build/server/classes/ home nested=build/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2002/12/10 07:00:52 Modified:.RELEASE-NOTES-4.1.txt Log: - Compile list of changes since 4.1.16. Revision ChangesPath 1.35 +46 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- RELEASE-NOTES-4.1.txt 7 Dec 2002 17:42:11 - 1.34 +++ RELEASE-NOTES-4.1.txt 10 Dec 2002 15:00:52 - 1.35 @@ -205,6 +205,9 @@ [4.1.15] Administration Webapp: Fix edition and creation of resource links. +[4.1.17] Default configuration: + Connector performance tweaks. + -- Catalina Bug Fixes: @@ -549,6 +552,17 @@ Conditional SSI enhancement, better emulation of Apache SSI, fix expression parser's handling of literals. +[4.1.17] #15086 + StandardWrapper: + Use the swallowOutput flag when unloading. + +[4.1.17] #15077 + StandardWrapper: + Mark servlets as unavailable when the wrapper is stopped. + +[4.1.17] CGIServlet, SSIServlet: + Fix for SSI normal configuration which invokes a CGI script. + Coyote Bug Fixes: @@ -629,6 +643,7 @@ Performance: Allow disabling upload timeout. [4.1.16] #14658 + Tomcat 4 Adapter CoyoteWriter: Performance: Full reimplementation of PrintWriter, fixing syncing as well as performance problems which occurred when a client abruplty disconnected. @@ -654,6 +669,36 @@ [4.1.16] JK2 HandlerRequest, JKCoyoteHandler: Lazy extraction of ssl certs to speed up jk/ajp13 when under SSL. + +[4.1.17] ActionCode: + Allow ActionCode to be used in a switch. + +[4.1.17] Response: + Fix Locale initilization to the default locale (en-us). + +[4.1.17] #15201 + Tomcat 4 Adapter: + Fix SSL attributes retrival with JK 2. + +[4.1.17] Tomcat 4 Adapter CoyoteResponse: + encodeURL does not encode session with empty URL (rfc2396). + +[4.1.17] HTTP/1.1 Http11Processor: + Fix incorrect setting of the socket timeout when the connection is + first established. + +[4.1.17] HTTP/1.1 Http11Processor: + Performance: Optimize soTimeout management when the upload timeout is + disabled. + +[4.1.17] PoolTcpEndpoint: + Reduce synchornization by not using connection object pooling. Also + minimize the amount of time during which no thread is listening on + the server socket. + +[4.1.17] ThreadPool: + Reduce synchronization by using an array of threads instead of + a Vector. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5735 HTTP connector running out of processors under heavy load --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 15:18 --- Glenn I was wondering, what is your hardware configuration, and what settings did you use for -Xmx? Also, did you run incgc? Thanks, Jim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Henri Gomez wrote: The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. Another solution can be seen in jboss. They do pack all the components ( or almost ), but also 3 config - minimal, default and all. One benefit is consistency. They do actually have 3-4 binary distributions - with the various servlet containers they support, but that's mostly because the integration of the container is not that integrated ( at least for tomcat ). I like very much Henri's proposal of fully-modular tomcat. The minimal would become JMX ( and modeler ). Then various profiles can be configured - by either a config file or placing some jars in a dir. You could have a JK-only ( for example jk + Axis - as a soap server ), or servlet only, or any other combination - all based on a simple config file. Yes - Jon will not be happy ( as far as I know Jon ) if jasper.jar is anywhere in the distribution, even if it is not used. I think the real argument against my minimal proposal is the current lack of the modular add-on mechanism. We almost have it, but something more is needed. There is one short-term solution - port the modules from 3.3 ( basically take the server/webapps/*/WEB-INF/lib and add this to the server loader, plus the config file ). Long term we can use JMX mlets to load the modules. We'll still have a single release of tomcat ( that doesn't mean we can't have more packages ). A single tomcat is quite important IMO - at least for our community. All we need is a more modular approach of TC 5, which should be able to load modules (JMX/JASPER) if available in classpath. If you take a look at how decent packaging tools like rpm/debian works, they are able to install a PRIMARY PACKAGE and OPTIONAL PACKAGES. For your purpose, scarab for example, you could only stay with the bare minimum TC 5, without installing the rest of TC 5. What about ? +1 Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Filip Hanik
Remy Maucherat wrote: I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. +1 Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 9/12/02 23:58 Costin Manolache [EMAIL PROTECTED] wrote: But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. I swear that _LOVE_ my mates... My friend Tonia, who's apparently better than me in getting out old posts, actually _FOUND_ it! :-) Thank you :-) And for your own viewing pleasure, that's it... Did your friend Tonia also found the 3 +1 votes ? Can someone explain to Pier that: 1. revolution can't be named tomcat-whatever 2. tomcat releases need a majority vote and at least 3 +1 votes. I didn't say you can't name your stuff jerry - or anything else. And my comment on naming it tomcat-high-availability was on the code that you done outside of tomcat. Do you still think it was ok to do so ? You can check with the board or whoever else in apache about that - or try to release an apache httpd - high-availability. There are many proposals for minimal tomcat - and one of the main divergences between 3.3 and 4.0 was the number of features. ( and it turned both position had positive and negative aspects - 4.0 features attracted probably more users than 3.3 minimality ). You may remember the 1M tomcat and the discussion about supporting J2ME with 3.3. So don't tell me you invented the minimal tomcat 4 months ago. When working in a community the behavior is quite important and does have an effect on others and yourself.( that's true for Jon - and for myself :-) One thing we learned is that a proposal needs more than some technical benefits - it also need buy-in from the community. That's how Apache works - if you don't know that. Costin (OK, it didn't have the [PROPOSAL] tag, but the wording was in there, c'mon, be flexible! :-) Yes, ok, that's so true... I also vented the idea that _MAYBE_ (but maybe) someone could have reimplemented the Standard* classes, but WHAT THE HELL? All I said I wanted was (quote myself) more or less what Jon does for Scarab... I said that IN JUNE... JUNE for damn sake... And somewhere along this thread when it after degenerated in the usual flame war that always happens when something needs to be done you said If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. And now _I_ am the idiot who makes false statements... Damn... I _knew_ I had a reason to be upset... Tonia, thanks, I owe you two favours for this one (next time I'm in the US!) Pier Original Message Subject: Re: 5.0 proposal Date: Mon, 24 Jun 2002 21:49:51 +0100 From: Pier Fumagalli [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Pier Fumagalli wrote: That's why counts where not right on my side of the border... I don't recall vetoing the proposal... I just complained vehemently that I'd prefer to see 4.0 out of the door and stable rather than a 4.1 and a 5.0... 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4. 4.1 is getting close - and it should be more stable and better than 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3. And 6.0 will probably be better than 5.0. If you are interested in maintaining and improving 4.0.4 - just volunteer as release manager for the branch, you have my +1 on it. I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and kiddies would start crying their butts off because they don't have the manager application, or JSP support :) But if anyone is interested I'd like to explore the opportunity of a Tomcat-HA (high-availability or hard-edition), based on 4.0 without the crap in there, and straightening out the request-response model... Simply, take the Catalina classes, and remove piles of useless stuff (more or less what Jon does for Scarab, but to a greater degree, maybe even reimplementing some of the Standard* classes). I can't veto as I don't really care how you want to spend your evenings and stuff... I don't think you can 'veto' a long term plan or release. AFAIK it's a majority vote. Veto in terms of -1ing it. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15239] New: - Creating new resource-link uses TYPE attribute value for NAME attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15239 Creating new resource-link uses TYPE attribute value for NAME attribute Summary: Creating new resource-link uses TYPE attribute value for NAME attribute Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: Minor Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When creating a new ResourceLink to a global DataSource, the Admin webapp creates the resource link using the value specified for TYPE for both TYPE and NAME attributes of the newly created element. Thus creating one link to a DataSource JDBC/Bob with name MyLinkToBob creates an element: ResourceLink global=JDBC/Bob name=javax.sql.DataSource type=javax.sql.DataSource/ The name MyLinkToBob is lost. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 2:36 AM, Henri Gomez [EMAIL PROTECTED] wrote: Yes but add the ability to activate/include modules, which is the Costin idea ;) Nope...Read my message with the ascii chart in it... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 7:30 AM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - Jon will not be happy ( as far as I know Jon ) if jasper.jar is anywhere in the distribution, even if it is not used. If Jasper is in there, then it isn't a (repeat) 'minimal JSR 154 only distribution.' -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans NamingResourcesMBean.java
remm2002/12/10 09:56:57
Modified:catalina/src/share/org/apache/catalina/mbeans
NamingResourcesMBean.java
Log:
- Fix creation of resource links.
- Fix bug 15239.
Revision ChangesPath
1.11 +6 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/NamingResourcesMBean.java
Index: NamingResourcesMBean.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/NamingResourcesMBean.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- NamingResourcesMBean.java 24 Jun 2002 21:11:42 - 1.10
+++ NamingResourcesMBean.java 10 Dec 2002 17:56:57 - 1.11
@@ -272,8 +272,8 @@
* @param resourceLinkName New resource link reference name
* @param type New resource link reference type
*/
-public String addResourceLink(String global, String resourceLinkName,
-String type) throws MalformedObjectNameException {
+public String addResourceLink(String resourceLinkName, String type,
+ String global) throws
MalformedObjectNameException {
NamingResources nresources = (NamingResources) this.resource;
if (nresources == null) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2002/12/10 10:02:50 Modified:.RELEASE-NOTES-4.1.txt Log: - Update release notes. Revision ChangesPath 1.36 +5 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- RELEASE-NOTES-4.1.txt 10 Dec 2002 15:00:52 - 1.35 +++ RELEASE-NOTES-4.1.txt 10 Dec 2002 18:02:49 - 1.36 @@ -700,6 +700,10 @@ Reduce synchronization by using an array of threads instead of a Vector. +[4.1.17] #15239 + NamingResourcesMBean: + Fix resource link creation. + Jasper Bug Fixes: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15239] - Creating new resource-link uses TYPE attribute value for NAME attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15239 Creating new resource-link uses TYPE attribute value for NAME attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 18:04 --- Fixed in CVS. This will be in 4.1.17. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15245] New: - 'milliseconds' should be localized.in Admin webapp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15245. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15245 'milliseconds' should be localized.in Admin webapp Summary: 'milliseconds' should be localized.in Admin webapp Product: Tomcat 4 Version: 4.1.16 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In Tomcat Adminstration Tool at connector.jsp (/server/webapps/admin/connector/), 'milliseconds' is hard coded. But there are more suitable expressions that stands for 1/1000 sec. in each language. So it should be localized. connector.jsp line: 108 controls:labelbean:message key=connector.connection.timeout/br (milliseconds) :/controls:label I think it should be : (bean:message key=connector.milliseconds/) :/controls:label and add the strings to 3 resource files at /server/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ AplicationResource_en.properties: (English) connector.milliseconds=milliseconds AplicationResource_es.properties: (Spanish) connector.milliseconds=milisegundos AplicationResource_ja.properties: (Japanese) connector.milliseconds=\u30df\u30ea\u79d2 NOTE: I don't know Spanish and got 'milisegundos' by a robot-translator. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources SaveResourceLinkAction.java
remm2002/12/10 10:12:40
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
SaveResourceLinkAction.java
Log:
- Fix bug 15239.
- Remove useless parameter.
Revision ChangesPath
1.5 +6 -8
jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveResourceLinkAction.java
Index: SaveResourceLinkAction.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveResourceLinkAction.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SaveResourceLinkAction.java 8 Nov 2002 11:32:51 - 1.4
+++ SaveResourceLinkAction.java 10 Dec 2002 18:12:40 - 1.5
@@ -170,15 +170,13 @@
// Perform an Add ResourceLink transaction
if (objectName == null) {
-String signature[] = new String[3];
+String signature[] = new String[2];
signature[0] = java.lang.String;
signature[1] = java.lang.String;
-signature[2] = java.lang.String;
-Object params[] = new Object[3];
+Object params[] = new Object[2];
params[0] = resourceLinkForm.getName();
params[1] = resourceLinkForm.getType();
-params[2] = resourceLinkForm.getGlobal();
String resourcetype = resourceLinkForm.getResourcetype();
String path = resourceLinkForm.getPath();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans NamingResourcesMBean.java mbeans-descriptors.xml
remm2002/12/10 10:12:51
Modified:catalina/src/share/org/apache/catalina/mbeans
NamingResourcesMBean.java mbeans-descriptors.xml
Log:
- Fix bug 15239.
- Remove useless parameter.
Revision ChangesPath
1.2 +6 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/NamingResourcesMBean.java
Index: NamingResourcesMBean.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/NamingResourcesMBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NamingResourcesMBean.java 18 Jul 2002 16:48:00 - 1.1
+++ NamingResourcesMBean.java 10 Dec 2002 18:12:51 - 1.2
@@ -272,8 +272,8 @@
* @param resourceLinkName New resource link reference name
* @param type New resource link reference type
*/
-public String addResourceLink(String global, String resourceLinkName,
-String type) throws MalformedObjectNameException {
+public String addResourceLink(String resourceLinkName, String type)
+throws MalformedObjectNameException {
NamingResources nresources = (NamingResources) this.resource;
if (nresources == null) {
@@ -289,7 +289,6 @@
resourceLink = new ContextResourceLink();
resourceLink.setName(resourceLinkName);
resourceLink.setType(type);
-resourceLink.setGlobal(global);
nresources.addResourceLink(resourceLink);
// Return the corresponding MBean name
1.15 +1 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml
Index: mbeans-descriptors.xml
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/mbeans-descriptors.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- mbeans-descriptors.xml8 Dec 2002 13:42:09 - 1.14
+++ mbeans-descriptors.xml10 Dec 2002 18:12:51 - 1.15
@@ -1701,9 +1701,6 @@
description=Add a resource link reference for this web application
impact=ACTION
returnType=void
- parameter name=global
- description=New resource reference global name
- type=java.lang.String/
parameter name=resourceLinkName
description=New resource reference name
type=java.lang.String/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Henri Gomez wrote: Yes but add the ability to activate/include modules, which is the Costin idea ;) Actually - I think it is your idea :-) ( well, now it makes a lot of sense - I'm in how didn't I think of it mode ). That means I will drop my minimal proposal, or at least rewrite it to be one profile in the normal distribution. Remy's arguments are also very valid. I think we can focus on 4 profiles: - JSR154 only - minimal ( JSR154 + JSR152 ) - default ( the current set of features ) - all The main technical problem is the class loader - we probably need to place most jars in a repository - but not in the loader - and use the manifest or config files to pick what we need. Again, the jmx model may help us. ( jboss solution is to just copy the files - which does makes sense in a way ) Jon - would that be reasonable middle-ground for you ? It gives you a JSR154-only profile, included in the main distribution. The downside is that jasper will still be included ( disabled and invisible in your profile - visible in all others ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer: Filip Hanik
+1 Larry -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 4:17 AM To: Tomcat Developers List Subject: [VOTE] New committer: Filip Hanik I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. He has my +1. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [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]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Remy Maucherat wrote: Martin Algesten wrote: This is the soundest idea I've heard so far. Multiple distributions sounds like disaster area to me. I currently think it is hard enough for a new user to decide Tomcat3/Tomcat4.x/Tomcat5 when presented with the choices. If there in addition to that is Tomcat4 lite, Tomcat4 all Tomcat5 lite disaster, don't go there. I want one distribution with --enable --disable for source compilation and if I choose binary I can edit the config files (server.xml or whatever) to remove the options I don't need. Exactly like httpd (sort of)... I really cannot believe I could agree with you on something ;-) Don't know what you two disagree on - but I think this is a very good point. Consider my minimal tomcat distribution dead - for now. I'm not sure about one distribution with --enable and --disable, but I think one distribution with different profiles ( and the option to create a profile that includes what you need and nothing else ) is the best choice. And it seems JMX plus some class loader magic plus some config can do that. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Filip Hanik
+1 Amy Remy Maucherat wrote: I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. He has my +1. 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]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 7:30 AM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - Jon will not be happy ( as far as I know Jon ) if jasper.jar is anywhere in the distribution, even if it is not used. If Jasper is in there, then it isn't a (repeat) 'minimal JSR 154 only distribution.' It'll be a JSR154 profile. And a Tomcat distribution. It's up to Sun to release JSR152 or JSR154 or whatever else - we develop tomcat. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Costin Manolache wrote: Henri Gomez wrote: Yes but add the ability to activate/include modules, which is the Costin idea ;) Actually - I think it is your idea :-) ( well, now it makes a lot of sense - I'm in how didn't I think of it mode ). That means I will drop my minimal proposal, or at least rewrite it to be one profile in the normal distribution. Remy's arguments are also very valid. I think we can focus on 4 profiles: - JSR154 only - minimal ( JSR154 + JSR152 ) - default ( the current set of features ) - all The main technical problem is the class loader - we probably need to place most jars in a repository - but not in the loader - and use the manifest or config files to pick what we need. Again, the jmx model may help us. ( jboss solution is to just copy the files - which does makes sense in a way ) Big +1. There's an embryo of some configuration for the different CL, but it needs to get more powerful and flexible to support this. Copying files is bad, no question about it. Jon - would that be reasonable middle-ground for you ? It gives you a JSR154-only profile, included in the main distribution. The downside is that jasper will still be included ( disabled and invisible in your profile - visible in all others ). Hopefully reason will prevail. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java
remm2002/12/10 10:49:06
Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
Log:
- Fix incorrect servlet context initialization if the admin webapp recieves a
stop/start.
Revision ChangesPath
1.5 +8 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ServerLifecycleListener.java 14 Nov 2002 14:24:06 - 1.4
+++ ServerLifecycleListener.java 10 Dec 2002 18:49:06 - 1.5
@@ -247,7 +247,10 @@
// undocumented in MX4J, and reports exist in the MX4J bug DB that
// this doesn't work
-} else if (Context.RELOAD_EVENT.equals(event.getType())) {
+}
+
+if ((Context.RELOAD_EVENT.equals(event.getType()))
+|| (Lifecycle.START_EVENT.equals(event.getType( {
// Give context a new handle to the MBean server if the
// context has been reloaded since reloading causes the
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] mod_jk - chroot and user issues
I recently created a port of mod_jk-1.2.1 for OpenBSD and needed to make
some minor patches to mod_jk. OpenBSD 3.2 has Apache 1.3.26 configured as
ServerType standalone, to chroot to /var/www and run as user www by default.
This combination requires a few minor patches so that mod_jk will continue
to work after an Apache restart.
Both jk_set_worker_file and jk_set_log_file need to call
ap_server_strip_chroot to account for the path changes while chrooted.
The log file is initially created as user/group = root/daemon, but after a
restart Apache is running as www/www so it doesn't have permission to reopen
the log file. In order to have the log file continue working after a
restart, I patched jk_init. Instead of setting conf-log to NULL when
jk_open_file_logger fails, I set it to main_log. In other words, if the new
log file can't be opened it falls back to the already open one. Other
possible solutions are to change the user and/or group of the log file to
match the Apache User/Group directives, however if the admin changes the log
file name the open will still fail unless the directory has write access for
the Apache User/Group.
I made some Makefile.in patches to allow the object files to be built
outside the source tree. I think these patches will work for other archs/OSs
too.
Please review and consider commiting. Please cc me if replying. Thank You.
-Kurt
$OpenBSD$
--- apache-1.3/mod_jk.c.origTue Nov 26 12:26:25 2002
+++ apache-1.3/mod_jk.c Mon Dec 9 01:59:18 2002
@@ -734,6 +734,8 @@ static const char *jk_set_worker_file(cm
/* we need an absolut path */
conf-worker_file = ap_server_root_relative(cmd-pool,worker_file);
+ap_server_strip_chroot(conf-worker_file,0);
+
if (conf-worker_file == worker_file)
conf-worker_file = ap_pstrdup(cmd-pool,worker_file);
@@ -762,6 +764,8 @@ static const char *jk_set_log_file(cmd_p
/* we need an absolut path */
conf-log_file = ap_server_root_relative(cmd-pool,log_file);
+ap_server_strip_chroot(conf-log_file,0);
+
if ( conf-log_file == log_file)
conf-log_file = ap_pstrdup(cmd-pool,log_file);
@@ -1742,7 +1746,7 @@ static void jk_init(server_rec *s, ap_po
/* Open up log file */
if(conf-log_file conf-log_level = 0) {
if(!jk_open_file_logger((conf-log), conf-log_file, conf-log_level)) {
-conf-log = NULL;
+conf-log = main_log;
} else {
main_log = conf-log;
}
$OpenBSD$
--- common/Makefile.in.orig Thu Dec 5 11:30:30 2002
+++ common/Makefile.in Thu Dec 5 11:32:29 2002
@@ -19,7 +19,7 @@ include list.mk
JAVA_INCL=-I @JAVA_HOME@/include -I @JAVA_HOME@/include/@OS@
CFLAGS=@apache_include@ @CFLAGS@ ${APXSCFLAGS} ${APXSCPPFLAGS} ${JAVA_INCL}
-include ../scripts/build/rules.mk
+include @top_srcdir@/scripts/build/rules.mk
JK=./
$OpenBSD$
--- apache-1.3/Makefile.in.orig Tue Nov 26 12:26:25 2002
+++ apache-1.3/Makefile.in Fri Dec 6 05:30:44 2002
@@ -1,6 +1,8 @@
## configure should make the Makefile out of this file.
-
+srcdir=@srcdir@
+top_srcdir=@top_srcdir@
+VPATH=@srcdir@
APXS=@APXS@
OS=@OS@
JAVA_HOME=@JAVA_HOME@
@@ -17,14 +19,13 @@ libexecdir=${APACHE_DIR}/libexec
JK_DIR := ..
BUILD_DIR = ${JK_DIR}/../build/jk/apache13
-#VPATH=.:../common
APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
JK=../common/
-JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
+JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
-APACHE_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I../common
+APACHE_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
# Compile commands
JK_CFLAGS = $(JK_INCL) $(JAVA_INCL) $(APACHE_CFLAGS)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2002/12/10 11:40:08 Modified:.tomcat.nsi Log: - Fix uninstaller logic. Revision ChangesPath 1.20 +2 -6 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- tomcat.nsi6 Dec 2002 09:17:07 - 1.19 +++ tomcat.nsi10 Dec 2002 19:40:08 - 1.20 @@ -25,6 +25,7 @@ !define MUI_CUSTOMPAGECOMMANDS !define MUI_UNINSTALLER + !define MUI_UNCONFIRMPAGE !define TEMP1 $R0 !define TEMP2 $R1 @@ -83,11 +84,6 @@ ; Main registry key InstallDirRegKey HKLM SOFTWARE\Apache Group\Tomcat\5.0 - - ;Uninstaller - !define MUI_UNCUSTOMPAGECOMMANDS - !insertmacro MUI_UNPAGECOMMAND_CONFIRM - !insertmacro MUI_UNPAGECOMMAND_INSTFILES !insertmacro MUI_RESERVEFILE_INSTALLOPTIONS !insertmacro MUI_RESERVEFILE_SPECIALINI -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
iplanet4.1 + ajp13 + tomcat 4.0.x
I am trying to integrate iplanet4.1 + ajp13 + tomcat 4.0.x on a solaris platform. I cant find any documentation on this on the jakarta.apache.org site. The only document I found was for the windows platform. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/neshowto.html Can someone please send any documentation on how to do this for the solaris platform. I found that this can be done from the link http://archives2.real-time.com/pipermail/tomcat-devel/2002-March/028580.html in the Tomcat Developers list . Regards, Suresh Venkatesan Solutions Support Vitria Technology, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15249] New: - FileLogger timestamp set to false or null is ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15249. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15249 FileLogger timestamp set to false or null is ignored Summary: FileLogger timestamp set to false or null is ignored Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am unable to remove the timestamps on Tomcat log files. If I change timestamp to false or remove the entry altogether, it continue to timestamp the log files. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/connector connector.jsp
amyroh 2002/12/10 12:41:48 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin ApplicationResources_en.properties ApplicationResources_es.properties ApplicationResources_ja.properties webapps/admin/connector connector.jsp Log: Fix 15245 - localize 'miliseconds' in admin. Revision ChangesPath 1.72 +1 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties Index: ApplicationResources_en.properties === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v retrieving revision 1.71 retrieving revision 1.72 diff -u -r1.71 -r1.72 --- ApplicationResources_en.properties22 Nov 2002 21:49:46 - 1.71 +++ ApplicationResources_en.properties10 Dec 2002 20:41:47 - 1.72 @@ -119,6 +119,7 @@ connector.address.ip=IP Address connector.redirect.portnumber=Redirect Port Number connector.min=Minimum +connector.milliseconds=milliseconds connector.max=Maximum connector.proxy.name=Proxy Name connector.proxy.portnumber=Proxy Port Number 1.61 +1 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties Index: ApplicationResources_es.properties === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v retrieving revision 1.60 retrieving revision 1.61 diff -u -r1.60 -r1.61 --- ApplicationResources_es.properties22 Nov 2002 21:49:46 - 1.60 +++ ApplicationResources_es.properties10 Dec 2002 20:41:47 - 1.61 @@ -120,6 +120,7 @@ connector.address.ip=Direcci\u00f3n IP connector.redirect.portnumber=N\u00fmero del puerto de redireccionamiento connector.min=M\u00ednimo +connector.milliseconds=milisegundos connector.max=M\u00e1ximo connector.proxy.name=Nombre del Proxy connector.proxy.portnumber=N\u00fmero de Puerto del Proxy 1.3 +1 -0 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_ja.properties Index: ApplicationResources_ja.properties === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_ja.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationResources_ja.properties10 Dec 2002 01:55:41 - 1.2 +++ ApplicationResources_ja.properties10 Dec 2002 20:41:47 - 1.3 @@ -119,6 +119,7 @@ connector.address.ip=IP\u30a2\u30c9\u30ec\u30b9 connector.redirect.portnumber=\u30ea\u30c0\u30a4\u30ec\u30af\u30c8\u30dd\u30fc\u30c8\u756a\u53f7 connector.min=\u6700\u5c0f +connector.milliseconds=\u30df\u30ea\u79d2 connector.max=\u6700\u5927 connector.proxy.name=\u30d7\u30ed\u30ad\u30b7\u540d connector.proxy.portnumber=\u30d7\u30ed\u30ad\u30b7\u30dd\u30fc\u30c8\u756a\u53f7 1.20 +1 -1 jakarta-tomcat-4.0/webapps/admin/connector/connector.jsp Index: connector.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/connector/connector.jsp,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- connector.jsp 24 Jul 2002 00:03:23 - 1.19 +++ connector.jsp 10 Dec 2002 20:41:48 - 1.20 @@ -105,7 +105,7 @@ controls:row labelStyle=table-label-text dataStyle=table-normal-text controls:labelbean:message key=connector.connection.timeout/br -(milliseconds) :/controls:label +(bean:message key=connector.milliseconds/) :/controls:label controls:data html:text property=connTimeOutText size=10/ /controls:data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp
amyroh 2002/12/10 12:43:54 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin ApplicationResources_en.properties ApplicationResources_es.properties ApplicationResources_ja.properties webapps/admin/connector connector.jsp Log: Port localization change from tomcat 4. Revision ChangesPath 1.7 +1 -0 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties Index: ApplicationResources_en.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- ApplicationResources_en.properties22 Nov 2002 22:24:56 - 1.6 +++ ApplicationResources_en.properties10 Dec 2002 20:43:54 - 1.7 @@ -119,6 +119,7 @@ connector.address.ip=IP Address connector.redirect.portnumber=Redirect Port Number connector.min=Minimum +connector.milliseconds=milliseconds connector.max=Maximum connector.proxy.name=Proxy Name connector.proxy.portnumber=Proxy Port Number 1.7 +1 -0 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties Index: ApplicationResources_es.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- ApplicationResources_es.properties22 Nov 2002 22:24:56 - 1.6 +++ ApplicationResources_es.properties10 Dec 2002 20:43:54 - 1.7 @@ -120,6 +120,7 @@ connector.address.ip=Direcci\u00f3n IP connector.redirect.portnumber=N\u00fmero del puerto de redireccionamiento connector.min=M\u00ednimo +connector.milliseconds=milisegundos connector.max=M\u00e1ximo connector.proxy.name=Nombre del Proxy connector.proxy.portnumber=N\u00fmero de Puerto del Proxy 1.3 +1 -0 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_ja.properties Index: ApplicationResources_ja.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_ja.properties,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationResources_ja.properties10 Dec 2002 01:56:36 - 1.2 +++ ApplicationResources_ja.properties10 Dec 2002 20:43:54 - 1.3 @@ -119,6 +119,7 @@ connector.address.ip=IP\u30a2\u30c9\u30ec\u30b9 connector.redirect.portnumber=\u30ea\u30c0\u30a4\u30ec\u30af\u30c8\u30dd\u30fc\u30c8\u756a\u53f7 connector.min=\u6700\u5c0f +connector.milliseconds=\u30df\u30ea\u79d2 connector.max=\u6700\u5927 connector.proxy.name=\u30d7\u30ed\u30ad\u30b7\u540d connector.proxy.portnumber=\u30d7\u30ed\u30ad\u30b7\u30dd\u30fc\u30c8\u756a\u53f7 1.3 +1 -1 jakarta-tomcat-catalina/webapps/admin/connector/connector.jsp Index: connector.jsp === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/connector/connector.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- connector.jsp 24 Jul 2002 20:57:26 - 1.2 +++ connector.jsp 10 Dec 2002 20:43:54 - 1.3 @@ -105,7 +105,7 @@ controls:row labelStyle=table-label-text dataStyle=table-normal-text controls:labelbean:message key=connector.connection.timeout/br -(milliseconds) :/controls:label +(bean:message key=connector.milliseconds/) :/controls:label controls:data html:text property=connTimeOutText size=10/ /controls:data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15245] - 'milliseconds' should be localized.in Admin webapp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15245. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15245 'milliseconds' should be localized.in Admin webapp [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 20:56 --- Fixed in CVS. This will be in 4.1.17. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15251] New: - tomcat server serving blank pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15251. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15251 tomcat server serving blank pages Summary: tomcat server serving blank pages Product: Tomcat 4 Version: 4.1.16 Platform: Sun OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After a certain time of use, the Tomcat server starts serving blank pages for all our jsps. The only way out is to restart the server. Our application is a large Struts based application using Oracle databases. I don't have a test case to reproduce the bug since it is very sporadic. But it happens at least every day in our test environment. It does not seems to appear on the same page neither. The bug was probably introduced after 4.1.14, since our application works perfectly with that version. Also, it is not platform specific, I saw it on Windows 2000 too. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
costin 2002/12/10 13:29:59
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Compiler.java
Log:
A small fix that may help resolving the ant test failures and
debug the compile errors related with javac.
In case of a compile error we'll log the config used for
compilation ( classpath, etc ) as well as the full exception thrown
by ant while compiling.
Revision ChangesPath
No revision
No revision
1.18.2.8 +25 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.18.2.7
retrieving revision 1.18.2.8
diff -u -r1.18.2.7 -r1.18.2.8
--- Compiler.java 24 Oct 2002 11:55:57 - 1.18.2.7
+++ Compiler.java 10 Dec 2002 21:29:59 - 1.18.2.8
@@ -249,6 +249,10 @@
String javaFileName = ctxt.getServletJavaFileName();
String classpath = ctxt.getClassPath();
+StringBuffer info=new StringBuffer();
+info.append(Compile: javaFileName= + javaFileName + \n );
+info.append(classpath= + classpath + \n );
+
String sep = System.getProperty(path.separator);
StringBuffer errorReport = new StringBuffer();
@@ -269,12 +273,15 @@
String pathElement = tokenizer.nextToken();
File repository = new File(pathElement);
path.setLocation(repository);
+info.append( cp= + repository + \n);
}
// Initializing sourcepath
Path srcPath = new Path(project);
srcPath.setLocation(options.getScratchDir());
+info.append( work dir= + options.getScratchDir() + \n);
+
// Configure the compiler object
javac.setEncoding(javaEncoding);
javac.setClasspath(path);
@@ -282,21 +289,28 @@
javac.setSrcdir(srcPath);
javac.setOptimize(! ctxt.getOptions().getClassDebugInfo() );
+info.append(srcDir= + srcPath + \n );
+
// Set the Java compiler to use
if (options.getCompiler() != null) {
javac.setCompiler(options.getCompiler());
+info.append(compiler= + options.getCompiler() + \n);
}
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
includes.setName(ctxt.getJspPath());
+info.append(include=+ ctxt.getJspPath() + \n );
+BuildException error=null;
try {
synchronized(javacLock) {
javac.execute();
}
} catch (BuildException e) {
success = false;
+error=e;
+info.append(Exception compiling + e.toString() + \n);
}
errorReport.append(logger.getReport());
@@ -316,8 +330,16 @@
if (!success) {
Constants.jasperLog.log( Error compiling file: + javaFileName +
+ errorReport,
Logger.ERROR);
+Constants.jasperLog.log( Info: + info.toString(),
+ Logger.ERROR);
+if( error != null ) {
+Constants.jasperLog.log( Exception: , error );
+error.printStackTrace();
+}
+
errDispatcher.javacError(errorReport.toString(), javaFileName,
pageNodes);
}
+
}
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2002/12/10 13:33:36
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Fixed dynamic attribute bug for XML syntax.
Revision ChangesPath
1.32 +7 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JspDocumentParser.java5 Dec 2002 17:56:43 - 1.31
+++ JspDocumentParser.java10 Dec 2002 21:33:35 - 1.32
@@ -169,6 +169,10 @@
// Use the default (non-validating) parser
SAXParserFactory factory = SAXParserFactory.newInstance();
+ factory.setNamespaceAware(true);
+ // Preserve xmlns attributes
+ factory.setFeature(http://xml.org/sax/features/namespace-prefixes;,
+true);
// Configure the parser
SAXParser saxParser = factory.newSAXParser();
1.67 +2 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- messages.properties 9 Dec 2002 23:27:03 - 1.66
+++ messages.properties 10 Dec 2002 21:33:36 - 1.67
@@ -289,7 +289,7 @@
jsp.error.unknown_attribute_type=Unknown attribute type ({1}) for attribute {0}.
jsp.error.jspelement.missing.name=Mandatory attribute 'name' missing in jsp:element
jsp.error.xmlns.redefinition.notimplemented=Internal error: Attempt to redefine
xmlns:{0}. Redefinition of namespaces is not implemented.
-jsp.error.could.not.add.taglibraries=Could not add tag one or more libraries.
+jsp.error.could.not.add.taglibraries=Could not add one or more tag libraries.
jsp.error.duplicate.name.jspattribute=The attribute {0} specified in the standard
or custom action also appears as the value of the name attribute in the enclosed
jsp:attribute
jsp.error.not.in.template={0} not allowed in a template text body.
jsp.error.badStandardAction=The action is not a recognizable standard action.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
costin 2002/12/10 13:38:01
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
Port the fixes to main.
This adds more debug info on compiler errors.
Revision ChangesPath
1.42 +16 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- Compiler.java 8 Dec 2002 13:42:53 - 1.41
+++ Compiler.java 10 Dec 2002 21:38:00 - 1.42
@@ -318,6 +318,10 @@
StringBuffer errorReport = new StringBuffer();
boolean success = true;
+StringBuffer info=new StringBuffer();
+info.append(Compile: javaFileName= + javaFileName + \n );
+info.append(classpath= + classpath + \n );
+
// Start capturing the System.err output for this thread
SystemLogHandler.setThread();
@@ -328,11 +332,13 @@
// Initializing classpath
Path path = new Path(project);
path.setPath(System.getProperty(java.class.path));
+info.append( cp= + System.getProperty(java.class.path) + \n);
StringTokenizer tokenizer = new StringTokenizer(classpath, sep);
while (tokenizer.hasMoreElements()) {
String pathElement = tokenizer.nextToken();
File repository = new File(pathElement);
path.setLocation(repository);
+info.append( cp= + repository + \n);
}
if( log.isDebugEnabled() )
@@ -343,28 +349,36 @@
Path srcPath = new Path(project);
srcPath.setLocation(options.getScratchDir());
+info.append( work dir= + options.getScratchDir() + \n);
+
// Configure the compiler object
javac.setEncoding(javaEncoding);
javac.setClasspath(path);
javac.setDebug(ctxt.getOptions().getClassDebugInfo());
javac.setSrcdir(srcPath);
javac.setOptimize(! ctxt.getOptions().getClassDebugInfo() );
+info.append(srcDir= + srcPath + \n );
// Set the Java compiler to use
if (options.getCompiler() != null) {
javac.setCompiler(options.getCompiler());
+info.append(compiler= + options.getCompiler() + \n);
}
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
-includes.setName(ctxt.getJspPath());
+File f=new File( ctxt.getJspPath());
+
+includes.setName(f.getCanonicalPath());
+info.append(include=+ ctxt.getJspPath() + \n );
try {
synchronized(javacLock) {
javac.execute();
}
} catch (BuildException e) {
-log.error( Javac exception , e);
+log.error( Javac execption , e);
+log.error( Env: + info.toString());
success = false;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: [VOTE] minimal JSR 154 only distribution
I'm going to repost this message once again because it seems Remy and Costin didn't bother reading it the first time and are now essentially agreeing to what I suggested below. What-EVER! -jon -- Forwarded Message From: Jon Scott Stevens [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] Date: Mon, 09 Dec 2002 01:16:20 -0800 To: tomcat-dev [EMAIL PROTECTED] Subject: Re: [VOTE] minimal JSR 154 only distribution What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. What do we really have to loose here? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] SPAM: Start SpamAssassin results SPAM: -109.30 hits, 5 required; SPAM: * -0.8 -- Found a In-Reply-To header SPAM: * -0.3 -- User-Agent header indicates a non-spam MUA (Entourage) SPAM: * 0.3 -- BODY: Asks you to click below SPAM: * -0.3 -- Long signature present (empty lines) SPAM: * -100.0 -- From: address is in the user's white-list SPAM: * -6.0 -- User is listed in 'whitelist_to' SPAM: * -0.2 -- Email came from some known mailing list software SPAM: * -2.0 -- AWL: Auto-whitelist adjustment SPAM: SPAM: End of SpamAssassin results -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: I'm going to repost this message once again because it seems Remy and Costin didn't bother reading it the first time and are now essentially agreeing to what I suggested below. What-EVER! What-EVER to you. Reading your posts is not my favorite activity - for this one I stoped at the first phrase ( a tree of downloads ). What Remy and Costin are agreeing on is one tomcat release that includes multiple profiles - so people can run jsr154 or minimal or default or all. Even if I would have passed this - the Java Server Faces part is clearly the end of your message for me ( and should have been the end of the conversation ). I don't know why you have the impression that I have to bother reading your messages. Costin -jon -- Forwarded Message From: Jon Scott Stevens [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] Date: Mon, 09 Dec 2002 01:16:20 -0800 To: tomcat-dev [EMAIL PROTECTED] Subject: Re: [VOTE] minimal JSR 154 only distribution What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. What do we really have to loose here? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 2:52 PM, Costin Manolache [EMAIL PROTECTED] wrote: What Remy and Costin are agreeing on is one tomcat release that includes multiple profiles - so people can run jsr154 or minimal or default or all. (repeat) Which is what I already suggested. I don't know why you have the impression that I have to bother reading your messages. Costin Because you respond to them. Geeez Costin. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
rant mode I don't know why people have the impression that they need support or some special motivation when voting on a proposal. Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. And I don't think including it in the minimal is a good idea either ( if it can run without it, then it shouldn't be in minimal ). The vote was about creating a separate distribution of tomcat with certain content. You can vote +1 or -1 if you want to influence the result, or -0 or +0 if you don't want to change the result, but still want to say you agree or not. If you had a bad dream about it last night or you feel it will confuse users or whatever - it doesn't matter, this is not a veto but a majority decision on a proposal. And a +1 doesn't mean ( in this case ) that you'll have to help. It has this meaning ( in tomcat at least ) only on the final vote to release. A +1 only means that you feel it is a good idea and will make tomcat better. Has everyone lost interest in tomcat and doesn't care what happens ? This open source stuff and majority vote and so on doesn't work if people don't participate. I can understand that we all have little time - but at least read the proposals ( marked with [VOTE] or [PROPOSAL] so you can set your mailer and ignore everything else ) and send your opinion. A simple +-1, +-0 is enough and shouldn't consume that much time. One concern I had about Jon's proposal is the tensions it may create among committers, and especially those that work or use jasper. If their answer is we don't give a damn about tomcat releases - then I'm wrong. My other concern is that users will be confused if they have N downloads to choose from, and our efforts on documenting and testing will be diluted if we have N releases each with 3 people working on them. Costin Jeanfrancois Arcand wrote: OK, seems I don't have any supports to stay with my -1 (seems nobody care about the AdminTool argument :-)). So I will change my mind and vote 0. -- Jeanfrancois Pier Fumagalli wrote: On 10/12/02 0:30 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Now, don't tell me that ALL that collection of cruft doesn't have a bug... It's just that we are lucky and noone found them yet (given enough eyes... Linus says)... I never say that and I will never says that. But I least I have try during the Security Audit to fix some of the obvious one. Still Tomcat is probably not enough secure (and will never be). My point is if you are aware of such obvious one, then let me know and I will fix them. You said (quote) Jasper/AdminTool/etc. are secure... That's a pretty bold statement. From my experience, security audits and stuff are all right, until someone doesn't call up at 3 AM saying the server is down because of a DOS... Nah, I don't like being woken up in the middle of the night... But I don't think Tomcat is more secure without JSP I know, I know, what I think you don't care :-) The bible (for us Sun customers, _your_ customers): http://wwws.sun.com/software/security/blueprints/#minimum Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology - Updated for the Solaris 8 Operating Environment - November 2000 - by Alex Noordergraaf Discusses the process of minimizing an installation of the Solaris Operating Environment. Mimimization is the process of removing all unnecessary components and services from the Solaris software to reduce system vulnerabilities. Also introduces a simple technique for replicating these types of installations across a large number of systems. _YOUR_ security folks tought me that... Go and talk to them, they're down in SCA-7 if I'm not wrong... Paranoia is an irreversible process for us on the line-of-fire. To sum up: rule of the thumb #3, less code, less bugs (you folks from Sun preach that all over your Solaris Blueprints stuff, I learnt it when your employer was paying my salary). Wow, didn't know that... I've missed the chance to work with you :-) Don't worry, you would have _hated_ working with me (and proudly keeping up my record of being the most hated freak on the planet). I should studies my Tomcat history and learn who is doing what, what biases he/she have, and then vote appropriatly. Oh, no, I got paranoid after I left Sun and started working on the other side of the barricade... Trying to use in production what I was coding earlier... :-) So, please, don¹t come up on a mailing list saying that is secure, just say that noone has found a bug yet, because that (and only that) is the truth... I agree my wording was not appropriate. Should say that in french next time :-) Pas de problemes (where are the accents on this keyboard?) Pier -- To unsubscribe, e-mail:
Re: [VOTE] minimal JSR 154 only distribution
Why not have one distribution of Tomcat but with an ant installer with different targets. The ant installer builds a layout of files for running tomcat based on the target. Then we only have one download (perhaps large) but with a variety of different installs. Some of the options could grab any distributions not included with the tomcat dist from remote sites. Some possible targets... soap-server servlet servlet-jsp standalone And many others. Perhaps with options to update an existing install. Regards, Glenn Costin Manolache wrote: Henri Gomez wrote: Yes but add the ability to activate/include modules, which is the Costin idea ;) Actually - I think it is your idea :-) ( well, now it makes a lot of sense - I'm in how didn't I think of it mode ). That means I will drop my minimal proposal, or at least rewrite it to be one profile in the normal distribution. Remy's arguments are also very valid. I think we can focus on 4 profiles: - JSR154 only - minimal ( JSR154 + JSR152 ) - default ( the current set of features ) - all The main technical problem is the class loader - we probably need to place most jars in a repository - but not in the loader - and use the manifest or config files to pick what we need. Again, the jmx model may help us. ( jboss solution is to just copy the files - which does makes sense in a way ) Jon - would that be reasonable middle-ground for you ? It gives you a JSR154-only profile, included in the main distribution. The downside is that jasper will still be included ( disabled and invisible in your profile - visible in all others ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 3:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Then we only have one download (perhaps large) but with a variety of different installs. Right now, I have to specially distribute Tomcat for Scarab. Instead, I want one small download that I can point people at and tell them to copy their scarab.war into. It should be a download which only contains code and data that Scarab requires (which is a minimal JSR 154 container). -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* -- Jeanfrancois -jon
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 3:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Then we only have one download (perhaps large) but with a variety of different installs. Right now, I have to specially distribute Tomcat for Scarab. Instead, I want one small download that I can point people at and tell them to copy their scarab.war into. It should be a download which only contains code and data that Scarab requires (which is a minimal JSR 154 container). -jon Right. You need a distribution tailored for your use. Others may have slightly different dists they need. Where does it stop? Would we end up with 2-3 dozen different distributions? Tomcat can be used in so many different ways that it can be very difficult for those devs who vote to decide on how many dists there should be and what they should contain. A single distribution with the most used components which included ant with different install targets would be much more flexible. Those components not included with Tomcat could be installed by automating retrieval and installation from a remote site. This achieves your goal of being able to easily setup a servlet only instance of Tomcat _and_ meets the requirement of only having one distribution. The contentious issue would be what components are bundled with Tomcat and which can be installed but have to be retrieved from a remote site. Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15256] New: - problem with jk/build.xml isset element lines 383 389
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15256. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15256 problem with jk/build.xml isset element lines 383 389 Summary: problem with jk/build.xml isset element lines 383 389 Product: Tomcat 4 Version: 4.1.12 Platform: Sun OS/Version: Linux Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I can't build the jk connector on a sparc linux machine, ant fails with the message: BUILDIR/jk/build.xml:383 Class org.apache.tools.ant.taskdefs.condition.Not doesn't support the nested isset element I've tried commenting this out (and the one on line 389) but the build script is expected messages so fails anyway after that tried with a couple of jdk's 1.4.1 and 1.3.1 (both Blackdown) linux version is Debian running a 2.4.18 kernel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
costin 2002/12/10 16:38:29
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
Remove getCanonicalPath.
Revision ChangesPath
1.43 +1 -2
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- Compiler.java 10 Dec 2002 21:38:00 - 1.42
+++ Compiler.java 11 Dec 2002 00:38:29 - 1.43
@@ -367,9 +367,8 @@
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
-File f=new File( ctxt.getJspPath());
-includes.setName(f.getCanonicalPath());
+includes.setName( includes.setName(ctxt.getJspPath());
info.append(include=+ ctxt.getJspPath() + \n );
try {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
embedding tomcat SSL in java application
Hi, I am trying to embed a Tomcat inside our java application. I am able to start up tomcat on port 8080. However when i am trying to start up Tomcat with SSL on port 8443 i am unable to do so. I dont get any error on standard output being generated by tomcat.However when i go to the browser and type https://localhost:8443 nothing happens and it just tries to open the page. The code snippet is given. Here embedded is an instance of Embedded Class. Connector connector =embedded.createConnector(null, 8080, false); embedded.addConnector(connector); SSLServerSocketFactory sslSocket = new SSLServerSocketFactory(); sslSocket.setAlgorithm(RSA); sslSocket.setKeystoreFile(C:/src/bdna/conf/.keystore); Connector sslConnector = embedded.createConnector(null, 8443, true); sslConnector.setScheme(https); sslConnector.setSecure(true); sslConnector.setFactory(sslSocket); embedded.addConnector(sslConnector); what am i missing ? thanks abhijat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* -- Jeanfrancois Then I wonder what the heck Costin thinks he is talking about. But then again, I have been wondering that for years now. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 4:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Right. You need a distribution tailored for your use. Others may have slightly different dists they need. Where does it stop? Would we end up with 2-3 dozen different distributions? Tomcat can be used in so many different ways that it can be very difficult for those devs who vote to decide on how many dists there should be and what they should contain. The line is very clear where it stops: A JSR 154 only container and a JSR 154 + JSR 152 container. That is why I'm not asking for any 'external' stuff to be included in the Tomcat distribution. I don't want to blur the lines. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* No, you don't. You can just copy jasper-runtime.jar in WEB-INF/lib and you're done. At least that used to work in 3.3 - I don't see any reason it'll not work ( except maybe some bugs ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Costin Manolache wrote: Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* No, you don't. You can just copy jasper-runtime.jar in WEB-INF/lib and you're done. At least that used to work in 3.3 - I don't see any reason it'll not work ( except maybe some bugs ). Is Jasper = Runtime + Compiler (jasper-runtime.jar + jasper-compiler.jar)? I was under the impression that when we discuss about removing Jasper, it was both part. Not only the compiler partIf it's only the compiler part, then yes you can still run the Admin Tool. -- Jeanfrancois Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 4:59 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* No, you don't. You can just copy jasper-runtime.jar in WEB-INF/lib and you're done. At least that used to work in 3.3 - I don't see any reason it'll not work ( except maybe some bugs ). Costin Huh? jar -xvf jasper-runtime.jar created: META-INF/ extracted: META-INF/MANIFEST.MF created: org/ created: org/apache/ created: org/apache/jasper/ created: org/apache/jasper/logging/ created: org/apache/jasper/util/ created: org/apache/jasper/runtime/ created: org/apache/jasper/resources/ ... -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15258] New: - ajp13 socket listens on localhost by default
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15258 ajp13 socket listens on localhost by default Summary: ajp13 socket listens on localhost by default Product: Tomcat 4 Version: 4.1.16 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The 1.28 revision of jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java made by user mturk changes the behavior of a default Tomcat installation to listen on localhost:8009 instead of *:8009. +if (getAddress() == null) +setAddress(localhost); It took us several hours to track down. This change is UNDOCUMENTED and prevents configurations where the httpd server and tomcat reside on different hosts, because there's no legal way to listen on any address. Additionally, all the modified source lines contain DOS-style EOL characters. I strongly suggest reverting this patch before releasing 4.1.16. As a temporary workaround, you can have the connector listen on any address by adding address=0.0.0.0 in the configuration: Connector className=org.apache.coyote.tomcat4.CoyoteConnector address=0.0.0.0 port=8009 minProcessors=5 maxProcessors=75 enableLookups=false redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jeanfrancois Arcand wrote: Costin Manolache wrote: Jeanfrancois Arcand wrote: Jon Scott Stevens wrote: on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* No, you don't. You can just copy jasper-runtime.jar in WEB-INF/lib and you're done. At least that used to work in 3.3 - I don't see any reason it'll not work ( except maybe some bugs ). Is Jasper = Runtime + Compiler (jasper-runtime.jar + jasper-compiler.jar)? I was under the impression that when we discuss about removing Jasper, it was both part. Not only the compiler partIf it's only the compiler part, then yes you can still run the Admin Tool. Yes, jasper=runtime + compiler. Last time I checked ( and I know no particular reason why this wouldn't work now ) the runtime can be included in the container - or it can be included in WEB-INF/lib for each precompiled app. Jasper doesn't particulary care where the runtime is located. A JSP is translated to a servlet. Jasper runtime is just one library that the generated servlet uses. You _can_ ( at least with the older jasper - and probably you can easily get the current one to work, if it doesn't already ) run jasper generated ( pre-compiled ) servlets with any servlet container ( weblogic, whatever ) - as long as the container doesn't include an older version of jasper ( that would mess the class loader). The real issue with Jon's proposal is not the fact that admin ( or any jsp ) won't run in the JSR154 distribution. It's more an issue of attitude. As a note - my proposal for minimal container ( that I consider now dead - I think the multi-profile solution is much better ) did not include the jasper compiler either. You don't need jasper compiler or javac on an embeded or production server to run JSPs. By including the runtime I didn't actually meant the current runtime, which could be easily included in the webapp by the precompiler, but whatever tomcat-specific optimizations we'll do ( I made a number of proposals about using the lower-level tomcat constructs for output, etc - didn't get too much enthusiasm, but I still think that it is the right way and can make JSPs much faster than the equivalent servlets ). Assuming such optimizations are done - they'll have to be included in the minimal container. Since right now there's no tomcat-specific optimization in jasper - my minimal proposal would be almost the same as the JSR154-only container, however it keeps the door open ( and includes the runtime as a matter of convenience ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15251] - tomcat server serving blank pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15251. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15251 tomcat server serving blank pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 07:04 --- I cannot reproduce this. You'll have to debug this more or give more information. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java
remm2002/12/10 23:34:25
Modified:jk/java/org/apache/jk/common ChannelSocket.java
Log:
- Restore old behavior: bind on all addresses by default.
- Note: the file EOLs are correupted. Please fix it.
Revision ChangesPath
1.29 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ChannelSocket.java22 Nov 2002 17:46:33 - 1.28
+++ ChannelSocket.java11 Dec 2002 07:34:25 - 1.29
@@ -314,7 +314,7 @@
if (maxPort startPort)
maxPort = startPort;
if (getAddress() == null)
-setAddress(localhost);
+setAddress(0.0.0.0);
for( int i=startPort; i=maxPort; i++ ) {
try {
sSocket=new ServerSocket( i, 0, inet );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerCompiler.java
[EMAIL PROTECTED] wrote: costin 2002/12/10 16:38:29 Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java Log: Remove getCanonicalPath. This may not be a good idea, and I think would break Jasper on Windows. I'll revert it, if you don't mind. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15258] - ajp13 socket listens on localhost by default
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15258 ajp13 socket listens on localhost by default [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 07:38 --- EOLs are not fixed, but AJP will again bind all addresses by default. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
remm2002/12/10 23:51:20
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
- Fix the build.
- Not using a canonical path may be ok. I need more testing though (don't port
that to 4.1.x ;-) ).
Revision ChangesPath
1.44 +1 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- Compiler.java 11 Dec 2002 00:38:29 - 1.43
+++ Compiler.java 11 Dec 2002 07:51:20 - 1.44
@@ -368,7 +368,7 @@
// Build includes path
PatternSet.NameEntry includes = javac.createInclude();
-includes.setName( includes.setName(ctxt.getJspPath());
+includes.setName(ctxt.getJspPath());
info.append(include=+ ctxt.getJspPath() + \n );
try {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
remm2002/12/10 23:51:48 Modified:.RELEASE-NOTES-4.1.txt Log: - Update release notes. Revision ChangesPath 1.37 +8 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- RELEASE-NOTES-4.1.txt 10 Dec 2002 18:02:49 - 1.36 +++ RELEASE-NOTES-4.1.txt 11 Dec 2002 07:51:48 - 1.37 @@ -704,6 +704,10 @@ NamingResourcesMBean: Fix resource link creation. +[4.1.17] #15258 + JK 2 ChannelSocket: + Bind all addresses by default. + Jasper Bug Fixes: @@ -922,6 +926,9 @@ Generator: Scripting variables declared AT_END do not work when tag implements TryCatchFinally. + +[4.1.17] Compiler: + Make exception reports more detailed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: I'm going to repost this message once again because it seems Remy and Costin didn't bother reading it the first time and are now essentially agreeing to what I suggested below. What-EVER! Lol. Actually, you are proposing releasing multiple binaries because you don't want to bother maintaining a small script in Scarab. To give a parallel, there's such a script in Slide. Somehow, it took something like 15 minutes to write, and is obviously not rocket science, and I am not asking for a Slide-ready-distribution for Tomcat. Costin has proposed to make profiles inside a single binary distribution (like JBoss does). I don't see how you can consider that to be the same thing. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
