Re: New repository org
Mark Thomas wrote: Using externals wasn't something I had thought of but if offers a nice way to provide all the source for one version in a single chekcout. We now have tomcat/current/5.5.x that uses externals to link in all the various modules. That's actually what I was thinking about, looks great. Now, the big question - where can I add a sandbox/experimental directory? Costin Mark Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separate repos. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New repository org
Could we just move all in tomcat5.5 ( and HEAD ) into one repository ( say, tomcat ) ? Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separate repos. Costin Remy Maucherat wrote: Bill Barker wrote: It occurs to me that I may have misunderstood, and you were just talking about setting up the svn:externals for tomcat/current. If that's the case, then +0 (I don't really care, but I'm glad that somebody does :). svn:externals sounds like a cool feature, I guess I'll have to look it up to know what it does. Mark Thomas wrote: > If by this you mean do a checkout of > http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x to a directory > called build in the build scripts then +1. If it involves any form of > svn move -1 since I don't understand what you are planning to move to > where and I have concerns about complications that might be created for > checkouts, future branches and future tags. No, I don't want to do any change to the repository. The problem is that svn isn't like CVS, so someone (like me, I tried it) which would checkout http://svn.apache.org/repos/asf/tomcat would be in trouble. It would be better to organize the developer environment. Right now, it organizes things using jakarta-tomcat-5, and all the other jakarta folders. CVS was simpler ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.xml
BTW - there are still few files missing, but the end result is a 1.2M jar containing all deps, that can be run with "java -jar" and only requires a webapps/ dir in the current dir. Costin [EMAIL PROTECTED] wrote: costin 2005/09/28 23:07:24 Modified:.build.xml Log: Add a target to build the standalone jar - in case anyone wants to play with it. Revision ChangesPath 1.239 +87 -1 jakarta-tomcat-5/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v retrieving revision 1.238 retrieving revision 1.239 diff -u -r1.238 -r1.239 --- build.xml 22 Sep 2005 10:39:37 - 1.238 +++ build.xml 29 Sep 2005 06:07:24 - 1.239 @@ -192,6 +192,7 @@ + @@ -658,7 +659,7 @@ - + @@ -1167,6 +1168,90 @@ + + + description="Do once before single jar tomcat"> + + + + + + + + + + + description="Build single jar tomcat"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -2051,4 +2136,5 @@ + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Remy Maucherat wrote: Jan Luehe wrote: As a reminder, CVS shound't be used anymore. I commited a bunch of small changes, don't know how easy it'll be to get them in after the switch to svn. Let me know if there's a problem, I can roll them back. BTW - I had some of the changes in IntrospectionUtils in my workspace as well, so I don't have to commit that :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java
I have few weeks, I'm trying to sync up some of the few changes I made
in the last year before the code is moved to svn and try a bit more
the 'embedded' scenario ( both single-jar tomcat - that actually works
well, and also coyote-only ).
I uploaded 2 jars at http://people.apache.org/~costin/mini - one has
full jasper, the other only the jsp runtime. There are still few
requirements on the dir structure - you need to have the conf/web.xml,
work/, webapps/, but besides that it's just 'java -jar
tomcat+jasper.jar', no extra jars required.
tomcat-http11.jar is just coyote, with a javascript adapter as example (
let me know if you want to play with it, I'll send additional info ).
Costin
Henri Gomez wrote:
Happy to see Costin is back :)
15 Sep 2005 06:04:01 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
costin 2005/09/14 23:04:01
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Support for corner case, when all tomcat is in a single jar and no fancy
classloaders are used.
Revision ChangesPath
1.23 +9 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Bootstrap.java3 May 2005 14:12:52 - 1.22
+++ Bootstrap.java15 Sep 2005 06:04:01 - 1.23
@@ -95,6 +95,10 @@
private void initClassLoaders() {
try {
commonLoader = createClassLoader("common", null);
+if( commonLoader == null ) {
+// no config file, default to this loader - we might be in a
'single' env.
+commonLoader=this.getClass().getClassLoader();
+}
catalinaLoader = createClassLoader("server", commonLoader);
sharedLoader = createClassLoader("shared", commonLoader);
} catch (Throwable t) {
@@ -122,10 +126,10 @@
// Local repository
boolean packed = false;
if (repository.startsWith(CATALINA_HOME_TOKEN)) {
-repository = getCatalinaHome()
+repository = getCatalinaHome()
+ repository.substring(CATALINA_HOME_TOKEN.length());
} else if (repository.startsWith(CATALINA_BASE_TOKEN)) {
-repository = getCatalinaBase()
+repository = getCatalinaBase()
+ repository.substring(CATALINA_BASE_TOKEN.length());
}
@@ -159,14 +163,14 @@
// Retrieving MBean server
MBeanServer mBeanServer = null;
if (MBeanServerFactory.findMBeanServer(null).size() > 0) {
-mBeanServer =
+mBeanServer =
(MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
} else {
mBeanServer = MBeanServerFactory.createMBeanServer();
}
// Register the server classloader
-ObjectName objectName =
+ObjectName objectName =
new ObjectName("Catalina:type=ServerClassLoader,name=" + name);
mBeanServer.registerMBean(classLoader, objectName);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mark Thomas wrote: Mladen Turk wrote: Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. I am about to kick of TC3 and TC4. Once that is complete (few days?) I'll do the last batch which will be TC5, Connectors and Jasper. Mark Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)
William A. Rowe, Jr. wrote: Costin Manolache wrote: Remy Maucherat wrote: I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Well, my first point was that, as a TLP, the lists should become @tomcat.apache.org; whatever they become. But AFA different lists are concerned, is it worth a vote? I'm going to abstain, as I'm not on the PMC (IIRC). But here it is, go ahead and cast an opinion... Bugs [ ] forward to [EMAIL PROTECTED] [X] forward to [EMAIL PROTECTED] Commits [ ] forward to [EMAIL PROTECTED] [X] forward to [EMAIL PROTECTED] Vote away :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strongly Tomcat 5.5.x will be committed to JDK 1.4.x in future..
The current servlet spec doesn't requires J2SE 5.0 - only the next one ( another stupid forced, unjustified transition IMO ). I would assume JDK1.4 will be supported for a while, as long as the current version of the servlet spec is in use. Tomcat3.3, which supports JDK1.1, has been maintained for quite a while after switching to JDK1.3 and then JDK1.4. I don't see how anyone who has been around for past upgrades could expect a mass migration to the new servlet spec and JDK1.5. Costin Yoav Shapira wrote: Hi, Tomcat 5.5 will always allow JDK 1.4. Tomcat 6.0, as required by the J2EE 5 specifications, will require J2SE 5.0. I repeat, for emphasis, that this is required by the J2EE 5 Specification itself, which Tomcat 6.0 will support: it is not our decision to drop support for JDK 1.4. Yoav --- Girish Vasvani <[EMAIL PROTECTED]> wrote: Hi, We'r puzzled between tomcat 5.0.x and 5.5.x. Due to our product restrictions we can't use JDK 1.5. Looked at jakarta web site, it seems that using tomcat 5.5.x seriese compated to 5.0.x is a good idea and recommended. Before committing our product to tomcat 5.5.9, I want to know how much tomcat dev team will be committed to supporting JDK 1.4.x going forward ? thanks in advance for your help, Girish - Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Bill Barker wrote: - Original Message - From: "Costin Manolache" <[EMAIL PROTECTED]> To: Sent: Thursday, September 08, 2005 10:56 PM Subject: Small refactoring in Http11Processor Hi, I have a small patch, spliting the JMX-dependent code in Http11Processor, i.e. the few lines of code dealing with the registration of the thread pool and per thread data - and moving all non-jmx code in a separate base class. I know Tomcat5 is heavily dependent on JMX, but the connector can be used in other containers, or it can be used standalone. This small change won't affect any functionality on tomcat - all methods are used only for intialization anyway, not in the critical path. Please review and let me know if it's ok to commit the change. It seems that the only thing this patch does is to allow you to exclude jmx.jar, so it's usefulness seems very minimal :). TC 3.3 & 4.1 already run very happily with the current code without JMX enabled. True, it allows a smaller package. TC3.3 and 4.1 don't register the connector, so no JMX-related code is called, but it still requires jmx.jar to be around. Something better would be a refactor that would remove the duplicated code between Http11Processor and Http11AprProcessor (which one doesn't do :). Yes, I've been thinking about this too :-), and also InternalAprBuffer and maybe add conditional compilation for the apr. But I didn't want to make the diff too big and risky. Of course, none of this is enough for me to veto your scratching an itch :). Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) I agree with Mladen that this would work better if you could wait a couple of weeks until we are up on SVN. Ok, sounds good, I need to clean up the code anyway ( well, there are 2-3 classes only and some build.xml ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Small refactoring in Http11Processor
Hi,
I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e. the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.
I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.
Please review and let me know if it's ok to commit the change.
Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)
Costin
? src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Index: src/java/org/apache/coyote/http11/Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
diff -b -u -w -r1.64 Http11Protocol.java
--- src/java/org/apache/coyote/http11/Http11Protocol.java 22 May 2005
17:12:11 - 1.64
+++ src/java/org/apache/coyote/http11/Http11Protocol.java 9 Sep 2005
05:31:50 -
@@ -56,98 +56,12 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
}
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString("http11protocol.setattribute", name,
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString("http11protocol.getattribute", key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString("http11protocol.socketfactory.initerror"),
- ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString("http11protocol.endpoint.initerror"), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString("http11protocol.init", getName()));
-
-}
ObjectName tpOname;
ObjectName rgOname;
@@ -178,460 +92,18 @@
( cHandler.global, rgOname, null );
}
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString("http11protocol.endpoint.starterror"), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString("http11protocol.start", getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch
Re: Top Level Project? Time for Top Level Lists?
Remy Maucherat wrote: So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Of course, but also fewer people will care about bug reports. I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging infinite loop w/5.5.9
Nathan Bubna wrote: On 8/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: Nathan Bubna wrote: hey folks, i'm a developer on the VelocityTools subproject, and we recently came across an issue with the use of commons-logging in Tomcat 5.5.9. by default, we configure our example applications to use an adapter between commons-logging and Velocity's LogSystem. this way, those of our tools which require logging are able to send messages to commons-logging and they get passed of to the LogSystem that the rest of Velocity is using (without having to pass that LogSystem around). We also, by default, configure our VelocityViewServlet (the core class of VelocityTools) to automatically send LogSystem messages to the servlet log. so, messages sent to c-l are sent the the Velocity LogSystem which sends the messages to the servlet log. this works just dandy for everyone in Tomcat 5.0.x, but when we deploy our very minimal example applications in Tomcat 5.5.9, we promptly receive stack overflows and out of memory errors that appear to be a nasty little commons-logging loop. can somebody help me figure out what change between 5.0 and 5.5 is causing this? and further, what can be done about it? i'm still not even sure whether to consider this a bug in our design or in Tomcat. any help would be much appreciated! In Tomcat 5.5, everything is logged to commons-logging, so the loop you get is to be expected. so, i guess that means web applications/frameworks that wish to work with Tomcat 5.5 must either not redirect commons-logging messages to their own logging solution or else they must not use servletContext.log(...) as a target for their logging solution, correct? Seems so - since servletContext.log() call commons-logging, not a good idea to use an impl. of commons-logging that eventually calls servletContext.log(). Maybe a better solution would be to have the Velocity LogSystem send messages to commons-logging, then everything will go to c-l and the chosen impl. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inprocess Tomcat/apache via mod_jk
With worker - it may work. However you may find mod_jk inprocess to be slower than ajp and mod_proxy ( or comparable in speed ), this is due to the way parameters are passed as strings ( i.e. lots of unoptimized char-byte conversion ). Porting to 5.5.x shouldn't be hard - the interface between tomcat and modjk is very simple: you need to startup, i.e. make sure classpath is set and the class that executes launches tomcat correctly, and then it's a simple class that does the request/response passing. If you do this for performance reasons - you may want to look at the code in jk2, and try to backport it. A benefit would be that the interface is even simpler - the req/response are passed in the same kind of buffer as ajp requests. AFAIK that's the only major difference. Since Remy, Mladen, etc have greatly optimized the regular tcp connectors - probably the difference on performance ( with this optimization backported ) will be small. But if you use the old style of interface - I'm sure jni will be slower (it was slower 2 years ago). Costin Christine Ho wrote: Hi, Thanks a lot. I am really appreciated for your reply. How about the worker MPM? My team is running the httpd.worker on RHEL4. The current setting is: StartServers 1 ServerLimit 1 MaxClients 64 MinSpareThreads 32 MaxSpareThreads 64 ThreadsPerChild 64 Does the inprocess Tomcat 5.5.9 work for the worker MPM? thanks, Christine --- Bill Barker <[EMAIL PROTECTED]> wrote: Well, inprocess doesn't really work for any MPM on *nix systems (e.g. with the prefork MPM, you end up with MaxChild copies of Tomcat running :). As a result, there just hasn't been that much interest in implementing (or even back-porting) a feature that only works on Windows and NetWare. - Original Message - From: "Christine Ho" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 16, 2005 3:30 PM Subject: inprocess Tomcat/apache via mod_jk Hi, I have posted this email a month ago. I just wonder if any developer on mod_jk can answer my question. I would like to have inprocess Tomcat 5.5.9 running in Apache 2.x if possible. thanks again, Christine Hi, I tried to setup Tomcat 5.5.9 running inside the apache server 2.x via the mod_jk on RHEL4. I got the following error: [debug] open_jvm2::jk_jni_worker.c (1055): JVM created [emerg] get_bridge_object::jk_jni_worker.c (1097): Can't find class org/apache/tomcat/modules/server/JNIEndpoint I looked at the mod_jk source codes and found out that the mod_jk supports the TC32_BRIDGE_TYPE and TC33_BRIDGE_TYPE. It doesnt support bridge type of tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have the JNIEndpoint.class. However, it seems to me that the deprecated mod_jk2 supports bridge type of tomcat 4.x and up because it tries to instantiate the class org/apache/jk/apr/TomcatStarter.class which exists in tomcat-ajp.jar. I really dont understand why the mod_jk supports tomcat 3.x only whereas the deprecated mod_jk2 supports tomcat 4.x and 5.x. Can somebody please tell me why? Also is it easy to have mod_jk to support TC55_BRIDGE_TYPE? Based on the mod_jk source codes jk_jni_worker.c, I think I just need to define the TC55_JAVA_BRIDGE_CLASS_NAME to be org/apache/jk/apr/TomcatStarter.class and then assign it to the btype. Is it just that simple? Another question is what the disadvantages of running tomcat inside the apache are. I googled and it seems to me that not too many people try to run inprocess tomcat inside apache. I would be interested in adding the 5.5 bridge type to the mod_jk. thanks, Christine __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: svn commit: r232601 - /tomcat/watchdog/branches/tc4.1.x/WARNING.txt
Did tomcat move to svn already ? Costin [EMAIL PROTECTED] wrote: Author: markt Date: Sun Aug 14 04:48:32 2005 New Revision: 232601 URL: http://svn.apache.org/viewcvs?rev=232601&view=rev Log: Remove CVS closure warning from SVN Removed: tomcat/watchdog/branches/tc4.1.x/WARNING.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP using APR
Bill Barker wrote: "Costin Manolache" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: If I understand you correctly, you want MsgAjp to use ByteBuffer instead of byte []. At the cost of never supporting JDK 1.3 ever again, this would probably actually improve the performance of ChannelSocket (after changing it to use a blocking SocketChannel). The biggest difference will be if it's a 'direct' buffer, i.e. zero copy. Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should be ok, if anyone needs jdk1.3, they can use the old code. Yes, the idea was that it would be a direct buffer. But where is the code ? It's on my hard-drive. Unlike Remy's APR stuff, o.a.jk is supposed to be a pretty stable package(s) at this point. I can't just check in stuff like this without a lot of testing to make sure that it doesn't break anything more than JDK 1.3 compatibility ;-). That's why C has conditional compilation - and java has some options-controlled ugly 'if' code :-) It doesn't break anything if the option/def is not selected ( just makes the code a bit uglier ). This way even JDK1.3 will be happy. The biggest problem in JNI ( and probably - in Java playing nice with other languages and the rest of the platform ) is the objects and buffers moving around almost randomly. Yes, it may improve a bit the garbage collection speed - so people can create millions of garbage objects without thinking about it, unlike most other languages that require you to think when allocating objects - but it is the kind of optimization that has disastrous consequences on the rest of the systems. Luckily gcj and kaffe and mono don't do this crazy thing. Direct buffers is one band-aid that should be used whenever possible. Costin Costin Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP using APR
Bill Barker wrote: If I understand you correctly, you want MsgAjp to use ByteBuffer instead of byte []. At the cost of never supporting JDK 1.3 ever again, this would probably actually improve the performance of ChannelSocket (after changing it to use a blocking SocketChannel). The biggest difference will be if it's a 'direct' buffer, i.e. zero copy. Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should be ok, if anyone needs jdk1.3, they can use the old code. But where is the code ? Costin Rémy This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Costin Manolache wrote: I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. No it doesn't. If the connection is keep-alive, and there is no activity for 100ms, the socket is put in the poller, and that thread is freed. When the next data on that socket arrives, the socket is signaled and passed to the thread pool. Mladen. Sorry, I missed that. So we can have as many 'keep alive' idle as we want - only those active are taking threads ? Which file implements this ( the 100ms timeout and poller ) ? I assume this is only done in the APR connector, or is it implemented in java as well ( nio ) ? . Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Remy Maucherat wrote: I looked at this yesterday, and while it is a cool hack, it is not that useful anymore (and we're also not going to use the concurrent utilities in Tomcat, so it's not really an option before we require Java 5). The main issue is that due to the fact keepalive is done in blocking mode, actual concurrency in the servlet container is unpredictable (the amount of processing threads - maxThreads - will usually be a lot higher than the actual expected concurrency - let's say 100 per CPU). If that issue is solved (we're trying to see if APR is a good solution for it), then the problem goes away. I'm still trying to understand the APR connector, but from what I see it is still mapping one socket ( 'keep alive' connection ) per thread. That's how it allways worked - but it's not necesarily the best solution. The only thing that is required is to have a thread per active request - the sleepy keep alives don't need thread ( that could be implemented using select in the apr, or nio in java ) Your patch is basically a much nicer implementation of maxThreads (assuming it doesn't reduce performance) which would be useful for the regular HTTP connector, so it's cool, but not worth it. Overall, I think the way maxThreads is done in the APR connector is the easiest (if the amount of workers is too high, wait a bit without accepting anything). That's a tricky issue :-) In some cases ( like load balancing ) not accepting is the right solution, but in other cases droping connections is not what people want ( in particular if most of the threads are just waiting on keep alives ). ( sorry if I missed some details in the new implementation :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat performance patch (in development) to reduce concurrency...
Mladen Turk wrote: Scott Marlow wrote: Hi, I wonder if anyone has any feedback on a performance change that I am working on making. Can you compare the performance of you code with the standard implementation when the concurrency is lower then maxThreads value? I see no point to make patches that will deal with cases presuming that the concurrency is always higher then the actual number of worker threads available. IMHO this is a bad design approach for the http applications, and NIO performance is a proof of that. It might help in cases where you have a very very slow clients. In any other case the thread context switching will kill the performance thought. Further more I don't see how can you avoid keep-alive connection problems without using a thread-per-connection model. The point is that with 100 keep-alive connections you will still have 100 busy threads. Why ? 100 keep alive connections doesn't mean 100 active requests, in real servers there are many 'keep alive' connections that are just waiting for the next request. In all servers I know, concurrency was higher than the configured number of workers - at peak time, at least, where performance matters. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java
Remy Maucherat wrote: Keith Wannamaker wrote: If no one else is concerned that Tomcat 5.5 doesn't work by default Any other nonsensical statement to make ? The only thing that does not work is opening third party documents from the website, due to IE's broken handling of this. How about a) going whining at M$ instead ? b) using appropriate configuration. Your veto is completely invalid anyway. IE is still (unfortunately) the browser used by a lot of people, and if there is a way to work around IE brokeness - I think it's a good idea to do it. Complaining to M$ doesn't work - people will just end up buying IIS instead :-) Seriously, not sure why is the veto invalid - if the choice is between having it working for 90% of the people and doing it 'right' - it is worth probably more discussion and a pragmatic decision :-) I would vote for fixing it for the 90% of people - at least until IE gets down to some 49%. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Bill Barker wrote: - Original Message - From: "Costin Manolache" <[EMAIL PROTECTED]> To: Sent: Friday, April 08, 2005 7:23 PM Subject: Re: New TLP draft Remy Maucherat wrote: Need to identify just how much of the jakarta-* CVS will go with Tomcat. Watchdog + ServletAPI modules? That's undecided. Would the old projects would remain at Jakarta, or would they be covered by the new project ? Why would they remain in jakarta ? They have the same committer list as tomcat, and are closely related. Urm, no. For example I, personally, have no karma for any of jakarta-servletapi* or jakarta-watchdog*. Also, jakarta-watchdog* are all dead projects. It's all about who wants to watch the corpse ;-). I know - now is the time to fix this :-) Code changes to jakarta-servletapi are still 'special' - since it must be an exact copy of the spec. But I see no reason for watchdog - it was supposed to be the semi-official test suite, but now Sun provides an official one, so watchdog is useless anyway. But both should go with tomcat - since the servlet API implementation is part of tomcat charter ( and I assume it will be removed from jakarta charter :-) Maybe someone should check with Sun - if they have any concerns. I think the avail should be consistent in the new TLP - i.e. all tomcat committers have access to all tomcat modules. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Remy Maucherat wrote: Need to identify just how much of the jakarta-* CVS will go with Tomcat. Watchdog + ServletAPI modules? That's undecided. Would the old projects would remain at Jakarta, or would they be covered by the new project ? Why would they remain in jakarta ? They have the same committer list as tomcat, and are closely related. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
Tim Funk wrote: Looks good. Just an idea, it may be nice to have the 3 new lists tomcat-bug - bug updates from bugzilla. When I subscribe to other groups tomcat-cvs - Same as tomcat-bug but just for cvs commits. tomcat-gump - For deaths by gump. If your not a committer - these are This has been debated many times :-), maybe this time it'll succeed. The typical argument for keeping it all in one place is that it may force people to read them instead of filtering the out with the mail app. It would be nice to split it - it'll be much easier to read tomcat-dev ( including in blogs.gmane.org ). Regarding CVS move - are we going to just change the name of the roots ( s/jakarta/apache/ ) or should we do a bit more reorg, to make it easier when we move to svn ? The current layout is based on a lot of 'historic' reasons that no longer apply. For 3.x and 4.x - of course it makes sense to just keep the trees as they are. Costin -Tim Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Remy Maucherat wrote: Kurt Miller wrote: From: "Yoav Shapira" <[EMAIL PROTECTED]> Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. +1 To get things started, since I'm probably close to the 6 month inactivity limit ( in either direction :), I would like to ask to stay in the active list :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Kurt Miller wrote: From: "Yoav Shapira" <[EMAIL PROTECTED]> Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? Congratulations to Remy. Also thank you Yoav for moving the formalities along. Congratulation Remy ! I think a lot of people agree that anyone who is an active committer should be in the PMC ( that's what jakarta has been doing for a long time ). It's 'should' - not 'must' - that means you are not required to do this if you really don't want to. I think Remy has already sent additional lists of people who are active but have not voted. I assume those who really don't want will have to send email to Remy to be taken out of the list before it goes to the board. Regarding 'emeritus status' - I think usually people who have not participated in the last 6 months ( or 1 year ) can be moved to 'emeritus' - unless they ask to remain in the list of active committers. ( for example because they plan to return to active soon, etc :-). We could send a mail to everyone in the avail list, and if we don't get an answer or we get an 'I don't care' - we should do the switch. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Mladen Turk wrote: Henri Gomez wrote: I could provide Linux binaries for Suse 8.0 PPC and Suse SLES 9 but it's up to distributions mainteners to provide such binaries (via rpm/deb). Take a look at jpackage for many Linux RPM binaries Yes, that is my opinion too. We should focus on providing a solid: 'configure && make && make install', rather then providing a binaries for ourself. I think that we are good and mature project that any serious linux distribution (at least targeted for enterprise environment) should take into account, and provide a binaries on their own. We can provide binaries for platforms that does not come with integrated build system like WIN32, and we are doing so. Although, personally I would be pleased to see the isapi_redirector.dll as part of the next XP service pack, it's hard too expect something like that :) I kind of disagree... If I want Firefox for linux - I get it from Mozilla.org. It may be a .tar.gz or .rpm - but it is a binary provided by the software maintainers, not by a 3rd party ( like a linux distributor ). And it is the 'real' thing, not a randomly modified version ( different flags and features, etc ). Linux is such a mess in large part because people who write software treat it as second-class - 'let someone else deal with compiling binaries for linux, I'll only do it for windows and mac'. As a result linux distributions have the freedom to mess up and 'personalize' each package to their own taste ( we all know how painful it is to switch from one distro to another or use/support 2 distros - each file is in a different place - this is called lock in ). On windows - you can get nice binaries, with installer and everything else you would expect - distributed by the package authors. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] PMC Chair
Jim Jagielski wrote: I would recommend that before anyone responds, "we" decide who should rec' and tally the votes. Also, votes should only be counted from those who will be on the new PMC. So before the vote: 1. Finalize list of PMC members (all current committers) 2. Determine who to collect and tally votes (I propose Henri Yandell) Let's not make this too long or complicated. Some votes are already out of the box, and I think we agree that any committer who wants to be in the PMC can get there by simply asking for it. So if Henri can send back a count ( or just the winner ) of all private votes he receives, as well as the list of people who voted - we can check against avail and update the PMC member list as well. ( a vote by a committer is an indication that he wants to vote so he wants to be in the pmc :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] PMC Chair
Yoav Shapira wrote: The initial Tomcat PMC chair should be: [ +1 ] Remy Maucherat [ ] Yoav Shapira Next year I'll switch, Yoav is great - I just think Remy deserves to be the first chair... Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Jim Jagielski wrote: The PMC Chair has "ultimate" authority, since the position is board appointed and results in the Chair being a VP of the ASF. There's no precedent for "sharing" the role or having a "co-Chair." The PMC Chair is the point man for the PMC. Yes, we know - that's one of the reasons some people want this to be a 'rotating' position. "Sharing" the role ( i.e. the tasks ) has a lot of precedents. I have no problem with someone having this kind of authority - in projects like Linux or Python, where the guy in charge created the project in the first place. I am not confortable at all with having the 'ultimate' authority appointed - even when (in most cases) it is at the recomandation of the community. IMO it is the worse of both worlds. The PMC Chair is nominated by the PMC, and the recommendation is sent in with the PMC resolution. The board then debates the issue and will usually approve the resolution and appoint the nominated person as chair. Since the PMC Chair is the main guy for the PMC, it is even more an issue for that person to be very much an ASF weenie and understand and embrace the Apache Way... It can be a "political" and "managerial" kind of position and any candidate should realize that sad fact :/ Well, Remy and Yoav are members of ASF - so they clearly passed the 'Apache Way' test. If this is a requirement - than the pool of candidates is going to be quite small ( Remy, Yoav, you, Bill - and Craig or Justina if they choose to get back ) For 'managerial' and 'political' - I think both did both ( maybe without enjoying it, but still...) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Remy Maucherat wrote: Costin Manolache wrote: Yoav Shapira wrote: If Remy is interested, I think it would be fair to have a vote. If whoever is first later decide he had too much politics/admin pains - we'll have a backup ready :-) At this point, I think I cannot avoid being a candidate. Yoav may be the best chair, however, so there's an opportunity for a real election. Good. Let's get this over then. I never liked "one candidate elections" or elections with 99% results ( remind me of an evil system :-) Yoav would be an excelent chair - however Remy has my vote this time. I'm at the moment in favor of allowing non consecutive one year terms. Of course :-) Costin Unfortunately, it means two people can share the job, which would defeat the purpose, but without this, we could run out of worthy/willing candidates pretty fast. I don't know what are the rules wrt board meetings ( if only the pmc is allowed, etc ), but while there is only one pmc chair, we can have as many volunteers as we want to help with the admin stuff - reports, etc( if I remember, Henri was doing this long before he became chair of jakarta pmc, same for Geir ). Right. So it's great to have as many people as possible volunteer for the unpleasand admin work - it will only make the admin job easier, and it'll make the rotation transition easier too. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Hola, What do you guys (parties in the subject) have to say about that? Lat's put all the cards on the table, do what ever is needed and move forward. I'm getting tired of all that politic bullshit, but I'm also aware it must be done. So ... Remy, Yoav? I'm waiting to hear from Remy on what he wants to do. He has to want to be the PMC chair ;) If he does want it and all the admin stuff that goes with it, it's fine with me. The role of a VP is something we can define, but doesn't really exist within other ASF projects, which just have the PMC chair and the rest of the PMC, so I don't think we need one. If Remy is interested, I think it would be fair to have a vote. If whoever is first later decide he had too much politics/admin pains - we'll have a backup ready :-) I don't know what are the rules wrt board meetings ( if only the pmc is allowed, etc ), but while there is only one pmc chair, we can have as many volunteers as we want to help with the admin stuff - reports, etc( if I remember, Henri was doing this long before he became chair of jakarta pmc, same for Geir ). So it's great to have as many people as possible volunteer for the unpleasand admin work - it will only make the admin job easier, and it'll make the rotation transition easier too. Costin I'm also fine with the annual rotation as suggested by Costin. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Howdy, I think the idea of rotating ( let's say yearly ? ) would be an excelent one - it'll avoid having people serve for too much ( and sometimes avoid bad habbits - like forgeting to ask the community before making important decisions :-) That's a decent plan. What do the other projects do about that ? Logging Services, which formed just recently, has a yearly PMC chair term, but the incumbent can repeat the role if the PMC so votes. Sounds ok - I would preffer a real rotation. What about 'can repeat the role if he wants and there is no other candidate' ? ( if he doesn't want - of course, someone else needs to be 'volunteered' ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: Hi, I would like to propose Remy == XX ( he can obviously refuse, but I hope he will not do that ). Obvious reasons on why he is the best choice, so I don't think consensus will be a problem - only his acceptance ( it'll not involve too much coding :-). I was thinking Remy might refuse, so he doesn't have to deal with all the administrative stuff that comes with the role. That and my own interest in the role prevent consensus at this point ;) It Remy will refuse - you have my vote :-) It's just that he done so much coding in this project - that I think it would be good if he is the first chair. I think the idea of rotating ( let's say yearly ? ) would be an excelent one - it'll avoid having people serve for too much ( and sometimes avoid bad habbits - like forgeting to ask the community before making important decisions :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Jim Jagielski wrote: Yoav Shapira wrote: Hi, I could... But there's the question of whether we want all committers on the PMC or just the active ones. The avail file has, in addition to the people I already listed: duncan,jon,rubys,akv,jhunter,preston,shemnon,shachor,bergsten,gonzo,mode,har ishp,arun,craigmcc,jluc,nacho,aried\ el,horwat,ed,alex,gaburici,jiricka,pierred,glenn,larryi,arieh,marcsaeg,danmi l,shai,keith,kief,melaquias,m\ braden,clucas,bip,seguin,mmanders,andya,ccain,bojan,patrickl,jazmin,ekr,manv een,cks,denisb,dsandbe\ rg,bobh,idarwin,johnturner,ecarmich,fuankg,clar,jim,wrowe John Turner, Jim J., Bill Rowe are obviously active, I'll add them right now. But many of the above are not active, emeritus committers... Personally, I would agree if people did not think I deserved PMC member status. I would be honored to accept, but would 100% understand if there were, well... thoughts that it was unwarranted :) I hope that Tomcat PMC will be one where each active committer who is willing will be a member, I don't want it to be an arbitrary and random process like it was in jakarta ( or asf membership ). If you are working on tomcat, I can't see why not be in PMC ( unless you really don't want to ) I don't know if I deserve it tough - since I haven't been very active last year - but since my project is now over, I hope to get back on tomcat and become active :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP Draft Proposal
Yoav Shapira wrote: NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX] be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further +1 I would like to propose Remy == XX ( he can obviously refuse, but I hope he will not do that ). Obvious reasons on why he is the best choice, so I don't think consensus will be a problem - only his acceptance ( it'll not involve too much coding :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the Tomcat5 WIN32 service runner
Mladen Turk wrote: @if "%1" == "install" goto cmdInstall @if "%1" == "uninstall" goto cmdUninstall @if "%1" == "start" goto cmdStart @if "%1" == "stop" goto cmdStop @if "%1" == "restart" goto cmdRestart echo Usage goto cmdEnd I assume the '.bat' is the only option - i.e. could you use arbitrary 'executables' or other 'scripting languages' ? I.e. if you have cygwin or equivalent installed - could it execute a .sh ? Or if you have different scripting engine - could it run the .js or .py instead of .bat? And the most interesting - could you specify an executable .jar as the command ? It's just that .bat is one of the ugliest scripting languages... Having the unix-style service mechanism, i.e. a script with start/stop/etc is IMO a step forward and makes it much easier to deal with services. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing the Tomcat5 WIN32 service runner
William A. Rowe, Jr. wrote: At 06:31 AM 2/21/2005, Mladen Turk wrote: Unlike any other java or java/jni implementations it does not tries to make a java as a service, but rather makes a batch (.bat) file as a service. IIUC, that means; 1. service signals (shutdown etc) aren't recognized by cmd (sh for you linux observers) in any useful manner. 2. it invokes cmd, which invokes the apps. You are stuck with an instance of cmd for the lifetime of the process. Seems like a big leap backwards, IMHO. If anything, a psuedo-sh script interpreter which picked up the envvar assignments (the only thing you want to move to .cmd for, anyways) makes more sense than this. Would it be possible to have the signals intercepted and cause the execution of the .bat file with different params ( like 'stop' or 'reload' or 'start' ), similar with unix init.d files ? I like the idea of running a .bat ( or arbitrary .exe ) as a service based on the analogy with the init.d files - but it needs the stop/restart as well. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
Both +1, of course. I guess you meant 'commiters for jakarta tomcat project' :-) Costin Mladen Turk wrote: I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and William A. Rowe ([EMAIL PROTECTED]) as commiters for the JTC connectors. Both of them are long time ASF members. Jim is even a director of Apache Software Foundation. They both are core apache httpd designers and developers for years now, and IMHO we should be proud tho have them on board :). I'm sure they will help us with the better apache httpd integration. So... [x] Yes, Jim is really a cool guy. [ ] No way. and.. [x] Sure, wellcome Bill. [ ] I think I know httpd better then him. The both have my ++1. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Well, numbers are statistics do speak for themself - but may tell different things. Apache may have most projects in SVN, but the world has most projects in cvs. And most tools (finally) have some good, first class built-in support for CVS, most people are (finally) familiar enough with using cvs. There are some plugins for svn ( and other version control tools ) - but not at the same level. I like SVN a lot - and for a new project probably I would choose it if there is a choice - sf.net or other places are cvs only. But I don't think all the pain for switching tomcat is justified, and switching few repositories but not others is even worse. Unless we're going to do major reorganization of the code ( move directories around ) or we start some complex branches, or we have any other need where SVN is much better than CVS - I would say it's better for everyone to stick with the stable environment. Costin Henri Yandell wrote: I've not heard anything about it being mandatory yet, but the numbers speak for themselves. The www.apache.org site has 24 coding projects. There are 22 projects listed on the svn.apache.org/viewcvs.cgi page. 2 of those are dead, so 20 out of 24 ASF projects have an svn presence of some kind. The people still left with readable CVS modules are: mod_perl ant 2/3rds of jakarta possibly gump (though they have an svn module too) apache conference most of xml logging half of web services So I assume at some point there'll be pressure to turn off the CVS server. On the command line, svn is pretty much the same as cvs. Some bits are faster, some slower. There are various improved features (http://subversion.tigris.org/ lists them) that people have been asking for for ages with CVS. Habit-wise, the only differences I've hit are: 1) you checkout from a url, not from a cvs-root and a path. 2) tagging/branching is done by copying a directory revision (really creating a symlink-style thing in the database) and isn't applied to every file individually. Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for standard development (checkout, update, diff, commit). I'm unsure whether you can create tags/branches using it as I always do that on the command line, be it cvs or svn. IntelliJ has a plugin and the next version will have it built in. TortoiseSvn is spoken well of, and I can vouch for svn on linux/OS X, I've had no problems in the last year of use. Docs are docs :) Yep, they'll need updating. Build scripts. Do you have scripts that check modules out of cvs? If so I imagine the ant support for svn might be a big deal. Unsure what it's like. Hen On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote: Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The FIX - Shutdown not working under SLES8 and FC2
Al Sutton wrote: Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: <[EMAIL PROTECTED]> To: "Tomcat Users List" Cc: Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address="127.0.0.1"). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts "you've got a strange config, it's your problem", I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address="127.0.0.1" to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton <[EMAIL PROTECTED]> wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From
Re: The FIX - Shutdown not working under SLES8 and FC2
What about: - add this information to the bug report - send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not very used, but probably google will find this if anyone has a similar problem ). Or post it in your weblog/site/etc for google to find. It should be obvious changing the default configuration only to deal with this case won't happen. If a computer can't locate itself by name - you'll have a lot of other problems. Costin ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address="127.0.0.1"). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts "you've got a strange config, it's your problem", I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address="127.0.0.1" to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton <[EMAIL PROTECTED]> wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump:
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
I assume this is going to be a compile/configure time option ? What about using a different approach - generate multiple .so files, one with common/base/non-optional functionality, and one for each optional library. Compile time options makes it hard to distribute compiled binaries and add more requirements. Costin [EMAIL PROTECTED] wrote: mturk 2005/02/02 23:47:49 Added: jni/native/src ssl.c Log: Add OpenSSL support. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jni/native/src/ssl.c Index: ssl.c === /* Copyright 2000-2004 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #include "apr.h" #include "apr_pools.h" #include "apr_file_io.h" #include "tcn.h" #ifdef HAVE_OPENSSL /* OpenSSL headers */ #include #include #include #include #include #include #include #include /* Avoid tripping over an engine build installed globally and detected * when the user points at an explicit non-engine flavor of OpenSSL */ #if defined(HAVE_OPENSSL_ENGINE_H) && defined(HAVE_ENGINE_INIT) #include #endif #else #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Well, if you can debug this and find the real cause and a fix - I'm sure someone will look at it. But please understand that Remy and the other tomcat developers deal with a lot of bugs, and usually it's frustrating to deal with bugs that happen only on certain situations. If Java code behaves correctly on most platforms - but it doesn't work on few distributions - you may as well report this as a bug to either Sun or the distribution. BTW, we are engineers, not PR people - so 'crappy' comments may happen :-) So if you have a patch or workaround - please reopen the bug and add the fix. It would be a better way to spend the time instead of arguing about closing/not closing it or hurt feelings :-) Costin Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say "Sorry, no-one has FC2", rather than "Closed bug, doesn't work on [insert name of totally different platform here]". The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the "crappy" comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a "crappy distro"? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider "crappy" I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of "not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup". Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platfo
Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work
[EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a "crappy distro"? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider "crappy" I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of "not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup". Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Postcard
Remy Maucherat wrote: Allistair Crossley wrote: *rotfl* that's not Remy at all! ;) Those viruses are annoying, since I cannot prevent them from reaching the list :( As long as they use a valid subscriber's address, I cannot do anything. I suppose it would be caught by a spam filter though. Rémy Maybe a solution would be to subscribe from an address that uses SPF - apache checks for SPF, so it'll reject it. I don't like SPF for many resons, but it does have its benfits :-) Gmail.com does spf btw. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk jni worker - apache + number of processes
The only way to do in-process with apache on unix is to use a multithreaded MPM and a small number of processes ( and lots of threads). JNI is not much more efficient than IPC - or at least not in the simplistic use. Even the applets in mozilla/konqueror/etc run out of process on unix ( but in-process on win and macosx ). Writting apache modules in java has been attempted before - unfortunately it never quite worked, and the multiprocess issue is just one of the problems. Costin Fox,Tim wrote: Hi Mladen - Thanks for your reply. I suspected as much. My real motivation here is to basically provide a java implementation of an apache module or filter. I didn't want to communicate via sockets or whatever to a shared java process due to performance considerations. Especially for doing stuff like setting the apache uri or filename via the request_rec, I thought that this would incur too much overhead. I'm guessing this is something that has been considered before. Any ideas? Maybe it's already been discounted for these reasons? Anyway, I guess this is turning into an Apache httpd question rather than a tomcat one! :) -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: 18 January 2005 12:43 To: Tomcat Developers List Subject: Re: mod_jk jni worker - apache + number of processes Fox,Tim wrote: Hi All- Apologies for cross-posting from the user group - but in retrospect I believe this might be a better forum for this question: I am interesting in using the in processes jni_worker with apache 2.0 on linux. My question concerns the number of instances of a jvm, and hence tomcat that will be created. My understanding is that, on linux the default mpm configuration will have multiple child server processes created. Does that mean there will be multiple jvms and hence multiple tomcat instances instantiated? Or is the jvm somehow "shared" across processes? You listed all the problems JNI connector faces on Linux, and also the facts why JNI is unusable. Is it a requirement of using the jni worker that the number of child server processes is limited to 1 in the apache config? I would suggest that you forgot all about inprocess JNI on any unix variant with Apache, or better all together. Even the stupid .NET has a separate process out of IIS. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
To be honest, I don't like where this is going. I think access to native functionality for tomcat is great - and starting with functionality provided by apr is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't be easy to add. So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an official binding - we can switch), and keep it open for the other non-apr stuff that may be interesting. Costin William A. Rowe, Jr. wrote: At 01:56 PM 1/13/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? He he :) I didn't said it should be private to J-T-C nor Jakarta. But the fact is that we don't have OO languages infrastructure for APR glue code. Seems to me that we'll need to go through incubation to create self standing apr-java project, or something like apr-oo/java. Self standing? If apr is borked (and the oo-dev'ers prove it) do you want another layer in the middle? This probably should be closely paired to apr to ensure communications and direction. Having them both under the same pmc ensures that the apr project doesn't go off on some weird tangent that interferes with oo implementations (not that I expect this would happen.) If you think we can make something like that in a reasonable amount of time, count me in. Happy to encourage it and I'll present it (with myself as a list moderator) to the apr project, and invite our modperl friends along with John Sterling and others who have created C++ wrappers. In other case I can rename the package to whatever name desired if it breaks some policy or something like. This sort of surprises me coming from an ASF java developer. I seriously doubt this team would find it amusing to discover org.apache.catalina namespaces populating an xml project's code. -1 on appropriating another ASF project's namespace (the same -1 I should have offered to forking proxy.) +/-0 if you want to build on org.apache.jk.apr namespace. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecation and JK2
Bill Barker wrote: - Original Message - From: "Costin Manolache" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 12, 2005 4:14 AM Subject: Re: Deprecation and JK2 A lot of the code is actually specific to the now-dead Jk2 - if the native jk2 is gone, probably you should clean up this side as well. - org.apache.jk.apr - the not-quite apr jni layer that connects to the native objects, as well as 'in-process' launcher ( I doubt it can be used by jk1.x ), also common.JniHandler - ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2. I think that proxy_ajp is hoping to be able to use ChannelUn someday. It's no more Jk2 specific than ChannelSocket is. It is using the jk2 'object' - it can be easily rewritten to use the new apr library directly, but in the current form I don't see how it could be used without jk2 native (and if you want to add it - it's easier to start from channelSocket ). Maybe it would be a good idea to rename the remaining files ( but please not org.apache.ajp - it would be confusing since this is the name of the very old connector package ). What is the story with in-process ? Is it still supported with jk1.x ? Only the (very) old 3.3 JniHandler at the moment. Maybe the new apr library will help improve this too. BTW, starting in-process java in jdk1.5 ( on linux at least ) it's amazing, no longer requires LD_LIBRARY_PATHs and seem to 'just work'. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deprecation and JK2
A lot of the code is actually specific to the now-dead Jk2 - if the native jk2 is gone, probably you should clean up this side as well. - org.apache.jk.apr - the not-quite apr jni layer that connects to the native objects, as well as 'in-process' launcher ( I doubt it can be used by jk1.x ), also common.JniHandler - ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2. Maybe it would be a good idea to rename the remaining files ( but please not org.apache.ajp - it would be confusing since this is the name of the very old connector package ). What is the story with in-process ? Is it still supported with jk1.x ? Costin Remy Maucherat wrote: Henri Gomez wrote: +0 JK / JK2 are also very specific to our current AJP implemtation. Maybe they should be called AJP instead ? I thouhgt I had done enough damage with my package renaming and class moving ;) The renaming here is nearly all located in strings which are supposed to be displayed to the user when there's an error, and also in comments -> low impact stuff. PS: Happy New Year to all TC-DEV members :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [INTRODUCE] apr-java
Mladen Turk wrote: Hi, Here is the work in progress for a new project I named apr-java. It offers a 'thin' layer using JNI over APR library. The initial code that I wrote over a year now had two way api, but I've decided to leave only Java->APR. I also have a working set of configure and make files for unixes, but since this is an overview of the technology, it's only a small subset of entire project, but you can get the picture :) . It will support around 90% of APR API (without things like strings, etc. that are well done inside java itself). The API itself on the Java side is done as close to the APR function call (apr_file_write -> File.write) with almost the same function parameters as well. You can see that the wrapping code is very thin in most cases with only a couple of lines for each function, mostly caused by pointer issues. I'm sending the gz file (tried zip but failed) so you can see what the general idea is. Of course the library can be extended with functions that APR doesn't offer (for now or never will). One of the things would be setting user and group for a process, sending data from parent to child process, etc. The question is: Is it acceptable (think that previous discussions say it is) Where to put that in the cvs. Comments? Looks good. It seems it still does a lot of String operations in native - unlike SWT for example, where it's almost always byte[]. Also the typical memcpy, etc should be included somewhere to allow data to move from/to the pool and java heap. Why not checking it in j-t-c ? Just to make sure - you expect it to also have non-apr native methods ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java
Remy Maucherat wrote: Costin Manolache wrote: Maybe: * @author Jason Hunter, as part of the book "Java Servlet Programming" * (O'Reilly). See http://www.servlets.com/book";> * http://www.servlets.com/book for more information. ? I think it is fair to respect the author wish for attribution. Given that the board recomends against @author tags and they may be someday removed, it doesn't matter that much... I am all in favor of giving proper attribution (author tags), but -1 on anything which restricts the ASF's copyright on the code (like advertising clauses in this case). As a result, I have to agree with all that pointed out that the code should be rewritten (in this case, the encoding list must be reconstructed from scratch). Rémy There is no "advertising clause" in this. He made it clear that the code is donated to ASF, under ASF license. Mentioning that the author developed the code while working on a book or while being paid by a company can't be that bad. I don't understand why ASF is so advertising-fobic when it comes to authors or companies that donate code or employee time to ASF, but until recently strictly required advertisment for the code owner ( ASF ) not only in the code, but also on the web site. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java
Maybe:
* @author Jason Hunter, as part of the book "Java Servlet Programming"
* (O'Reilly). See http://www.servlets.com/book";>
* http://www.servlets.com/book for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be
someday removed, it doesn't matter that much...
Costin
[EMAIL PROTECTED] wrote:
remm2005/01/04 14:14:42
Modified:util/java/org/apache/tomcat/util/http
LocaleToCharsetMap.java
catalina/src/share/org/apache/catalina/util
CharsetMapper.java
Log:
- Remove legally questionable comment. The code was properly donated to the ASF.
Revision ChangesPath
1.3 +2 -14 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java
Index: LocaleToCharsetMap.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LocaleToCharsetMap.java 24 Feb 2004 08:50:04 - 1.2
+++ LocaleToCharsetMap.java 4 Jan 2005 22:14:42 - 1.3
@@ -14,15 +14,6 @@
* limitations under the License.
*/
-/*
- *
- * This class was originally written by Jason Hunter <[EMAIL PROTECTED]>
- * as part of the book "Java Servlet Programming" (O'Reilly).
- * See http://www.servlets.com/book for more information.
- * Used by Sun Microsystems with permission.
- *
- */
-
package org.apache.tomcat.util.http;
import java.util.*;
@@ -30,11 +21,8 @@
/**
* A mapping to determine the (somewhat arbitrarily) preferred charset for
* a given locale. Supports all locales recognized in JDK 1.1.
- * This class was originally written by Jason Hunter [EMAIL PROTECTED]
- * as part of the book "Java Servlet Programming" (O'Reilly).
- * See http://www.servlets.com/book";>
- * http://www.servlets.com/book for more information.
- * Used by Sun Microsystems with permission.
+ *
+ * @author Jason Hunter
*/
public class LocaleToCharsetMap {
1.5 +2 -8 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
Index: CharsetMapper.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CharsetMapper.java 29 Aug 2004 16:46:13 - 1.4
+++ CharsetMapper.java 4 Jan 2005 22:14:42 - 1.5
@@ -14,13 +14,6 @@
* limitations under the License.
*/
-/*
- * This class is based on a class originally written by Jason Hunter
- * <[EMAIL PROTECTED]> as part of the book "Java Servlet Programming"
- * (O'Reilly). See http://www.servlets.com/book for more information.
- * Used by Sun Microsystems with permission.
- */
-
package org.apache.catalina.util;
@@ -38,6 +31,7 @@
* it loads, or by subclassing it (to change the algorithm) and then using
* your own version for a particular web application.
*
+ * @author Jason Hunter
* @author Craig R. McClanahan
* @version $Date$ $Version$
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP issues
Jason Hunter wrote: nor see why we need an exception for such a such a small amount of code. You need an exception because (a) the code was included from a third party codebase and (b) a lot of research and testing went into compiling the map used by the mapper. I can easily add an @author tag for you in the relevant files, but the comment currently creates a legal doubt. As I wrote in my email and for the archived record, I want the classes to have the recognition that is expected when Apache includes code from a third party library that's under a license that requires attribution (just like Apache's). The files says "copyright ASF" - but it seems that's not completely accurate ( I assume someone mistakenly removed your "Copyright Jason Hunder" ? ). As an author, you should be able to keep any notice that you consider apropriate. If you didn't explicitely assign the coypright to ASF ( or to Sun ), than I don't think it would be right for anyone to remove your name or attribution. If you did assign the rights to ASF - then as you know anything can be removed or changed by the new owner, including @author tags or any mention of previous author ( just make sure your name does gets into whatever obscure file lists all people who contributed something ) :-) Note: Many companies and individuals donated more than these 10 lines of code, Yes, and I too donated plenty of code to the Tomcat codebase. But these classes I donated (to Sun at the time) with attribution because they were from a separate, pre-existing codebase with a life of its own. If you write a book and include a paragraph from someone else's book with permission, you mention it and you point at the source of the original work. You don't just say, "Written by author X" you say, "Written by author X as part of book Y, published by Z." That's why the attribution I put on those classes includes the who, what, and where. I see it as the ethical thing to do. I fully agree. Doesn't matter how small a contribution is ( or looks at some later time ), keeping the reference to the author and whatever else the author wants to include is the right thing to do ( if the code is accepted and used ). Too bad what's ethical doesn't matter that much, only copyrights and IP ownership :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Or: 1. Wait for Mladen to check in the code 2. figure out how to build it and how to install it easily in tomcat ( and other java applications ). 3. probably add one native method. I don't think "wrapping it as apr component" makes sense ( apr is not a component system like xpcom ). 4. write the java mbean - using the native method and making all conversions between the native signature and java style ( if SWT-style of jni is used - i.e. using byte[], int pointers, etc - and doing java adaptation in java ). I'm as curious as you are to see the code and figure out how it can be used, I love jni :-) Costin Peter Lin wrote: So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this? 1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote: Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Benson Margulies wrote: For systems with a /proc file system with these statistics, this doesn't require any JNI ... Yes, there are a lot of ways to workaround java limitations. /proc is one. But even on linux, a lot is not exposed via /proc, but ioctl. I guess the goal is not to implement sysinfo, but have a way to get more platform-specific information and access platform-specific features. Costin -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 10:04 AM To: Tomcat Developers List Subject: Re: adding features to Status servlet sysinfo on unix/linux should be pretty easy. I've used windows performance stats before when i tried to write the equivalent of the status servlet for IIS. I will try to write an exe named sysinfo that spits out similar performance stats. how can I help mladen? peter On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Why don't you check in some of this to j-t-c or some 'proposal' area ? AFAIK apr has a lot of functionality, but not everything is included. It would be nice if it is not limited to apr. Usually with JNI the hardest part is to build, distribute and then set it up and debug ld_library_path issues. If you do it for one library, it's easy to add more. Costin Mladen Turk wrote: Peter Lin wrote: that sounds great. does it have support for sysinfo? if it does, I'll try using your apr-java package. No, but it's up to us to decide what will go inside. APR is included, but I wish to leave that as open as it could be. It already have win32.c,unix.c and netware.c files for platform specific stuff that APR doesn't offer. Having sysinfo sounds good to me. WIN32 has also good performance data gathering, and I'm sure that Netware has them too. I also wish to include the OS specific things from httpd like setting group, user, sending data to child process, etc... What matters is that we'll have a generic native component, with well defined build and distribution specification. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Mladen Turk wrote: Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. Well, I'm working over a year now on a project that I've called apr-java. This is a thin (for now) wrapper around apr and apr-utils, so it will be supported on all platforms the apr is. Things like true shared memory, process mutexes, advanced networking, pipes, etc. that are missing from the core Java will be supported. Usages are many, like writing high-performance networking connector for Tomcat, making Tomcat a Apache mpm-like server with multiple JVMs, etc... I hope I'll have a working start point this month, so we could discuss is it worth the effort at all, would it fit inside JTC, commons, or to go trough apache incubation as a separate project. Mladen. Anything that allows Java to do things only native apps can do instead of beeing as dumb as the dumbest platform is worth the effort :-) JTC already has some apr and jni code ( it is true, using the dead jk2 model ), why not start there and if it grows big enough move to commons? BTW - it would be really great if it would use the SWT model, i.e. JNI methods matching exactly the APR signatures and param types, with minimal ammount of C wrapper code. It works really well, and it's the easiest to maintain and fastest of all JNI flavors I've seen. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
As implementation - I assume you weren't going to add a native method and a .so library to the standalone tomcat distribution :-) Adding capability to StatusServlet to report arbitrary mbean attributes would make this feature easy to add ( there is some code in JmxProxyServlet - but it it would be much better if integrated and made consistent with the status servlet ). For the JNI + mbean implementation - it may be better to use a separate component ( I don't see why it would be specific in any way to tomcat - any jmx-based app could use this ). There are several other OS-specific informations of interest ( including in Windows ), JMX is designed exactly for this - to expose management info for different systems. Costin Peter Lin wrote: that's why I decided it was a good idea to ask for other's thoughts. From a stress testing perspective, I find system load stats very valuable. breaking tomcat isn't something I find desirable either, but there has to be a better way to measure system load other than ssh into the server and use top. manually doing top or sysinfo is fine for load testing, but for performance monitoring, something automated is desirable. My thought was to make it optional and have it detect whether or not a native lib for that platform exists. If it doesn't it would affect the status servlet and would look exactly the same as it does now. on the otherhand, if the user enables it and a native lib exists, it could display the system load. the only other option is to lobby Sun to add system load stats to the VM, so that it is portable across platforms. peter On Fri, 31 Dec 2004 17:27:03 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I would personally have some reservations about doing this... It's a little better if it's a module you can activate and deactivate, but still... First, if it's not something you can do cross-platform, I'm not sure I'd like it. AFAIK Tomcat is nicely cross-platform now, anything that breaks that wouldn't be good I think. I understand this would be an optional component (right?), so it wouldn't actually be *breaking* anything, but the expectation I think is that anything in Tomcat works on all platforms, so would it be a good thing to introduce something that doesn't fit that mold? Second, and more importantly, it doesn't feel right to me to expose this type of information through an app server. Your talking about statistics that aren't truly related to the app server, although is certainly affected by the app server, so it's debatable whether they should be there or not. I agree this is useful information to have access to, but I'm not sure it'd be the right place for it. Have you considered maybe making this part of some Commons package? Make it something that any app could make use of, that might be a very nice thing. Heck, it might be somewhere in there already for all I know. Just my thoughts on it anyway. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Peter Lin wrote: it could be a separate module. It definitely should use MBean. In terms of getting the CPU load stats, I was thinking of calling the standard sysinfo loads[]. Is there some other way of getting the system load stats? or CPU stats? that doesn't require calling native code? peter On Fri, 31 Dec 2004 13:13:54 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote: Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. I would also update JMeter in the process to display the system load average. peter lin Wouldn't be better to have a way to display an arbitrary mbean attribute, plus an mbean tracking system load ( and maybe memory/disk statistics ) ? Dealing with jni is allways tricky ( including build issues, etc ) - it is better to have it in separate modules. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding features to Status servlet
Peter Lin wrote: I'm thinking of adding system load stats to the status servlet. What do other's think about it? It would use JNI to call a native lib and it would only work on unix, but it would be good to have. I would also update JMeter in the process to display the system load average. peter lin Wouldn't be better to have a way to display an arbitrary mbean attribute, plus an mbean tracking system load ( and maybe memory/disk statistics ) ? Dealing with jni is allways tricky ( including build issues, etc ) - it is better to have it in separate modules. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13_worker.c
Mladen Turk wrote: jean-frederic clere wrote: Mladen Turk wrote: Costin Manolache wrote: Are you joking :-) ? If we can not alloc couple of bytes from the system, then the entire system is unstable. Or that the process that makes the malloc() has reached a configurable limit of the amount of memory it is allowed to use. Sure, but the system is still unusable. This checking is done inside worker_factory, called from init_jk, so IMHO the apache will fail long before. But if everyone thinks it's a good to check for failed memory allocation on small objects, I'll revert the patch. Well, I see your point - probably it doesn't matter much, I'm sure other places in code will not check and it would crash anyway. Most OSes use swap, so the system will trash and become unuseable before running out of memory. But there are other cases where the swap is not used - and then malloc failure is a common condition under load. If the system is very loaded, it is possible you'll run low on memory and you don't know which malloc will fail - maybe the small one. The correct behavior would be to give up and return a 500 on the request ( that may go through since apache probably already have the memory allocated in the memory pools ). On single process/multithread systesm, an apache server crashing under load is not a good thing :-) IMO all mallocs should be checked - but probably I spend too much time with systems with very little memory where a crash is not such a good thing :-) Costin Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp13_worker.c
Mladen Turk wrote: David Rees wrote: Are you sure it's a good idea to wait until it crashes rather than fail in a controlled method? How much overhead is there to check aw->name for NULL? Can't be much... Yes I am. Look, if the system can not alloc 1000 bytes of memory what's the purpose to continue? Mt. Are you joking :-) ? At least do an printf and exit(), coredump is never good (some systems don't collect the core - so the user will have no idea what just happened ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector RequestFacade.java LocalStrings.properties
Remy Maucherat wrote: Jan Luehe wrote: Bill Barker wrote: In the case I was referring to, some project was storing a servlet request (facade) in a ThreadLocal and, due to a bug in their code, was hanging on to it beyond the request's lifetime. This was happening only under rare circumstances. Great use case. And the talented programmer who coded that "thing" couldn't figure out what the problem was quickly enough without a proper error message, I assume ;) So in this case, the Request behind the facade was indeed null. So now he'll get an error message saying "null request". Actually, it sounds like one of these useless M$ error messages. Lol and +1 for Bill's suggestion to change text to "if you're reading this, you're a moron" :D As long as the exception doesn't get into the web browser of some user :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contrib directory
Shapira, Yoav wrote: Hi, Another option for now is to setup a SourceForge project for this. I'd be glad to link to it from our docs/FAQs/wiki pages. You (two) could be its committers, and we could work together to get additional contributors setup there. There has to be a critical mass... It seems there is some mass - if the same idea is mentioned at the same time by more people :-) I think it would be good to have few tomcat committers as project admins - at least 3 (the magic number). I volunteer, it seems Yoav is also interested - anyone else ? Costin Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 9:18 AM To: Tomcat Developers List Subject: RE: contrib directory why not put it in the NetBeans repository where you're already setup? I'm only setup to commit to the /core module, which is not where the Tomcat files are found. Actually, we started out in the direction of contributing our Tomcat changes to NetBeans, see http://www.netbeans.org/issues/show_bug.cgi?id=49420 And we contributed patches to NetBeans to start Tomcat on OpenVMS and a catalina.com to be placed in the tomcat bin directory that NetBeans ships. The NetBeans folks told us they'd prefer we make the launcher contributions to Tomcat, since that's where they belong...which is why I opened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499 against Tomcat. Meg -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 8:53 AM To: Tomcat Developers List Subject: RE: contrib directory Hi, That actually gave me an idea: why not put it in the NetBeans repository where you're already setup? In Apache, there needs to be a long-demonstrated background of contributions before getting commit privileges. We have different processes in this area than NetBeans and some of the other open-source collaborations. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Garrison, Meg [mailto:[EMAIL PROTECTED] Sent: Monday, November 01, 2004 7:03 AM To: Tomcat Developers List Subject: RE: contrib directory Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to "boot us out".. That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now.. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwid
Re: contrib directory
Garrison, Meg wrote: Hi Leslie, I'm also willing to maintain the HP OpenVMS scripts. Rather than create a whole new project (tomcat-contrib) maybe it would be possible for the Tomcat folks to grant us commit access to a single module/folder in their CVS library (a contrib folder of some sort). Then they wouldn't have to worry about committing our changes, etc.. If we misbehave and don't follow their rules, then they have the option to "boot us out". That's how the NetBeans project does it. For example, I have commit powers in the core module, which is where the OpenVMS launcher lives, but no other. Our needs for NetBeans (as yours, I'm sure) require that the default Tomcat distribution contain our launcher somewhere...it doesn't have to be in /bin. It would be a good idea, but I don't think it is possible at the moment. Commit access requires a unix account on a machine, at least for cvs. Even if this could be solved - there are non-technical problems, ASF requires a CLA, and a certain review and oversight process. Ant has an ant-contrib project on sourceforge ( including few ant committers ). Maybe we should have a tomcat-contrib as well. This would be a good idea even for committers - there is experimental stuff and code that is not necesarily "servlet container" but is tomcat related ( like non-http servers, etc ). Costin Any other ideas? Meg -Original Message- From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:29 PM To: Shapira, Yoav Cc: Tomcat Developers List; Garrison, Meg Subject: Re: contrib directory Dear all, I'm willing to spend some of my limited free time to collect, organize and maintain these contributed code. However, it is very unlikely that I would be ever a committer on this project with my OS/2 launchers. So, as Yoav said, we could find an other committer. Or we could create an other project something like tomcat-contrib where we maintain our code. Best regards, Leslie Kishalmi Shapira, Yoav wrote: Hi, Yeah, it's gone for now. The reason is that the maintenance aspect is too hard for the long term. While I don't doubt the quality of you (or anyone else's) work, nothing is perfect. It is inevitable that the scripts will need work. Even if you stay on top of it and keep submitting patches, someone will have to keep checking for them and applying them. I'm not interested in doing that work, and other committers apparently aren't interested enough to even comment on what an appropriate place in CVS might be for these contributions. So I took them out for now. That's not to say they're gone forever. I can see a couple of possible solutions, and that's why I'm doing this thread on tomcat-dev as opposed to just replying to you personally. One approach is what I'm doing now: contributed stuff is owned by authors (like you) who post it wherever they want (hp.com, personal web sites, whatever), and we link to it from our FAQ and/or wiki pages. This approach solves the long-term maintenance concerns. If this was a one-time effort, I would have done it and we'd be all set by now. But it's not, and I just don't have the bandwidth to work it ;( Another approach is for someone else with commit privileges to say they're interested and do what they think is appropriate. That can happen at any time, I wouldn't stand in their way obviously, as I'm not principally objecting to these contributions. I just don't have the bandwidth to deal with them at this point. So this issue is not dead. It's just not going to be in 5.0.30/5.5.4. We might also want to raise it on tomcat-user to see if people have other creative approaches to solving this. Are you really going to take the contrib directory out? I was just about to make a contribution to you via PayPal as a thank you... Thank you ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.3 Stability Rating
Remy Maucherat wrote: - Allowing pluggability for commons-modeler Can you elaborate a bit more on this ? The basic functionality of modeler is to take an object and a descriptor and return an mbean. This can be made pluggable - a simple interface with a single method is probably enough to hide most of modeler's logic. But all the descriptors need to be converted. But what do you want to use instead and how ? Move the mbean descriptors to conf/ so it can be replaced with another format ( since this is specific to modeler ) ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: True, in ASF land as in other community, it's the users and developpers base which make a solution/product successfull or forgotten. BTW, jk 1.2.x is allready very stable and should stay like this for now : - JK 1.2.x is now on bug-fix only mode. - AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in) Should we start a new AJP/JK/whatever connector is another story which has been debated this summer when we speak about mod_ajp. We should first be very prudent since users may be puzzled by : jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine. Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev and will be present only in Apache 2.1.x, may be there is a need for a new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we should list the requested features missing in jk 1.2.x For IIS/Domino - I think having it maintained and developed by apache is a waste. In both mod_jk and mod_jk2 we pay a significant price for trying to be "multi-server", and it seems clear this is a feature that only few people want. If an external project wants to create an IIS connector based on mod_ajp or jk - that's great. But they should do it taking full advantage of whatever IIS provides, including consistent config, etc. I suggest take a look about what was detailed in mod_ajp thread (July 2004) and see if a new consensus could appears. On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker <[EMAIL PROTECTED]> wrote: - Original Message - From: "Dave Oxley" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 11, 2004 3:35 PM Subject: Re: JK Todo List So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? JK2 is dead because (like mod_webapp before it :), it failed to attract a community interested in maintaining it. You might as well ask 'why doesn't mod_webapp just replace JK?' There are also technical reasons I think. Like the attempt to "object oriented C" but without using one of the existing solutions. And not droping featurea from mod_jk. But you're right - lack of community interest was the main problem. Costin Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? Why use APR in mod_jk ? Support for Apache1.3 is IMO more important than support for IIS. And so far, mod_jk seems to work without any apr - and it is in maintainance mode, so no major changes should be made. Costin On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller <[EMAIL PROTECTED]> wrote: From: "Mladen Turk" <[EMAIL PROTECTED]> Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? I have to agree - for Apache ( even 2 ) the complexity of multiprocess is too big and it's not worth it in almost all cases. But having a jni library to access OS-specific features is not a bad idea. For example registry, change UID ( I know c-daemon could do the same), unix sockets, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Todo list
Remy Maucherat wrote: Remy Maucherat wrote: - Decent default java.util.logging configuration I don't see any sensible configuration given what the standard handlers are (limited rotation options, little possibility of avoiding hardcoding logfiles paths, etc). Also, the reload operation is not exposed to JMX (other operations are exposed, however). So I'll add a default configuration file from the JRE, where we'll add some example catagory names to help users, but that's unfortunately all that can be done by default. Rémy And some people are using log4j :-) I just can't live with the 2-line per log and the formated date, and I found no way to change this ( except writting my own formatter ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Jess Holle wrote: In general the same-user, same-machine stuff works great (including with Tomcat 5) if you specify -Dcom.sun.management.jmxremote as part of the command line. Again - remember not everyone is using Sun JDK1.5 implementation. My understanding is Macs don't have 1.5 yet, neither most other platforms. This is without any special web app or such. What I really want to see is a nice bit of code that allows you to fire up a JMX RMI connector that: * Finds the first free port in a range (e.g. assuming you have a number of slave processes, this does not apply to Tomcat as it does not have such logic for it AJP port, etc). * Support user/password and SSL * Does not rely on implementation internals, i.e. requiring Java 5 is fine, but having hooks into sun.* or MX4J or whatever classes is no good That's not hard to add. You actually need the first free port in the range for rmiregistry - or you can use existing rmiregistry if one is found. You need different rmi names - that's easier. Adding user/pass/ssl is not hard - if someone has the itch it shouldn't be a problem. javax.man.remote has all that's needed AFAIK. IF you look at jmxremote webapp that I checked in - there is no mx4j or sun code, just plain javax. Costin -- Jess Holle Remy Maucherat wrote: Dominik Drzewiecki wrote: I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ? Neither have I (I am talking of tomcat running as Windows service). It seems that both processes : tomcat JVM and jconsole JVM have to be owned by the same user. Maybe that is the case with you? Hovewer, starting tomcat from my system account solves the problem. For more info see: http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html Both jconsole and the application must by executed by the same user name. The management and monitoring system uses the operating system's file permissions. I'm running both with the same usename on Windows, and it doesn't work. Since it's Windows and I like to be able to do stuff, I of course run with root privileges. Seems to me it would work on Unix, but is currently broken on Windows (I use XP pro SP 2), or something. Over a TCP port, it works good. I couldn't find a comprehensive guide on all these nice system properties, while there's tons of docs on the new command line commands. If I use the service, which runs with the SYSTEM account, it of course doesn't work any better ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Remy Maucherat wrote: Dominik Drzewiecki wrote: Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. Because they don't work with JDK1.4, and any people (including me) can't switch to Java5 since it breaks too much :-) The option you mention are in fact the same thing with the webapp I'm suggesting - they have the effect of loading the standard javax.management.remote connector. The difference is that jx.m.r is using the standard API and will work with any JMX implementation, while "com.sun" is specific to sun's implementation of jmx. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM <1.5) Your post motivated me for trying jconsole, and I have to say it's really good. Yes, jconsole is the reason I wrote the app too. Plus the fact that mx4j2.0 no longer works with jkmx ( they dumped the connector beans from distribution since they now support the standard jx.m.r ) As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5. Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed. No, removing jk2.properties - and removing JkMX - is a good thing. I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Remy Maucherat wrote: I didn't have time to look at the code yet, though. Wait a week or 2 - the loader part is fine, but the catalina side is still a bit messy and I need to find a good way to integrate with the build ( to make it completely optional/isolated - I don't want to affect the 5.5 schedule by breaking something :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: What about commons-deamon? What about it :-) ? Daemon is a different level - it's about launching a resident process (or service in windows ). No connection with how the process is loading its classes. Sure, but the wheel was invented long time ago :). How about making things usable? Which things to make usable ? Daemon ? It's not my itch to start services on windows:-) Yes, the wheel was invented long ago - and we are still using the simplistic hierarchical class loader + delegation. Do we really need all those different loaders? That can be said about anything :-) I'm making the compile optional - so if you don't explicitely ask for it it'll not get compiled. When it's completely ready - I hope it will replace Bootstrap/StandardClassLoader - so we'll still have 1 loader for standalone. If embeded - as I said, the intent is to not use the loader but the embedor's loader - however ability to split tomcat in smaller components and manage each separately should remain ( supported by the embedding app loader ). That's why the loader is mirroring the fundamental behavior of mlet/jboss/eclipse/osgi - i.e. repository of classloaders delegating to each other. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: Costin, can you elabborate the purpose of the patch? Perhaps I've missed few discussions. There are few goals: - allow tomcat components ( connector, valves, etc ) to be added/removed/upgraded dynamically, at runtime - without requiring a full restart. - cleanup the startup code - the split startup package, lots of introspection and dependencies ( commons-logging, jmx needed in CLASSPATH ) - maybe improve the class loading - for example WebappClassLoader use of the jar index, the code is a bit complex, etc - make it easier to integrate tomcat in apps like jboss or eclipse - which both use similar class loaders and module mechanisms ( jbossmx and osgi ). One extra benefit may be on allowing more flexibility in the common/shared/webapp hierarchy - if WebappClassLoader extends the loader, it will be easier to have webapps using different versions of shared libraries ( right now you need to place shared libs in shared or common, and you can't have more than a version ). I've been trying to do this for a very long time - there is some code in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but using an m-let-like classloader is a better solution than what was there. What about commons-deamon? What about it :-) ? Daemon is a different level - it's about launching a resident process (or service in windows ). No connection with how the process is loading its classes. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: loader
Mladen Turk wrote: Costin, can you elabborate the purpose of the patch? Perhaps I've missed few discussions. There are few goals: - allow tomcat components ( connector, valves, etc ) to be added/removed/upgraded dynamically, at runtime - without requiring a full restart. - cleanup the startup code - the split startup package, lots of introspection and dependencies ( commons-logging, jmx needed in CLASSPATH ) - maybe improve the class loading - for example WebappClassLoader use of the jar index, the code is a bit complex, etc - make it easier to integrate tomcat in apps like jboss or eclipse - which both use similar class loaders and module mechanisms ( jbossmx and osgi ). One extra benefit may be on allowing more flexibility in the common/shared/webapp hierarchy - if WebappClassLoader extends the loader, it will be easier to have webapps using different versions of shared libraries ( right now you need to place shared libs in shared or common, and you can't have more than a version ). I've been trying to do this for a very long time - there is some code in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but using an m-let-like classloader is a better solution than what was there. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMX Remote connection
Bill Barker wrote: - Original Message - From: "Costin Manolache" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 05, 2004 10:06 PM Subject: JMX Remote connection Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any "official" mechanism. At the moment, jk2.properties is still used (we're just not shipping the default one). It should be possible to configure JkMX via Connector attributes. I thought JkMX only supports the "old style" connector - not the new javax.management.remote, and since jk2.properties is being deprecated I assumed JkMX will go as well, or at least move to a higher level. The code in JkMX seems very specific to mx4j - and I couldn't get it working with mx4j2.0, the package name changed ( mx4j.adapter.rmi -> mx4j.remote.rmi ) and the mechanism didn't seem to work. Can we at least add the JMXConnectionServerFactory as another special case ? A separate webapp seemed cleaner. Costin I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even "trusted" ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
loader
I checked in the first part - I'm still working on making build.xml changes and the catalina-side code. It is certainly experimental code for now - I think it works better than Bootstrap/etc, but the reloading of connectors/etc is still very tricky ( it kind of works, but I still don't have a clean interface ). I placed it in util/loader mainly for eclipse/IDE users - I have it compiled to a separate classes dir, and use the eclipse autocompilation - it's pretty cool and efficient ( i.e. no need to use "ant" or compile most of the time, just type and run :-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JMX Remote connection
Hi, Not sure what's the new policy for loading the Jmx RMI connector. jk2.properties was a hack - and now that it is removed, I was wandering if we have any "official" mechanism. I had a small class that hooked in the connector, and I now refactored it to a webapp - nothing fancy ( it's not even "trusted" ), only loads rmiregistry and the jmx connector. I can check it in if there's no other mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 there are the cli options ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More needed connector refactoring
Bill Barker wrote: - Original Message - From: "Costin Manolache" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 29, 2004 9:01 AM Subject: Re: More needed connector refactoring Remy Maucherat wrote: Hi, - I'll add a thread pool similar to the one in Tomcat 4.0, as an optional policy to the current one; the idea is that it's very dumb, and could be more stable in some environments (that RH 9 thing ...), but is not as efficient as the current one; I'll do some benchmarks to see if for a single CPU computer there's any difference between the two, and I propose that whichever is the fastest for that use case becomes the default one (with a preference for the TC 4.0 one in case of a tie, as it's simpler) I'm a bit confused - what happened with the thread pool and how did we end up with 2 ? I missed this change. - I think conf/jk2.properties should go, since we can have arbitrary properties on the Connector element, and additionally, it has an extremely confusing name; any comments on that ? +1 :-) It will make the Connector element in server.xml really hideous, and restrict component names to be valid XML attribute names (e.g. channelSocket.localhost:8009 is a no-no :). Other than that, I don't see a problem. Maybe a better solution would be to introduce a new tag ( "mbean" or "module" or similar ), so we can express the fact that jk is composed from multiple components. The intention of jk2.properties was to have a way to configure generic components ( mbean-like ), with a simple way to parse/save the changes from both java and C. Since "C" is no longer an issue - there is no problem with using an xml file, like server.xml. And a good "save changes" implementation shouldn't be specific to jk. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More needed connector refactoring
Remy Maucherat wrote: Hi, - I'll add a thread pool similar to the one in Tomcat 4.0, as an optional policy to the current one; the idea is that it's very dumb, and could be more stable in some environments (that RH 9 thing ...), but is not as efficient as the current one; I'll do some benchmarks to see if for a single CPU computer there's any difference between the two, and I propose that whichever is the fastest for that use case becomes the default one (with a preference for the TC 4.0 one in case of a tie, as it's simpler) I'm a bit confused - what happened with the thread pool and how did we end up with 2 ? I missed this change. - I think conf/jk2.properties should go, since we can have arbitrary properties on the Connector element, and additionally, it has an extremely confusing name; any comments on that ? +1 :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classloader
I had a small vacation, and managed to make some of the changes in the classloader/module area. I'm not completely done - but I want to eventually start checking in some of the code ( if nobody objects ). To avoid breaking anything, I started a new package ( o.a.tomcat.util.loader ), and started with the existing classes, with small refactorings. - WebappClassLoader - Bootstrap - CatalinaProperties plus some extra classes to support jboss ( or m-let) style loading. I tried to remove all dependencies outside JDK1.4 - the package is very small, and I think it's ok to not use commons-logging or jmx in this area. Apache.naming and jmx functionality is added via hooks - after the server loader ( now "repository" ) is started. I think this will improve a bit the code structure - currently we have a bit of a mess in how we select some classes in the bin/ jars. I'm not planning any change in the existing code - except adding few classes and code to allow the new loader to be used ( as an option ) instead of the old one. My goal ( which is not yet completely done ) is to support "modules" for connectors/interceptors/etc - with reloading and all the cool stuff, and make this integrable with existing systems ( jboss, other jmx/mlet based applications, eclipse ). Instead of having the entire tomcat as one chunk of code ( plus all the depenencies ) integrated in one plugin, it should be possible to add a smaller subset and then have connectors/auth/etc as separate plugins. Please let me know if this is ok with you - I'll have another long trip in mid Oct. and I hope to get this done, but if there are problems with what I'm trying to do ( or conflicts with other plans ), I would appreciate feedback before I waste the time :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting usage of Tomcat...
Mladen Turk wrote: Shapira, Yoav wrote: http://www.theserverside.com/talks/VendorPerspectives/Mainsoft/interview .tss Yes, indeed :) Almost a year ago I proposed a project that would enable Tomcat to seemesly integrate the legacy code. Something like moving the perspective from being an backend to becoming an integrator. Of course, the reaction was not much in favor :). But seems that the direction is to integrate as much of those 'million lines written' as possible. Regards, MT. We know more now than we did one year ago :-) Beeing able to integrate our code in other apps and other apps in our code is indeed becoming more and more important. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [5.5] Release plan votes
Remy Maucherat wrote: The vote result is: - the release plan seems to be mostly ok - it is acceptable to use the J2SE 1.4 API for this release (only Costin seems to disagree with that); I expect this will allow using things like the NIO API without any difficulties or the need for compatibility code Well, I disagree with all the incompatibilities and version hell between jdk releases. I like NIO too, even if I use j2me most of the time :-) Costin - Yoav will RM this branch Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When to cut 5.5.0?
Remy Maucherat wrote: Shapira, Yoav wrote: Hola, - compat: JARs for JDK 1.4 (Xerces, XML apis and JMX impl) - admin: the admin webapp (with so many people declaring that they're not using it, I don't see a reason to keep it in the default download) Does one sign (PGP, MD5) jars as well? I'd think so. Yes, but these are zips and tgz (for ex, the admin needs an extra xml file, so unfortunately we can't have the war as the download). Yeah, the only thing about that is that I can't run "ant release" ;) It does a clean, build, and test. To build you need JDK 1.4, to test JDK 1.5. I should probably modify the test targets to specify JDK 1.5. I can still do 'ant clean dist' with JDK 1.4, then change JAVA_HOME and do 'ant run-tester run-watchdog' so this is not a showstopper. Alternately, you can add copying a jmx.jar for the test target to take care of running them with JDK 1.4. I think I removed running Watchdog, as it didn't seem very useful anymore. Will the mx4j be included in the release ( since it is targeted for 1.4) ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [5.5] Release plan votes
Remy Maucherat wrote: I approve the release plan: [X] Yes [ ] No Tomcat 5.5 should use the following API set for the coding: [X] J2SE 1.3 [ ] J2SE 1.4 [ ] J2SE 5.0 Actually - use "target="1.3" - but the distribution should be 1.4 based (i.e. no Xerces ). I'm also ok with having a 1.5 distribution ( no xerces, no mx4j ) - but again, with target=1.3 and instructions for 1.3 and 1.4 users to download the missing jars. You can have target="1.3" with j2se without harm. Yoav Shapira will act as the release manager for this branch: [X] Yes [ ] No Thanks :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: It depends how you define support, right? Does "support" mean by default everything is configured for JDK 1.3, and Tomcat is built with target="1.3" ? Or does it means there's an easy way to set this target parameter (e.g. a build.properties setting) and build your own Tomcat for 1.3? What is the cost of having "target=1.3" by default ? It means the class files and the release will work with jdk1.3 - and it will also run on 1.4 or 1.5. What is the benefit of having target=1.4 and forcing people who use 1.3 to recompile the entire tomcat ? Stability versus featurism is much more of a judgment call IMHO. Does stability mean we stick with an old platform (JDK 1.3) and jump through hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features? If so, then at what point does the cost (e.g. performance) become higher than the benefit (ease of use for old platform users)? It's a subjective call I think. That's a question for Sun :-), who is forcing people to jump through the hoops by bundling all features with the VM. Tomcat core already works with 1.3 - and you can have optional connectors/valves/etc that only work with 1.5 or 1.6 - with just a simple conditional compilation. I understand why MSFT is forcing people to upgrade windows - they make a lot of money from that, and don't care how much the users will suffer to upgrade. But we don't gain that much by forcing people to upgrade the VM to use the latest version of tomcat. I wish Sun would sell and make money on the VM - so at least someone would gets some benefit from this forced upgrade cycle :-) While I don't doubt the legitimacy of your pro-1.3 arguments, you just don't see users on the mailing list with anything other than JDK 1.4. We already get more JDK 1.5 questions than JDK 1.3 it seems, even though 1.5 is still in beta. IMO that's because 1.3 is used in production for quite a while - so most problems are solved. If you release the next version with 1.4 target - you may get more 1.3 questions :-) Upgrading the VM is almost the same with upgrading the OS - there are still plenty of packages for RedHat7.3 or NT, and most of the questions are from people trying the latest OS and noticing things are breaking. So I don't know, I'm not 100% convinced we should require JDK 1.5, and I'm not 100% convinced we should drop 1.3, I'm just in the middle ;) I'm comfortable with requiring 1.4 though, as it's been more than 2 years since JDK 1.4 was released. I'm ok with using 1.5 features, or having a default distribution for 1.5 - as long as the code is compiled with target=1.3 ( no major harm ) and it is possible to run the basic tomcat with 1.3 ( with some additional packages - parser, mx4j, etc ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Shapira, Yoav wrote: Hi, Please make sure "target=1.3" is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to I'm also not big on JDK 1.3 as the default target. I'm +0 on adding a "javaTarget" build.properties attribute that users can set to "1.3" but whose default value is 1.4, 1.5, or none, but not 1.3. I haven't seen a question on tomcat-user with someone running JDK 1.3 for a long time now. Maybe that's because they don't have "endorsed" problems and things just work and are stable :-) "Write once, run anywhere" - why would you choose a target that will not run for a (significant) number of people, and try to force them to choose between upgrading tomcat and upgrading other software ? What do we gain ? Few features that are available anyway - with many choices of better implementations. Sun has the bad habit of breaking compatibility and the "run anywhere" promise on every release. 5.0 is particularly bad. I consider "run anywhere" one of the essential things in java - including the ability to run with other vendor or open source VMs. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: Please make sure "target=1.3" is present in all javac tasks :-) Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to replace jakarta-regexp use with Java regexp. Obviously people who don't want to upgrade (ex: I saw a really funny thread on tomcat-user about a guy who wants JMX runtime stats on 4.1.x, like the ones that were in 5.0.x) aren't going to upgrade to this new branch, because of API breakage. I'm using 1.3 most of the time, there is a _lot_ of software out there that doesn't work in jdk1.4 and won't work in jdk1.5 either. Not to mention companies having policies and supporting only one VM ( so they don't have to deal with all the incompatibilities between versions ). I'm personally -1 on droping support for 1.3 ( well, I would be +1 on supporting J2ME or 1.1 as a baseline :-). Even compiling software with jdk1.5 or loading it in an IDE is problematic. I think we should value stability more than featurism - and value flexibility and modularity more than bloat. There are people who have problems with the Sun/Microsoft policy of bundling features in order to reduce competition ( logging, mx4j/jbossmx, jakarta-regexp, parser, etc ). Especially when those features are hard to replace with better implementations ( even if they implement an API and have some convoluted "endorsed" setting to replace ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: No, you misunderstood. - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, everything - jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs, not the whole thing) - jakarta-tomcat-5.5.0-compat.tar.gz - for JRE 1.4, no Admin You mean mx4j ? I'm not sure about having the main target be a JRE beta, but I understand your point, it's cleaner this way. The alternative would be to have a 1.4 distro, with mx4j jars included, and detect at runtime if it's 1.5 and skip them from the loader. I suspect people will keep using 1.4 and 1.5 for a while, as usual there are incompatibilities - so it's better to be able to use the same tomcat with both. Please make sure "target=1.3" is present in all javac tasks :-) - jakarta-tomcat-5.5.0-admin.zip - admin WAR + the XML file - jakarta-tomcat-5.5.0-admin.tar.gz - admin WAR + the XML file Good. Costin Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. IMO, the admin webapp is better located in the special folder we're using right now. It helps with catalina_base. What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. This is a bad idea. - Windaube XP only supports .zip - tgz allows setting Unix execute flag Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
What does that leave us with in terms of distros? Let me try: [Source distros, same as today] - jakarta-tomcat-5.5.0-src.zip - jakarta-tomcat-5.5.0-src.tar.gz [Binary distros] - jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.tar.gz - for JRE 5.0, no Admin - jakarta-tomcat-5.5.0.exe - for Windows, JRE 5.0, no Admin - jakarta-tomcat-5.5.0-jre14.zip - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.tar.gz - for JRE 1.4, no Admin - jakarta-tomcat-5.5.0-jre14.exe - for Windows JRE 1.4, no Admin + another one for each of the above with Admin? Why ? We can distribute admin.war as a separate binary, who needs it can install it separately. What is the difference between JRE1.4 and JRE5.0 distribution ? I'm building with 1.4 and 1.5 and it works fine with 1.5, 1.5 and 1.3, do we need separate builds ? BTW - I don't know how hard it would be to have admin.war also distributed as a .exe with installer ( just need to extract the war in the tomcat dir ). Maybe we should have admin separately, i.e. jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml), that users can just drop into their webapps directory? I'd rather have that than 6 more binary distributions. +1 What about dropping .tar.gz distros? I realize its files are smaller than zip, but every platform has zip support and I doubt many of our users (who are mostly developers for companies or open-source afficionadoes) are on dialup connections. Alternatively (this is what JonAS has done for example) we could just have .tgz files which the Windows Winzip can handle. This saves the release manager work and reduces user confusion slightly, as they are faced with less download choices. I see the latter (user confusion) increasing when we have JRE1.4 and JRE5.0 distros. Do we do any line ending processing for tgz and zip ? The expectation is that .tgz distributions use unix LF, and zip files use CRFL. If tgz and zip are identical ( and I assume it's CRLF since the build is on windows ) - then it's a good idea to have only zip ( tgz with CRLF is confusing ) Costin Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.5] Packaging
Remy Maucherat wrote: I'm planning to do the following changes to packaging: - removing commons-launcher from the final distribution (I see little use of it, since we have good scripts and native wrappers available); it will stay as a dependency to launch stuff during the build process - new release archives based on the contents of the "compat" folder, for JRE 1.4 users (the default distributions will be for JRE 5.0) Is JRE1.5 final available ? Last I checked it was still beta. I think it's a good idea to keep 1.4 as default target at least until 1.5 is out of beta. Are you going to include xerces or just leave it out and tell 1.3 users to download an xml parser and install it in common/lib ? - new release archives for the admin webapp (= not in the main archive; not everyone uses it, and it's quite large) Not sure what that means :-). - the Windows installer will remain the same for now (= an offline installer), as I don't see how to make it an online installer and still respect the mirror scheme we use Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
I think we long ago agreed not to vote -1 just because you want somebody to work on a different codebase :-) If Keith has an itch in 4.1 branch - and if he can find 2 more +1 votes, than it's his right to have a release, and the 4.1 branch will become "maintained". A branch is maintained if there are committers interested to maintain it - not if someone else decides it shouldn't be maintained and they should do something else. 4.1 is stable and works good enough - yes, 5.x is faster and has better architecture, but some people don't like to change production systems very often, and it is very good for them to know that what they are using is still maintained ( we're not msft to make money by forcing people to upgrade ) Costin Shapira, Yoav wrote: Hi, The 4.1.31 maintenance release should happen: [ ] Yes [ X ] No -1 on this release. Reasons have been stated in detail in the other thread, but to summarize this branch is no longer maintained and users should upgrade to 5.x or custom-patch if they have an emergency. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common/endorsed & classLoader
Bill Barker wrote: Are endorsed jars getting loaded somewhere else other than Bootstrap? Using the default startup scripts, they are loaded into the System CL (the only way a delegating CL can find them :). You mean -Djava.endorsed.dirs in catalina scripts, correct? Yup. BTW, why do they need to be loaded into the System CL in the scripts on top of commonLoader in Bootstrap using common.loader property in org/apache/catalina/startup/catalina.properties? CLFactory sets delegate=true on the StandardCL instances, so they are delegating loaders (This is in 5.0.x; in 5.5 StandardCL is pretty much just a URLCL, which delegates). As a result, they will always find the xml classes in the System CL (for JVM >= 1.4). Thus if you want to change your xml classes from the JVM default, that's where you have to have them. It doesn't really matter if they are in the common.loader property or not (except, of course, for JVM < 1.4 :). To make things a bit more interesting, I believe there are some checks in JDK1.4 to prevent you to override rt.jar classes. That's what "endorsed" really does, allow you to bypass those checks. I don't think we managed to get xerces and jaxp to load from a classloader even with delegation disabled. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Jeanfrancois Arcand wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. Except if you turn validation on, which will not works since XML schema is not supported in Crimson or early version of Xerces (remember the nightmare) Yes, schema validation on JDK1.4 is lost because the parser doesn't support it well enough. I think it may be better to just check if the parser supports schema validation, and if not just display a warning that schema validation is disabled on parser that don't support it. It's easy to detect what version of xerces or if crimson is used. Fact is a lot of parsers don't support schema validation, and it is better to allow tomcat to work with any parser than try to force a specific version of parser. Well, the right solution is to just remove the option to turn schema validation on at startup - it is a huge waste of time at startup, it should be done only at deploy time by deploy tools :-) I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. One question we should explore is do we really wants to have a dependencies on Xerces? Like you already said, a pull parser might be better, smaller and more stable than having to rely on Xerces. Not sure if pull parser supports schema yet... +1 of dropping Xerces ;-) I don't think many pull parsers support schema, they are supposed to be faster and simpler :-) It's not about dropping xerces - we will still use the xerces inside jdk1.4 and jdk1.5 - we just shouldn't force a specific version and take all the pain for endorsed.dir - but let the user use whatever Jaxp parser he wants and disable schema validation if the parser doesn't support it. Costin -- Jeanfrancois them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. The disk space benefits aren't worth it. The central administration benefits might be, but I wonder how many people use this. Maybe an informal survey on the user list is worth doing? How about the other way around - stop support for the combined tomcat, and default to multi-user ( or multi-config ). I would be very happy to see the server layout change to support multiple configurations. Something like: /bin /lib - with manifest/properties file used to select what goes to common, server, shared :-) /servers /servers/all /servers/minimal With conf/ and webapps/ under each server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDT and Jasper
Remy Maucherat wrote: Remy Maucherat wrote: Hi, I've changed my mind a lot on this particular subject, but I'm still investigating. I'm looking at JDT right now, for use in Jasper, to replace Ant + javac task as the default Java compiler. It might be mature enough, and would run with a JRE. It is also relatively small (the whole compiler is less about 1.5M after trimming stuff from the jdtcore JAR, to compare with the Ant JAR which doesn't do much by itself and is slightly less than 1M). The other advantages: - loads "source dependencies" from the classloader - good error reporting API (no need for hackish text output capture anymore) Note: The license seems ok (Cocoon uses it already). To restate maybe a little more clearly, we would go back to having more than one compiler, with the two supported options being: - Ant with javac task (which AFAIK supports virtually all the compilers) - (and shipped by default) JDT That sounds better :-). Since JDT is from eclipse, we can also use the idea of plugin here - and have the javac task and other compilers as separate plugins the user can download and install. I'm making some progress with the class loader - modules placed in server/webapps/ can now be loaded ( with Class.forName or equiv ) from the server class loader, and can access classes from each other. Reloading of server classes also seems to work now, after serveral problems ( at least for the smtp connector I'm playing with ). My current approach is to use server/webapps as the equivalent of eclipse plugins - with a ContainerServlet that does all initialization, etc. It just reuses all the webapp infrastrucutre ( manager can control modules, etc ). That means an ant/javac plugin could be packaged as a ( priviledged ) war and deployed in tomcat. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: both jdk1.5 and jdk1.4 needed to build tomcat????
What I did is add target="1.3" source="1.3" on each target in build.xml files failing under 1.5. Also in Eclipse java/compiler/compliance - 1.3, and same in idea. This lets me compile with 1.5 or eclipse ( I have it set to generate classes in the same dir ant would compile - so ant is only doing the packing ). I use JDK1.3 mostly for OptimizeIt, I have a very old version that doesn't support 1.4+. Costin Shapira, Yoav wrote: Hi, Note also that CVS HEAD is not guaranteed to be stable until we make a release. If you want a stable reproduction of current code, do your checkouts with the TOMCAT_5_0 branch. Yoav Shapira Millennium Research Informatics -Original Message- From: Hiller, Dean D (Dean) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 5:52 PM To: Tomcat Developers List Subject: RE: both jdk1.5 and jdk1.4 needed to build tomcat Thanks, I will do that. dean -Original Message- From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:49 PM To: Tomcat Developers List Subject: Re: both jdk1.5 and jdk1.4 needed to build tomcat It works for me with those steps using JDK 1.4, no problem if you need to try again, I suggest to clean your machine, and start over (this includes all the downloads in /usr/share/java) Filip - Original Message - From: "Hiller, Dean D (Dean)" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, August 12, 2004 4:38 PM Subject: both jdk1.5 and jdk1.4 needed to build tomcat I for some reason needed 1.4jdk and 1.5jdk to build tomcat. My steps are below. Any help would be appreciated as to how I can correct this Using jdk1.5 and Filip's great list of steps(thanks Filip, the list made life easier, and I am almost there) I go through the list to build tomcat 1. cvs co jakarta-tomcat-5 works great 2. cd jakarta-tomcat-5 obviously works 3. ant update works great 4. ant download breaks, and looks like 1.5 problems, so I switch to 1.4 and it works!!!. Basically the tomcat-deps module is not compiling in 1.5 as it conflicts with many different things. 5. ant dist sticking with 1.4 doesn't work, and going to 1.5 doesn't work. So now, I am basically stuck again on Jakarta-tomcat-5/build/classes not compiling at all. I am not sure where to go. I am trying to think what are the possibilities of what is wrong. 1. I need to do some configuration which I haven't done. 2. Builds currently don't work if starting from scratch as something was modified on accident? 3. they do work if you already had everything downloaded? I followed the steps above twice. I don't suppose having to switch between 1.4 and 1.5 makes my situation easier to debug, as that could be part of my problem too. Don't suppose someone just wants to send me a zipped up version of their view that builds?? I would like to fix this and will continue to look at the problem, but I am not really sure where to start so it may take me some time as I jump into all this. Thanks, dean -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 2:16 PM To: 'Tomcat Developers List' Subject: RE: tomcat build broken with strange javac error(never seen this one before) 1. Ignore the "stop sending me mail" message. Someone has managed to get themselves subscribed to the list and is obviously incapable of following the simple instructions included in every mail to unsubscribe. One of the list owners (of which I am one) will sort this out. 2. & 3. The right place to posts depends on the question and will always be a judgement call and different people will make different judgements. I wouldn't worry about it too much - personally I thought this one was on the border line. Mark -Original Message- From: Hiller, Dean D (Dean) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 8:29 PM To: Tomcat Developers List Subject: RE: tomcat build broken with strange javac error(never seen this one before) Huh, 3 questions about this mail list then. 1. confused by "stop sending me mail" when this is my first mail to this list 2. Huh, I thought building would be a developer issue 3. Where should I post future questions on the source code I am looking at in tomcat??? The users list states it is for configuration issues, etc. ps. Thanks shapira for the jdk1.5 note. That makes sense, duh. Thanks, dean -Original Message- From: Joshua Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 1:21 PM To: Tomcat Developers List Subject: Re: tomcat build broken with strange javac error(never seen this one before) Stop sending me e-mail. - Original Message - From: "Hiller, Dean D (Dean)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 12, 2004 3:00 PM Subject: tomcat build broken with strange javac error(never seen this one before) I have never seen an error from javac like this before(and I am by no means new to java). I have even read the JLS and
Re: JDT and Jasper
Are you talking about the compiler in eclipse ? Does it allow a way to set up to use jikes ? Costin Remy Maucherat wrote: Hi, I've changed my mind a lot on this particular subject, but I'm still investigating. I'm looking at JDT right now, for use in Jasper, to replace Ant + javac task as the default Java compiler. It might be mature enough, and would run with a JRE. It is also relatively small (the whole compiler is less about 1.5M after trimming stuff from the jdtcore JAR, to compare with the Ant JAR which doesn't do much by itself and is slightly less than 1M). The other advantages: - loads "source dependencies" from the classloader - good error reporting API (no need for hackish text output capture anymore) Note: The license seems ok (Cocoon uses it already). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
To clarify: I wasn't proposing to remove the separate product installation and runtime, but the contrary - to make that the default. Right now tomcat operates in 2 modes - one where CATALINA_HOME is identical with CATALINA_BASE, and one where you have them separate ( like you use ). I think it would be cleaner if separate mode will be the default, with the runtime files always in a separate hierarchy. But it's more of a cosmetic change. Costin Rainer Jung wrote: We are using it also and it is very helpful. It is one of the standard product features of a container to be able to seperate container product installation from runtime instance specific files. It works very nicely with tomcat. We can even allow instance admins to extend TC by changing to an alternate catalina.properties file (classloader definitions). It's not just a question of users sharing the base installation. I have a small enhancement request: we regularly change catalina.sh to include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We do this immediately after CATALINA_TEMPDIR is set. This way all instances share the same catalina.sh and instance specific commandline flags (memory sizing, catalina.properties, ...) can be done in the instance local setenvInstance.sh without changing the product installation. Please keep the separation of product installation and runtime instance. Rainer Jung kippdata informationstechnologie George Sexton wrote: How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Petr Jiricka wrote: Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. Hi Tomcat developers, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. If you remove common/endorsed: - jdk1.3 - it'll work if you add your own parser in common/lib or jre/lib/ext or classpath - jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema validation might fail, everything else should work. - jdk1.5 - AFAIK everything should work. The reason endorsed was added is JDK1.4, where we had to add newer org.apache.xerces and javax.xml ( replacing what's in rt.jar ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
