Henri Gomez wrote:
The AJP13 protocol will have to be enhanced (or better enabled) to use
the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness,
neither to
define all the Data Filter modes like cryptography or co
Henri Gomez wrote:
The AJP13 protocol will have to be enhanced (or better enabled) to use
the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness,
neither to
define all the Data Filter modes like cryptography or co
Mladen Turk wrote:
But we don't wish to write something modular and unlimitedly extendable.
Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
Having that in mind, we have APR, and 'almost' a finite set of requirements,
without the need to 'think modular' or 'think cross-webserver'.
I actually built this yesterday upon rediscovering it -- and it seems to
work fine.
Unfortunately:
1. The licensing is unclear.
2. There appears to be no active maintenance or support of this module.
I'm thus more than a little reluctant to put too many eggs in this basket.
--
Jess Holle
Günt
Hi,
> A good number desparately want NTLM-based authentication. [They like
> the single-sign on for Windows clients, but they love the notion of
> better security than clear-text name/password, etc, without having to
> buy a server certificate or use HTTPS on their intranet.] If Apache 2
> had a
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Ideally since we could have a cluster of Apache WebServer
linked to a cluster of Tomcat ServletEngines, and that member
could enter or exit these 2 clusters we should have something
using Multicast (ideally a native JavaGroups)
> -Original Message-
> From: Henri Gomez
>
> Ideally since we could have a cluster of Apache WebServer
> linked to a cluster of Tomcat ServletEngines, and that member
> could enter or exit these 2 clusters we should have something
> using Multicast (ideally a native JavaGroups) for b
Henri Gomez wrote:
Mladen Turk wrote:
The AJP13 protocol will have to be enhanced (or better enabled) to use
the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness,
neither to
define all the Data Filter modes lik
Mladen Turk wrote:
Costin Manolache wrote
I can understand the jk2 "object oriented C" is considered
too complex.
True.
But I certainly can't agree on a design that is not modular
and doesn't support this basic requirement. We already have
mod_jserv and mod_webapp
- and a long history of
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
I think you're mixing the Java side with the native side. I think the
Java side should obviously use JMX to monitor what's going on with
Tomcat. However, the native side will just recieve proprietary messages.
We have to keep the
Mladen Turk wrote:
-Original Message-
From: Remy Maucherat
The only 2 JNI models that actually work are jk2 "protocol
marshalling, pass only byte[]" and eclipse swt "small simple calls
with mostly int and byte[] params"
All that is cool, but what you propose looks a lot like JK 2
(J
Costin Manolache wrote:
Henri Gomez wrote:
You must keep in mind that tomcat5 is no longer server.xml centric !
It can use separate config files in different directories, if it is
embedded it can use the embedor's config, etc.
And httpd.conf is static - you can't modify it. We support using
http
Costin Manolache wrote
>
> I can understand the jk2 "object oriented C" is considered
> too complex.
True.
> But I certainly can't agree on a design that is not modular
> and doesn't support this basic requirement. We already have
> mod_jserv and mod_webapp
> - and a long history of "re
Remy Maucherat wrote:
Monitoring and controlling the native code from java is IMO quite
usefull and important by itself. Even Apache supports limited
monitoring ( SNMP, mod_status, etc ).
Ok. We'll see if I'm more convinced when you show your code ;) For now,
I'm siding with Henri and his propo
I was lucky enough to ditch a bloated buggy j2ee engine in place of
tomcat/apache while we were in the process of switching CIO's. As nice as it
is to have someone to blame, its even harder to justify having to pay the fat
up front prices and yearly (lack of) support contracts for something that
Costin Manolache wrote:
Jess Holle wrote:
Henri Gomez wrote:
It's better then having people struggle with mod_jk config and
feeling it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for
Windows :)
I'd love to -- and have.
Unfortunately, some h
Jess Holle wrote:
Henri Gomez wrote:
It's better then having people struggle with mod_jk config and
feeling it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for
Windows :)
I'd love to -- and have.
Unfortunately, some have drank too much Mic
Costin Manolache wrote:
Jess Holle wrote:
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them
to do it". They have plenty of developers and money - they could
send a check to Andy and Henri, or do it themself :-)
Costin Manolache wrote:
Remy Maucherat wrote:
I think you're mixing the Java side with the native side. I think the
Java side should obviously use JMX to monitor what's going on with
Tomcat. However, the native side will just recieve proprietary messages.
We have to keep the native side as small
Jess Holle wrote:
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them
to do it". They have plenty of developers and money - they could send
a check to Andy and Henri, or do it themself :-)
I'm quite certain that
Remy Maucherat wrote:
I think you're mixing the Java side with the native side. I think the
Java side should obviously use JMX to monitor what's going on with
Tomcat. However, the native side will just recieve proprietary messages.
We have to keep the native side as small and simple as possible t
With all the talk about the new jk, I hope of the main focuses will be
to make the integration between Tomcat and Apache a lot easier. I find
that there are very few hosting companies out there that are able to do
this correctly and as such do not support Java/JSP/Servlets. It has come
to a poi
Costin Manolache wrote:
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them to
do it". They have plenty of developers and money - they could send a
check to Andy and Henri, or do it themself :-)
Hey why not? :)
I
> -Original Message-
> From: Jess Holle [mailto:[EMAIL PROTECTED]
>
> Unfortunately, some have drank too much Microsoft Kool-Aid.
>
> A good number desparately want NTLM-based authentication. [They like
> the single-sign on for Windows clients, but they love the notion of
> better s
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]
> >
> > The only 2 JNI models that actually work are jk2 "protocol
> > marshalling, pass only byte[]" and eclipse swt "small simple calls
> > with mostly int and byte[] params"
>
>
> All that is cool, but what you p
> -Original Message-
> From: Remy Maucherat
> >
> > The only 2 JNI models that actually work are jk2 "protocol
> > marshalling, pass only byte[]" and eclipse swt "small simple calls
> > with mostly int and byte[] params"
>
>
> All that is cool, but what you propose looks a lot like J
Henri Gomez wrote:
It's better then having people struggle with mod_jk config and
feeling it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for
Windows :)
I'd love to -- and have.
Unfortunately, some have drank too much Microsoft Kool-Aid.
A g
Costin Manolache wrote:
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears
to be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days gettin
Henri Gomez wrote:
You must keep in mind that tomcat5 is no longer server.xml centric !
It can use separate config files in different directories, if it is
embedded it can use the embedor's config, etc.
And httpd.conf is static - you can't modify it. We support using
httpd.conf for performance-v
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files,
using the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models that actua
Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few w
Costin Manolache wrote:
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days getti
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files, using
the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models that actua
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on
Jess Holle wrote:
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on
Costin Manolache wrote:
Remy Maucherat wrote:
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part);
so I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
+1
- it should have a name which doesn
Costin Manolache wrote:
We should first determine if Apache2 will have to monitor a
service/system links to the various tomcats (in cluster
configuration) to learn about real-time topology.
In fact, that is why I've pursued the .xml config over the current one.
The main idea is to _internally_
> > Ah appologies I though crypto would mean SSL'ing the link
> or encypting the
> > AJP contents with AES/Blowfish et al.
>
> It could of course, all we need is a fast crypto protocol, and more
> important something ALLREADY available in APR/Apache2/Java
Although this is getting off topic, usi
Remy Maucherat wrote:
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files, using
the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models that actually work are jk2 "protoc
Remy Maucherat wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in fe
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files, using
the same protocol.
The real important lesson in Jk2 is that JNI works faster and better
if it is not used to pass objects.
The only 2 JNI models that actually work are jk2 "protocol
marshalling, pass
[EMAIL PROTECTED] wrote:
What I am trying to say is that do not dismiss 1.3.x unless
it is difficult
to include.
Well if we had to support Apache 1.3, will have to support two very
different web-server and could make use of APR since Apache 1.3 came
without APR.
Ah ok - so this is complex to
Costin Manolache wrote:
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few weeks I'll have
som
Andy Armstrong wrote:
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
be rocket
science though. [Dang thing just shows a red down arrow on the
filter whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm
thinking
Remy Maucherat wrote:
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so
I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
+1
- it should have a name which doesn't confuse folks :)
mod_t
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to be
rocket
science though. [Dang thing just shows a red down arrow on the filter
whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm
thinking about starting to sell
We should first determine if Apache2 will have to monitor a
service/system links to the various tomcats (in cluster
configuration) to learn about real-time topology.
In fact, that is why I've pursued the .xml config over the current one.
The main idea is to _internally_ have config tree (right
Costin Manolache wrote:
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few weeks I'll
have som
> > What I am trying to say is that do not dismiss 1.3.x unless
> it is difficult
> > to include.
>
> Well if we had to support Apache 1.3, will have to support two very
> different web-server and could make use of APR since Apache 1.3 came
> without APR.
Ah ok - so this is complex to make it
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few weeks I'll have
something working and I'll g
Remy Maucherat wrote:
Henri Gomez wrote:
Second reference to mod_coyote ?
Should we retains this one ?
Maybe ;)
We have two connectors planned. This one will use AJP, while the other
would use JNI, so we need two, different, non confusing names. So naming
this mod_jk3 would be bad, just like nam
mod_jk with Apache is not that hard.
Actually I believe it is fairly easy
mod_jk2 is much harder for me to understand.
Getting the IIS connectors to work with IIS 6 appears to be rocket
science though. [Dang thing just shows a red down arrow on the filter
whatever you do without giving any r
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Well I'd like to see jk 1.2.x continuing its slow maintenance
cycle since it's the most used module for now.
And start from scratch the new mod_coyote.
Ok, but let's try to make the code 'reusable', protocol and basic
config tr
[EMAIL PROTECTED] wrote:
Just my 2 pence worth (as an apache/tomcat admin in a large company);
- the configuration should be in Apache's config file, rather than
some complex properties file
+1
Yes please!
The general idea is to connect to TC and get the URI/VHOST
topology, but we
still need
> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 19, 2004 5:58 AM
> To: 'Tomcat Developers List'
> Subject: RE: Some JK2 ideas v.3
>
>
>
> > -Original Message-
> > From: Henri Gomez
> >
Just my 2 pence worth (as an apache/tomcat admin in a large company);
> >>>- the configuration should be in Apache's config file, rather than
> >>>some complex properties file
> >>
> >>+1
Yes please!
> > The general idea is to connect to TC and get the URI/VHOST
> topology, but we
> > still
> -Original Message-
> From: Henri Gomez
>
> Well I'd like to see jk 1.2.x continuing its slow maintenance
> cycle since it's the most used module for now.
>
> And start from scratch the new mod_coyote.
>
> > Ok, but let's try to make the code 'reusable', protocol and basic
> > conf
Henri Gomez wrote:
Second reference to mod_coyote ?
Should we retains this one ?
Maybe ;)
We have two connectors planned. This one will use AJP, while the other
would use JNI, so we need two, different, non confusing names. So naming
this mod_jk3 would be bad, just like naming the two mod_coyote1
> -Original Message-
> From: Henri Gomez [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 19, 2004 8:07 AM
> To: Tomcat Developers List
> Subject: Re: Some JK2 ideas v.3
>
> Second reference to mod_coyote ?
>
> Should we retains this one ?
Why wouldn'
Mladen Turk wrote:
-Original Message-
From: Remy Maucherat
For example majors Linux distributions are now using Apache
2 instead
of Apache 1.3. So Apache 2.x will be more and more used.
When not running inside Apache, there are tons of things when
cannot use, including configuratio
Mladen Turk wrote:
-Original Message-
From: Remy Maucherat
For example majors Linux distributions are now using Apache
2 instead
of Apache 1.3. So Apache 2.x will be more and more used.
When not running inside Apache, there are tons of things when
cannot use, including configuratio
> -Original Message-
> From: Remy Maucherat
>
> > For example majors Linux distributions are now using Apache
> 2 instead
> > of Apache 1.3. So Apache 2.x will be more and more used.
>
> When not running inside Apache, there are tons of things when
> cannot use, including configurat
Henri Gomez wrote:
Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
No more code complexity to handle all the web-servers around,
we should focus on Apache 2.x.
Yes. A lot of the complexity is to allow running
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
We should first determine if Apache2 will have to monitor a
service/system links to the various tomcats (in cluster
configuration) to learn about real-time topology.
In fact, that is why I've pursued the .xml config over the cu
> -Original Message-
> From: Henri Gomez
>
> We should first determine if Apache2 will have to monitor a
> service/system links to the various tomcats (in cluster
> configuration) to learn about real-time topology.
>
In fact, that is why I've pursued the .xml config over the current
Remy Maucherat wrote:
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so
I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
Of course.
- it should have a name which doesn't confuse folks
Cavan Morris wrote:
Andy Armstrong wrote:
I have concrete examples of people giving up on Tomcat altogether for
no other reason than the fact that they couldn't get JK configured. By
comparison the rest of the task of configuring Tomcat is a walk in the
park. Please let's not be so up ourselves
Mladen Turk wrote:
-Original Message-
From: Remy Maucherat
- it should be simpler than JK 1 or 2
That's the general idea
- it should have a name which doesn't confuse folks :)
APR_JAVA as static core lib + mod_javalink?
For example I wish to make a WIN2003 http.sys kernel module.
-
Andy Armstrong wrote:
I have concrete examples of people giving up on Tomcat altogether for
no other reason than the fact that they couldn't get JK configured. By
comparison the rest of the task of configuring Tomcat is a walk in the
park. Please let's not be so up ourselves that we forget that
Endre Stølsvik wrote:
All the jk's I've been exposed for -sucks- when it comes to these aspects
- ANYTHING that makes it easier to use are VERY WELCOME feature.
I have concrete examples of people giving up on Tomcat altogether for no
other reason than the fact that they couldn't get JK configured.
Endre Stølsvik wrote:
> | Cool that you have useful stuff to contribute. I'll kick you out of
this
> | list, and recommend you don't come back.
I should have added "if you keep this attitude" at the end.
> But isn't -kicking me off the list- rather harsh? I didn't flame
anyone in
> particular, o
Endre Stølsvik wrote:
On Thu, 15 Jul 2004, jean-frederic clere wrote:
| >
| >
| > 2. workers2.properties -> workers2.xml using apr_utils xml support.
| > Get rid of 'assumed' properties like figuring out the context from url.
| > Get rid of copying mappings from 'default' to virtual hosts.
| > Of c
On Wed, 14 Jul 2004, Jess Holle wrote:
|
| >>Using a modular multi-XML-file approach does not pollute the
| >>result with any additional server-specific or Tomcat-specific
| >>baggage. It just makes management and automated
| >>configuration/installation much more workable.
| >>
| >>
| >In contra
On Thu, 15 Jul 2004, jean-frederic clere wrote:
| >
| >
| > 2. workers2.properties -> workers2.xml using apr_utils xml support.
| > Get rid of 'assumed' properties like figuring out the context from url.
| > Get rid of copying mappings from 'default' to virtual hosts.
| > Of course, it would requi
Remy Maucherat wrote:
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so
I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
- it should have a name which doesn't confuse folks :)
- Apache
David Rees wrote:
That is the reason I have stuck with mod_jk instead of moving to mod_jk2,
a quick look at the mod_jk2 docs makes my eyes glaze over, and mod_jk
works just fine for my usage...
If it helps any the docs don't seem to be in sync with the code either...
--
Andy Armstrong
-
Henri Gomez wrote:
>
> My idea is about a new module, only Apache 2.x for now, which will
> make use of SetEnv, SetEnvIf, BrowserMath and Location
> directives to redirect some URLs to tomcats via AJP.
This sounds like a great idea. It would be easy to configure, and I would
love to be able to co
[EMAIL PROTECTED] wrote:
>
> There is a learning cliff with mod_jk2 that many I feel try to climb, and
> don't make it. They then tomcat gives them a bad taste.
>
> KISS - the easier it is to do a simple config (and at the same time have
> flexibility to do a complicated one) the better.
That is
How about mod_tomcat?
-Tim
Mladen Turk wrote:
-Original Message-
From: Remy Maucherat
- it should have a name which doesn't confuse folks :)
APR_JAVA as static core lib + mod_javalink?
For example I wish to make a WIN2003 http.sys kernel module.
--
> -Original Message-
> From: Remy Maucherat
>
>
> - it should be simpler than JK 1 or 2
That's the general idea
> - it should have a name which doesn't confuse folks :)
APR_JAVA as static core lib + mod_javalink?
For example I wish to make a WIN2003 http.sys kernel module.
> - No
> -Original Message-
> From: Henri Gomez
>
> Well I'd like to see the JK3 or whatever will name the new
> module to be much more simpler and with less code.
>
Bingo!
I'm trying over and over again to 'push' something like 'zero-config', not
depandant of any current container.
Just im
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so
I don't know if I have a say in any decision, but I though I should
participate as well.
- it should be simpler than JK 1 or 2
- it should have a name which doesn't confuse folks :)
- Apache 2.x specific using AP
Henri Gomez wrote:
Well I'd like to see the JK3 or whatever will name the new module to be
much more simpler and with less code.
+1 to that. It really has the feel of something that's more complex than
it should be at the moment.
--
Andy Armstrong
-
Mladen Turk wrote:
-Original Message-
From: Henri Gomez
Of course all that sounds like JK3, but ...
Did you see my post about a simpler module specific for now
to Apache 2.x (2.0/2.1), may be something which could be
included in standard Apache 2.x distribution which will save
us hou
Tim Funk wrote:
If this is all wishlists .. it'd be nice if we could set the worker and
handler via mod_rewrite.
Intead of
JkMount /*.jsp loadbalancer
Say:
RewriteCond %{REQUEST_URI} *\.jsp
RewriteRule ^(.+)$$1 [T=jk,E=worker:loaderbalance]
[If my syntax above is correct]
I was thin
Tim Funk wrote:
If this is all wishlists .. it'd be nice if we could set the worker and
handler via mod_rewrite.
Intead of
JkMount /*.jsp loadbalancer
Say:
RewriteCond %{REQUEST_URI} *\.jsp
RewriteRule ^(.+)$$1 [T=jk,E=worker:loaderbalance]
[If my syntax above is correct]
Rewrite re
have
flexibility to do a complicated one) the better.
> -Original Message-
> From: Tim Funk [mailto:[EMAIL PROTECTED]
> Sent: 15 July 2004 15:25
> To: Tomcat Developers List
> Subject: Re: Some JK2 ideas v.2
>
>
> I wasn't thinking of a dependency on mod_rewrite, but a
I wasn't thinking of a dependency on mod_rewrite, but a way to to configure
JK based on common data structures that may be set by mod_rewrite.
Its actually a restatement of this:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=108987495224170&w=2
-Tim
[EMAIL PROTECTED] wrote:
Would do you think a de
Jess Holle wrote:
Both approaches have their advantages
Just don't loose the multi-file configuration flexibility given by
JkUriSet.
Gack, I meant "lose". I did one of my own pet-peeve typos
Also, having either XML-based configuration *or* pure .conf
configuration would be more easily un
Angus Mezick wrote:
-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Mladen Turk wrote:
-Original Message-
From: Bill Barker
Having the option to do per-host and even per-context configs
makes life much easier for admins of servers that support it.
Otherwise, yo
Both approaches have their advantages
Just don't loose the multi-file configuration flexibility given by JkUriSet.
Also, having either XML-based configuration *or* pure .conf
configuration would be more easily understood than the current
workers2.properties details.
Mladen Turk wrote:
-O
> If this is all wishlists .. it'd be nice if we could set the
> worker and
> handler via mod_rewrite.
>
> Intead of
>JkMount /*.jsp loadbalancer
> Say:
>RewriteCond %{REQUEST_URI} *\.jsp
>RewriteRule ^(.+)$$1 [T=jk,E=worker:loaderbalance]
>
> [If my syntax above is correct]
If this is all wishlists .. it'd be nice if we could set the worker and
handler via mod_rewrite.
Intead of
JkMount /*.jsp loadbalancer
Say:
RewriteCond %{REQUEST_URI} *\.jsp
RewriteRule ^(.+)$$1 [T=jk,E=worker:loaderbalance]
[If my syntax above is correct]
-Tim
Mladen Turk wrote:
> -Original Message-
> From: Jess Holle [mailto:[EMAIL PROTECTED]
> Mladen Turk wrote:
>
> >>-Original Message-
> >>From: Bill Barker
> >>
> >>Having the option to do per-host and even per-context configs
> >>makes life much easier for admins of servers that support it.
> >> Ot
> -Original Message-
> From: Henri Gomez
> >
> > Of course all that sounds like JK3, but ...
>
> Did you see my post about a simpler module specific for now
> to Apache 2.x (2.0/2.1), may be something which could be
> included in standard Apache 2.x distribution which will save
> us
Mladen Turk wrote:
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
Seems that the major obstacle is the configuration, so I propose that we
forget that for a while, and make a
'generalized' environment that will sattisfy all the 'needs'
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
Seems that the major obstacle is the configuration, so I propose that we
forget that for a while, and make a
'generalized' environment that will sattisfy all the 'needs'.
That environmen
jean-frederic clere wrote:
My idea is about a new module, only Apache 2.x for now, which will
make use of SetEnv, SetEnvIf, BrowserMath and Location
directives to redirect some URLs to tomcats via AJP.
Everything in httpd.conf, probably that is a good idea. Reusing existing
directives also.
Many
jean-frederic clere wrote:
Henri Gomez wrote:
Andy Armstrong wrote:
Mladen Turk wrote:
In contrary, it makes it simpler, cause you have a common
denominator, and
that is
'well documented' config file, usable on any container.
Well documented is the crux here for me. Or at least readily
understa
Henri Gomez wrote:
Andy Armstrong wrote:
Mladen Turk wrote:
In contrary, it makes it simpler, cause you have a common
denominator, and
that is
'well documented' config file, usable on any container.
Well documented is the crux here for me. Or at least readily
understandable. I've just had someon
1 - 100 of 119 matches
Mail list logo
