RE: Tomcat 4.1.x Clustering
Just had a look at it. Not tried it yet, but have a query. Why haven't you used JavaGroups for this? Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 23:23 To: Tomcat Developers List Subject: Tomcat 4.1.x Clustering okey dokey, a pre taste of what tomcat 5 is going to include, a fully working version of clustering for your Tomcat 4.1.x codebase. I wrote this against 4.1.12, but intend to test it with later versions as well. Let me know if you beat me to it. http://www.filip.net/tomcat-clustering.html Tomcat 5, will ship with clustering, or at least a module with clustering :) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 9:33 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Costin Manolache wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: costin 2003/03/07 22:52:36 Modified:coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Log: A Server is not required for non-standalone operation. In fact, Embeded doesn't define a server, and most apps embeding tomcat use this approach. All we care is an Engine. Hmm, yes. Well, actually, no. In that junk code (I should have put a fixme), I'm trying to look up the hosts. I was planning to rewrite the code using JMX and remove the coupling (the only good solution IMO). What do you think ? It's even better. But you can just look for contexts - using the j2eeType=WebModule to do the query ( but you'll have to parse the host and path from the name - the spec doesn't define a host attribute ). What I think is that we should clean up a bit before 5.0 is final - we have Embeded which doesn't extend or use Service or Server, and is probably used either directly or as a model by people. Engine is the only stable point ( which makes sense ), we should deprecate and make sure we don't depend too much on Service or Server ( except the standalone case ), otherwise some features will not work very well if tomcat is embeded in some other app. And we should clean up the naming conventions ASAP. We don't need 5 names ( server name, service name, engine name, jvmroute and JMX domain ) - all we need is a Servlet Engine ID - common to all of them. That sounds reasonable. 4 unique IDs seems overkill. Remy - 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] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
DO NOT REPLY [Bug 17822] New: - Jars on [WEBAPLICATION]/WEB-INF/lib are sended twice to the classpath compiler
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17822 Jars on [WEBAPLICATION]/WEB-INF/lib are sended twice to the classpath compiler Summary: Jars on [WEBAPLICATION]/WEB-INF/lib are sended twice to the classpath compiler Product: Tomcat 4 Version: 4.1.21 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When Jasper 2 calls the Javac compiler to compile a JSP page, the classpath parameters has inside twice the path to jars on [WEBAPLICATION]/WEB-INF/lib. Works fine, but maybe it could break some platforms if there are many jars on the WEB-INF/lib dir. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17827] New: - JSPC does not work unless catalina.home is set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17827.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17827
JSPC does not work unless catalina.home is set
Summary: JSPC does not work unless catalina.home is set
Product: Tomcat 4
Version: 4.1.21
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This is actually on build 4.1.22 Alpha
In o.a.j.compiler.Compiler
Line # 164 project.setBasedir( System.getProperty(catalina.home));
if the System.getProperty() returns null a NullPointerException is thrown.
the code used to say
if(System.getProperty(catalina.home) != null){
project.setBasedir( System.getProperty(catalina.home));
}
any reason this was changed??
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tomcat 4.1.22 Alpha released
Remy Maucherat wrote: Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ I've got very strange problem when building 4.1.22, some jar are corrupted !!! BTW, I'm using ant 1.5.2 (maybe a problem with it ?) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tomcat 4.1.22 Alpha released
Henri Gomez wrote: Remy Maucherat wrote: Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ I've got very strange problem when building 4.1.22, some jar are corrupted !!! BTW, I'm using ant 1.5.2 (maybe a problem with it ?) The problem came from the fact I built ant 1.5.2 with jikes 1.18 and IBM SDK 1.4.0 on linux. I rebuilt ant 1.5.2 with IBM SDK 1.3.1 and no more problems. False alert (but may be Costin could forward it to ant-dev since I didn't track this list right now). Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.1.x Clustering
incompatible licenses Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 2:53 AM To: 'Tomcat Developers List' Subject: RE: Tomcat 4.1.x Clustering Just had a look at it. Not tried it yet, but have a query. Why haven't you used JavaGroups for this? Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 23:23 To: Tomcat Developers List Subject: Tomcat 4.1.x Clustering okey dokey, a pre taste of what tomcat 5 is going to include, a fully working version of clustering for your Tomcat 4.1.x codebase. I wrote this against 4.1.12, but intend to test it with later versions as well. Let me know if you beat me to it. http://www.filip.net/tomcat-clustering.html Tomcat 5, will ship with clustering, or at least a module with clustering :) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 9:33 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Costin Manolache wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: costin 2003/03/07 22:52:36 Modified:coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Log: A Server is not required for non-standalone operation. In fact, Embeded doesn't define a server, and most apps embeding tomcat use this approach. All we care is an Engine. Hmm, yes. Well, actually, no. In that junk code (I should have put a fixme), I'm trying to look up the hosts. I was planning to rewrite the code using JMX and remove the coupling (the only good solution IMO). What do you think ? It's even better. But you can just look for contexts - using the j2eeType=WebModule to do the query ( but you'll have to parse the host and path from the name - the spec doesn't define a host attribute ). What I think is that we should clean up a bit before 5.0 is final - we have Embeded which doesn't extend or use Service or Server, and is probably used either directly or as a model by people. Engine is the only stable point ( which makes sense ), we should deprecate and make sure we don't depend too much on Service or Server ( except the standalone case ), otherwise some features will not work very well if tomcat is embeded in some other app. And we should clean up the naming conventions ASAP. We don't need 5 names ( server name, service name, engine name, jvmroute and JMX domain ) - all we need is a Servlet Engine ID - common to all of them. That sounds reasonable. 4 unique IDs seems overkill. Remy - 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] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.1.x Clustering
How is LGPL incompatible? I can understand GPL. Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 10 March 2003 17:45 To: Tomcat Developers List Subject: RE: Tomcat 4.1.x Clustering incompatible licenses Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 2:53 AM To: 'Tomcat Developers List' Subject: RE: Tomcat 4.1.x Clustering Just had a look at it. Not tried it yet, but have a query. Why haven't you used JavaGroups for this? Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 23:23 To: Tomcat Developers List Subject: Tomcat 4.1.x Clustering okey dokey, a pre taste of what tomcat 5 is going to include, a fully working version of clustering for your Tomcat 4.1.x codebase. I wrote this against 4.1.12, but intend to test it with later versions as well. Let me know if you beat me to it. http://www.filip.net/tomcat-clustering.html Tomcat 5, will ship with clustering, or at least a module with clustering :) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 9:33 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Costin Manolache wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: costin 2003/03/07 22:52:36 Modified:coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Log: A Server is not required for non-standalone operation. In fact, Embeded doesn't define a server, and most apps embeding tomcat use this approach. All we care is an Engine. Hmm, yes. Well, actually, no. In that junk code (I should have put a fixme), I'm trying to look up the hosts. I was planning to rewrite the code using JMX and remove the coupling (the only good solution IMO). What do you think ? It's even better. But you can just look for contexts - using the j2eeType=WebModule to do the query ( but you'll have to parse the host and path from the name - the spec doesn't define a host attribute ). What I think is that we should clean up a bit before 5.0 is final - we have Embeded which doesn't extend or use Service or Server, and is probably used either directly or as a model by people. Engine is the only stable point ( which makes sense ), we should deprecate and make sure we don't depend too much on Service or Server ( except the standalone case ), otherwise some features will not work very well if tomcat is embeded in some other app. And we should clean up the naming conventions ASAP. We don't need 5 names ( server name, service name, engine name, jvmroute and JMX domain ) - all we need is a Servlet Engine ID - common to all of them. That sounds reasonable. 4 unique IDs seems overkill. Remy - 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] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail has been scanned for all viruses by Star Internet. The service is
RE: Tomcat 4.1.x Clustering
uuhh, it's been a long debate, not sure if it's archived somewhere, and it wasn't my decision. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:49 AM To: 'Tomcat Developers List' Subject: RE: Tomcat 4.1.x Clustering How is LGPL incompatible? I can understand GPL. Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 10 March 2003 17:45 To: Tomcat Developers List Subject: RE: Tomcat 4.1.x Clustering incompatible licenses Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 2:53 AM To: 'Tomcat Developers List' Subject: RE: Tomcat 4.1.x Clustering Just had a look at it. Not tried it yet, but have a query. Why haven't you used JavaGroups for this? Dave. -Original Message- From: Filip Hanik [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 23:23 To: Tomcat Developers List Subject: Tomcat 4.1.x Clustering okey dokey, a pre taste of what tomcat 5 is going to include, a fully working version of clustering for your Tomcat 4.1.x codebase. I wrote this against 4.1.12, but intend to test it with later versions as well. Let me know if you beat me to it. http://www.filip.net/tomcat-clustering.html Tomcat 5, will ship with clustering, or at least a module with clustering :) Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, March 08, 2003 9:33 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Costin Manolache wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: costin 2003/03/07 22:52:36 Modified:coyote/src/java/org/apache/coyote/tomcat5 MapperListener.java Log: A Server is not required for non-standalone operation. In fact, Embeded doesn't define a server, and most apps embeding tomcat use this approach. All we care is an Engine. Hmm, yes. Well, actually, no. In that junk code (I should have put a fixme), I'm trying to look up the hosts. I was planning to rewrite the code using JMX and remove the coupling (the only good solution IMO). What do you think ? It's even better. But you can just look for contexts - using the j2eeType=WebModule to do the query ( but you'll have to parse the host and path from the name - the spec doesn't define a host attribute ). What I think is that we should clean up a bit before 5.0 is final - we have Embeded which doesn't extend or use Service or Server, and is probably used either directly or as a model by people. Engine is the only stable point ( which makes sense ), we should deprecate and make sure we don't depend too much on Service or Server ( except the standalone case ), otherwise some features will not work very well if tomcat is embeded in some other app. And we should clean up the naming conventions ASAP. We don't need 5 names ( server name, service name, engine name, jvmroute and JMX domain ) - all we need is a Servlet Engine ID - common to all of them. That sounds reasonable. 4 unique IDs seems overkill. Remy - 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] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
Re: [ANN] Tomcat 4.1.22 Alpha released
Henri Gomez wrote: Henri Gomez wrote: Remy Maucherat wrote: Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ I've got very strange problem when building 4.1.22, some jar are corrupted !!! BTW, I'm using ant 1.5.2 (maybe a problem with it ?) The problem came from the fact I built ant 1.5.2 with jikes 1.18 and IBM SDK 1.4.0 on linux. I rebuilt ant 1.5.2 with IBM SDK 1.3.1 and no more problems. False alert (but may be Costin could forward it to ant-dev since I didn't track this list right now). There is a problem with ant1.5.2 with WinZip - a new release will be made soon to fix it. I don't know what ant can do wrt the compiler. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New SSL HOWTOs and jsse in 1.1.8
In regards to this document: http://w6.metronet.com/~wjm/tomcat/2001/Aug/msg00494.html I do not believe jsse will work with 1.1.8. There are some native java classes that are missing in JDK 1.1.8 that are required by jsse specifically: java.security.PrivilegedAction. This is required in the java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()) method that is required to allow connections to use secure urls such as ldaps https etc. I don't have security access to the java.security file so I have to do everything programmatically but from what I've read using the addProvider method in your code is equivalent to putting the security.provider.3=com.sun.net.ssl.internal.ssl.Provider line in the java.security file so it's not really necessary for us to edit the java.security file. I can have it changed but since our install of 1.1.8 is on a shared afs volume it may affect other servers that do not have jsse installed so I'm reluctant to do that just for testing purposes. Any suggestions? Thanks Lawrence Symms Systems Analyst OIT-Unversity of Maryland 3101 Mitchell Bldg 301-405-7259
JK2 for AOLserver 4.0
Hello, I am a developer at AOL and have been recently working on a JK2 family module for AOLserver. The module is ready now and I'd like to take steps necessary to contribute the sources to Tomcat project. I read the guidelines for contribution, but still am a bit confused about the process, e.g., -- should I formulate proposal to a PMC? -- do I need write permission to CVS to make the submission or posting an archive with instructions to tomcat-dev list is the way to go? -- how do I interact with Decision Makers should the code manifest any deficiency? Please advise. In the meantime, some details about this software Name: nsjk2 (libnsjk2.so) Versions: Tomcat 4.1.18, AOLserver 4.0(beta) Tested on OS: Solaris 2.7 Compiles under: Forte 6, GCC Functional Summary: -- adds support for Java Servlets and JSP to AOLserver environment; -- supports virtual servers -- when Tomcat runs in-process and talks with JK2 via JNI channel, Java servlets can access native dynamic content mechanism (ADP) and evaluate Tcl scripts or include ADP pages. Source files affected: jakarta-tomcat-connectors-src/jk/build.properties jtc-src/jk/native2/build.xml jtc-src/jk/native2/server (adds aolserver directory with C and Java sources) Thank you, Alexander Leykekh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17848] New: - Support XHTML media type (RFC 3236) in Catalina
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17848. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17848 Support XHTML media type (RFC 3236) in Catalina Summary: Support XHTML media type (RFC 3236) in Catalina Product: Tomcat 4 Version: Nightly Build Platform: All URL: http://www.ietf.org/rfc/rfc3236.txt OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Please add a mapping for the XHTML media type within catalina/src/conf/web.xml: mime-mapping extensionxht/extension mime-typeapplication/xhtml+xml/mime-type /mime-mapping mime-mapping extensionxhtml/extension mime-typeapplication/xhtml+xml/mime-type /mime-mapping Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17849] New: - Support XHTML media type (RFC 3236) in Catalina
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17849 Support XHTML media type (RFC 3236) in Catalina Summary: Support XHTML media type (RFC 3236) in Catalina Product: Tomcat 5 Version: Nightly Build Platform: All URL: http://www.ietf.org/rfc/rfc3236.txt OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Please add a mapping for the XHTML media type within catalina/src/conf/web.xml: mime-mapping extensionxht/extension mime-typeapplication/xhtml+xml/mime-type /mime-mapping mime-mapping extensionxhtml/extension mime-typeapplication/xhtml+xml/mime-type /mime-mapping Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17851] New: - WEB-INF/{lib,class} inconsistently added to JSP classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17851.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17851
WEB-INF/{lib,class} inconsistently added to JSP classpath
Summary: WEB-INF/{lib,class} inconsistently added to JSP
classpath
Product: Tomcat 4
Version: 4.1.18
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm building a web application by making a JAR file for the guts of the
application and a bunch of JSPs for the application itself. As long as I don't
use any classes from my JAR file, things work, but it appears that the javac
used to build .class files out of my .jsp files doesn't have that JAR file in
its classpath. The same appears to be true of classes in the WEB-INF/classes
directory.
Here's the simplest way I have to reproduce the problem:
I created a directory under webapps called playground, and created a
WEB-INF/classes directory under that. Elsewhere, I wrote a public class named
Hello (no package, that's the whole name) with one public method, public
String run(), which just returns the string Hello, sailor!. I compiled it to
a .class file and dropped that in WEB-INF/classes (on another occasion I
packaged that into a JAR and put that into WEB-INF/lib -- nothing changes).
Then, I created an index.jsp that contains nothing but the line:
jsp:useBean id=h class=Hello /
When I go to that page, I get an error saying it can't be compiled because the
symbol Hello can't be found. But if I change it to:
jsp:useBean id=h class=Hello type=Object /
It actually compiles. And if I add the following line:
%= h %
I get a string of the form [EMAIL PROTECTED], so I can tell the Java runtime was able
to correctly load the class and call its constructor and everything. And if I
add a toString method to my Hello class, its return value is correctly shown
there.
So it looks to me like WEB-INF/{lib,class} are in the classpath at the JSP's
runtime, but not at its compile-time.
I have tested this on MacOS X with JDK 1.3.1 and 1.4.1, and on Solaris with JDK
1.4.1, and on Linux with JDK 1.4.1. It behaves the same way in all those cases.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17851] - WEB-INF/{lib,class} inconsistently added to JSP classpath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17851.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17851
WEB-INF/{lib,class} inconsistently added to JSP classpath
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||DUPLICATE
--- Additional Comments From [EMAIL PROTECTED] 2003-03-11 00:13 ---
*** This bug has been marked as a duplicate of 10036 ***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
luehe 2003/03/10 17:39:31
Modified:.build.xml
Log:
Made location of JSP and Servlet API classes configurable
Revision ChangesPath
1.94 +9 -7 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -r1.93 -r1.94
--- build.xml 5 Mar 2003 21:25:51 - 1.93
+++ build.xml 11 Mar 2003 01:39:31 - 1.94
@@ -45,6 +45,8 @@
property name=servlet.home value=../jakarta-servletapi-5/jsr154/dist/
property name=jsp.home value=../jakarta-servletapi-5/jsr152/dist/
property name=tomcat.build value=${basedir}/build/
+ property name=servletapi.jar
value=${tomcat.build}/common/lib/servlet-api.jar/
+ property name=jspapi.jar value=${tomcat.build}/common/lib/jsp-api.jar/
property name=tomcat.dist value=${basedir}/dist/
property name=tomcat.release value=${basedir}/release/
property name=webapps.buildvalue=${catalina.home}/webapps/build/
@@ -78,11 +80,11 @@
mkdir dir=${tomcat.build}/common/lib /
uptodate property=servletapi.build.notrequired
- targetfile=${tomcat.build}/common/lib/servlet-api.jar
+ targetfile=${servletapi.jar}
srcfiles dir=${api.home}/jsr154/src includes=** /
/uptodate
uptodate property=jspapi.build.notrequired
- targetfile=${tomcat.build}/common/lib/jsp-api.jar
+ targetfile=${jspapi.jar}
srcfiles dir=${api.home}/jsr152/src includes=** /
/uptodate
@@ -124,7 +126,7 @@
ant dir=${api.home}/jsr154 target=jar
property name=servlet-api.build value=${tomcat.build} /
-property name=servlet-api.jar
value=${tomcat.build}/common/lib/servlet-api.jar/
+property name=servlet-api.jar value=${servletapi.jar}/
/ant
/target
@@ -132,7 +134,7 @@
echo== Building: ${jsp-api.jar}/echo
ant dir=${api.home}/jsr152 target=jar
property name=jsp-api.build value=${tomcat.build} /
-property name=jsp-api.jar
value=${tomcat.build}/common/lib/jsp-api.jar/
+property name=jsp-api.jar value=${jspapi.jar}/
/ant
!-- clean up --
delete file=${tomcat.build}/manifest /
@@ -185,7 +187,7 @@
property name=tomcat-coyote.jar
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
property name=tomcat-util.jar
value=${tomcat.build}/server/lib/tomcat-util.jar/
- property name=servlet.jar
value=${tomcat.build}/common/lib/servlet-api.jar/
+ property name=servlet.jar value=${servletapi.jar}/
/ant
/target
@@ -431,9 +433,9 @@
echo== Building: commons-el /echo
ant dir=${cvs.base}/jakarta-commons/el target=jar-only
-property name=servlet-api.jar
location=${tomcat.build}/common/lib/servlet-api.jar /
+property name=servlet-api.jar location=${servlet-api.jar} /
property name=commons-el.jar
location=${tomcat.build}/common/lib/commons-el.jar /
-property name=jsp-api.jar
value=${tomcat.build}/common/lib/jsp-api.jar/
+property name=jsp-api.jar value=${jspapi.jar}/
property name=compile.optimize value=false /
property name=build.home value=${tomcat.build} /
/ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java ServerLifecycleListener.java
amyroh 2003/03/10 19:25:52
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java ServerLifecycleListener.java
Log:
Set to use JSR77 names as default.
Revision ChangesPath
1.41 +11 -8
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java
Index: MBeanFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- MBeanFactory.java 19 Sep 2002 22:55:48 - 1.40
+++ MBeanFactory.java 11 Mar 2003 03:25:52 - 1.41
@@ -1227,13 +1227,16 @@
*
* @exception Exception if a component cannot be removed
*/
-public void removeContext(String name) throws Exception {
+public void removeContext(String name, String pname) throws Exception {
// Acquire a reference to the component to be removed
ObjectName oname = new ObjectName(name);
-String serviceName = oname.getKeyProperty(service);
-String hostName = oname.getKeyProperty(host);
-String contextName = getPathStr(oname.getKeyProperty(path));
+ObjectName poname = new ObjectName(pname);
+String serviceName = poname.getKeyProperty(service);
+String hostName = poname.getKeyProperty(host);
+String pathname = oname.getKeyProperty(name);
+String path = pathname.substring(pathname.lastIndexOf('/'));
+String contextName = getPathStr(path);
Server server = ServerFactory.getServer();
Service service = server.findService(serviceName);
Engine engine = (Engine) service.getContainer();
1.38 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ServerLifecycleListener.java 12 Feb 2003 22:11:27 - 1.37
+++ ServerLifecycleListener.java 11 Mar 2003 03:25:52 - 1.38
@@ -367,6 +367,7 @@
try {
+setJsr77Names(true);
MBeanFactory factory = new MBeanFactory();
createMBeans(factory);
createMBeans(ServerFactory.getServer());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/context contexts.jsp
amyroh 2003/03/10 19:26:19
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
Lists.java TomcatTreeBuilder.java
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/context
ContextForm.java ContextsForm.java
DeleteContextAction.java DeleteContextsAction.java
EditContextAction.java SaveContextAction.java
webapps/admin/context contexts.jsp
Log:
Update to use JSR77 names.
Revision ChangesPath
1.15 +16 -10
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/Lists.java
Index: Lists.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/Lists.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Lists.java3 Feb 2003 22:55:00 - 1.14
+++ Lists.java11 Mar 2003 03:26:19 - 1.15
@@ -229,16 +229,22 @@
throws Exception {
StringBuffer sb = new StringBuffer(host.getDomain());
-sb.append(:type=Context,host=);
-sb.append(host.getKeyProperty(host));
-sb.append(,service=);
-sb.append(host.getKeyProperty(service));
-sb.append(,*);
+sb.append(:j2eeType=WebModule,*);
+//sb.append(:type=Context,host=);
+//sb.append(host.getKeyProperty(host));
+//sb.append(,service=);
+//sb.append(host.getKeyProperty(service));
+//sb.append(,*);
ObjectName search = new ObjectName(sb.toString());
ArrayList contexts = new ArrayList();
Iterator names = mbserver.queryNames(search, null).iterator();
+String hostName = host.getKeyProperty(host);
+String queryString = Catalina:j2eeType=WebModule,name=//+hostName;
while (names.hasNext()) {
-contexts.add(names.next().toString());
+String name = names.next().toString();
+if (name.startsWith(queryString)) {
+contexts.add(name);
+}
}
Collections.sort(contexts);
return (contexts);
1.37 +38 -18
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java
Index: TomcatTreeBuilder.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/TomcatTreeBuilder.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- TomcatTreeBuilder.java13 Sep 2002 01:35:34 - 1.36
+++ TomcatTreeBuilder.java11 Mar 2003 03:26:19 - 1.37
@@ -103,6 +103,7 @@
// This SERVER_LABEL needs to be localized
private final static String SERVER_LABEL = Tomcat Server;
+public final static String DOMAIN = Catalina;
public final static String SERVER_TYPE = Catalina:type=Server;
public final static String FACTORY_TYPE = Catalina:type=MBeanFactory;
public final static String SERVICE_TYPE = Catalina:type=Service;
@@ -110,6 +111,7 @@
public final static String CONNECTOR_TYPE = Catalina:type=Connector;
public final static String HOST_TYPE = Catalina:type=Host;
public final static String CONTEXT_TYPE = Catalina:type=Context;
+public final static String CONTEXT_JSR77_TYPE = Catalina:j2eeType=WebModule;
public final static String DEFAULTCONTEXT_TYPE = Catalina:type=DefaultContext;
public final static String LOADER_TYPE = Catalina:type=Loader;
public final static String MANAGER_TYPE = Catalina:type=Manager;
@@ -317,8 +319,10 @@
while (contextNames.hasNext()) {
String contextName = (String) contextNames.next();
ObjectName objectName = new ObjectName(contextName);
+String name = objectName.getKeyProperty(name);
+String path = name.substring(name.lastIndexOf('/'));
String nodeLabel =
-Context ( + objectName.getKeyProperty(path) + );
+Context ( + path + );
TreeControlNode contextNode =
new TreeControlNode(contextName,
Context.gif,
@@ -326,7 +330,9 @@
EditContext.do?select= +
URLEncoder.encode(contextName) +
nodeLabel= +
-URLEncoder.encode(nodeLabel),
+URLEncoder.encode(nodeLabel) +
+hostName= +
+URLEncoder.encode(hostName),
content,
DO NOT REPLY [Bug 17859] New: - need cygwin friendly JAVA_ENDORSED_DIRS property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17859. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17859 need cygwin friendly JAVA_ENDORSED_DIRS property Summary: need cygwin friendly JAVA_ENDORSED_DIRS property Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] in: bin/catalina.sh line: 98-107 PROBLEM: Need to convert JAVA_ENDORSED_DIRS property to cygwin/windows friendly format. FIX: # For Cygwin, switch paths to Windows format before running java if $cygwin; then JAVA_HOME=`cygpath --path --windows $JAVA_HOME` CATALINA_HOME=`cygpath --path --windows $CATALINA_HOME` CATALINA_BASE=`cygpath --path --windows $CATALINA_BASE` CATALINA_TMPDIR=`cygpath --path --windows $CATALINA_TMPDIR` CLASSPATH=`cygpath --path --windows $CLASSPATH` JSSE_HOME=`cygpath --path --windows $JSSE_HOME` JAVA_ENDORSED_DIRS=`cygpath --path --windows $JAVA_ENDORSED_DIRS` fi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17860] New: - JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17860 JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property Summary: JAVA_ENDORSED_DIRS overrides jdk1.4's default java.endorsed.dirs property Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] PROBLEM: The default property for JDK1.4's 'java.endorsed.dirs' property is /install- path/j2sdk/jre/lib/endorsed (or $JAVA_HOME/jre/lib/endorsed). Catalina's start- up scripts do not preserve this value and overrides/replaces it with whatever is defined in bin/setclasspath.sh (and bin/setclasspath.bat). FIX: (setclasspath.sh: line: 30) from: JAVA_ENDORSED_DIRS=$BASEDIR/bin:$BASEDIR/common/endorsed to: JAVA_ENDORSED_DIRS=$JAVA_HOME/jre/lib/endorsed:$BASEDIR/bin:$BASEDIR/commo n/endorsed FIX: (setclasspath.bat: line: 36) from: set JAVA_ENDORSED_DIRS=%BASEDIR%\bin;%BASEDIR%\common\endorsed to: set JAVA_ENDORSED_DIRS=%JAVA_HOME%\jre\lib\endorsed;%BASEDIR%\bin;%BASEDIR% \common\endorsed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17849] - Support XHTML media type (RFC 3236) in Catalina
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17849 Support XHTML media type (RFC 3236) in Catalina [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 07:19 --- *** This bug has been marked as a duplicate of 17848 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17848] - Support XHTML media type (RFC 3236) in Catalina
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17848. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17848 Support XHTML media type (RFC 3236) in Catalina --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 07:19 --- *** Bug 17849 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Tomcat 4.1.22 Alpha released
Tomcat 4.1.22 Alpha is now available for testing. Changes over 4.1.21 include: - Fix for mangling with JSPC - Fix precompilation with tag libraries packaged in JARs - Fix JDBC store thread safety bug which was causing improper session access The release notes include the full list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.22-alpha/ Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-commons-daemon could use that ?
Mark R. Diggory wrote: (Please excuse the cross post, I wanted to get this out onto the the Commons Development List and to JPackage as well. I think the Tomcat Lists seem to get a little crowded) Henri, I emailed the developer of Easy Posix (Greg Guerin). Turns out that its current implementation is dependent upon Ten , a Mac OS X package for MacJVM, so it is not deployable in the standard Linux OS. From my conversation with him, he spoke that he is planning to develop a straight JNI implementation of the EasyPosix interfaces in the future, but that if others went that route earlier he would have an interest. As there has already been much work in the JNI area with daemon, this would certainly seem an interesting co-evolution. Perhaps daemon could grow into quite a powerful java based service environment with the addition of a JNI Implementation of EasyPosix?! In jakarta-commons-daemon the JNI is limited to what was needed for the daemon. Cygwin supports a wide array of posix functions, and making sure the implementation of EasyPosix that worked on cygwin as well would provide a port of these functions to Windows via Cygwin. I am afraid that is not a very accepted solution. jakarta-commons-daemon (service) uses Cygwin and a lot of people were complaining about that. Apache has an already portable runtime: APR. It would be probably more efficient to bring an APR interface to JNI than to use a new runtime. And that is already some code in jakarta-connectors. Perhaps, even a standard could evolve to support a specific subset of posix-like Functions. Using something like EasyPosix as a guide, a java program (daemon or not) that needed greater access to POSIX functions could be ported to any system that EasyPosix was supported on, completely independent of its implementation on that system. It would possibly make java services quite cross-platform for at least in the unix/linux/darwin/cygwin world. Another point of interest: If JPackage produced a Tomcat RPM based on the current implementation of daemon and another implementation of daemon based on EasyPosix were developed. It would be easy to adapt to such a change. In the end, this would possibly make EasyPosix the means by which daemon could be ported to Darwin/Mac without the wieght of compiling or porting a JNI implementation. -Mark Henri Gomez wrote: I didn't track jakarta-commons-daemon but I know many of you here which are subscribed to it. What do you think of easyposix ? http://www.amug.org/~glguerin/sw/easyposix/overview.html Couldn't it be a nice add-on for daemon ? It's still related to tomcat since I need a very complete java service launcher for tomcat, and this easyposix as very nice features. Comments welcomed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Greg Guerin wrote: The supplied code only provides a Mac OS X implementation. That implementation uses JDirect-3, which is an Apple-specific means to call arbitrary native-code functions directly from Java, without an intervening JNI layer. All other platforms will need a JNI implementation for that platform. Absent a JNI implementation, the unimplemented implementation is used, i.e. UnPosix. See the docs for UnPosix for more details. You could pattern a JNI imp off the Mac OS X imp. The mapping of the Mac OS X implementation to JNI functions, and the bodies of the JNI functions themselves, should be fairly straightforward. That's because all the 'native' methods in the Ten class are essentially the names of C functions in the BSD/Posix library. Getting the callbacks right is a little trickier, but well within the skill-set of a capable JNI programmer. FYI, I have write Easy Posix JNI imp on my list of projects to do, but it's several items down in the queue right now, and at least a couple months or more away from getting to the head of the queue. The source may not be instantly portable to Linux, but it shouldn't be so different that it would be useless as a starting point. Or, if you wrote a JNI imp for Linux before I get to the JNI imp for Mac OS X, I wouldn't mind the positions being reversed. On another note, Apache has another package they've been working on that is a java based daemon for running Java programs as daemons on both Unix and Windows. http://jakarta.apache.org/commons/sandbox/daemon/ Henri Gomez (of www.jpackage.org - the packagers of the tomcat and other java based rpm's) and I reviewed your site and suggested to both Apache and JPackage that they should seriously take a look at your package as an additional tool for controlling Java based Daemons. While I am not actually an Apache developer, I have a great interest in the organization, regularly use the tools they develop and often try to make recommendations to improve the
