tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: TC evolment
Date Sat, 03 Apr 2004 20:40:37 GMT
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 

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message