Re: TC evolment

2004-04-03 Thread Remy Maucherat
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: TC evolment

2004-04-03 Thread Mladen Turk
 

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



Re: TC evolment

2004-04-03 Thread Costin Manolache
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Respuesta de En Plenitud

2004-04-03 Thread [EMAIL PROTECTED]
Muchas gracias por contactarse con En Plenitud.

Por motivos de organización y eficiencia, solo podemos responder por este medio a las 
consultas sobre el funcionamiento del sitio, resolver inconvenientes y dudas técnicas, 
y contactos por motivos comerciales, periodísticos o de intercambio.

Si usted nos escribe por otros motivos, por favor siga leyendo.

CONSULTAS A ESPECIALISTAS

El servicio de consultas gratuitas (NO incluye las consultas por temas migratorios) a 
especialistas es exclusivo para los usuarios registrados. Para registrarse en forma 
gratuita (la suscripción al newsletter, y la inscripción en los foros o los cursos NO 
es un registro en el sitio) puede hacerlo ahora mismo en:

http://www.enplenitud.com/Registro.asp

Si ya está registrado, puede realizar su consulta con nuestros especialistas ahora 
mismo, llenando el formulario que se encuentra en:

http://www.enplenitud.com/login.asp?vaa=Especialistas.asp

Si se debe a otro motivo, le responderemos dentro de las próximas 72 horas. 
Si usted no recibe respuesta en ese lapso, es porque se produjo algún inconveniente en 
los servidores de correo (si utiliza un webmail, recuerde vaciar su casilla en forma 
periódica y revisar también la bandeja Listas de correo o Correo no deseado). 
De ser así, le rogamos nos reitere su consulta mencionando, de ser posible, una 
dirección alternativa de correo electrónico para responderle a ambas direcciones. 

Con nuestras disculpas por cualquier molestia que pudiéramos ocasionarle, le enviamos 
un cordial saludo


Equipo de En Plenitud
www.enplenitud.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk2 and debug on specials uri

2004-04-03 Thread NormW
Good morning All.
A little slower than some, plus intervening activities...
A check of jk_uriEnv.c shows neither debug or disabled are 'settable'
properties, so using a standard set approach (using setAttr) currently isn't
possible; perhaps these could be added to the setAttributes list and
function? From a JMX viewpoint these should also then be visible via
getAttr, in which case they should be at the end of the Info lists so they
are at the right hand end of the /jkstatus page uri table
Lastly, being able to control these flags during normal service might be of
some operational benefit also. (using /jkstatus?set= ).

Norm


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tomcat 5.0.21 - Problems

2004-04-03 Thread NormW
Good morning All.
In trying the 5.0.21 alpha release of Tomcat, note two problems:-

1. Passing the 'stop' command initiates unload but the process hangs at the
following point -
INFO: unregistering logger Catalina: type=logger
Also noted in 5.0.19.

2. The admin application shows the following structure:
* Tomcat Server
  |_ null (Catalina)
   |_ null (localhost)
 and only displays a partial list of the registered apps.
 Also see java.lang.NullPointerException -
java.net.URLEncoder.encode(URLEncoder.java:185) which might be either cause
or effect.

 Replacing the {HOME}/server/webapps/admin directory with that from
release 5.0.19 displays correctly:
* Tomcat Server
  |_ Service (Catalina)
   |_ Host (localhost)
 and displays a full list of the registered apps.

If someone wants these in bugzilla please advise.
Regards,
Norm


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk2 and debug on specials uri

2004-04-03 Thread NormW
Good afternoon Henri.
In visualising the process of JkUriSet, arrived at the following in
pseudo-code. Shame I can't translate it to C otherwise I would offer a diff.
:-)
Regards,
Norm

JkUriSet property, value
/* Only allow inside a Location block */
if (!location block) {
 log error, JkUriSet not allowed here
 return CONFIG_ERROR
}
/* 2 Parameters - property and value */
if (!property or !value) {
 log error, missing parameter(s) - property and value
 return CONFIG_ERROR
}
/* The property must be in the setAttrInfo list */
if(!property in setAttrInfo() ) {
 log error, property not settable-, property
 return CONFIG_ERROR
}
/* Create uri name using host, port, location */
 .. ()
if(!valid name) {
 log error, missing or invalid data - , host,port,context
 return CONFIG_ERROR
}
/* Check for existing uri object - update it or create a new one */
if(exist uri name) {
point to it;
log warning, using existing uri object - , name
} else {
status = create_uri()
if(status !=OK) {
log emerg, create uri object failed - , status
return CONFIG_ERROR
}
set uri object
(name,host,port,context,match_type,timing,disabled,debug)
if(default_worker != NULL) {
set group = default_worker
}
}
/* Set passed property value but first set if it is set already */
if (getAttr(property) != NULL) {
  log warning, updating existing uri object property - ,
property,value
}
if(setAttr(property, value)!=OK) {
 log error, setting property failed - , property,value
 return CONFIG_ERROR
}
return OK.
--


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed

2004-04-03 Thread bobh
To whom it may engage...

This is an automated request, but not an unsolicited one. For help 
understanding the request please visit 
http://gump.apache.org/nagged.html, 
and/or contact [EMAIL PROTECTED]

Project jakarta-tomcat-5 has an issue affecting its community integration, and has 
been outstanding for 4 runs. The current state is 'Failed', for reason 'Build Failed'

Full details are available at: 
http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html, however 
some snippets follow:

-  -  -  -  - -- --  G U M P

Gump provided these annotations:

 - Info - Jar [servlets-default.jar] identifier set to jar basename: [servlets-default]
 - Info - Jar [naming-common.jar] identifier set to jar basename: [naming-common]
 - Info - Jar [naming-resources.jar] identifier set to jar basename: [naming-resources]
 - Info - Jar [catalina.jar] identifier set to jar basename: [catalina]
 - Info - Jar [bootstrap.jar] identifier set to jar basename: [bootstrap]
 - Info - Jar [servlets-common.jar] identifier set to jar basename: [servlets-common]
 - Info - Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker]
 - Info - Dependency on javamail exists, no need to add for property mail.jar.
 - Info - Dependency on jaf exists, no need to add for property activation.jar.
 - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property servlet-api.jar.
 - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property 
xmlParserAPIs.jar.
 - Info - Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 - Info - Dependency on commons-el exists, no need to add for property commons-el.jar.
 - Info - Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 - Info - Dependency on ant exists, no need to add for property ant.home.
 - Info - Dependency on jsse exists, no need to add for property jsse.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.jar.
 - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar.
 - Info - Dependency on jndi exists, no need to add for property jndi.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 - Info - Dependency on javamail exists, no need to add for property mail.home.
 - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 - Info - Dependency on jaf exists, no need to add for property activation.home.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 - Info - Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 - Info - Dependency on jakarta-struts exists, no need to add for property struts.home.
 - Info - Enable verbose output, due to 3 previous error(s).
 - Info - Failed with reason build failed
 - Info - Enable debug output, due to build failure.


-  -  -  -  - -- --  G U M P
Gump performed this work:

http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Failed
Elapsed: 0 hours, 1 minutes, 4 seconds
Command Line: java 
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat33.home=*Unset* 
-Djsp-api.jar=/data3/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar 
-Dtomcat-coyote.home=/data3/gump/jakarta-tomcat-connectors/coyote 
-Djndi.jar=/data3/gump/opt/jndi1_2_1/lib/jndi.jar 
-Dsite2.home=/data3/gump/jakarta-site2 
-DxmlParserAPIs.jar=/data3/gump/xml-xerces2/java/build/xercesImpl.jar 
-Dactivation.home=/data3/gump/opt/jaf-1.0.1 -Djmx.home=/data3/gump/opt/jmx-1_2-ri 
-Djdbc20ext.jar=/data3/gump/opt/jdbc2_0/jdbc2_0-stdext.jar 
-Djmx-tools.jar=/data3/gump/opt/jmx-1_2-ri/lib/jmxtools.jar 
-Dregexp.jar=/data3/gump/jakarta-regexp/build/jakarta-regexp-20040404.jar 
-Dmail.home=/data3/gump/opt/javamail-1.3 -Dant.home=/data3/gump/ant/dist 
-Dcommons-modeler.home=/data3/gump/jakarta-commons/modeler 

Respuesta de En Plenitud

2004-04-03 Thread [EMAIL PROTECTED]
Muchas gracias por contactarse con En Plenitud.

Por motivos de organización y eficiencia, solo podemos responder por este medio a las 
consultas sobre el funcionamiento del sitio, resolver inconvenientes y dudas técnicas, 
y contactos por motivos comerciales, periodísticos o de intercambio.

Si usted nos escribe por otros motivos, por favor siga leyendo.

CONSULTAS A ESPECIALISTAS

El servicio de consultas gratuitas (NO incluye las consultas por temas migratorios) a 
especialistas es exclusivo para los usuarios registrados. Para registrarse en forma 
gratuita (la suscripción al newsletter, y la inscripción en los foros o los cursos NO 
es un registro en el sitio) puede hacerlo ahora mismo en:

http://www.enplenitud.com/Registro.asp

Si ya está registrado, puede realizar su consulta con nuestros especialistas ahora 
mismo, llenando el formulario que se encuentra en:

http://www.enplenitud.com/login.asp?vaa=Especialistas.asp

Si se debe a otro motivo, le responderemos dentro de las próximas 72 horas. 
Si usted no recibe respuesta en ese lapso, es porque se produjo algún inconveniente en 
los servidores de correo (si utiliza un webmail, recuerde vaciar su casilla en forma 
periódica y revisar también la bandeja Listas de correo o Correo no deseado). 
De ser así, le rogamos nos reitere su consulta mencionando, de ser posible, una 
dirección alternativa de correo electrónico para responderle a ambas direcciones. 

Con nuestras disculpas por cualquier molestia que pudiéramos ocasionarle, le enviamos 
un cordial saludo


Equipo de En Plenitud
www.enplenitud.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]