Re: AJP Todo
The ${Server}Config files are about as good as I can get them. Any
remaining improvements would require someone that knows more about Catalina
than I do. The main improvement that I can think of would require an API
change in Catalina, but this configuration method will likely be obsolete by
the time 4.1 rolls out (thanks to Costin and Henri).
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
If the web app is deployed as a directory, you can call context.getDocBase() for this. If the context is deployed as a WAR file, there is no such thing as the document base as an absolute path. In such a scenario, you need to choose one of the following options: Unfortunately, if the context is declared in server.xml, getDocBase returns the docBase declared in server.xml (e.g. examples in the shipping server.xml). I can't see how to turn this into an absolute path. * Forward *all* requests to Tomcat for processing This is my preference. The problem is determining if it is deployed as a WAR file or not given the context. This one is probably just my stupidity however :). You should be able to use Context.getResource and then use instanceof to see if it's a FileDirContext, a WARDirContext or something else altogether (in which case, you should do the same as if it was a WAR, I think). * Reject a webapp that is deployed this way Please don't do that :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sun, Dec 09, 2001 at 08:24:35PM -0800, Bill Barker wrote: ... (b) For a context defined in the server.xml, there seems to be no public way to determine the document base as an absolute path. This may just be my lack of familiarity with Catalina however. On a related note, I wasn't able to find any way to determine if a Context even has a document base (as opposed to a war file). What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3) getRealPath public java.lang.String getRealPath(java.lang.String path) Returns a String containing the real path for a given virtual path. For example, the path /index.html returns the absolute file path on the server's filesystem would be served by a request for http://host/contextPath/index.html;, where contextPath is the context path of this ServletContext.. The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive). - So, getServletContext().getRealPath( / ) incze -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
- Original Message - From: Incze Lajos [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, December 10, 2001 8:02 AM Subject: Re: AJP Todo What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3) Absolutely nothing. And indeed this is the route I took, since looking at the code showed that the Naming methods still didn't guarantee an absolute path and this one always returns null for non-file-based contexts. Now if I can just find someone to Listen to, I'll be done :). getRealPath public java.lang.String getRealPath(java.lang.String path) Returns a String containing the real path for a given virtual path. For example, the path /index.html returns the absolute file path on the server's filesystem would be served by a request for http://host/contextPath/index.html;, where contextPath is the context path of this ServletContext.. The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive). - So, getServletContext().getRealPath( / ) incze -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Mon, 10 Dec 2001, Bill Barker wrote: Date: Mon, 10 Dec 2001 20:00:35 -0800 From: Bill Barker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: AJP Todo - Original Message - From: Incze Lajos [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, December 10, 2001 8:02 AM Subject: Re: AJP Todo What's wrong with this? (ServletContext method javadoc both 2.2 and 2.3) Absolutely nothing. And indeed this is the route I took, since looking at the code showed that the Naming methods still didn't guarantee an absolute path and this one always returns null for non-file-based contexts. That's because there *is* no such thing as an absolute path for an entry inside a WAR file. Talk to your favorite OS vendor about that one. Now if I can just find someone to Listen to, I'll be done :). What is it you think should be changed? Craig getRealPath public java.lang.String getRealPath(java.lang.String path) Returns a String containing the real path for a given virtual path. For example, the path /index.html returns the absolute file path on the server's filesystem would be served by a request for http://host/contextPath/index.html;, where contextPath is the context path of this ServletContext.. The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive). - So, getServletContext().getRealPath( / ) incze -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, December 10, 2001 8:59 PM
Subject: Re: AJP Todo
On Mon, 10 Dec 2001, Bill Barker wrote:
Date: Mon, 10 Dec 2001 20:00:35 -0800
From: Bill Barker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: AJP Todo
- Original Message -
From: Incze Lajos [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, December 10, 2001 8:02 AM
Subject: Re: AJP Todo
What's wrong with this? (ServletContext method javadoc both 2.2 and
2.3)
Absolutely nothing. And indeed this is the route I took, since looking
at
the code showed that the Naming methods still didn't guarantee an
absolute
path and this one always returns null for non-file-based contexts.
That's because there *is* no such thing as an absolute path for an entry
inside a WAR file. Talk to your favorite OS vendor about that one.
Don't get so touchy :). I'm certainly not going to criticize Tomcat 4.x
when I'm the first to admit that I don't know it very well. I was actually
referring to FileDirContext.getNameInNamespace when I was talking about
non-absolute paths. As it is now, ${Server}Config does a forwardAll if the
Context is defined by a WAR file.
Now if I can just find someone to Listen to, I'll be done :).
What is it you think should be changed?
I don't know about changed. I'll simply describe the problem I'm facing.
A lot of users simply want to include one ApacheConfig statement in the
server.xml, include that file in the httpd.conf file and forget about it.
In order to get the configuration info, I need to Listen to somebody who
fires the START_EVENT at the end of Lifecycle.start (e.g. Container and
derived). This leaves Host as the highest level I can Listen to. However,
there are some one-time-only entries in the file that can't be repeated, so
Host doesn't work so well for simple configurations. I'd really like Server
(since it is a singleton), but Server fires it's event at the beginning, so
the sub-elements aren't configured yet. At the moment, I'm thinking that if
I'm Listening to a Server, I'll write the one-time-only information. Then
you'll have to Listen to any Host or Context that you want configured as
well.
Craig
getRealPath
public java.lang.String getRealPath(java.lang.String path)
Returns a String containing the real path for a given virtual path.
For example, the path /index.html returns the absolute file path
on the server's filesystem would be served by a request for
http://host/contextPath/index.html;, where contextPath is the context
path of this ServletContext..
The real path returned will be in a form appropriate to the computer
and
operating system on which the servlet container is running, including
the
proper path separators. This method returns null if the servlet
container
cannot translate the virtual path to a real path for any reason (such
as
when the content is being made available from a .war archive).
-
So, getServletContext().getRealPath( / )
incze
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
I've just checked in an initial port of ${Server}Config for 4.x into j-t-c.
The problems I'm having at the moment are:
(a) While Container fires the start-event at the end, Server fires it at the
beginning. As a result, I can't really have this as a Server Listener as I
would like.
(b) For a context defined in the server.xml, there seems to be no public way
to determine the document base as an absolute path. This may just be my
lack of familiarity with Catalina however. On a related note, I wasn't able
to find any way to determine if a Context even has a document base (as
opposed to a war file).
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 4:17 PM
Subject: Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
Date: Sat, 1 Dec 2001 17:17:31 -0800
From: Bill Barker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: AJP Todo
I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
Catalina novice. The 3.3 API is more command and control, so it is
easier
to get to the information.
+0 on officially supporting AJP in tomcat 4.x, as has been discussed
(i.e. I favor the idea, but cannot help).
It will take me a little time to find out how to
get the servlet-mappings in Catalina.
Nearly all of the configuration-related information related to a web
application is available via getXxx or findXxx methods on the
org.apache.catalina.context.Context interface. For servlet mappings in
particular, you can look up the mapping for a particular pattern with
findServletMapping(), or get all the defined mapping patterns with
findServletMappings().
There are similar methods available to access all the other stuff that was
configured in web.xml (or, in some cases, from server.xml).
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sun, 9 Dec 2001, Bill Barker wrote:
Date: Sun, 9 Dec 2001 20:24:35 -0800
From: Bill Barker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: AJP Todo
I've just checked in an initial port of ${Server}Config for 4.x into j-t-c.
The problems I'm having at the moment are:
(a) While Container fires the start-event at the end, Server fires it at the
beginning. As a result, I can't really have this as a Server Listener as I
would like.
(b) For a context defined in the server.xml, there seems to be no public way
to determine the document base as an absolute path. This may just be my
lack of familiarity with Catalina however. On a related note, I wasn't able
to find any way to determine if a Context even has a document base (as
opposed to a war file).
If the web app is deployed as a directory, you can call
context.getDocBase() for this. If the context is deployed as a WAR file,
there is no such thing as the document base as an absolute path. In
such a scenario, you need to choose one of the following options:
* Forward *all* requests to Tomcat for processing
* Reject a webapp that is deployed this way
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 8:29 PM Subject: Re: AJP Todo If the web app is deployed as a directory, you can call context.getDocBase() for this. If the context is deployed as a WAR file, there is no such thing as the document base as an absolute path. In such a scenario, you need to choose one of the following options: Unfortunately, if the context is declared in server.xml, getDocBase returns the docBase declared in server.xml (e.g. examples in the shipping server.xml). I can't see how to turn this into an absolute path. * Forward *all* requests to Tomcat for processing This is my preference. The problem is determining if it is deployed as a WAR file or not given the context. This one is probably just my stupidity however :). * Reject a webapp that is deployed this way Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: AJP Todo
Well seing Remy and Costin discussing and being agree on such subject make me more than happy and show that it was a good idea to exit connector code from tomcat 3.x/4.x CVS. The refactory on jk is important, but will give mod_jk more flexibility than ever. Yes, having jk as a common connector for ALL current tomcat servers, is a good idea, it will ease migration between 3.2/3.3/4.0 and even more allow a mixed use of all of them :) Many thanks again for that consensus :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 02, 2001 6:36 PM To: Tomcat Developers List Subject: Re: AJP Todo On Sat, 1 Dec 2001 [EMAIL PROTECTED] wrote: On the TODO list for AJP, there is: - Implementing jvmroute. I think I found a way to do it without accessing the Request. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Remy Maucherat wrote: If you want to work on this, it would be great to make it a bit more independent of the container. Right now it is very tightly coupled, in order for it to work you need to start tomcat, it doesn't work very well with context reloads, etc. I'd leave it being tied to the container, and getting the lifecycle / container events. It's (at least it should be) a simple piece of code, and although most of the code could be static utility methods, I'd implement the wrapper as a listener, instead of a webapp. A trusted webapp can register listeners ( or should be able to ), it should be able to register connectors, etc. Long term we should be able to extract the information from web.xml without having to fully start tomcat ( and use it as a parser to extract the servlet mappings, etc ). Well, if you can also port the 'trusted app' - it would be really great. I said I would, but it will require adding a few method to the Context interface (so please, no screaming over API breakage ;-)). As long as you don't remove methods, I'm ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001 [EMAIL PROTECTED] wrote: On the TODO list for AJP, there is: - Implementing jvmroute. I think I found a way to do it without accessing the Request. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
Date: Sat, 1 Dec 2001 17:17:31 -0800
From: Bill Barker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: AJP Todo
I have no objection to help porting ${Server}Config to 4.x, but I'm still a
Catalina novice. The 3.3 API is more command and control, so it is easier
to get to the information.
+0 on officially supporting AJP in tomcat 4.x, as has been discussed
(i.e. I favor the idea, but cannot help).
It will take me a little time to find out how to
get the servlet-mappings in Catalina.
Nearly all of the configuration-related information related to a web
application is available via getXxx or findXxx methods on the
org.apache.catalina.context.Context interface. For servlet mappings in
particular, you can look up the mapping for a particular pattern with
findServletMapping(), or get all the defined mapping patterns with
findServletMappings().
There are similar methods available to access all the other stuff that was
configured in web.xml (or, in some cases, from server.xml).
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
I have no objection to help porting ${Server}Config to 4.x, but I'm still a
Catalina novice. The 3.3 API is more command and control, so it is easier
to get to the information. It will take me a little time to find out how to
get the servlet-mappings in Catalina.
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 4:40 PM
Subject: AJP Todo
Hi,
On the TODO list for AJP, there is:
- Implementing jvmroute.
- Adding a mechanism like there is in Tomcat 3.3 to automatically generate
a
configuration file. That should be relatively easy to do using a server
listener (or a host listener).
I'm not going to do either of these. I have no clue how to do the first
one,
and no time to do the second one.
So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on
Tomcat 4. I did bootstrap the porting of the docs already, and I've also
fixed the problems with compiling against the CVS HEAD, so I think I've
done
my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
you guys :)
If people are willing to actively support it, and if the risk for creating
a
security vulnerability is low, we could also enable the AJP 1.3 connector
and the server listener by default (and declare it officially supported),
so
that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff.
Thanks,
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
**
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Remy Maucherat wrote: Hi, On the TODO list for AJP, there is: - Implementing jvmroute. Unfortunately that's not that easy. Manager has no way to access the Request, and that means no way to get the jvmRoute. The only possible hack is to 'intercept' the cookie header in jk and rewrite it in both directions ( to extract and insert the jvmroute ). Pretty ugly, but I see no other way with the current API. I'll try to do the hack, but I want to first finish the refactoring. - Adding a mechanism like there is in Tomcat 3.3 to automatically generate a configuration file. That should be relatively easy to do using a server listener (or a host listener). Hmmm. That shouldn't be difficult, but I would wait with it too. There are some major simplifications in jk2 configuration, and I think it is possible to have a much cleaner solution to synchronize web.xml/server.xml and httpd.conf/urimap.properties. Porting the 3.3 config generator would be great as a temporary solution, if anyone has the time. I'm not going to do either of these. I have no clue how to do the first one, To be honest, I have no clue either ( except for the hack - which is what I'll probably do if nobody find a better solution ). Tomcat 4. I did bootstrap the porting of the docs already, and I've also fixed the problems with compiling against the CVS HEAD, so I think I've done Great, many thanks ! my part :) If you want to see full support for AJP in TC 4.0.2, it's up to you guys :) Well, if you can also port the 'trusted app' - it would be really great. For 3.3 jk will be packaged as a 'trusted web application' ( i.e. a WAR with an extra interceptors.xml ), so users can deploy it / update it / etc as simple as with any other application. For 4.0 we create the jar that will be put in lib/catalina/..., but it would be nice to be able to use the same .WAR file. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
I have no objection to help porting ${Server}Config to 4.x, but I'm still a
Catalina novice. The 3.3 API is more command and control, so it is easier
to get to the information. It will take me a little time to find out how to
get the servlet-mappings in Catalina.
I'm a bit unhappy with the config generator in 3.3 - I think we can do
better.
If you want to work on this, it would be great to make it a bit more
independent of the container. Right now it is very tightly coupled,
in order for it to work you need to start tomcat, it doesn't work very
well with context reloads, etc.
Of course, we don't have any way to change the mappings without restarting
apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
can be changed at run time, we just need the protocol support to send
update requests ).
One idea was to generate a .properties file for each webapp, following the
same style with webapps/ directory. If a webapp is reloaded we can
regenerate the app's mappings and get jk to reload only that file.
We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
without starting the server. This would allow the configuration to be done
'off line'.
Costin
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 4:40 PM
Subject: AJP Todo
Hi,
On the TODO list for AJP, there is:
- Implementing jvmroute.
- Adding a mechanism like there is in Tomcat 3.3 to automatically generate
a
configuration file. That should be relatively easy to do using a server
listener (or a host listener).
I'm not going to do either of these. I have no clue how to do the first
one,
and no time to do the second one.
So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on
Tomcat 4. I did bootstrap the porting of the docs already, and I've also
fixed the problems with compiling against the CVS HEAD, so I think I've
done
my part :) If you want to see full support for AJP in TC 4.0.2, it's up to
you guys :)
If people are willing to actively support it, and if the risk for creating
a
security vulnerability is low, we could also enable the AJP 1.3 connector
and the server listener by default (and declare it officially supported),
so
that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff.
Thanks,
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
**
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
Catalina novice. The 3.3 API is more command and control, so it is
easier
to get to the information. It will take me a little time to find out
how to
get the servlet-mappings in Catalina.
I'm a bit unhappy with the config generator in 3.3 - I think we can do
better.
If you want to work on this, it would be great to make it a bit more
independent of the container. Right now it is very tightly coupled,
in order for it to work you need to start tomcat, it doesn't work very
well with context reloads, etc.
I'd leave it being tied to the container, and getting the lifecycle /
container events. It's (at least it should be) a simple piece of code, and
although most of the code could be static utility methods, I'd implement the
wrapper as a listener, instead of a webapp.
Of course, we don't have any way to change the mappings without restarting
apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
can be changed at run time, we just need the protocol support to send
update requests ).
One idea was to generate a .properties file for each webapp, following the
same style with webapps/ directory. If a webapp is reloaded we can
regenerate the app's mappings and get jk to reload only that file.
We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
without starting the server. This would allow the configuration to be done
'off line'.
Tomcat 4. I did bootstrap the porting of the docs already, and I've also
fixed the problems with compiling against the CVS HEAD, so I think I've
done
Great, many thanks !
my part :) If you want to see full support for AJP in TC 4.0.2, it's up
to
you guys :)
Well, if you can also port the 'trusted app' - it would be really great.
I said I would, but it will require adding a few method to the Context
interface (so please, no screaming over API breakage ;-)).
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
