Osgifing Tomcat
Hi to all, Did there is plans, ideas or interest around about OSGI-fing Tomcat ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk and Apache 2.2.x
While rebuilding mod_jk 1.2.26 on a Linux box SLES 10 up to date I see a strange error at startup time : Apache failed to start since the ap_get_server_description symbol was missing. Did ap_get_server_description() appears with apache 2.2.3 ou 2.2.4 ?: in apache2/mod_jk.c there is a test #if (AP_MODULE_MAGIC_AT_LEAST(20051115,4)) s->server_software = (char *)ap_get_server_description(); #else s->server_software = (char *)ap_get_server_version(); #endif On my SLES ap_mmn.h contains : #define MODULE_MAGIC_COOKIE 0x41503232UL /* "AP22" */ #ifndef MODULE_MAGIC_NUMBER_MAJOR #define MODULE_MAGIC_NUMBER_MAJOR 20051115 #endif #define MODULE_MAGIC_NUMBER_MINOR 5 /* 0...n */ But the Apache 2.2 is only 2.2.3 : /usr/sbin/httpd2 -v Server version: Apache/2.2.3 Server built: Mar 26 2008 12:23:18 SLES 10 provides a 2.2.3 core Apache 2 with mpm defs for 2.2.5 so get it in mind if we get report about mod_jk problems on Suse SLES 10 boxes :) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm
It is possible to perform successful authentication against an Active Directory server with the standard JNDIRealm but only if: a) A bind DN and bind password is supplied to JNDIRealm b) Anonymous searches (with null credentials) are successful against the server (b) is highly unlikely because by default, Active Directory does not allow searches of the user tree for anonymous users. It is not desirable to enable this behavior in many cases because it allows any network client to discover the Active Directory user list without credentials. For (a) to work, the Active Directory administrator must give bind DN and password of a user with search permissions to the Tomcat administrator. This could either be the Administrator password or the password of a dummy user that is set up for this purpose. However, this is also undesirable in many cases because it means that the LDAP administrator is giving out an Administrator-level password that is likely being stored in plain text inside the Tomcat configuration. This is more secure than anonymous access but still isn't acceptable for many users. My patch changes the behavior so that the credentials provided during authentication are used during a login to perform the LDAP search. Seth Leger Sr. Software Developer Raritan, Inc. Henri Gomez wrote: Did someone as a example LDAP configuration against AD available against standard JNDIRealm ? Regards. 2008/4/14, Seth Leger <[EMAIL PROTECTED]>: When working on this, I would appreciate if bug 44645 could also be resolved. It's a fairly trivial patch. https://issues.apache.org/bugzilla/show_bug.cgi?id=44645 I also have additional fixes for JNDIRealm that address problems in connecting to Active Directory. The biggest issue is that during the authenticate() call, an LDAP search is performed. The current implementation uses the bind DN/bind password to perform the search or null credentials (if the bind DN/bind password is not provided). However, it should also use the credentials being supplied to the authenticate() call; adding code to do this resolves a giant hurdle in getting AD authentication to work properly with most Active Directory setups. There is also a lifecycle bug in the JNDIRealm that causes authentication problems if stop() -> start() calls are issued against it. I was waiting to open bugs and supply patches for these additional issues until bug 44645 was resolved (since that would give me a new base for patching). Bug 44645 is a much more severe issue since it affects all LDAP servers that use invalid or expired SSL certificates. I'll paste the description I gave in the bug in case anyone sees this message via search engines: "This [bug 44645 patch] is necessary so that you can perform customized SSL negotiation on the connection. For instance, it allows you to connect to an SSL server with an invalid, expired, self-signed, or otherwise untrusted certificate. To do this, you just need to write a javax.net.ssl.SSLSocketFactory that does not perform the normal certificate validation during the SSL handshake and then specify the classname on the new setSocketFactory() call added by this patch." Seth Leger Sr. Software Engineer Raritan, Inc. [EMAIL PROTECTED] wrote: Brandon DuRette schrieb: While trying to track down an issue with logins taking a very long time, I just discovered in the 5.5.26 source code/Javadoc for JNDIRealm (likewise in the 6.0 documentation) that there's a big bold TODO to support connection pooling in the JNDIRealm. I think this may be part of the login problem I'm seeing. Looking over the current source code, I can see that it's going to require a fairly extensive refactoring of the JNDIRealm code. I'm willing to take a shot at fixing it, but wanted to first check with the list on a couple of Thanks in advance for any pointers. Regards, Brandon Dear Brandon, re-doing JNDIRealm seems to me very necesary, but for an other reason as yours, mentioned above. As I said in my mail (27 Feb 2008 to bug 42579) JNDIRealm is hardly useable with (Windows Server 2003) Active Directory Domains -- except for very small / trivial cases. After a long history of frustrations, I solved all the Tomcat+AD-issues by an own ADweRealms. Experiences are, so far, 100% good (with Apache Tomcat/6.0.16 on JDK1.6.0_05 and before also with 5.5.x od 1.5.0_y). I offered the solution, already, in mentioned mail. (got nil reactions) Perhaps, you could make your newly designed JNDIRealm realy fit for Active Directory. It would be warmly welcomed by all who tried to use / would have liked to use (but, as I know from some, gave up) Tomcat with AD. Good luck Albrecht -- PS.: For your convinience follows part of mentioned mail, in the hope of giving some pointers, you asked for in your mail. --- Comment #2
svn commit: r650563 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm
Date: Tue Apr 22 09:07:02 2008
New Revision: 650563
URL: http://svn.apache.org/viewvc?rev=650563&view=rev
Log:
- Votes.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=650563&r1=650562&r2=650563&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Apr 22 09:07:02 2008
@@ -80,34 +80,55 @@
Need to identify new wrapper for queued request after reload
http://svn.apache.org/viewvc?rev=649302&view=rev
+1: markt
+ -1: remm (there's a check for null on the next line -> not good; other than
that small glitch,
+ this is not an expensive check unless it is unavailable so it's probably
fine; honestly,
+ I would still consider adding isStarted to Container - maybe it should
be in Lifecycle,
+ but I'd say any container should have the flag)
+
+// Select the Wrapper to be used for this Request
+Wrapper wrapper = request.getWrapper();
+if (wrapper == null) {
+String requestURI = request.getDecodedRequestURI();
+notFound(requestURI, response);
+return;
+} else if (wrapper.isUnavailable()) {
+ // May be as a result of a reload, try and find the new wrapper
+wrapper = (Wrapper) container.findChild(wrapper.getName());
+if (wrapper == null) {
+String requestURI = request.getDecodedRequestURI();
+notFound(requestURI, response);
+return;
+}
+}
+
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43656
coerceToType() modifies some values. Patch provided by Nils Eckert
http://svn.apache.org/viewvc?rev=649638&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Add test case for https://issues.apache.org/bugzilla/show_bug.cgi?id=43656
http://svn.apache.org/viewvc?rev=649783&view=rev
http://svn.apache.org/viewvc?rev=649785&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fixes to make test case above pass
http://svn.apache.org/viewvc?rev=649784&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=29936
Create digesters and parsers earlier so we aren't using the webapp class
loader when we create them.
http://svn.apache.org/viewvc?rev=649974&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=31257
Quote endorsed dirs if they contain a space
http://svn.apache.org/viewvc?rev=649993&view=rev
- +1: markt
+ +1: markt, remm
-1:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm
> It is possible to perform successful authentication against an Active
> Directory server with the standard JNDIRealm but only if:
>
> a) A bind DN and bind password is supplied to JNDIRealm
got that
> b) Anonymous searches (with null credentials) are successful against the
> server
>
> (b) is highly unlikely because by default, Active Directory does not allow
> searches of the user tree for anonymous users. It is not desirable to enable
> this behavior in many cases because it allows any network client to discover
> the Active Directory user list without credentials.
>
> For (a) to work, the Active Directory administrator must give bind DN and
> password of a user with search permissions to the Tomcat administrator. This
> could either be the Administrator password or the password of a dummy user
> that is set up for this purpose. However, this is also undesirable in many
> cases because it means that the LDAP administrator is giving out an
> Administrator-level password that is likely being stored in plain text
> inside the Tomcat configuration. This is more secure than anonymous access
> but still isn't acceptable for many users.
>
> My patch changes the behavior so that the credentials provided during
> authentication are used during a login to perform the LDAP search.
I do some search today and debugged TC 6.0.x trunk from my eclipse.
Authentification works great and the only remaining problem it so
setup roles in AD for users.
I used :
ldap://ldap.mycorp.com:389";
alternateURL="ldap://ldap.mycorp.com:389";
connectionName="cn=someldapaccounttobind,ou=MyCorp
Users,dc=mycorp,dc=com"
connectionPassword="someldapaccounttobindpassword"
userBase="ou=MyCorp Users,dc=mycorp,dc=com"
userSearch="(sAMAccountName={0})"
userSubtree="true"
referrals="follow"
userRoleName="memberOf"
debug="true"
/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm
Henri Gomez wrote:
I do some search today and debugged TC 6.0.x trunk from my eclipse.
Authentification works great and the only remaining problem it so
setup roles in AD for users.
I used :
ldap://ldap.mycorp.com:389";
alternateURL="ldap://ldap.mycorp.com:389";
connectionName="cn=someldapaccounttobind,ou=MyCorp
Users,dc=mycorp,dc=com"
connectionPassword="someldapaccounttobindpassword"
userBase="ou=MyCorp Users,dc=mycorp,dc=com"
userSearch="(sAMAccountName={0})"
userSubtree="true"
referrals="follow"
userRoleName="memberOf"
debug="true"
/>
Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm
code because your Active Directory administrator has given you search
credentials for the Active Directory server
(cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
But not all Active Directory administrators are willing to give out a
set of credentials like this (for instance, a strict, enterprise
environment where password access is strictly controlled).
My patch removes that requirement from the JNDIRealm. Instead of relying
on a hard-coded value for authentication, it can fall back to using the
credentials being supplied to the authenticate() call to perform the
JNDI search (which will succeed because users have permissions to view
their own LDAP object instance, as far as I know this is always true).
The password is never stored; it is only transmitted at login time to
the server (and this transmission can be protected from interception
with LDAP over SSL).
It's a pretty minor change, written similarly to the way that the
current JNDIRealm code retries during connection timeouts.
Seth Leger
Sr. Software Engineer
Raritan, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
I think OSGI has some good ideas - it is pretty good at handling class loaders and loading/unloading modules. On the other side, they are very 'framework' - and like all other frameworks you have to do all things their way and they re-invent a lot of wheels ( from logging APIs to almost everything else ). If we could stick to the core - i.e. module loading/unloading - it wouldn't be bad. I did a quick search for OSGI implementations with apache license - and it looks there is even an apache project, felix... Costin On 4/22/08, Henri Gomez <[EMAIL PROTECTED]> wrote: > Hi to all, > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? > > Regards > > - > 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: Osgifing Tomcat
2008/4/22, Costin Manolache <[EMAIL PROTECTED]>: > I think OSGI has some good ideas - it is pretty good at handling class > loaders and loading/unloading modules. On the other side, they are > very 'framework' - and like all other frameworks you have to do all > things their way and they re-invent a lot of wheels ( from logging > APIs to almost everything else ). If we could stick to the core - i.e. > module loading/unloading - it wouldn't be bad. > > I did a quick search for OSGI implementations with apache license - > and it looks there is even an apache project, felix... Yep, I allready take look at felix and it's fine. I think OSGIfing Tomcat is a good idea, as today a servlet engine is only piece of code in IT architectures. With more and more OSGI plugins in enterprises, we should have an OSGi plugable tomcat or we'll see in a very near future others players do servlet services in OSGI land. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDIRealm
Do you have a patch against the current JNDIRealm ?
2008/4/22, Seth Leger <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
>
> > I do some search today and debugged TC 6.0.x trunk from my eclipse.
> > Authentification works great and the only remaining problem it so
> > setup roles in AD for users.
> >
> > I used :
> >
> > className="org.apache.catalina.realm.JNDIRealm"
> > connectionURL="ldap://ldap.mycorp.com:389";
> > alternateURL="ldap://ldap.mycorp.com:389";
> >
> connectionName="cn=someldapaccounttobind,ou=MyCorp
> > Users,dc=mycorp,dc=com"
> >
> connectionPassword="someldapaccounttobindpassword"
> > userBase="ou=MyCorp Users,dc=mycorp,dc=com"
> > userSearch="(sAMAccountName={0})"
> > userSubtree="true"
> > referrals="follow"
> > userRoleName="memberOf"
> > debug="true"
> > />
> >
> >
> Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm code
> because your Active Directory administrator has given you search credentials
> for the Active Directory server
> (cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
> But not all Active Directory administrators are willing to give out a set of
> credentials like this (for instance, a strict, enterprise environment where
> password access is strictly controlled).
>
> My patch removes that requirement from the JNDIRealm. Instead of relying on
> a hard-coded value for authentication, it can fall back to using the
> credentials being supplied to the authenticate() call to perform the JNDI
> search (which will succeed because users have permissions to view their own
> LDAP object instance, as far as I know this is always true). The password is
> never stored; it is only transmitted at login time to the server (and this
> transmission can be protected from interception with LDAP over SSL).
>
> It's a pretty minor change, written similarly to the way that the current
> JNDIRealm code retries during connection timeouts.
>
> Seth Leger
> Sr. Software Engineer
> Raritan, Inc.
>
> -
> 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 42707] add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=42707
Andrew Mottaz <[EMAIL PROTECTED]> changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #1 from Andrew Mottaz <[EMAIL PROTECTED]> 2008-04-22 13:03:42 PST
---
The support for this in Mapper.java is easy to add: (Note -- this is based on
code posted by Luke Kirby, inelegantly re-written)
public synchronized void addHost(String name, String[] aliases,
Object host) {
Host[] newHosts = new Host[hosts.length + 1];
Host newHost = new Host();
ContextList contextList = new ContextList();
newHost.name = name;
newHost.contextList = contextList;
newHost.object = host;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
for (int i = 0; i < aliases.length; i++) {
newHosts = new Host[hosts.length + 1];
newHost = new Host();
newHost.name = aliases[i];
newHost.contextList = contextList;
newHost.object = host;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
}
}
}
else {
Host aliasedHost;
// insert failed because the host already exists; grab it
int hostPos = find(hosts, name);
if (hostPos >= 0) {
aliasedHost = hosts[hostPos];
for (int i = 0; i < aliases.length; i++) {
newHosts = new Host[hosts.length + 1];
newHost = new Host();
newHost.name = aliases[i];
newHost.contextList = aliasedHost.contextList;
newHost.object = aliasedHost.object;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
}
}
} else {
System.out.println("huh?");
}
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42707] add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=42707 Andrew Mottaz <[EMAIL PROTECTED]> changed: What|Removed |Added Blocks||44856 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44856] New: add host alias using jmx doesn' t take affect until restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=44856
Summary: add host alias using jmx doesn't take affect until
restart
Product: Tomcat 5
Version: Unknown
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Depends on: 42707
Part of the problem is that Mapper.java will not properly update aliases for a
Host that already exists. Potential fix in Mapper.java: (Note -- code
originally posted by Luke Kirby, inelegantly re-written)
public synchronized void addHost(String name, String[] aliases,
Object host) {
Host[] newHosts = new Host[hosts.length + 1];
Host newHost = new Host();
ContextList contextList = new ContextList();
newHost.name = name;
newHost.contextList = contextList;
newHost.object = host;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
for (int i = 0; i < aliases.length; i++) {
newHosts = new Host[hosts.length + 1];
newHost = new Host();
newHost.name = aliases[i];
newHost.contextList = contextList;
newHost.object = host;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
}
}
}
else {
Host aliasedHost;
// insert failed because the host already exists; grab it
int hostPos = find(hosts, name);
if (hostPos >= 0) {
aliasedHost = hosts[hostPos];
for (int i = 0; i < aliases.length; i++) {
newHosts = new Host[hosts.length + 1];
newHost = new Host();
newHost.name = aliases[i];
newHost.contextList = aliasedHost.contextList;
newHost.object = aliasedHost.object;
if (insertMap(hosts, newHosts, newHost)) {
hosts = newHosts;
}
}
} else {
// I can't imagine why this would happen..
System.out.println("huh?");
}
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650645 - /tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
Author: markt
Date: Tue Apr 22 13:43:50 2008
New Revision: 650645
URL: http://svn.apache.org/viewvc?rev=650645&view=rev
Log:
Revert previous patch to fix obvious potential NPE as pointed out by Remy.
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java?rev=650645&r1=650644&r2=650645&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java Tue
Apr 22 13:43:50 2008
@@ -136,13 +136,6 @@
// Select the Wrapper to be used for this Request
Wrapper wrapper = request.getWrapper();
-
-if (wrapper.isUnavailable()) {
-// May be as a result of a reload
-// Try and find the new wrapper
-wrapper = (Wrapper) container.findChild(wrapper.getName());
-}
-
if (wrapper == null) {
String requestURI = request.getDecodedRequestURI();
notFound(requestURI, response);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650648 - /tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
Author: markt
Date: Tue Apr 22 13:46:26 2008
New Revision: 650648
URL: http://svn.apache.org/viewvc?rev=650648&view=rev
Log:
Remy's better fix for 43683.
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java?rev=650648&r1=650647&r2=650648&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContextValve.java Tue
Apr 22 13:46:26 2008
@@ -140,6 +140,14 @@
String requestURI = request.getDecodedRequestURI();
notFound(requestURI, response);
return;
+} else if (wrapper.isUnavailable()) {
+// May be as a result of a reload, try and find the new wrapper
+wrapper = (Wrapper) container.findChild(wrapper.getName());
+if (wrapper == null) {
+String requestURI = request.getDecodedRequestURI();
+notFound(requestURI, response);
+return;
+}
}
// Normal request processing
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r650651 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt
Date: Tue Apr 22 13:50:35 2008
New Revision: 650651
URL: http://svn.apache.org/viewvc?rev=650651&view=rev
Log:
Update proposal with new patch.
I'll let Remy reverse his -1 assuming he is happy with his own patch ;)
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=650651&r1=650650&r2=650651&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Apr 22 13:50:35 2008
@@ -78,29 +78,14 @@
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43683
Need to identify new wrapper for queued request after reload
- http://svn.apache.org/viewvc?rev=649302&view=rev
+ http://svn.apache.org/viewvc?rev=650648&view=rev
+1: markt
-1: remm (there's a check for null on the next line -> not good; other than
that small glitch,
this is not an expensive check unless it is unavailable so it's probably
fine; honestly,
I would still consider adding isStarted to Container - maybe it should
be in Lifecycle,
but I'd say any container should have the flag)
-
-// Select the Wrapper to be used for this Request
-Wrapper wrapper = request.getWrapper();
-if (wrapper == null) {
-String requestURI = request.getDecodedRequestURI();
-notFound(requestURI, response);
-return;
-} else if (wrapper.isUnavailable()) {
- // May be as a result of a reload, try and find the new wrapper
-wrapper = (Wrapper) container.findChild(wrapper.getName());
-if (wrapper == null) {
-String requestURI = request.getDecodedRequestURI();
-notFound(requestURI, response);
-return;
-}
-}
-
+ markt - It was easy to work around this time.
+ Maybe adding isStarted is something for 6.2.x/7.0.x?
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=43656
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44850] response.flushbuffer() doesn' t flush the data to the output
https://issues.apache.org/bugzilla/show_bug.cgi?id=44850 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-22 13:53:20 PST --- The latest source from trunk works as expected for me. If you still see the issue with 6.0.16 or trunk, you'll need to provide a test case (the source for a Servlet of JSP should be sufficient in this case) so we can investigate further. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43627] ClassNotFoundException for JSP with long path
https://issues.apache.org/bugzilla/show_bug.cgi?id=43627 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-22 14:05:42 PST --- Hmm. Odd. I can get to the point where both windows explorer and cmd refuse to navigate to the next directory (I think the limit is around 255 characters) but Tomcat is happily compiling and displaying the JSP. I wonder if it is JVM related? I am using 1.6.0_05 with XP Home SP2 with all the current patches. I am also testing with trunk but I can't recall anything that might have fixed this since 6.0.14. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43424] MD5 files for 6.0.14 contain unexpanded "${md5sum. binary-prefix}"
https://issues.apache.org/bugzilla/show_bug.cgi?id=43424 Mark Thomas <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Mark Thomas <[EMAIL PROTECTED]> 2008-04-22 14:32:33 PST --- This fix was applied back on 22-Oct-2007 and is included in 6.0.16 onwards. Many thanks for the patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk and Apache 2.2.x
Hi Henri, I noticed the same area as a source of possible trouble, e.g. w.r.t. the binaries we distribute ourselves. So since a few weeks we have "--enable-api-compatibility" as a configure flag, that will disable the use of post GA 2.2.x functions. It's already in the 1.2.27 changelog http://people.apache.org/~rjung/mod_jk-dev/docs/miscellaneous/changelog.html and configure doc http://people.apache.org/~rjung/mod_jk-dev/docs/webserver_howto/apache.html Thanks for letting us know your observation! Regards, Rainer Henri Gomez schrieb: While rebuilding mod_jk 1.2.26 on a Linux box SLES 10 up to date I see a strange error at startup time : Apache failed to start since the ap_get_server_description symbol was missing. Did ap_get_server_description() appears with apache 2.2.3 ou 2.2.4 ?: in apache2/mod_jk.c there is a test #if (AP_MODULE_MAGIC_AT_LEAST(20051115,4)) s->server_software = (char *)ap_get_server_description(); #else s->server_software = (char *)ap_get_server_version(); #endif On my SLES ap_mmn.h contains : #define MODULE_MAGIC_COOKIE 0x41503232UL /* "AP22" */ #ifndef MODULE_MAGIC_NUMBER_MAJOR #define MODULE_MAGIC_NUMBER_MAJOR 20051115 #endif #define MODULE_MAGIC_NUMBER_MINOR 5 /* 0...n */ But the Apache 2.2 is only 2.2.3 : /usr/sbin/httpd2 -v Server version: Apache/2.2.3 Server built: Mar 26 2008 12:23:18 SLES 10 provides a 2.2.3 core Apache 2 with mpm defs for 2.2.5 so get it in mind if we get report about mod_jk problems on Suse SLES 10 boxes :) Regards - 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]
[Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Although it's a little goofy to f/w this to the tomcat list, it seems this might clear up your fluxored mod_jk test ;-) --- Begin Message --- Author: wrowe Date: Wed Apr 9 01:48:19 2008 New Revision: 646229 URL: http://svn.apache.org/viewvc?rev=646229&view=rev Log: Per httpd/trunk r440337 - "Replace ap_get_server_version with ap_get_server_banner" mod_ftp must call ap_get_server_banner for httpd 2.3+. PR: 44747 Submitted by: Tom Donovan Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c?rev=646229&r1=646228&r2=646229&view=diff == --- httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c (original) +++ httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c Wed Apr 9 01:48:19 2008 @@ -150,7 +150,11 @@ FTP_REPLY_SERVICE_READY, 0, "%s FTP Server (%s) ready.", fc->orig_server->server_hostname, +#if AP_MODULE_MAGIC_AT_LEAST(20060905,0) + ap_get_server_banner()); +#else ap_get_server_version()); +#endif return rv; } Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c?rev=646229&r1=646228&r2=646229&view=diff == --- httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c (original) +++ httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c Wed Apr 9 01:48:19 2008 @@ -742,7 +742,13 @@ case FTP_REPLY_SYSTEM_TYPE: ftp_reply(fc, c->output_filters, r->pool, FTP_REPLY_SYSTEM_TYPE, 0, apr_pstrcat(r->pool, "UNIX Type: L8 System: \"", - ap_get_server_version(), "\"", NULL)); +#if AP_MODULE_MAGIC_AT_LEAST(20060905,0) + ap_get_server_banner(), + +#else + ap_get_server_version(), +#endif + "\"", NULL)); break; case FTP_REPLY_CONTROL_CLOSE: fsc = ftp_get_module_config(r->server->module_config); --- End Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Hi Bill, thanks for this. The problem though is not with the test, but if your compilation environment does not match your runtime environment. In Henri's case, and also in the case where we provide binaries, the build environment contains a newer version of 2.2.x httpd header files than the real runtime version is. That's why we have an additional configure flag to overwrite the AP_MODULE_MAGIC_AT_LEAST magic to build a backwards compatible module even if your build environment contains the newer API. Without the flag we check against AP_MODULE_MAGIC_AT_LEAST(20051115,4), which is fine for 2.2.x and allows to use ap_get_server_banner() for 2.2.4+. The below test in mod_ftp trunk is AP_MODULE_MAGIC_AT_LEAST(20060905,0), which is appropriate for trunk. Regards, Rainer William A. Rowe, Jr. schrieb: Although it's a little goofy to f/w this to the tomcat list, it seems this might clear up your fluxored mod_jk test ;-) Betreff: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c Von: [EMAIL PROTECTED] Datum: Wed, 09 Apr 2008 08:48:22 - An: [EMAIL PROTECTED] An: [EMAIL PROTECTED] Author: wrowe Date: Wed Apr 9 01:48:19 2008 New Revision: 646229 URL: http://svn.apache.org/viewvc?rev=646229&view=rev Log: Per httpd/trunk r440337 - "Replace ap_get_server_version with ap_get_server_banner" mod_ftp must call ap_get_server_banner for httpd 2.3+. PR: 44747 Submitted by: Tom Donovan Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c?rev=646229&r1=646228&r2=646229&view=diff == --- httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c (original) +++ httpd/mod_ftp/trunk/modules/ftp/ftp_connection.c Wed Apr 9 01:48:19 2008 @@ -150,7 +150,11 @@ FTP_REPLY_SERVICE_READY, 0, "%s FTP Server (%s) ready.", fc->orig_server->server_hostname, +#if AP_MODULE_MAGIC_AT_LEAST(20060905,0) + ap_get_server_banner()); +#else ap_get_server_version()); +#endif return rv; } Modified: httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c URL: http://svn.apache.org/viewvc/httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c?rev=646229&r1=646228&r2=646229&view=diff == --- httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c (original) +++ httpd/mod_ftp/trunk/modules/ftp/ftp_protocol.c Wed Apr 9 01:48:19 2008 @@ -742,7 +742,13 @@ case FTP_REPLY_SYSTEM_TYPE: ftp_reply(fc, c->output_filters, r->pool, FTP_REPLY_SYSTEM_TYPE, 0, apr_pstrcat(r->pool, "UNIX Type: L8 System: \"", - ap_get_server_version(), "\"", NULL)); +#if AP_MODULE_MAGIC_AT_LEAST(20060905,0) + ap_get_server_banner(), + +#else + ap_get_server_version(), +#endif + "\"", NULL)); break; case FTP_REPLY_CONTROL_CLOSE: fsc = ftp_get_module_config(r->server->module_config); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Henri Gomez wrote: Hi to all, Did there is plans, ideas or interest around about OSGI-fing Tomcat ? I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt my original plan was just to make sure all the MANIFEST.MF for each file would have enough in it so that each JAR can be a OSGi bundle. after that, one can add on as much or as little as one wishes Filip Regards - 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: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Rainer Jung wrote: Hi Bill, thanks for this. The problem though is not with the test, but if your compilation environment does not match your runtime environment. In Henri's case, and also in the case where we provide binaries, the build environment contains a newer version of 2.2.x httpd header files than the real runtime version is. That's why we have an additional configure flag to overwrite the AP_MODULE_MAGIC_AT_LEAST magic to build a backwards compatible module even if your build environment contains the newer API. Without the flag we check against AP_MODULE_MAGIC_AT_LEAST(20051115,4), which is fine for 2.2.x and allows to use ap_get_server_banner() for 2.2.4+. The below test in mod_ftp trunk is AP_MODULE_MAGIC_AT_LEAST(20060905,0), which is appropriate for trunk. It's not an issue; because 2.2 builds of the module can't load in 2.0 and shouldn't be loaded in 2.3-dev, this simply isn't a problem. The flip occurs within 2.1-dev and we don't target binaries to such users. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
Is that enough so that web applications, either as a whole or in partial, can be upgraded without stopping them? It's my understanding that if web applications are loaded in an OSGi classloader, these kind of things are possible. Paul On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > Henri Gomez wrote: > > > Hi to all, > > > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? > > > > > I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt > my original plan was just to make sure all the MANIFEST.MF for each file > would have enough in it so that each JAR can be a OSGi bundle. > > after that, one can add on as much or as little as one wishes > > Filip > > > Regards > > > > - > > 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: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
William A. Rowe, Jr. schrieb: Rainer Jung wrote: Hi Bill, thanks for this. The problem though is not with the test, but if your compilation environment does not match your runtime environment. In Henri's case, and also in the case where we provide binaries, the build environment contains a newer version of 2.2.x httpd header files than the real runtime version is. That's why we have an additional configure flag to overwrite the AP_MODULE_MAGIC_AT_LEAST magic to build a backwards compatible module even if your build environment contains the newer API. Without the flag we check against AP_MODULE_MAGIC_AT_LEAST(20051115,4), which is fine for 2.2.x and allows to use ap_get_server_banner() for 2.2.4+. The below test in mod_ftp trunk is AP_MODULE_MAGIC_AT_LEAST(20060905,0), which is appropriate for trunk. It's not an issue; because 2.2 builds of the module can't load in 2.0 and shouldn't be loaded in 2.3-dev, this simply isn't a problem. The flip occurs within 2.1-dev and we don't target binaries to such users. Hmmm, I'm talking only about 2.2. The function ap_get_server_banner() has been added between 2.2.3 and 2.2.4 with an associated minor MMN bump. So any module build against 2.2.4 using ap_get_server_banner() shielded by AP_MODULE_MAGIC_AT_LEAST(20051115,4) will not load into 2.2.3, because the symbol ap_get_server_banner can not be resolved. That was the original issue noticed by Henri. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "fungway" by fungway
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by fungway: http://wiki.apache.org/tomcat/fungway New page: hello world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Rainer Jung wrote: Hmmm, I'm talking only about 2.2. The function ap_get_server_banner() has been added between 2.2.3 and 2.2.4 with an associated minor MMN bump. So any module build against 2.2.4 using ap_get_server_banner() shielded by AP_MODULE_MAGIC_AT_LEAST(20051115,4) will not load into 2.2.3, because the symbol ap_get_server_banner can not be resolved. That was the original issue noticed by Henri. Right - simply don't use it until the original is deprecated, in 2.3-dev. That's the only answer for ABI between 2.2.0 and 2.2.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat Wiki] Update of "fungway" by fungway
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by fungway: http://wiki.apache.org/tomcat/fungway -- - hello world. + deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk and Apache 2.2.x
Good. What do you means by 'in all httpd production releases'. Apache 2.2.x is allready used in production, and how to determine which releases of http 2.2.x are 'production releases' or not. BTW, good idea this --enable-api-compatibility Regards 2008/4/23 Rainer Jung <[EMAIL PROTECTED]>: > Hi Henri, > > I noticed the same area as a source of possible trouble, e.g. w.r.t. the > binaries we distribute ourselves. So since a few weeks we have > "--enable-api-compatibility" as a configure flag, that will disable the use > of post GA 2.2.x functions. > > It's already in the 1.2.27 changelog > > > http://people.apache.org/~rjung/mod_jk-dev/docs/miscellaneous/changelog.html > > and configure doc > > http://people.apache.org/~rjung/mod_jk-dev/docs/webserver_howto/apache.html > > Thanks for letting us know your observation! > > Regards, > > Rainer > > Henri Gomez schrieb: > > > > > > > > > While rebuilding mod_jk 1.2.26 on a Linux box SLES 10 up to date I see > > a strange error at startup time : > > > > Apache failed to start since the ap_get_server_description symbol was > missing. > > > > Did ap_get_server_description() appears with apache 2.2.3 ou 2.2.4 ?: > > > > > > in apache2/mod_jk.c there is a test > > > > #if (AP_MODULE_MAGIC_AT_LEAST(20051115,4)) > >s->server_software = (char *)ap_get_server_description(); > > #else > >s->server_software = (char *)ap_get_server_version(); > > #endif > > > > On my SLES ap_mmn.h contains : > > > > #define MODULE_MAGIC_COOKIE 0x41503232UL /* "AP22" */ > > > > #ifndef MODULE_MAGIC_NUMBER_MAJOR > > #define MODULE_MAGIC_NUMBER_MAJOR 20051115 > > #endif > > #define MODULE_MAGIC_NUMBER_MINOR 5 /* 0...n */ > > > > > > But the Apache 2.2 is only 2.2.3 : > > > > /usr/sbin/httpd2 -v > > Server version: Apache/2.2.3 > > Server built: Mar 26 2008 12:23:18 > > > > > > SLES 10 provides a 2.2.3 core Apache 2 with mpm defs for 2.2.5 so get > > it in mind if we get report about mod_jk problems on Suse SLES 10 > > boxes :) > > > > Regards > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Well Suse RPM provided an Apache 2.2.3 but with ap_mmm from 2.2.5. It's pretty common on Linux Enterprise distributions to use a know core (ie 2.2.3) and apply security patches from later (ie: 2.2.5). >2008/4/23 Rainer Jung <[EMAIL PROTECTED]>: > William A. Rowe, Jr. schrieb: > > > Rainer Jung wrote: > > > > > Hi Bill, > > > > > > thanks for this. The problem though is not with the test, but if your > compilation environment does not match your runtime environment. In Henri's > case, and also in the case where we provide binaries, the build environment > contains a newer version of 2.2.x httpd header files than the real runtime > version is. That's why we have an additional configure flag to overwrite the > AP_MODULE_MAGIC_AT_LEAST magic to build a backwards compatible module even > if your build environment contains the newer API. > > > > > > Without the flag we check against AP_MODULE_MAGIC_AT_LEAST(20051115,4), > which is fine for 2.2.x and allows to use ap_get_server_banner() for 2.2.4+. > The below test in mod_ftp trunk is AP_MODULE_MAGIC_AT_LEAST(20060905,0), > which is appropriate for trunk. > > > > > > > It's not an issue; because 2.2 builds of the module can't load in 2.0 and > > shouldn't be loaded in 2.3-dev, this simply isn't a problem. The flip > > occurs within 2.1-dev and we don't target binaries to such users. > > > > Hmmm, I'm talking only about 2.2. The function ap_get_server_banner() has > been added between 2.2.3 and 2.2.4 with an associated minor MMN bump. So any > module build against 2.2.4 using ap_get_server_banner() shielded by > AP_MODULE_MAGIC_AT_LEAST(20051115,4) will not load into 2.2.3, because the > symbol ap_get_server_banner can not be resolved. That was the original issue > noticed by Henri. > > Regards, > > Rainer > > > > - > 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: mod_jk and Apache 2.2.x
Henri Gomez schrieb: Good. What do you means by 'in all httpd production releases'. With "Only use httpd API functions available in all httpd production releases of the chosen major httpd release branch" I try to say: for any a.b.X it will use only API functions, available in all versions a.b.c arbitrary c). So especially if X > c and there is a new function in a.b.X we won't use it. So if you use this configure flag, you are on the safe side. Maybe I should add "Use this flag, if you expect to deploy the binary mod_jk module on a minor version of httpd older than the one you were using for compiling the module." Apache 2.2.x is allready used in production, and how to determine which releases of http 2.2.x are 'production releases' or not. Yes, I should remove those "production releases". We don't support the other ones anyhow. All of 2.even.x is production. BTW, good idea this --enable-api-compatibility Thanks. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: svn commit: r646229 - in /httpd/mod_ftp/trunk/modules/ftp: ftp_connection.c ftp_protocol.c]
Henri Gomez wrote: Well Suse RPM provided an Apache 2.2.3 but with ap_mmm from 2.2.5. It's pretty common on Linux Enterprise distributions to use a know core (ie 2.2.3) and apply security patches from later (ie: 2.2.5). IMHO that's incorrect. You cannot change mmn unless you support what mmn is supposed to support. This is clear distribution error not mod_jk or httpd one. Distribution is simply laying saying: "OK I support 2.2.5 API" while the real statement should be: "I support something from 2.2.5 API, but it's up to you to figure out what" Pretty confusing, and we shouldn't bother with something like that cause if we don't trust the headers in httpd, what's the point? Cheers -- (TM) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
