Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hello Remy, Thanx for your help and I hope we have now a better server.xml saving support. The new features are: - Clustering support - new 5.5 Connector attribute mapping support (with correct https saving) - backup the context.xml also as default mode - Internally you can save Server/Service/Host/Context at PrintWriter - configurable and extendable I hope we have fun with the new modul :-) Peter s.u Remy Maucherat schrieb: Remy Maucherat wrote: I've thought about this more. Actually, maybe it's better to leave an indirection (and keep the compatibility as a bonus). Otherwise, we start to have to hardcode (or make configurable = more complexity) an ObjectName. So I think you probably have made the right choice. Now that I have looked at it, I have some comments: - nearly all of the logging is done as log.error(e), which isn't cool, because it logs e.toString() rather than a stack trace Yes, this is a ToDO and I spent time for this. - I think some special cases are needed for Context handling (but it's not very high priority, the current stuff does the job): * avoid saving information which is in the default context configuration (I think MBeans should be added for exposing the context defaults) Yes, the Context handling is very spezial. Currently the only chance is parse context defaults at a fresh new Context and strip down the real Context. Bad,Bad and no easy :-( I hope we have at future a DefaultContext MBean and use this at HostConfig and StoreConfig. * don't save path except in server.xml I thing that can I fix! * don't save docBase if the webapp is in the host appBase OK! It seems to work as well as the old code, so it's great :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 49 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-13012005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-13012005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-13012005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-13012005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-13012005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2413012005, brutus:brutus-public:2413012005 Gump E-mail Identifier (unique within run) #26. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[APR-JAVA] cvs upload
Hi all, You can find the sources at: http://www.apache.org/~mturk/ File is: http://www.apache.org/~mturk/apr-java.tar.gz My intention is to put that inside: jakarta-tomcat-connectors/apr-java Although OtherBill thinks this is not a proper place to put that code, IMO until we have a generic infrastructure inside APR for OO languages glue code it can be placed here thought. How to build the library: WIN32: 1. You will need system environment variable JAVA_HOME that points to J2SDK installation path 2. Create directory of your choice and unpack apr-1.0.1.tar.gz in directory apr. 3. Unpack apr-java.tar.gz It should look like: some_path\apr some_path\apr-java 4. Build APR 5. Build APR-JAVA 6. cd java\org\apache\apr\jni 7. javac *.java 8. copy libapr-1.dll to java directory 9. copy libaprjava-1.dll to java directory 10. cd java 11. java org.apache.apr.jni.Test UNIX: 1. export JAVA_HOME=/path/to/the/java 2. mkdir work 3. cd work 4. tar zxf /path/to/apr-1.0.1.tar.gz 5. tar zxf /path/to/apr-java.tar.gz Building APR 7. cd apr-1.0.1 8. ./configure 9. make 10. make install 11. cd ../apr-java 12. ./buildconf --with-apr=../apr-1.0.1 13. ./configure --with-apr=../apr-1.0.1 or ./configure --with-apr=/usr/local/apr 14. make 15. make install 16. export LD_LIBRARY_PATH=/usr/local/apr/lib 17. cd java 18. $JAVA_HOME/bin/javac org/apache/apr/jni/*.java 19. $JAVA_HOME/bin/java org.apache.apr.jni.Test That's it. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33063] - Filter-mapping matches / (should only match *.do and *.jsp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33063. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33063 --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 11:39 --- Of course you know what's being sent: the only thing which isn't changed are the getRequestURL/URI methods (which, BTW, return the %xx encoded path as sent by the client, so the algorithm you used won't work in other cases). You should use the other methods to retrieve path information. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33080] New: - JasperLoader throws NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33080.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33080
Summary: JasperLoader throws NullPointerException
Product: Tomcat 5
Version: Unknown
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
When Im trying to get name of class (which is java.sql.Connection)
String name=connection.getClass().getName();
Iv got this Exception:
Error java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.jasper.servlet.JasperLoader$1.run(JasperLoader.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.jasper.servlet.JasperLoader.loadClass
(JasperLoader.java:174)
at org.apache.jasper.servlet.JasperLoader.loadClass
(JasperLoader.java:110)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at org.apache.jsp.WEB.SYST_005fPERF.SPView_jsp$DbModule.finalize
(SPView_jsp.java:175)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
Also when I write
if(connection instanceof org.apache.commons.dbcp.PoolableConnection){}
Iv got the same Exception. But connection.toString()
returns [EMAIL PROTECTED]
What's up??
May be that is my bug?
With best regards
Konstantin
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/storeconfig/test/src/share/org/apache/catalina/storeconfig StoreContextAppenderTest.java
pero2005/01/13 05:08:20
Modified:modules/storeconfig/src/share/org/apache/catalina/storeconfig
StandardContextSF.java StoreContextAppender.java
modules/storeconfig/test/src/share/org/apache/catalina/storeconfig
StoreContextAppenderTest.java
Log:
don't save path except in server.xml
don't save docBase if the webapp is in the host appBase
Revision ChangesPath
1.2 +1 -1
jakarta-tomcat-catalina/modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java
Index: StandardContextSF.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StandardContextSF.java8 Jan 2005 11:14:07 - 1.1
+++ StandardContextSF.java13 Jan 2005 13:08:20 - 1.2
@@ -81,8 +81,8 @@
else
storeContextSeparate(aWriter, indent,
(StandardContext) aContext);
+return;
}
-return;
}
}
}
1.2 +60 -11
jakarta-tomcat-catalina/modules/storeconfig/src/share/org/apache/catalina/storeconfig/StoreContextAppender.java
Index: StoreContextAppender.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/storeconfig/src/share/org/apache/catalina/storeconfig/StoreContextAppender.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- StoreContextAppender.java 8 Jan 2005 11:14:07 - 1.1
+++ StoreContextAppender.java 13 Jan 2005 13:08:20 - 1.2
@@ -16,20 +16,26 @@
package org.apache.catalina.storeconfig;
import java.io.File;
+import java.io.IOException;
+
+import javax.print.DocPrintJob;
import org.apache.catalina.Container;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.core.StandardHost;
/**
- * store StandardCOntext Attributes ...
+ * store StandardContext Attributes ... TODO DefaultContext Handling
+ *
* @author Peter Rossbach
*
*/
public class StoreContextAppender extends StoreAppender {
/*
- * (non-Javadoc)
+ * Print Context Values. ulli Spezial handling to default workDir.
+ * /lili Don't save path at external context.xml /lili Don't
+ * generate docBase for host.appBase webapps LI/ul
*
* @see
org.apache.catalina.config.StoreAppender#isPrintValue(java.lang.Object,
* java.lang.Object, java.lang.String,
@@ -38,15 +44,61 @@
public boolean isPrintValue(Object bean, Object bean2, String attrName,
StoreDescription desc) {
boolean isPrint = super.isPrintValue(bean, bean2, attrName, desc);
-if (isPrint workDir.equals(attrName)) {
+if (isPrint) {
StandardContext context = ((StandardContext) bean);
-String defaultWorkDir = getDefaultWorkDir(context);
-isPrint = !defaultWorkDir.equals(context.getWorkDir());
+if (workDir.equals(attrName)) {
+String defaultWorkDir = getDefaultWorkDir(context);
+isPrint = !defaultWorkDir.equals(context.getWorkDir());
+} else if (path.equals(attrName)) {
+isPrint = desc.isStoreSeparate()
+ desc.isExternalAllowed()
+ context.getConfigFile() == null;
+} else if (docBase.equals(attrName)) {
+Container host = context.getParent();
+if (host instanceof StandardHost) {
+File appBase = getAppBase(((StandardHost) host));
+File docBase = getDocBase(context,appBase);
+isPrint = !appBase.equals(docBase.getParentFile());
+}
+}
}
return isPrint;
}
+protected File getAppBase(StandardHost host) {
+
+File appBase;
+File file = new File(host.getAppBase());
+if (!file.isAbsolute())
+file = new File(System.getProperty(catalina.base), host
+.getAppBase());
+try {
+appBase = file.getCanonicalFile();
+} catch (IOException e) {
+appBase = file;
+}
+return (appBase);
+
+}
+
+protected File getDocBase(StandardContext context, File appBase) {
+
+File docBase;
+File file = new File(context.getDocBase());
+if (!file.isAbsolute())
+file = new
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
pero2005/01/13 05:16:51 Modified:webapps/docs changelog.xml Log: Upate my storeconfig comment Revision ChangesPath 1.219 +2 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.218 retrieving revision 1.219 diff -u -r1.218 -r1.219 --- changelog.xml 11 Jan 2005 23:27:36 - 1.218 +++ changelog.xml 13 Jan 2005 13:16:50 - 1.219 @@ -33,7 +33,8 @@ Add installer for mod_jk on IIS. (mturk) /add add -New store config module for better server.xml saving support (pero) +New store config module for better server.xml saving support.br/ + Add lt;Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener /gt; to your server.xml (pero) /add update bug32081/bug: Remove the JDK requirement from the Unix scripts, submitted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Yes, I thing the first step to better saving server.xml is done! +1 Vote for Release 5.5.7 Peter Remy Maucherat schrieb: I think the initial work on the new config save is now done, and it appears to be working at least as well as the old one. Yoav, would it be ok to do a new build picking up all the changes and fixes ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Peter Rossbach wrote: Yes, I thing the first step to better saving server.xml is done! It works very well (I tested again with your latest patch - the removal of path will hopefully avoid users getting bad ideas ;) ). The XML is clean, well indented, and easy to read. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.5.7 ?
Hi, It's certainly OK for you to do one ;) If you want me to do it, that's also OK, but it will have to wait until this weekend. Either way is fine with me. I haven't looked at (much less written) any code recently, as I expected for this January boot camp at school... Yoav -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 8:00 AM To: Tomcat Developers List Subject: 5.5.7 ? I think the initial work on the new config save is now done, and it appears to be working at least as well as the old one. Yoav, would it be ok to do a new build picking up all the changes and fixes ? 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]
DO NOT REPLY [Bug 33058] - Request session null after chain.doFilter() in Filter class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33058 [EMAIL PROTECTED] changed: What|Removed |Added URL||http://www.vincebloise.info/ ||bfg.war Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 15:01 --- The linked war file (http://www.vincebloise.info/bfg.war) contains the source as well as class files. Please run the application and notice how the Filter implementation request has a null session when filtering from the main.jsp page. The application asks for a user id and password, but it will take anything in these fields. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33058] - Request session null after chain.doFilter() in Filter class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33058 --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 15:03 --- I cannot access your test case. Please attach it to the bug report (it's quite easy to do). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Yoav Shapira wrote: Hi, It's certainly OK for you to do one ;) If you want me to do it, that's also OK, but it will have to wait until this weekend. Either way is fine with me. I haven't looked at (much less written) any code recently, as I expected for this January boot camp at school... I'm ok with waiting for this week-end. There's no rush. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Well, that really OK! Peter Yoav Shapira schrieb: Hi, It's certainly OK for you to do one ;) If you want me to do it, that's also OK, but it will have to wait until this weekend. Either way is fine with me. I haven't looked at (much less written) any code recently, as I expected for this January boot camp at school... Yoav -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 8:00 AM To: Tomcat Developers List Subject: 5.5.7 ? I think the initial work on the new config save is now done, and it appears to be working at least as well as the old one. Yoav, would it be ok to do a new build picking up all the changes and fixes ? 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] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33085] New: - new Host without restarting Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33085. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33085 Summary: new Host without restarting Tomcat Product: Tomcat 4 Version: 4.1.31 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'd want to create and deploy new Virtual(s) Host(s) and Contexts without having to restart the entire Tomcat Server (4.1.31 or 5.0.28). This works if my Host(s) exist in server.xml when I start Tomcat. BUT, if I want to create and deploy new Hosts before deploying new Contexts, I don't succeed (I tried this with the Tomcat Admin tool and the Tomcat Manager Tool) In my test, I create a new Host (myHOST) with the Tomcat Admin tool. I put a manager Context into it. The problem is : With the Admin GUI, it's not possible to put privileged=true !! so, when I launch http://myHost:8080/manager/html/list, I have a SecurityException because the HTMLManagerServlet is privileged and cannot be loaded by this web app... So, the new feature consist in : add the privileged property within the tomcat Admin form. Note : it is the same with Tomcat 5.0.28. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33058] - Request session null after chain.doFilter() in Filter class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33058 --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 18:22 --- I got the test case (which is an anything but minimal JSF-Struts webapp :( ; this is not a user support forum, and we don't do find-whatever-is-wrong-in-your-webapp work), and I still do not understand what the problem could be. Please state clearly what the problem is. Overall, I doubt there's a bug with session handling. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33058] - Request session null after chain.doFilter() in Filter class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33058 --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 19:01 --- (In reply to comment #4) I got the test case (which is an anything but minimal JSF-Struts webapp :( ; this is not a user support forum, and we don't do find-whatever-is-wrong-in-your-webapp work), and I still do not understand what the problem could be. Please state clearly what the problem is. Overall, I doubt there's a bug with session handling. (In reply) The problem: An object is placed in the session scope via HttpSession = request.getSession() session.setAttribute(...) in a servlet. That servlet then forwards the request to a JSP page in a directory that is monitored by a filter servlet. The filter servlet attempts to retrieve the session attribute from the request via session.getSessionAttribute(...) and finds that the request's session has all its attributes set to null. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33058] - Request session null after chain.doFilter() in Filter class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33058. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33058 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 19:07 --- Then, this works for me. Please do not reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33002] - Containter does not return a 404 error for permanently unavailable Web components
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33002 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 19:20 --- There's a test case for this in the Tomcat tester web application. This is for throwing unavailable on init of a servlet. The code is identical for service, so it should work. Please do not reopen this report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33002] - Containter does not return a 404 error for permanently unavailable Web components
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33002 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33002] - Containter does not return a 404 error for permanently unavailable Web components
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33002 --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 19:38 --- No, the specification states that the 404 error should be returned for permanent unavailability in the service method. Exceptions in init are covered in SRV2.3.2; the bug I refer to relates to the third paragraph of SRV2.3.3.2 For the init method, (SRV2.3.2.1) the specification implies that permanent unavailability is treated the same way as a ServletException... the Web component will be released, but the container can immediately attempt to recreate the object. I will provide a test case to you, but it will take me a day or two. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
org.apache.apr... ??? If this is private, and you've suggested it should be, don't you mean org.apache.jakarta.apr... ? Bill At 04:25 AM 1/13/2005, Mladen Turk wrote: Hi all, You can find the sources at: http://www.apache.org/~mturk/ File is: http://www.apache.org/~mturk/apr-java.tar.gz My intention is to put that inside: jakarta-tomcat-connectors/apr-java Although OtherBill thinks this is not a proper place to put that code, IMO until we have a generic infrastructure inside APR for OO languages glue code it can be placed here thought. How to build the library: WIN32: 1. You will need system environment variable JAVA_HOME that points to J2SDK installation path 2. Create directory of your choice and unpack apr-1.0.1.tar.gz in directory apr. 3. Unpack apr-java.tar.gz It should look like: some_path\apr some_path\apr-java 4. Build APR 5. Build APR-JAVA 6. cd java\org\apache\apr\jni 7. javac *.java 8. copy libapr-1.dll to java directory 9. copy libaprjava-1.dll to java directory 10. cd java 11. java org.apache.apr.jni.Test UNIX: 1. export JAVA_HOME=/path/to/the/java 2. mkdir work 3. cd work 4. tar zxf /path/to/apr-1.0.1.tar.gz 5. tar zxf /path/to/apr-java.tar.gz Building APR 7. cd apr-1.0.1 8. ./configure 9. make 10. make install 11. cd ../apr-java 12. ./buildconf --with-apr=../apr-1.0.1 13. ./configure --with-apr=../apr-1.0.1 or ./configure --with-apr=/usr/local/apr 14. make 15. make install 16. export LD_LIBRARY_PATH=/usr/local/apr/lib 17. cd java 18. $JAVA_HOME/bin/javac org/apache/apr/jni/*.java 19. $JAVA_HOME/bin/java org.apache.apr.jni.Test That's it. 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
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. If you think we can make something like that in a reasonable amount of time, count me in. In other case I can rename the package to whatever name desired if it breaks some policy or something like. Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33002] - Containter does not return a 404 error for permanently unavailable Web components
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33002 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-13 21:01 --- As I said, we have a test case for this, and it works fine. I recommend you don't waste your time, and reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird mod_jk / Tomcat behavior
Hi, I've been running Tomcat 3.3 with Apache frontend servers for quite some time now without any problems. Recently I switched to Tomcat 4.1.30, Apache 1.3.33 and Jakarta Tomcat Connectors 4.1.30. The site is ran on two servers with load balanced AJP 1.3 workers handled by mod_jk. The JDK used is Sun's 1.4.2 on Linux x86. Recently we started noticing weird behaviors when the site was heavily loaded (several tens of requests per second being sent to Tomcat). There is an authentication servlet which is accessed using a POST request which passes both a username and password to the servlet. Those infos are used to check the authentication and retrieve the user context. The weird behavior we started to notice was that some users would send an authentication request and be redirected to the site with the user context of another user. At first we thought there was a problem of mixed session IDs, but it appears this was not the case. Our suspicion is now on the AJP 1.3 link between mod_jk and Tomcat. The AJP 1.3 protocol sends the request type and header in a different packet than the request body, therefore our guess is that for a reason yet unknown the AJP Connector on the Tomcat side receives the wrong request body, as this body is carrying the user and password info, the authentication is done with the wrong user data and therefore the context being loaded for the user is that of another one. Has anybody experienced such a behavior with POST requests being sent incorrectly from mod_jk to Tomcat? I saw bug 30551 which talks about POST requests but no other mention of those in any other connector bug. The analysis of the mod_jk code could not lead us to any potential problem so we suspect there might be a problem on the Tomcat side, maybe because of an incompatibility between the JDK and Tomcat 4.1.30. Any experience on this part of the Tomcat source code would be greatly appreciated. Mathias. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird mod_jk / Tomcat behavior
Mathias Herberts wrote: Hi, I've been running Tomcat 3.3 with Apache frontend servers for quite some time now without any problems. Recently I switched to Tomcat 4.1.30, Apache 1.3.33 and Jakarta Tomcat Connectors 4.1.30. That's interesting. Can yo try the latest JK 1.2.8 version? Also are there any error messages in the mod_jk.log? Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird mod_jk / Tomcat behavior
Mathias Herberts wrote: Hi, I've been running Tomcat 3.3 with Apache frontend servers for quite some time now without any problems. Recently I switched to Tomcat 4.1.30, Apache 1.3.33 and Jakarta Tomcat Connectors 4.1.30. And also... This kind of question belongs to Tomcat users list. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
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]
DO NOT REPLY [Bug 31804] - setParent() is not called on nested tags in a tag file (.tagx)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31804 --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 00:05 --- http://issues.apache.org/bugzilla/show_bug.cgi?id=31804 Could someone please advise me on whether this Bug is fixed? Bugzilla shows this bug to be filed under Tomcat 4.0 I am using Tomcat 5.0.28 and am having problems when using the jsp:param tag. I get tons of deprecation errors. My IDE is jbuilder 2005 and am using : java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) any tips on whether this bugID is fixed for Tomcat 5.0.28 (or how could it be fixed OR a workaround ) would be greatly appreciated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 00:06 --- http://issues.apache.org/bugzilla/show_bug.cgi?id=31804 Could someone please advise me on whether this Bug is fixed? Bugzilla shows this bug to be filed under Tomcat 4.0 I am using Tomcat 5.0.28 and am having problems when using the jsp:param tag. I get tons of deprecation errors. My IDE is jbuilder 2005 and am using : java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) any tips on whether this bugID is fixed for Tomcat 5.0.28 (or how could it be fixed OR a workaround ) would be greatly appreciated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 00:08 --- sorry. prior post had the wrong URL the correct one is : http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committer: Jean-Jacques Clar
I'm definitely a +1 on this. Since I changed jobs, I haven't been able to keep up like I would like, and Jean-Jacques has stepped in to help. Having worked directly with him, his is a great fit, especially since he is already a httpd and an apr committer, I think he can be a great help on mod_jk and mod_jk2 and any other Apache related plugins as well. Mike Anderson I'd like to nominate Jean-Jacques Clar [EMAIL PROTECTED] as committer for the JTC connectors. Jean-Jacques works for Novell where I met him already; he's there working with the Apache and Tomcat stuff, and since Mike left the company there's now no other commiter from Novell anymore with karma for the Tomcat stuff. Jean-Jacques is already commiter of httpd, and I think now also of apr, so I believe he's a good candidate. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33090] New: - Add Timestamp to catalina.out
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33090. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33090 Summary: Add Timestamp to catalina.out Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] A timestamp (or the option to add a timestamp) needs to be added to the classes org.apache.catalina.logger.SystemErrLogger and org.apache.catalina.logger.SystemOutLogger. The catalina.out file contains a trove of information, but it is difficult to figure out when something occurred without a date/timestamp -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33090] - Add Timestamp to catalina.out
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33090. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33090 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 01:03 --- Loggers are gone in 5.5, enhancements to them in earlier branches are a waste of time. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: [APR-JAVA] cvs upload
Costin Manolache wrote: 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. I agree with you. After all, the main focus is Tomcat support, as APR's main focus is Httpd support. One of the goals is to add openssl support, as well as witting Servlet API four using by legacy applications (like module interface for httpd). Perhaps my posts led to wrong presumption that this is only JNI wrapper over APR library. 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. Sure, org.apache.tomcat.jni would be fine, and even better reflect the purpose of the package. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [APR-JAVA] cvs upload
At 01:25 AM 1/14/2005, Mladen Turk wrote: Costin Manolache wrote: 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. I agree with you. After all, the main focus is Tomcat support, as APR's main focus is Httpd support. Outch! Hope that isn't the worldwide impression; http://apr.apache.org/projects.html Other portability-related issues are also welcomed, discussed and oftentimes adopted! For example - multicast is fairly useless to http: scheme, but development of multicast is lively and progressing well, and is subject to tcp/ip implementation quirks and deviations. Yes it sprouted from httpd's portability needs, but work continues apace and it's been a -long- time since I heard the refrain We don't need to do that, it's not required by httpd. That train of thought gets slapped down fast :) However, apr isn't a dumping ground. If the concern isn't really portability, but more akin to library wrappers and so on, those items end up in the apr-util (dumping ground) of nice-to-have sorts of features, or sometimes dismissed out of hand. One of the goals is to add openssl support, as well as witting Servlet API four using by legacy applications (like module interface for httpd). Perhaps my posts led to wrong presumption that this is only JNI wrapper over APR library. Probably my confusion. 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. Sure, org.apache.tomcat.jni would be fine, and even better reflect the purpose of the package. Clearly, your interface will be broader than apr. When you do encounter the need for abstracting apr specifically, I do hope you consider doing this in a concerted effort. A reply to my post on [EMAIL PROTECTED], that an oo-dev abstraction effort is worthwhile, wanted, or you want to participate in, would be most appreciated. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
