-----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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
