Respuesta de En Plenitud
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]
[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed
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 -Dc
Re: jk2 and debug on specials uri
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 (! 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]
Tomcat 5.0.21 - Problems
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
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]
Respuesta de En Plenitud
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: TC evolment
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]
RE: TC evolment
> -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
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]
