El error ocurre en el SERVIDOR 1 al instanciar un JApplet en un HttpServlet,
sin embargo funcionaba correctamente en el SERVIDOR 2.

SERVIDOR 1:
Apache Tomcat/5.5.9
JVM 1.4.2_05-b04 (Sun Microsystems Inc.)
Linux 2.4.21-20.EL i386

SERVIDOR 2:
Apache Tomcat/4.1.18
JVM 1.4.2_<05
Linux 2.4.21-20.EL i386


-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
------- MENSAJES SOBRE EL ERROR CON LOS DEL
--------
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
David García

Posted on 17 Aug 2005 06:55 PM

--------------------------------------------------------------------------
Hola,

Desde el cambio de servidor tomcat 4.1.18 a 5.5.9, todo va correcto,
excepto un problema con un applet, que funciona correctamente en 4.1.30,
pero en 5.5.9 ocurre lo siguiente:

- Si utilizo el applet incrustado en un HTML funciona correctamente.
- Pero si instancio el JApplet desde un servlet me da un error (ver
más abajo).

¿Tienen alguna referencia sobre este caso?
¿Alguna idea?



EL ERROR (el mensaje del error no existe, eso ya es raro de por si):

null
java.applet.Applet.(Applet.java:44)
javax.swing.JApplet.(JApplet.java:97)
es.folch.fabrica.DesgloseApplet.(DesgloseApplet.ja va:321)
es.folch.fabrica.InformeDesglose.getImagenInforme( InformeDesglose.java:240)
es.folch.comun.Informes.generatePDFDocumentBytes(I nformes.java:770)
es.folch.comun.Informes.imprime(Informes.java:114)
es.folch.fabrica.InformeDesglose.logicaServicio(In formeDesglose.java:173)
es.folch.fabrica.InformeDesglose.procesaServicio(I nformeDesglose.java:70)
es.folch.Principal.getServicio(Principal.java:844)
es.folch.Principal.procesaLlamada(Principal.java:5 07)
es.folch.Cargador.procesaLlamada(Cargador.java:71)
es.folch.Cargador.doGet(Cargador.java:52)
javax.servlet.http.HttpServlet.service(HttpServlet .java:689)
es.folch.Cargador.service(Cargador.java:47)
javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:856)
org.apache.coyote.http11.Http11Protocol$Http11Conn ectionHandler.processConnection(Http11Protocol.jav a:744)
org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
java.lang.Thread.run(Thread.java:534)

enREDados: Atencion al cliente

Posted on 17 Aug 2005 10:46 PM

--------------------------------------------------------------------------
No creo que sea cosa del Tomcat, parece más probable que sea por la
JDK... pruebe a compilar el applet con la JDK 1.4.2_05-b04


David G. Folch

Posted on 18 Aug 2005 08:05 PM

--------------------------------------------------------------------------
No encuentro la versión 1.4.2_05-b04 en java.sun.com
¿Tienes un link?
¿Porqué una 1.4.2_05-b4 cuando ya hay una 1.4.2_09 con un montón de
bug-fixes?

Me he bajado la 1.4.2_09 y he recompilado y subido los nuevos class,
pero el error sigue siendo el mismo en www.folch.es
En mi servidor local funciona correctamente con Tomcat 4.1.30 y
jdk1.4.2_09.

¿No será algo de configuración de vuestro tomcat?



enREDados: Atencion al cliente

Posted on 18 Aug 2005 11:28 PM

--------------------------------------------------------------------------
Pues no sé... si quieres te pasamos al Tomcat 4, o a otro servidor con
Tomcat 5 y JDK 1.5.

David G. Folch

Posted on 20 Aug 2005 04:51 PM

--------------------------------------------------------------------------
Pues sería interesante ver si el problema desaparece en Tomcat 5 y JDK
1.5.


David G. Folch

Posted on 20 Aug 2005 05:09 PM

--------------------------------------------------------------------------
He encontrado algo:

La JVM 1.4 en Linux tiene una dependencia con X11

A la hora de ejecutar la JVM ponerle la opción:
java.awt.headless=false

http://forums.liferay.com/lofiversio....php/t865.html
[...]"Looks like you are trying to run a client program using a JVM
that has been started wither with "-server" or java.awt.headless=true.
Review how you are trying to launch the database manager, namely the JVM
parameters."[...]

http://www.jguru.com/faq/view.jsp?EID=222296

Aki dice que hay que ejecutar un X server para evitar el problema.
http://bugs.sun.com/bugdatabase/view...bug_id=4281163



enREDados: Atencion al cliente

Posted on 20 Aug 2005 05:15 PM

--------------------------------------------------------------------------
Esta noche probamos a pasarlo a JDK 1.5, y si no va, volvemos al
Tomcat 4 que sí tiene lo del headless=false... en los demás servidores el
headless está a true, que es lo normal para que funcionen las aplicaciones
con gráficos.

enREDados: Atencion al cliente

Posted on 21 Aug 2005 12:40 AM

--------------------------------------------------------------------------
Hemos copiado la cuenta a otro servidor, pero ha dado errores al
trasladar la base de datos, probablemente porque utilizan tablas innodb, que
deben ser creadas a mano y en cierto orden, por las dependencias.

El dominio todavía sigue apuntando al servidor antiguo. ¿Qué hacemos,
quieren que apunte al nuevo a pesar del problema con la BD?

David G. Folch

Posted on 21 Aug 2005 12:16 PM

--------------------------------------------------------------------------
El dominio todavía sigue apuntando al servidor antiguo. ¿Qué hacemos,
quieren que apunte al nuevo a pesar del problema con la BD?

NO!!!

David G. Folch

Posted on 21 Aug 2005 12:19 PM

--------------------------------------------------------------------------
Por la info que he visto en la web, me parece que para que funcione en
el servidor linux el paquete java.awt.* hay que poner
java.awt.headless=false, podríais hacer ese cambio solo para confirmar que
funciona?

Porque en Tomcat 4 headless=false y en los Tomcat 5
headless=true??????????????

enREDados: Atencion al cliente

Posted on 21 Aug 2005 01:08 PM

--------------------------------------------------------------------------
> Por la info que he visto en la web, me parece que para que funcione
en el servidor linux el paquete java.awt.* hay que poner
java.awt.headless=false, podríais hacer ese cambio solo para confirmar que
funciona?

No, hay clientes que lo necesitan.

> Porque en Tomcat 4 headless=false y en los Tomcat 5
headless=true??????????????

Porque en el 4 y en el 3 había que hacer lo que tú dijiste, instalar
el X11, poner el headless a false, y hacer un auténtico follón para que el
Tomcat se comunicara con el X11 (tardamos meses en conseguir que
funcionara)... pero con el 5 no hace falta, si se pone a true funcionan bien
los gráficos.

David G. Folch

Posted on 21 Aug 2005 01:13 PM

--------------------------------------------------------------------------
> Por la info que he visto en la web, me parece que para que funcione
en el servidor linux el paquete java.awt.* hay que poner
java.awt.headless=false, podríais hacer ese cambio solo para confirmar que
funciona?

No, hay clientes que lo necesitan.

¿NOSOTROS NO SOMOS UN CLIENTE?



enREDados: Atencion al cliente

Posted on 21 Aug 2005 02:35 PM

--------------------------------------------------------------------------
> > Por la info que he visto en la web, me parece que para que
funcione en el servidor linux el paquete java.awt.* hay que poner
java.awt.headless=false, podríais hacer ese cambio solo para confirmar que
funciona?
>
> No, hay clientes que lo necesitan.
>
> ¿NOSOTROS NO SOMOS UN CLIENTE?

Sí, pero es un servidor compartido, no se puede cambiar todo por que
lo diga un sólo cliente... para eso necesitaríais un servidor dedicado.

Ya os he trasladado a otro servidor, sólo falta hacer que el dominio
apunte a él.

enREDados: Atencion al cliente

Posted on 21 Aug 2005 02:37 PM

--------------------------------------------------------------------------
Tenemos servidores para todos los gustos, lo que no se puede hacer es
cambiar un servidor así como así... Tenemos Tomcat 4 con jdk 1.4, Tomcat 5
con jdk 1.4 y Tomcat 5 con jdk 1.5, sólo tienes que elegir.

David G. Folch

Posted on 21 Aug 2005 03:57 PM

--------------------------------------------------------------------------
Bueno, a ver, es que no es tan sencillo.

Si lo ponemos en un servidor como el que teníamos en un principio
(TC4.1 y JDK1.4)
¿Volveremos a tener problemas de performance o recursos?

Si lo ponemos en un servidor (TC5.5 y JDK1.5)
¿Estamos seguros de que se arregla el problema HeadlessException?

En cualquier caso, hay que volver a volcar base de datos, y siempre
pueden salir más problemas.

Por ahora ni necesitamos, ni queremos pagar un servidor dedicado.
Pero es necesario que esa parte de la aplicación funcione, (es un
JApplet de 5000 lineas que me dibuja el desglose de modelos, es fundamental
para fábrica).

No encuentro una solución factible vía re-implementación del código.
Si no puedes cambiar la opción sólo para mi contexto, o no puedes o
quieres configurar nuestro servidor compartido de manera que no pete (con el
headless=false), yo ya no se que proponer, no creo que esa modificación
afecte a los otros contextos/clientes, y solucionaría el problema de mi
aplicación.

Supongo que si cambiamos a un servidor TC5.5 y JDK1.5 el problema
persistirá, si no se configura la JVM como dice en este link
http://anjackson.net/node/740 (ver Java Flags).

Tu dirás.








enREDados: Atencion al cliente

Posted on 22 Aug 2005 11:10 AM

--------------------------------------------------------------------------
> Bueno, a ver, es que no es tan sencillo.
>
> Si lo ponemos en un servidor como el que teníamos en un principio
(TC4.1 y JDK1.4)
> ¿Volveremos a tener problemas de performance o recursos?

Claro, porque ahí el tratamiento de imágenes se hacía como tú dices,
de la forma antigua, a través del X11, lo que es lentísimo. A partir del
Tomcat 5, es el propio Java el que hace el tratamiento de imágenes, es mucho
más fácil y mucho más rápido.

> Si lo ponemos en un servidor (TC5.5 y JDK1.5)
> ¿Estamos seguros de que se arregla el problema HeadlessException?

No lo sé, por eso hemos trasladado el web a otro servidor, para
probarlo.

> En cualquier caso, hay que volver a volcar base de datos, y siempre
pueden salir más problemas.

Si usais tablas innodb, deberíais tener un script que cree
automáticamente esas tablas en su debido orden (teniendo en cuenta las
dependencias), porque el dump del mysql las vuelca como le da la gana, y
luego al restaurarla da errores... si alguna vez hay algún problema con la
base de datos, estará hecho el backup, pero no se podrá restaurar a menos
que tengais hecho ese script.

> Por ahora ni necesitamos, ni queremos pagar un servidor dedicado.
> Pero es necesario que esa parte de la aplicación funcione, (es un
JApplet de 5000 lineas que me dibuja el desglose de modelos, es fundamental
para fábrica).
>
> No encuentro una solución factible vía re-implementación del código.

Es probable que ese sea el problema, que tengais alguna cosa deprecada
que sólo funciona en Tomcat 4 y haya cambiado en el 5... en ese caso, con
pasarlo al servidor del Tomcat 5 no se arreglaría, habría que pasarlo al del
Tomcat 4 (pero si haceis el script para crear la BD, se puede probar a
pasarlo a los dos en un momento).

> Si no puedes cambiar la opción sólo para mi contexto, o no puedes o
quieres configurar nuestro servidor compartido de manera que no pete (con el
headless=false), yo ya no se que proponer, no creo que esa modificación
afecte a los otros contextos/clientes, y solucionaría el problema de mi
aplicación.

No se puede poner para un sólo cliente, y claro que afectaría a los
demás. Como puedes ver en http://folch.es:8080/testImg.jsp , ahora mismo el
tratamiento de imágenes funciona bien desde Java. Haciendo lo que tú
quieres, dejaría de funcionar.

> Supongo que si cambiamos a un servidor TC5.5 y JDK1.5 el problema
persistirá, si no se configura la JVM como dice en este link
http://anjackson.net/node/740 (ver Java Flags).

¡Pero si así es como está configurado! Ahora mismo está puesto como
dice en ese enlace, con headless=true. Tú me habías dicho que querías justo
lo contrario, headless=false e instalar el X11 y el Xvfb, como se hacía con
el Tomcat 3 y 4.

David G. Folch

Posted on 22 Aug 2005 05:05 PM

--------------------------------------------------------------------------
Error en Tomcat 5.5.9 que funcionaba en 4.1.18

> Bueno, a ver, es que no es tan sencillo.
>
> Si lo ponemos en un servidor como el que teníamos en un principio
(TC4.1 y JDK1.4)
> ¿Volveremos a tener problemas de performance o recursos?

Claro, porque ahí el tratamiento de imágenes se hacía como tú dices,
de la forma antigua, a través del X11, lo que es lentísimo. A partir del
Tomcat 5, es el propio Java el que hace el tratamiento de imágenes, es mucho
más fácil y mucho más rápido.

OK, tu eres el experto!!!

> Si lo ponemos en un servidor (TC5.5 y JDK1.5)
> ¿Estamos seguros de que se arregla el problema HeadlessException?

No lo sé, por eso hemos trasladado el web a otro servidor, para
probarlo.

Para mi no es tan fácil cambiar de servidor en mi máquina local, soy
programador, no administrador de servidores.
Por eso al menos quería saber cual era el problema.


> En cualquier caso, hay que volver a volcar base de datos, y siempre
pueden salir más problemas.

Si usais tablas innodb, deberíais tener un script que cree
automáticamente esas tablas en su debido orden (teniendo en cuenta las
dependencias), porque el dump del mysql las vuelca como le da la gana, y
luego al restaurarla da errores... si alguna vez hay algún problema con la
base de datos, estará hecho el backup, pero no se podrá restaurar a menos
que tengais hecho ese script.

Yo puedo hacerlo desde el PHPMyAdmin pero me lleva 1 hora y media de
copy/paste!!!.
La manera es haciendo una copia de seguridad del servidor.
Hay que poner un
set foreign_key_cheks = 0;
antes de empezar a ejecutar el script o scripts;
y al finalizar
set foreign_key_cheks = 1;

> Por ahora ni necesitamos, ni queremos pagar un servidor dedicado.
> Pero es necesario que esa parte de la aplicación funcione, (es un
JApplet de 5000 lineas que me dibuja el desglose de modelos, es fundamental
para fábrica).
>
> No encuentro una solución factible vía re-implementación del código.

Es probable que ese sea el problema, que tengais alguna cosa deprecada
que sólo funciona en Tomcat 4 y haya cambiado en el 5... en ese caso, con
pasarlo al servidor del Tomcat 5 no se arreglaría, habría que pasarlo al del
Tomcat 4 (pero si haceis el script para crear la BD, se puede probar a
pasarlo a los dos en un momento).

Como ya te comenté, el problema es que:

- Applet da un error null, cuando mi HttpServlet instancia (usa) mi
JApplet (Applet forma parte JApplet ).

Ahora he hecho la misma prueba pero con un JApplet pelado tampoco NO
FUNCIONA!!!!!
ImageBuffer p.ej. SI FUNCIONA!!!!!!

Así que hay un problema de incompatibilidad, o, configuración, con
Tomcat y/o JDK, que en las versiones anteriores SI funcionaba. Pero no
encuentro nada al respecto en la web.


> Si no puedes cambiar la opción sólo para mi contexto, o no puedes o
quieres configurar nuestro servidor compartido de manera que no pete (con el
headless=false), yo ya no se que proponer, no creo que esa modificación
afecte a los otros contextos/clientes, y solucionaría el problema de mi
aplicación.

No se puede poner para un sólo cliente, y claro que afectaría a los
demás. Como puedes ver en http://folch.es:8080/testImg.jsp , ahora mismo el
tratamiento de imágenes funciona bien desde Java. Haciendo lo que tú
quieres, dejaría de funcionar.

OK!!!

> Supongo que si cambiamos a un servidor TC5.5 y JDK1.5 el problema
persistirá, si no se configura la JVM como dice en este link
http://anjackson.net/node/740 (ver Java Flags).

¡Pero si así es como está configurado! Ahora mismo está puesto como
dice en ese enlace, con headless=true. Tú me habías dicho que querías justo
lo contrario, headless=false e instalar el X11 y el Xvfb, como se hacía con
el Tomcat 3 y 4.

Veo que no nos habíamos entendido en esto, OK!!
---------------------------------------------------------
-----------------------------------------------------------
De todas maneras quiero investigar un poco más en Sun...
Supongo que te diré algo mañana.

Saludos





enREDados: Atencion al cliente

Posted on 22 Aug 2005 05:43 PM

--------------------------------------------------------------------------
> Yo puedo hacerlo desde el PHPMyAdmin pero me lleva 1 hora y media de
copy/paste!!!.

Pero eso lo tienes que hacer sólo una vez, y ya lo tienes para toda la
vida, lo guardas en un archivo de texto y listo... vendría bien por si
alguna vez hay que restaurar un backup.

> La manera es haciendo una copia de seguridad del servidor.
> Hay que poner un
> set foreign_key_cheks = 0;
> antes de empezar a ejecutar el script o scripts;
> y al finalizar
> set foreign_key_cheks = 1;

Eso no lo sabía... ¿hay que hacerlo al copiar la base de datos, o al
escribirla? Supongo que al escribirla en el destino, ¿no?

Pues si quieres lo hacemos y probamos si funciona en el otro
servidor... pero ya te digo, me da que el problema va a ser de la
aplicación, que usa alguna función que ya no existe.

> Como ya te comenté, el problema es que:
> - Applet da un error null, cuando mi HttpServlet instancia (usa) mi
JApplet (Applet forma parte JApplet ).
>
> Ahora he hecho la misma prueba pero con un JApplet pelado tampoco NO
FUNCIONA!!!!!
> ImageBuffer p.ej. SI FUNCIONA!!!!!!

Ah, entonces no es por los gráficos... entonces lo del headless no
tiene nada que ver, debe ser otra cosa. ¿A ver si tienes que subir alguna
clase? Prueba a subir la clase JApplet a tu directorio lib, a ver qué pasa.

> Así que hay un problema de incompatibilidad, o, configuración, con
Tomcat y/o JDK, que en las versiones anteriores SI funcionaba. Pero no
encuentro nada al respecto en la web.

Igual estoy diciendo una tontería, pero ¿podrías meter la aplicación
dentro de un JFrame en lugar de un JApplet? No sé, es algo que he encontrado
por ahí...

Busca por aquí: http://www.google.es/search?q=japplet+tomcat+5.5

> > Supongo que si cambiamos a un servidor TC5.5 y JDK1.5 el problema
persistirá, si no se configura la JVM como dice en este link
http://anjackson.net/node/740 (ver Java Flags).
>
> ¡Pero si así es como está configurado! Ahora mismo está puesto como
dice en ese enlace, con headless=true. Tú me habías dicho que querías justo
lo contrario, headless=false e instalar el X11 y el Xvfb, como se hacía con
el Tomcat 3 y 4.
>
> Veo que no nos habíamos entendido en esto, OK!!

Tú habías dicho que se pusiera a false... pero vamos, que eso sólo
afecta a los gráficos, el problema es otro.

David G. Folch

Posted on 22 Aug 2005 07:23 PM

--------------------------------------------------------------------------
Error en Tomcat 5.5.9 que funcionaba en 4.1.18

> Yo puedo hacerlo desde el PHPMyAdmin pero me lleva 1 hora y media de
copy/paste!!!.

Pero eso lo tienes que hacer sólo una vez, y ya lo tienes para toda la
vida, lo guardas en un archivo de texto y listo... vendría bien por si
alguna vez hay que restaurar un backup.

Los datos de la base de datos cambian, y los de la estructura de la
misma también. Necesito volcados completos de la bbdd del servidor. (Todavía
estamos en fase de desarrollo).


Eso no lo sabía... ¿hay que hacerlo al copiar la base de datos, o al
escribirla? Supongo que al escribirla en el destino, ¿no?

SI !!

Pues si quieres lo hacemos y probamos si funciona en el otro
servidor... pero ya te digo, me da que el problema va a ser de la
aplicación, que usa alguna función que ya no existe.

POR MI ADELANTE, GRACIAS!


> Como ya te comenté, el problema es que:
> - Applet da un error null, cuando mi HttpServlet instancia (usa) mi
JApplet (Applet forma parte JApplet ).
>
> Ahora he hecho la misma prueba pero con un JApplet pelado tampoco NO
FUNCIONA!!!!!
> ImageBuffer p.ej. SI FUNCIONA!!!!!!

Ah, entonces no es por los gráficos... entonces lo del headless no
tiene nada que ver, debe ser otra cosa. ¿A ver si tienes que subir alguna
clase? Prueba a subir la clase JApplet a tu directorio lib, a ver qué pasa.

Yo te dije lo del headless por esto (isHeadless lo llama applet): o
sea, que desde el punto de vista de java, es un tema de privilegios (del
x11?? no se, pero está relacionado con ("java.awt.headless", "false"), si
faltara una clase en el servidor daría un ClassNotFoundException o algo x el
estilo. Pero no un null (exception).

/*
* ***(#)GraphicsEnvironment.java 1.55 03/01/23
*
* Copyright 2003 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
[...]
public static boolean isHeadless() {
return getHeadlessProperty();
}
/**
* ***return the value of the property "java.awt.headless"
* ***since 1.4
*/
private static boolean getHeadlessProperty() {
if (headless == null) {
String nm = (String)java.security.AccessController.doPrivilege d(
new sun.security.action.GetPropertyAction(
"java.awt.headless", "false"));
if (nm.equals("true")) {
headless = Boolean.TRUE;
} else {
headless = Boolean.FALSE;
}
}
return headless.booleanValue();
}


> Así que hay un problema de incompatibilidad, o, configuración, con
Tomcat y/o JDK, que en las versiones anteriores SI funcionaba. Pero no
encuentro nada al respecto en la web.

Igual estoy diciendo una tontería, pero ¿podrías meter la aplicación
dentro de un JFrame en lugar de un JApplet? No sé, es algo que he encontrado
por ahí...


Busca por aquí: http://www.google.es/search?q=japplet+tomcat+5.5

HE VISTO EL LINK DEL JFRAME PERO NO CREO QUE TENGA NADA QUE VER.


> > Supongo que si cambiamos a un servidor TC5.5 y JDK1.5 el problema
persistirá, si no se configura la JVM como dice en este link
http://anjackson.net/node/740 (ver Java Flags).
>
> ¡Pero si así es como está configurado! Ahora mismo está puesto como
dice en ese enlace, con headless=true. Tú me habías dicho que querías justo
lo contrario, headless=false e instalar el X11 y el Xvfb, como se hacía con
el Tomcat 3 y 4.
>
> Veo que no nos habíamos entendido en esto, OK!!

Tú habías dicho que se pusiera a false... pero vamos, que eso sólo
afecta a los gráficos, el problema es otro.

SI, ESTÁ CLARO





-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------




Atte,

Folch, S.A.
David García Folch
Analista/programador

Que yo sepa no se deben usar librerías del API gráfico dentro de los
servidores de aplicaciones, porque me supongo que no quieras que esa
ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
conseguirías de la forma en la que te da error es lo primero.
Recuerdo que EJBs ya ponía restricciones al uso de clases de los
paquetes AWT y Swing, pero Servlets me parece que no lo hacía antes. La
explicación puede ser esa, pues Tomcat 4.x implementa la especificación
2.3 de Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan
añadido las restricciones.
Lo correcto es meter el applet en el HTML para que lo arranque la
máquina virtual del navegador del cliente.
Es que no entiendo si puedes tener algún caso de uso en el que quieras
arrancar la ventana de applet en el servidor, que además, siendo Linux,
lo correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.

Un saludo

Que yo sepa no se deben usar librerías del API gráfico dentro de los
servidores de aplicaciones, porque me supongo que no quieras que esa
ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
conseguirías de la forma en la que te da error es lo primero.
Recuerdo que EJBs ya ponía restricciones al uso de clases de los
paquetes AWT y Swing, pero Servlets me parece que no lo hacía antes. La
explicación puede ser esa, pues Tomcat 4.x implementa la especificación
2.3 de Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan
añadido las restricciones.
Lo correcto es meter el applet en el HTML para que lo arranque la
máquina virtual del navegador del cliente.
Es que no entiendo si puedes tener algún caso de uso en el que quieras
arrancar la ventana de applet en el servidor, que además, siendo Linux,
lo correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.

Un saludo

Que yo sepa no se deben usar librerías del API gráfico dentro de los
servidores de aplicaciones, porque me supongo que no quieras que esa
ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
conseguirías de la forma en la que te da error es lo primero.
Recuerdo que EJBs ya ponía restricciones al uso de clases de los
paquetes AWT y Swing, pero Servlets me parece que no lo hacía antes. La
explicación puede ser esa, pues Tomcat 4.x implementa la especificación
2.3 de Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan
añadido las restricciones.
Lo correcto es meter el applet en el HTML para que lo arranque la
máquina virtual del navegador del cliente.
Es que no entiendo si puedes tener algún caso de uso en el que quieras
arrancar la ventana de applet en el servidor, que además, siendo Linux,
lo correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.

Un saludo

Que yo sepa no se deben usar librerías del API gráfico dentro de los
servidores de aplicaciones, porque me supongo que no quieras que esa
ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
conseguirías de la forma en la que te da error es lo primero.
Recuerdo que EJBs ya ponía restricciones al uso de clases de los
paquetes AWT y Swing, pero Servlets me parece que no lo hacía antes. La
explicación puede ser esa, pues Tomcat 4.x implementa la especificación
2.3 de Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan
añadido las restricciones.
Lo correcto es meter el applet en el HTML para que lo arranque la
máquina virtual del navegador del cliente.
Es que no entiendo si puedes tener algún caso de uso en el que quieras
arrancar la ventana de applet en el servidor, que además, siendo Linux,
lo correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.

Un saludo

Que yo sepa no se deben usar librerías del API gráfico dentro de los
servidores de aplicaciones, porque me supongo que no quieras que esa
ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
conseguirías de la forma en la que te da error es lo primero.
Recuerdo que EJBs ya ponía restricciones al uso de clases de los
paquetes AWT y Swing, pero Servlets me parece que no lo hacía antes. La
explicación puede ser esa, pues Tomcat 4.x implementa la especificación
2.3 de Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan
añadido las restricciones.
Lo correcto es meter el applet en el HTML para que lo arranque la
máquina virtual del navegador del cliente.
Es que no entiendo si puedes tener algún caso de uso en el que quieras
arrancar la ventana de applet en el servidor, que además, siendo Linux,
lo correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.

Un saludo

Mi caso de uso es un JApplet que contiene 2 JPanels entre otros objetos
Swing. Este JApplet es la herramienta cliente para editar piezas de modelos
en 2d (cálculos a través de fórmulas de vectores con variables).

El problema es que fue mal diseñado desde el principio y todos los objetos
(incluidos los paneles de dibujo) forman parte del applet (están codificados
dentro de un solo archivo con 5000 lineas).

Este applet se instancia desde un servlet para mostrar el informe de
desglose de modelos de pedidos.

¿Crees que podré utilizar un JPanel desde el servlet para que me haga el
dibujo?

Estoy en medio del refactoring del JApplet (y una migración completa)

Gracias x tu interés
Saludos,
David G. Folch

"Mindundi" <xxx***gmail.com> escribió en el mensaje
news:SKlQe.92642$US.44757***news.ono.com...
> Que yo sepa no se deben usar librerías del API gráfico dentro de los
> servidores de aplicaciones, porque me supongo que no quieras que esa
> ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
> conseguirías de la forma en la que te da error es lo primero.
> Recuerdo que EJBs ya ponía restricciones al uso de clases de los paquetes
> AWT y Swing, pero Servlets me parece que no lo hacía antes. La explicación
> puede ser esa, pues Tomcat 4.x implementa la especificación 2.3 de
> Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan añadido las
> restricciones.
> Lo correcto es meter el applet en el HTML para que lo arranque la máquina
> virtual del navegador del cliente.
> Es que no entiendo si puedes tener algún caso de uso en el que quieras
> arrancar la ventana de applet en el servidor, que además, siendo Linux, lo
> correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.
>
> Un saludo

Mi caso de uso es un JApplet que contiene 2 JPanels entre otros objetos
Swing. Este JApplet es la herramienta cliente para editar piezas de modelos
en 2d (cálculos a través de fórmulas de vectores con variables).

El problema es que fue mal diseñado desde el principio y todos los objetos
(incluidos los paneles de dibujo) forman parte del applet (están codificados
dentro de un solo archivo con 5000 lineas).

Este applet se instancia desde un servlet para mostrar el informe de
desglose de modelos de pedidos.

¿Crees que podré utilizar un JPanel desde el servlet para que me haga el
dibujo?

Estoy en medio del refactoring del JApplet (y una migración completa)

Gracias x tu interés
Saludos,
David G. Folch

"Mindundi" <xxx***gmail.com> escribió en el mensaje
news:SKlQe.92642$US.44757***news.ono.com...
> Que yo sepa no se deben usar librerías del API gráfico dentro de los
> servidores de aplicaciones, porque me supongo que no quieras que esa
> ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
> conseguirías de la forma en la que te da error es lo primero.
> Recuerdo que EJBs ya ponía restricciones al uso de clases de los paquetes
> AWT y Swing, pero Servlets me parece que no lo hacía antes. La explicación
> puede ser esa, pues Tomcat 4.x implementa la especificación 2.3 de
> Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan añadido las
> restricciones.
> Lo correcto es meter el applet en el HTML para que lo arranque la máquina
> virtual del navegador del cliente.
> Es que no entiendo si puedes tener algún caso de uso en el que quieras
> arrancar la ventana de applet en el servidor, que además, siendo Linux, lo
> correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.
>
> Un saludo

Mi caso de uso es un JApplet que contiene 2 JPanels entre otros objetos
Swing. Este JApplet es la herramienta cliente para editar piezas de modelos
en 2d (cálculos a través de fórmulas de vectores con variables).

El problema es que fue mal diseñado desde el principio y todos los objetos
(incluidos los paneles de dibujo) forman parte del applet (están codificados
dentro de un solo archivo con 5000 lineas).

Este applet se instancia desde un servlet para mostrar el informe de
desglose de modelos de pedidos.

¿Crees que podré utilizar un JPanel desde el servlet para que me haga el
dibujo?

Estoy en medio del refactoring del JApplet (y una migración completa)

Gracias x tu interés
Saludos,
David G. Folch

"Mindundi" <xxx***gmail.com> escribió en el mensaje
news:SKlQe.92642$US.44757***news.ono.com...
> Que yo sepa no se deben usar librerías del API gráfico dentro de los
> servidores de aplicaciones, porque me supongo que no quieras que esa
> ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
> conseguirías de la forma en la que te da error es lo primero.
> Recuerdo que EJBs ya ponía restricciones al uso de clases de los paquetes
> AWT y Swing, pero Servlets me parece que no lo hacía antes. La explicación
> puede ser esa, pues Tomcat 4.x implementa la especificación 2.3 de
> Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan añadido las
> restricciones.
> Lo correcto es meter el applet en el HTML para que lo arranque la máquina
> virtual del navegador del cliente.
> Es que no entiendo si puedes tener algún caso de uso en el que quieras
> arrancar la ventana de applet en el servidor, que además, siendo Linux, lo
> correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.
>
> Un saludo

Mi caso de uso es un JApplet que contiene 2 JPanels entre otros objetos
Swing. Este JApplet es la herramienta cliente para editar piezas de modelos
en 2d (cálculos a través de fórmulas de vectores con variables).

El problema es que fue mal diseñado desde el principio y todos los objetos
(incluidos los paneles de dibujo) forman parte del applet (están codificados
dentro de un solo archivo con 5000 lineas).

Este applet se instancia desde un servlet para mostrar el informe de
desglose de modelos de pedidos.

¿Crees que podré utilizar un JPanel desde el servlet para que me haga el
dibujo?

Estoy en medio del refactoring del JApplet (y una migración completa)

Gracias x tu interés
Saludos,
David G. Folch

"Mindundi" <xxx***gmail.com> escribió en el mensaje
news:SKlQe.92642$US.44757***news.ono.com...
> Que yo sepa no se deben usar librerías del API gráfico dentro de los
> servidores de aplicaciones, porque me supongo que no quieras que esa
> ventana de Applet aparezca en el servidor, sino en el cliente. Lo que
> conseguirías de la forma en la que te da error es lo primero.
> Recuerdo que EJBs ya ponía restricciones al uso de clases de los paquetes
> AWT y Swing, pero Servlets me parece que no lo hacía antes. La explicación
> puede ser esa, pues Tomcat 4.x implementa la especificación 2.3 de
> Servlets, y Tomcat 5.x, la 2.4, en la que quizás sí se hayan añadido las
> restricciones.
> Lo correcto es meter el applet en el HTML para que lo arranque la máquina
> virtual del navegador del cliente.
> Es que no entiendo si puedes tener algún caso de uso en el que quieras
> arrancar la ventana de applet en el servidor, que además, siendo Linux, lo
> correco es que ni tuviera arrancadas las X, para mejorar el rendimiento.
>
> Un saludo