The trick is to get all dependencies. Do an "ant download", then create
project for repository, tomcat-connectors, tomcat-catalina, jasper,
servletapi ( with the obvious dependencis ). Eclipse will find all
source trees and jars, then compile without problems. Same works
in Idea.
Costin
Hiller,
William A. Rowe, Jr. wrote:
At 02:15 PM 8/7/2004, Costin wrote:
Now let's see how to get this in Apache2.0...
Gonna try to make that happen, if I can somehow merge history (ick)
It would be great if we would have at least one or 2 people who are committers in both projects. Since we can't propose
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
BTW, does the spec says that the form login page is excluded from
filters ??
That's undefined, as it's some kind of internal dispatching of the
container. It seemed reasonable trying to do it with a RD forward.
Well,
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat
5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum. I'm +0.5 on this.
Fir
Remy Maucherat wrote:
One simple solution is to add
<% // Force the initialization of "action" servlet
RequestDispatcher
actionS=getServletContext().getNamedDispatcher("action").include(request,response);
%>
in login.jsp
This seems good enough already.
Ok, I'll check it in then after I figur
I'm sorry, but can't remember - why do we still need the endorsed ?
I tought they were a temporary solution for JDK1.4 and some validation
problems - tomcat should work fine with any SAX/DOM parser, including
the one in JDK1.4.
The only problem is JDK1.3 - and I agree that it would be better to
Remy Maucherat wrote:
The time is mostly parsing web.xml. However, it's nothing when
compared to starting certain webapps (such as the admin webapp),
where *one* webapp takes more time than starting up the rest of
Tomcat (including all the simple webapps, JMX and the modeler
descriptors, etc).
Excelent !
Now let's see how to get this in Apache2.0...
It would be great if we would have at least one or 2 people who are
committers in both projects. Since we can't propose Mladen in apache,
maybe we can convince Graham to join tomcat :-)
Costin
Mladen Turk wrote:
Standard:
Apache2.0.50/
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
From my profile, the bottleneck for the startup time is XML parsing
and accessing entries in JARs (we can't do anything about that), with a
Did you try a pull parser ? kxml2 is really fast and only 42K :-)
The other app
Remy Maucherat wrote:
From my profile, the bottleneck for the startup time is XML parsing and
accessing entries in JARs (we can't do anything about that), with a
Did you try a pull parser ? kxml2 is really fast and only 42K :-)
The other approach - which I think may have a lot of benefits - is t
Remy Maucherat wrote:
Costin Manolache wrote:
Can you experiment with WebappClassLoader instead :-) ? SCL is only used
in standalone mode and only for loading internal classes. And removing
it will improve class loading time by itself - one less layer of if()
and indirections.
( I&#
Remy Maucherat wrote:
Costin Manolache wrote:
Is there any reason we still need StandardClassLoader ? It seems it is
only used once, in ClassLoaderFactory, and it is used exactly like a
regular URLClassLoader - the only thing that needs to be moved is the
convert() method. The code itself is
Is there any reason we still need StandardClassLoader ? It seems it is
only used once, in ClassLoaderFactory, and it is used exactly like a
regular URLClassLoader - the only thing that needs to be moved is the
convert() method. The code itself is just debug and duplication of
URLClassLoader - t
Mladen Turk wrote:
[EMAIL PROTECTED] commited
+/* read the first bloc of data */
+if (bufsiz > 0) {
+status = ajp_send_data_msg(p_conn->sock, r,
Just wondering. Can we send initial POST data together with header?
Not sure what the spec are saying abut that, but t
Remy Maucherat wrote:
Hi,
I'd like to nominate Peter Rossbach as a
committer on the Tomcat project. Peter submitted a significant amount of
useful patches for Tomcat, and wants to contribute more.
He has my +1.
Rémy
+1
Costin
Remy Maucherat wrote:
Costin Manolache wrote:
The major problem is intercepting the changes. It can be done:
- inside the jmx impl ( interceptors, etc )
- using the property changed events
- by wrapping each mbean when it is registered.
One important question is if we need to save server.xml, or
Graham Leggett wrote:
Costin Manolache wrote:
Hard == replicating the configuration data to all the nodes, instead
of having it in a central place ( file or a config server ). Not
impossible, but it's a different problem, and not very commonly used
Ldap, nis, ldap and most other "conf
Remy Maucherat wrote:
Hi,
I'd like to make this feature less hardcoded (right now, it's ugly ;) ).
A first step would be to extract the code to another helper class, but
that's all I can think of. Does anyone have any ideas ?
What I tried earlier ( but didn't finish ), and I still think is a good
Graham Leggett wrote:
is not what people want, but still - having each worker in the pool
push config on arbitrary requests seems a bit extreme, and much harder
to implement on the server side as well.
Depends on what you mean by "hard". I don't see anything hard about
adding headers to a respo
Jan Luehe wrote:
Bill,
luehe 2004/07/27 17:43:17
Modified:coyote/src/java/org/apache/coyote Response.java
Log:
Fixed Bugtraq 6152759 ("Default charset not included in Content-Type
response header if no char encoding was specified").
According to the Servlet 2.4 spec, calling:
Ser
Graham Leggett wrote:
Henri Gomez wrote:
Well using an URL could be a good idea, since it could be :
- a static file, edited by admin, on the web-server or
another web-server/tomcat
- a dynamically generated file, PHP/JSP/Servlet/PERL, whatever.
An URL is a logical solution, which leaves us with
Graham Leggett wrote:
Costin Manolache wrote:
Httpd already has some support for that - .htaccess for example
The trouble with .htaccess is that it only applies for data on the local
filesystem. Url space created by other content handlers (such as proxy
or ajp) is not covered.
I know - it was
Graham Leggett wrote:
The reason I want to focus on dynamic cluster is that it does have a
direct impact on the config format and code.
But only after you've chosen how this dynamic config is going to work.
Right now httpd does not have a concept of dynamic config, and although
adding such a cap
Mladen Turk wrote:
I start to write some code by extracting part of jk2 and
wonder for example about logging.
I'd like to have a pluggable logging function, something
which will be by default using stdout/stderr, but which could
be overrided to use Apache2 logging functions.
Well, I can extra
Graham Leggett wrote:
Filip Hanik (lists) wrote:
why are we so focused on dynamic this dynamic that,
This thread is focused on the dynamic features, and was split out from
the thread on the new work on ajp. Whether we do the dynamic features
now or later isn't important, what is important is tha
Henri Gomez wrote:
What about adding/updating of webapps ? Is this a feature that will
never be added ( because if it will be and it is not part of the
design - then we're back to spaghetti )
Well if you recall my AJP/1.4 proposal it was on my wish-list :
Adding/Removing/Updating a webapp on a t
Mladen Turk wrote:
Well, the way I see (think that Henri has the similar ideas) is to have the
ajp protocol lib, usable to communicate to TC from any container, not only
http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0
branch _and_only_ if the proxy_ajp doesn't get back propa
Remy Maucherat wrote:
jean-frederic clere wrote:
We have noted that mod_proxy + mod_proxy_http are slow compared with
mod_jk.
I think that the next step should be to try to find "why" instead
writting a new modules. May be a quick hacked mod_proxy_ajp to replace
mod_proxy_http is the first step.
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK
pool at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
If I make a design flaw, and the entire project gets
unusable, it will
make it just something like mod_java, mod_warp, mod_jk and
mod_jk2 are... Dead.
Nobody will get hanged for that.
I don't think the goal is to accumulate
Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Of course, no one is forced to participate in development, but
everyone is
welcome. The only question is do we have enough juice to make it
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi
Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Of course, no one is forced to participate in development, but
everyone is
welcome. The only question is do we have enough juice to make it
official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone
Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Of course, no one is forced to participate in development, but
everyone is welcome.
The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for
First, by "dynamic updates" I mean changes to apache2 config that don't
require a restart. For example, .htaccess files provide such a thing (
for a different area ).
What updates ? There are several forms:
1.
- add a new worker to a pool ( for example - expect big load, you buy
more hardware,
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK
pool at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
org.apache.jk.common.JkMX tries to initialize the JMX HTTP
Mladen Turk wrote:
Of course, no one is forced to participate in development, but everyone is
welcome.
The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all,
Remy Maucherat wrote:
Rainer Jung wrote:
Am I right, that by design TC 5 only fully supports one Coyote JK pool
at the moment?
I enabled JMX HTTP adaptor via mx.enabled=true. Obviously
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not
only once, but for every Coyote JK pool
Henrique Faria wrote:
Hello!
Has anyone already developed a non http tomcat connector in java? We're
wondering if it is possible to implement connectors, for other
protocols, to work within tomcat infrastructure.
The answer is yes, it is possible - and IMO a very good idea.
The impl can benefit a l
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation,
but with finer control over what is exported/imported and pretty
strong versioning. In addition osgi supports permissions on importing
packages
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for
5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the St
Remy Maucherat wrote:
Costin Manolache wrote:
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
I'll tweak the StandardCL to do a bit the same as the WebappCL
Remy Maucherat wrote:
Graham Leggett wrote:
Remy Maucherat wrote:
It's cool to have one less thing to configure, but it seems to me
jvmRoute is the most reliable and efficient way of doing stickiness
Can you describe the jvmRoute method to me?
It's really dumb: we append the node name to the sess
Quick question - did you had any discussion on class loaders for 5.next?
It's one area I'm playing with, I want to make sure I'm not going in
oposite direction :-)
BTW - another feature idea would be to extend the JMX configuration into
the webapps, i.e. allow jmx apps to view and configure cont
Filip Hanik - Dev wrote:
I didn't say anything about "just simple round robin"
the algorithm for distribution can be entirely separate from the "stickiness" as they
are two separate things. The distribution
algorithm, (round ron, load, random, etc) is separate and should not be confused.
Stickyne
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It mak
One thing missing - the proposal to actually just use mod_proxy, with
enhancements for load balancing, and with http as protocol ( i.e. drop
Ajp ).
That would be a real simplification on both sides !
The tiny performance benefit of a binary protocol is really not worth
it. The 'http parsing' pa
Henri Gomez wrote:
Can we simplify this ?
Let's drop the word "worker" too :-)
The request is passed to a servlet container that may consist of one
or multiple instances.
Agreed, remove the old terms.
The proposal about mod_proxy + proxy_ajp could be something fine
isn't it.
And proxy_ajp could m
Henri Gomez wrote:
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the s
Remy Maucherat wrote:
Costin Manolache wrote:
Well, the mod_proxy + enhancements for sticky session + enhancements
for passing auth info sounds reasonable - and if nobody wants the JMX
support, then maybe we won't need to write a new connector anyway :-)
Remy will be happy - we'll on
I agree here, it is an excelent idea.
If we want to keep it to a minimum - no multi-protocol, no jmx, no
multiple servers - then making enhancements to mod_proxy and using http
is much better than a mod_ajp.
Tomcat httpd is fast enough, and all mod_proxy enhancements for load
balancing could be
Graham Leggett wrote:
In all my deployments of tomcat I have never seen the point of a custom
protocol that did exactly what HTTP does, so all my tomcat deployments
are all HTTP, with a simple mod_proxy frontend.
Even the "get Apache to server static content" feature wasn't enough of
a drawcard
Well, the mod_proxy + enhancements for sticky session + enhancements for
passing auth info sounds reasonable - and if nobody wants the JMX
support, then maybe we won't need to write a new connector anyway :-)
Remy will be happy - we'll only use the http connector.
Costin
Graham Leggett wrote:
He
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'.
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
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
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
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
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 i
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
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
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, probab
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
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
I assume next release from HEAD will be labeled 5.1 ?
If you plan changes big enough to require a branch, probably a 5.0 ->
5.1 is also needed.
Costin
Shapira, Yoav wrote:
Hi,
So at some point soon (the next day or two), we want to put the current
tomcat 5 code on a branch called tomcat_5_0 (the
jean-frederic clere wrote:
I am building a rpm of Tomcat for one of FSC product (OpenIS). It
installs Tomcat in /opt/SMAWoIS/jakarta-tomcat-${VERSION} and
/opt/SMAWoIS/jakarta-tomcat or /opt/SMAWoIS/jakarta-tomcat5. It uses
jsvc (for common-daemon) to start/stop the Tomcat.
I was planning to "b
jean-frederic clere wrote:
Costin Manolache wrote:
It seem we had one - but was removed 4 years ago, when Henri started
it's RPMs ( if I remember corectly ).
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat/src/etc/Attic/tomcat.spec?rev=1.3&view=markup
If I update it for 4.x and
It seem we had one - but was removed 4 years ago, when Henri started
it's RPMs ( if I remember corectly ).
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat/src/etc/Attic/tomcat.spec?rev=1.3&view=markup
If I update it for 4.x and 5.0 - and manage to get it working on windows
with cygwyn's RPM - c
> Bill Barker wilshire.com> writes:
> Apache HTTPd doesn't ignore the problem: When I type
> './configure --layout=RedHat' it compiles everything nicely configured into
> the proper location .
By "ignore the problem" I meant the problem that each linux distribution is
placing http config files
Shapira, Yoav wrote:
That would be the ideal solution, but I doubt it. Henri ?
Does Henri (or do you, Henri, since you're reading this ;)) work
for/with JPackage.org to generate RPMs?
I do preffer insisting on our layout and having a warning on the site
and
at
startup if this is modified. But if
Remy Maucherat wrote:
Finally - am I overreacting, are other people seeing this as a real
issue, or should we just ignore the problem like apache does ?
I would answer no, as the stability issue is a big problem (the HTTPd
doesn't have that issue; why is the worst left to us ? :/). The
director
Shapira, Yoav mpi.com> writes:
>
> Hola,
>
> >Distros like Debian and Redhat have a policy to include packages in FHS
> >- of course each uses different layouts, but it's something under /etc,
> >/var/log, etc.
>
> Do we have an option of getting JPackage to do RPMs according to our
> layout?
Shapira, Yoav wrote:
Hi,
Finally - am I overreacting, are other people seeing this as a real
issue, or should we just ignore the problem like apache does ?
At the moment, I tend to think yes (we should ignore this problem),
because: we make the same assumptions as httpd regarding the technical
li
RPMs, why not point (in docs, or a link
somewhere) to the JPackage.org ones?
http://www.jpackage.org/
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Steve Raeburn [mailto:[EMAIL PROTECTED]
Sent: Monday, May 17, 2004 1:59 AM
To: Tomcat Developers List
Subject: RE: Fedora &quo
ourse, if you can also make it easier for Fedora to use the official
TC releases, then that would be great too.
I'll go back to lurking now :-)
Steve
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: May 16, 2004 5:14 PM
To: [EMAIL PROTECTED]
Subj
Remy Maucherat wrote:
It is very nice they are bundling java tools and tomcat - but I thing
it is a big problem ( for tomcat developers, fedora users and tomcat
users ) that they distribute such a badly modified tomcat ( and call
it tomcat)
But for a daemon, which is often more complex and ne
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
For the critical path probably it's good to keep using an interface,
but for all "container changes" and other notification - there is no
performance issue.
Yes, but we can't be too bad either: if we take
Remy Maucherat wrote:
For the critical path probably it's good to keep using an interface,
but for all "container changes" and other notification - there is no
performance issue.
Yes, but we can't be too bad either: if we take one minute to deploy a
webapp (unless we're precompiling on deploy ;
Remy Maucherat wrote:
Costin Manolache wrote:
I don't know if you saw it, but Fedora ( the free Redhat distro )
includes now tomcat-4.1.27. I think this is a big problem and we should
Yes, I saw that FC 2 claims to bundle a lot of Java tools, including
Tomcat.
Ant actually works quite wel
Hi,
I don't know if you saw it, but Fedora ( the free Redhat distro )
includes now tomcat-4.1.27. I think this is a big problem and we should
be aware of it - the "tomcat" they distribute uses the worst layout,
doesn't start like any other tomcat, it seem to run out of file
descriptors about 90
Remy Maucherat wrote:
Shapira, Yoav wrote:
One area to keep in mind there is performance. There's no argument on
the utility of JMX at all. I also think most of the performance hit
would be at initialization (and shutdown), as you're
creating/naming/binding JMX operations/attributes. This is be
Remy Maucherat wrote:
Au menu:
- Using Embedded
- Using JMX (which I think is cool)
- Using the in-memory connector
Speaking of which, the in-memory connector might be good for a bare
bones JNI connector, if someone wants to try. The current JK JNI has
about the same overhead os a socket, so it
I already said I'm -0 on XML format for /jkstatus.
It is a status page to allow people to quickly see the status. If you
want to programmatically process it - the right solution is to get the
informations into the JMX engine on tomcat side. I believe there is
already code to do some of this and
e
JSP 2.0 Specification Lead
Sun Microsystems, Inc.
Costin Manolache wrote:
Nice :-)
Did you try it ? I'm curious, could you run a quick helo world
benchmark ( helo.jsp / help.php ) ?
The big question is the level of integration - i.e. if you can call java
objects from php or use some of th
Nice :-)
Did you try it ? I'm curious, could you run a quick helo world benchmark
( helo.jsp / help.php ) ?
The big question is the level of integration - i.e. if you can call java
objects from php or use some of the nice PHP features from java.
Costin
Henri Gomez wrote:
Hi to all,
Mladen disc
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Shapira, Yoav wrote:
Hi,
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.
Whoa there ;) Maybe if you're talking about JNI, but not integration in
general ;) It's a very broad ter
Henri Gomez wrote:
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, pytho
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 o
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
Henri Gomez wrote:
No problem for me to provide the result in XML, since I've got friend
aroud which could provide me some nice XSL still sheet.
Second advantage, the jkstatus could be used by others apps for example
for monitoring purposes.
+0 for XML (lack of time to works on this ;().
-0 - if s
Thorsten Kamann wrote:
Hello,
Henri Gomez schrieb:
Well I didn't like very well the hardcoded way, so I'd like to have it
externally.
We could :
Define a stylesheet property var in workers2.properties, which will
contains a full URL and if this var is null, fallback to previous method.
Is ther
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, deliv
Mladen Turk wrote:
-Original Message-
From: Andy Armstrong
Heretic perhaps, but I'd like to integrate PHP (perhaps even Perl)
directly with TC.
What do you mean by 'integrate'? Have tomcat handle PHP
requests by some means?
mod_php inside TC.
I found out that TC is only 8% slower
Davanum Srinivas wrote:
Henri,
it's a recommendation, NOT a mandate. So even if this is not done it's ok
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg06498.html)
-- dims
A mandate means something like "if you don't do that, your accounts
and/or project CVS will be disabled"
A recommendatio
101 - 200 of 783 matches
Mail list logo
