You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by jean-frederic clere <jf...@fujitsu-siemens.com> on 2004/03/31 17:58:07 UTC
Re: TC evolment
Mladen Turk wrote:
> Hi,
>
> Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl) directly
> with TC.
What do you want to do?
- Call native methods in TC to get PHP running.
- Write a servlet engine that understands PHP. (Well the problem would be the
libraries).
> Are there any thoughts on the subject, or perhaps someone is already working
> on it?
> Anyhow I'd like to hear are there any pros or cons, and finally are there
> any interest of doing that at all.
>
>
> MT.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>>For tomcat - you can attempt to rewrite/replace every
>>
>>feature in Java
>>
>>>( we are doing this for LDAP auth for example - not sure if JNDI is
>>>better or faster than the native ldap auth in apache ). Or
>>
>>you can try
>>
>>>to use JNI or connectors - like mod_jk. Or you can just use what
>>>already works and is stable, and do something better with your time
>>>:-)
>>
>>We'll see the result when it's done :) If Mladen wants to try
>>it because he feels like he has a need for it, it's fine by me.
I'm not trying to stop him. I am also very interested in Java-native
communication.
However I haven't seen too many success stories of good integration of
native language and java ( even in the cases where it-kind-of-works, it
is still hacky and few people use it for real stuff ). So if what he
needs is PHP - I think it's fair to suggest using Apache for that :-)
> Basically I'd like to do two things for start:
>
> a) Servlet 2.4 native interface, that will load native libraries like a
> standard servlet.
> b) PHP sapi (in additon of few simpler ones) as an example for consuming
> such a interface.
Well, for start - how do you plan to do the native interface ? I assume
JNI, but which flavor ? SWT-style ( only int and array parameters, tiny
native methods ) or jk2 style ( marshalling - even if in process ) ? Did
you find any other way to get decent speed out of JNI?
>>Well, it doesn't seem that PHP + Apache 2 is that well tested
>>either ;)
>>
>>In the end, the JSR from Zend and others shows this may not
>>be a bad direction. Obviously, mod_jk and similar
>>technologies need to exist for integration purposes, or any
>>setup where Java isn't the main technology used.
>>
>
>
> Yes, the JSR 223 (although haven't found a final spec. jet) itself is
> talking about native integration, and IMHO it makes sence for particular use
> cases.
> OTOH connector architecture has a different perspective, and it is meant to
> be used in different situations like you said.
)
I'm not sure we are talking about the same thing here - by "connector" I
mean something similar with XPConnect or UNO. Jk is a very specialized
case ( actually a mix between a http request forwarder and a minimal
marshalling-based connector ).
The role of the connector is to make the adaptation between the runtimes
used on the 2 sides and deal with the limitations of JNI.
Fact is Java ( or at least the current JVMs) is among the worse
languages when it comes to integration with other systems. "Connectors"
are attempts to solve this.
Having a JSR for native integration doesn't change the problem - applets
have been a standard part of Java since 1.0, and they still don't work
very well (except maybe on windows ). And applets are a much simpler
problem than integrating 2 languages.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>>For tomcat - you can attempt to rewrite/replace every
>>
>>feature in Java
>>
>>>( we are doing this for LDAP auth for example - not sure if JNDI is
>>>better or faster than the native ldap auth in apache ). Or
>>
>>you can try
>>
>>>to use JNI or connectors - like mod_jk. Or you can just use what
>>>already works and is stable, and do something better with your time
>>>:-)
>>
>>We'll see the result when it's done :) If Mladen wants to try
>>it because he feels like he has a need for it, it's fine by me.
I'm not trying to stop him. I am also very interested in Java-native
communication.
However I haven't seen too many success stories of good integration of
native language and java ( even in the cases where it-kind-of-works, it
is still hacky and few people use it for real stuff ). So if what he
needs is PHP - I think it's fair to suggest using Apache for that :-)
> Basically I'd like to do two things for start:
>
> a) Servlet 2.4 native interface, that will load native libraries like a
> standard servlet.
> b) PHP sapi (in additon of few simpler ones) as an example for consuming
> such a interface.
Well, for start - how do you plan to do the native interface ? I assume
JNI, but which flavor ? SWT-style ( only int and array parameters, tiny
native methods ) or jk2 style ( marshalling - even if in process ) ? Did
you find any other way to get decent speed out of JNI?
>>Well, it doesn't seem that PHP + Apache 2 is that well tested
>>either ;)
>>
>>In the end, the JSR from Zend and others shows this may not
>>be a bad direction. Obviously, mod_jk and similar
>>technologies need to exist for integration purposes, or any
>>setup where Java isn't the main technology used.
>>
>
>
> Yes, the JSR 223 (although haven't found a final spec. jet) itself is
> talking about native integration, and IMHO it makes sence for particular use
> cases.
> OTOH connector architecture has a different perspective, and it is meant to
> be used in different situations like you said.
)
I'm not sure we are talking about the same thing here - by "connector" I
mean something similar with XPConnect or UNO. Jk is a very specialized
case ( actually a mix between a http request forwarder and a minimal
marshalling-based connector ).
The role of the connector is to make the adaptation between the runtimes
used on the 2 sides and deal with the limitations of JNI.
Fact is Java ( or at least the current JVMs) is among the worse
languages when it comes to integration with other systems. "Connectors"
are attempts to solve this.
Having a JSR for native integration doesn't change the problem - applets
have been a standard part of Java since 1.0, and they still don't work
very well (except maybe on windows ). And applets are a much simpler
problem than integrating 2 languages.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> If you're worried about risk, then probably glueing PHP with tomcat
>> will be a bad choice.
>>
>> Tomcat is limited by Java's bad support for integration with native
>> code. Apache will have no problem running Php, perl, python, .net or
>> integrating with any native library that exists today. For tomcat
>> running openSSL seems to be a big thing, and we know too well how
>> difficult it is to get it working with JNI.
>>
>> For tomcat - you can attempt to rewrite/replace every feature in Java
>> ( we are doing this for LDAP auth for example - not sure if JNDI is
>> better or faster than the native ldap auth in apache ). Or you can try
>> to use JNI or connectors - like mod_jk. Or you can just use what
>> already works and is stable, and do something better with your time :-)
>
>
> We'll see the result when it's done :) If Mladen wants to try it because
> he feels like he has a need for it, it's fine by me.
>
>>> And there is the maintainability, scalability, etc. which I think
>>> Java is
>>> better at.
Well I made some benchmarks on TC 3.3.2, TC 4.1.30, TC 5.0.19, Apache 2,
mod_php 4.3.5 and mod_php 5.0RC1 this week-end and you could see that to
serve the good old HelloWorld (or its html/php counter part), Java is
allways faster.
This 'bench' has been conducted on a Pentium 4 with 512Mo RAM
, Windows XP and Sun SDK 1.4.2-04.
I used each time the default server configurations.
Regards
RE: TC evolment
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Remy Maucherat
> >
> > For tomcat - you can attempt to rewrite/replace every
> feature in Java
> > ( we are doing this for LDAP auth for example - not sure if JNDI is
> > better or faster than the native ldap auth in apache ). Or
> you can try
> > to use JNI or connectors - like mod_jk. Or you can just use what
> > already works and is stable, and do something better with your time
> > :-)
>
> We'll see the result when it's done :) If Mladen wants to try
> it because he feels like he has a need for it, it's fine by me.
>
Basically I'd like to do two things for start:
a) Servlet 2.4 native interface, that will load native libraries like a
standard servlet.
b) PHP sapi (in additon of few simpler ones) as an example for consuming
such a interface.
>
> Well, it doesn't seem that PHP + Apache 2 is that well tested
> either ;)
>
> In the end, the JSR from Zend and others shows this may not
> be a bad direction. Obviously, mod_jk and similar
> technologies need to exist for integration purposes, or any
> setup where Java isn't the main technology used.
>
Yes, the JSR 223 (although haven't found a final spec. jet) itself is
talking about native integration, and IMHO it makes sence for particular use
cases.
OTOH connector architecture has a different perspective, and it is meant to
be used in different situations like you said.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> If you're worried about risk, then probably glueing PHP with tomcat will
> be a bad choice.
>
> Tomcat is limited by Java's bad support for integration with native
> code. Apache will have no problem running Php, perl, python, .net or
> integrating with any native library that exists today. For tomcat
> running openSSL seems to be a big thing, and we know too well how
> difficult it is to get it working with JNI.
>
> For tomcat - you can attempt to rewrite/replace every feature in Java (
> we are doing this for LDAP auth for example - not sure if JNDI is better
> or faster than the native ldap auth in apache ). Or you can try to use
> JNI or connectors - like mod_jk. Or you can just use what already works
> and is stable, and do something better with your time :-)
We'll see the result when it's done :) If Mladen wants to try it because
he feels like he has a need for it, it's fine by me.
>> And there is the maintainability, scalability, etc. which I think Java is
>> better at.
>
> Java may be more maintainable - but in this particular case do you think
> PHP + JNI/connector + tomcat would be more maintainable than the
> existing and well tested Apache + mod_php ?
Well, it doesn't seem that PHP + Apache 2 is that well tested either ;)
In the end, the JSR from Zend and others shows this may not be a bad
direction. Obviously, mod_jk and similar technologies need to exist for
integration purposes, or any setup where Java isn't the main technology
used.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
>
>
>>>From Costin Manolache
>>Sent: Saturday, April 03, 2004 9:14 AM
>>
>>>
>>>If a majority of my web content is a dynamic one, delivered through
>>>JSP, PHP, or what ever, why would I need a dummy web server
>>
>>as an intermediate?
>>
>>
>>The webserver is not only for static content. If you use
>>Apache just because it serves the static content faster than
>>tomcat - you are using it for the wrong reason.
>>
>
>
> Yes, but I found myself lately to use it just for glueing those techologies
> together, of course thanks to the large module database, it's not such a big
> deal.
> Having every content passing several systems is not so stable solution
> thought, cause each channel will add it's risk percentage.
If you're worried about risk, then probably glueing PHP with tomcat will
be a bad choice.
Tomcat is limited by Java's bad support for integration with native
code. Apache will have no problem running Php, perl, python, .net or
integrating with any native library that exists today. For tomcat
running openSSL seems to be a big thing, and we know too well how
difficult it is to get it working with JNI.
For tomcat - you can attempt to rewrite/replace every feature in Java (
we are doing this for LDAP auth for example - not sure if JNDI is better
or faster than the native ldap auth in apache ). Or you can try to use
JNI or connectors - like mod_jk. Or you can just use what already works
and is stable, and do something better with your time :-)
>
>
>>The raw page speed is not everything. There is also the
>>memory use, CPU load, startup time, stability, etc.
>>
>
>
> And there is the maintainability, scalability, etc. which I think Java is
> better at.
Java may be more maintainable - but in this particular case do you think
PHP + JNI/connector + tomcat would be more maintainable than the
existing and well tested Apache + mod_php ?
About scalability - April 1 is over on my timezone :-)
> As you said nothing stops me of doing something like that, and of course
> nothing stops me being totally wrong :).
Well, what would be wrong is to not try if you think it's a good idea:-)
I'm allways interested in integration between Java and native code - and
even if I don't think Tomcat+PHP would stand a chance to Apache+mod_php
- I'm looking forward to see more work in the area of JNI or
connectivity between java and the rest of the world.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: TC evolment
Posted by Mladen Turk <mt...@apache.org>.
> From Costin Manolache
> Sent: Saturday, April 03, 2004 9:14 AM
> >
> >
> > If a majority of my web content is a dynamic one, delivered through
> > JSP, PHP, or what ever, why would I need a dummy web server
> as an intermediate?
>
>
> The webserver is not only for static content. If you use
> Apache just because it serves the static content faster than
> tomcat - you are using it for the wrong reason.
>
Yes, but I found myself lately to use it just for glueing those techologies
together, of course thanks to the large module database, it's not such a big
deal.
Having every content passing several systems is not so stable solution
thought, cause each channel will add it's risk percentage.
>
> The raw page speed is not everything. There is also the
> memory use, CPU load, startup time, stability, etc.
>
And there is the maintainability, scalability, etc. which I think Java is
better at.
As you said nothing stops me of doing something like that, and of course
nothing stops me being totally wrong :).
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: jean-frederic clere
>>
>>What do you want to do?
>>- Call native methods in TC to get PHP running.
>>- Write a servlet engine that understands PHP. (Well the
>>problem would be the libraries).
>>
>
>
> If a majority of my web content is a dynamic one, delivered through JSP,
> PHP, or what ever, why would I need a dummy web server as an intermediate?
> That's my thoughts. True, I'm thinking of having native connection to PHP,
> but that's irrelevant compared to the concept itself.
> Nowadays we are having connectors (to the so called mighty webservers) to
> the TC, but I'd like to rotate that a bit. Static content is becoming less
> and less significant than before, and I cannot imagine a ISP provider that
> doesn't offer some dynamic content 'connector'.
> I think that we need to change the thinking perspective from TC being a
> 'helper' to TC being a 'workhorse'.
The webserver is not only for static content. If you use Apache just
because it serves the static content faster than tomcat - you are using
it for the wrong reason.
A lot of people use Apache because they feel it's more stable and secure.
Other use it because of the hundreds of modules - like mod_php,
mod_perl, etc. Yes, you could make mod_php work with tomcat - or you
could even rewrite the entire php in java. And nobody can stop you from
doing this if you have the time and itch.
But if you just want to use PHP instead of JSP - you may be better just
doing it with the existing stable solution, which is Apache.
The raw page speed is not everything. There is also the memory use, CPU
load, startup time, stability, etc.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: jean-frederic clere
>>
>>What do you want to do?
>>- Call native methods in TC to get PHP running.
>>- Write a servlet engine that understands PHP. (Well the
>>problem would be the libraries).
>>
>
>
> If a majority of my web content is a dynamic one, delivered through JSP,
> PHP, or what ever, why would I need a dummy web server as an intermediate?
> That's my thoughts. True, I'm thinking of having native connection to PHP,
> but that's irrelevant compared to the concept itself.
> Nowadays we are having connectors (to the so called mighty webservers) to
> the TC, but I'd like to rotate that a bit. Static content is becoming less
> and less significant than before, and I cannot imagine a ISP provider that
> doesn't offer some dynamic content 'connector'.
> I think that we need to change the thinking perspective from TC being a
> 'helper' to TC being a 'workhorse'.
The webserver is not only for static content. If you use Apache just
because it serves the static content faster than tomcat - you are using
it for the wrong reason.
A lot of people use Apache because they feel it's more stable and secure.
Other use it because of the hundreds of modules - like mod_php,
mod_perl, etc. Yes, you could make mod_php work with tomcat - or you
could even rewrite the entire php in java. And nobody can stop you from
doing this if you have the time and itch.
But if you just want to use PHP instead of JSP - you may be better just
doing it with the existing stable solution, which is Apache.
The raw page speed is not everything. There is also the memory use, CPU
load, startup time, stability, etc.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Remy Maucherat <re...@apache.org>.
Mladen Turk wrote:
>>What do you want to do?
>>- Call native methods in TC to get PHP running.
>>- Write a servlet engine that understands PHP. (Well the
>>problem would be the libraries).
>
> If a majority of my web content is a dynamic one, delivered through JSP,
> PHP, or what ever, why would I need a dummy web server as an intermediate?
> That's my thoughts. True, I'm thinking of having native connection to PHP,
> but that's irrelevant compared to the concept itself.
> Nowadays we are having connectors (to the so called mighty webservers) to
> the TC, but I'd like to rotate that a bit. Static content is becoming less
> and less significant than before, and I cannot imagine a ISP provider that
> doesn't offer some dynamic content 'connector'.
> I think that we need to change the thinking perspective from TC being a
> 'helper' to TC being a 'workhorse'.
Ok. If you manage to do it, I think performance is going to be
important, and you (= we)'ll need to publicize it. It has to be
comparable to Apache 2 / mod_php, obviously ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>>>I think that we need to change the thinking perspective
>>
>>from TC being
>>
>>>>a 'helper' to TC being a 'workhorse'.
>>>
>>>Interesting idea Mladen.
>>
>>Next idea.
>>
>>If we drop Apache 2.0 support we need to have jk/jk2 jobs
>>done somewhere :
>>What about Tomcat 5 & Coyote as a ajp13 dispatcher with
>>advances and fine tuning rules, which could be updated in
>>real time in via JMX ?
>>
>
>
> Yes something like that, It will allow mod_jk2 lb features and header
> preproc, but in pure Java, and it'll need to expose some kind of the API,
> usable from native code.
> Having that in Java will allow dynamic config either using JMX or some other
> technology.
> Will it use ajp13 as a messaging protocol? I don't know yet.
The discussion is open :)
In fact we could need only a TC5 subset, mainly only Coyote HTTP 1.1.
To forward request to remote Tomcat we could use AJP or may be RMI ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: TC evolment
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
> >> I think that we need to change the thinking perspective
> from TC being
> >> a 'helper' to TC being a 'workhorse'.
> > Interesting idea Mladen.
> Next idea.
>
> If we drop Apache 2.0 support we need to have jk/jk2 jobs
> done somewhere :
> What about Tomcat 5 & Coyote as a ajp13 dispatcher with
> advances and fine tuning rules, which could be updated in
> real time in via JMX ?
>
Yes something like that, It will allow mod_jk2 lb features and header
preproc, but in pure Java, and it'll need to expose some kind of the API,
usable from native code.
Having that in Java will allow dynamic config either using JMX or some other
technology.
Will it use ajp13 as a messaging protocol? I don't know yet.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> Mladen Turk wrote:
>
>>
>>
>>
>>> -----Original Message-----
>>> From: jean-frederic clere
>>> What do you want to do?
>>> - Call native methods in TC to get PHP running.
>>> - Write a servlet engine that understands PHP. (Well the problem
>>> would be the libraries).
>>>
>>
>>
>> If a majority of my web content is a dynamic one, delivered through JSP,
>> PHP, or what ever, why would I need a dummy web server as an
>> intermediate?
>> That's my thoughts. True, I'm thinking of having native connection to
>> PHP,
>> but that's irrelevant compared to the concept itself.
>> Nowadays we are having connectors (to the so called mighty webservers) to
>> the TC, but I'd like to rotate that a bit. Static content is becoming
>> less
>> and less significant than before, and I cannot imagine a ISP provider
>> that
>> doesn't offer some dynamic content 'connector'.
>> I think that we need to change the thinking perspective from TC being a
>> 'helper' to TC being a 'workhorse'.
>
>
> Interesting idea Mladen.
>
> +0
Next idea.
If we drop Apache 2.0 support we need to have jk/jk2 jobs done
somewhere :
What about Tomcat 5 & Coyote as a ajp13 dispatcher with
advances and fine tuning rules, which could be updated
in real time in via JMX ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Thanks Craig (Was: Re: TC evolment)
Posted by Sriram N <sr...@yahoo.com>.
--- Craig McClanahan <cr...@apache.org> wrote:
> <wistful-smile>
> And to think it was only a couple of years ago that I got thorougly
> chastised (by more than a few people participating in this thread :-)
> for suggesting that Tomcat standalone might actually be a viable
> production solution for some applications.
> </wistful-smile>
If it makes you feel good:
I was a lurker on those old threads. I'm happy to say that I decided to go
along with your judgement and use Tomcat for some solutions that we'd need to
deliver. I'd used TC 4.0.1 way back then, and our apps are still running fine
on the following configuration :Win98, Pentium 200MMX, 64 MB RAM, JDK 1.3.1.
>
> Craig McClanahan
>
-- Sriram
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Craig McClanahan <cr...@apache.org>.
Henri Gomez wrote:
> Mladen Turk wrote:
>
>>
>>
>>
>>> -----Original Message-----
>>> From: jean-frederic clere
>>> What do you want to do?
>>> - Call native methods in TC to get PHP running.
>>> - Write a servlet engine that understands PHP. (Well the problem
>>> would be the libraries).
>>>
>>
>>
>> If a majority of my web content is a dynamic one, delivered through JSP,
>> PHP, or what ever, why would I need a dummy web server as an
>> intermediate?
>> That's my thoughts. True, I'm thinking of having native connection to
>> PHP,
>> but that's irrelevant compared to the concept itself.
>> Nowadays we are having connectors (to the so called mighty
>> webservers) to
>> the TC, but I'd like to rotate that a bit. Static content is becoming
>> less
>> and less significant than before, and I cannot imagine a ISP provider
>> that
>> doesn't offer some dynamic content 'connector'.
>> I think that we need to change the thinking perspective from TC being a
>> 'helper' to TC being a 'workhorse'.
>
>
> Interesting idea Mladen.
>
> +0
<wistful-smile>
And to think it was only a couple of years ago that I got thorougly
chastised (by more than a few people participating in this thread :-)
for suggesting that Tomcat standalone might actually be a viable
production solution for some applications.
</wistful-smile>
The recent improvements in the perfornance of Tomcat standalone (with
refactorings like the Coyote connector, plus other optimizations in the
Catalina core) have definitely widened the scope of applications where
Tomcat standalone is "good enough" ... but it always has been for any
departmental app with a limited user population (which is a
many-orders-of-magnitude number of real live apps). I'm glad to see
that the "Tomcat isn't worthy of standalone status, it needs to be
hidden behind a *real* web server" crowd are finally coming to
understand that there is a substantial number of use cases where Tomcat
standalone is a perfectly reasonable solution.
Or, if you'd prefer it in a sound bite ... "fast enough is fast
enough". If Tomcat standalone meets your performance requirements, you
have my blessing if you choose to avoid the pain of learning how to
configure it to integrate with Apache's HTTPD server :-).
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC evolment
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: jean-frederic clere
>>
>>What do you want to do?
>>- Call native methods in TC to get PHP running.
>>- Write a servlet engine that understands PHP. (Well the
>>problem would be the libraries).
>>
>
>
> If a majority of my web content is a dynamic one, delivered through JSP,
> PHP, or what ever, why would I need a dummy web server as an intermediate?
> That's my thoughts. True, I'm thinking of having native connection to PHP,
> but that's irrelevant compared to the concept itself.
> Nowadays we are having connectors (to the so called mighty webservers) to
> the TC, but I'd like to rotate that a bit. Static content is becoming less
> and less significant than before, and I cannot imagine a ISP provider that
> doesn't offer some dynamic content 'connector'.
> I think that we need to change the thinking perspective from TC being a
> 'helper' to TC being a 'workhorse'.
Interesting idea Mladen.
+0
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: TC evolment
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: jean-frederic clere
>
> What do you want to do?
> - Call native methods in TC to get PHP running.
> - Write a servlet engine that understands PHP. (Well the
> problem would be the libraries).
>
If a majority of my web content is a dynamic one, delivered through JSP,
PHP, or what ever, why would I need a dummy web server as an intermediate?
That's my thoughts. True, I'm thinking of having native connection to PHP,
but that's irrelevant compared to the concept itself.
Nowadays we are having connectors (to the so called mighty webservers) to
the TC, but I'd like to rotate that a bit. Static content is becoming less
and less significant than before, and I cannot imagine a ISP provider that
doesn't offer some dynamic content 'connector'.
I think that we need to change the thinking perspective from TC being a
'helper' to TC being a 'workhorse'.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org