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'.
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
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
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
> -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:
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
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
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
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
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
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
> > 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
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
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
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.
-
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
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
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
48 matches
Mail list logo
