Re: [mindfood] Sobre #34 de Effective Java [1]

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

Hola de nuevo,

Siguiendo con el relato de ayer, lamentablemente utilizar proxies dinámicos no 
resuelve el problema, ya que lo que hacen es implementar dinámicamente 
interfaces.
En este caso, lo que hay que interceptar son llamadas a métodos de JspWriter, 
que es una clase que extiende de Writer, que a su vez es una clase, no un 
interfaz.
Llegados a este punto, no sé si lo más conveniente sería tratar de manipular 
en runtime el bytecode, o bien proporcionar "parches" para las distintas 
implementaciones y versiones de los compiladores jsp. ¿Se os ocurre alguna 
alternativa más? ¿Qué opción os parece más acertada?

Por otro lado, hasta ahora los micro-kernels no han conseguido convencerme de 
su idoneidad. Sin embargo, uno de los puntos que favorecen intrínsecamente, y 
que yo en el plano teórico nunca he visto encajar, ha sido la definición de 
una interfaz por clase. En este caso tengo que reconocer que hubiera 
simplificado el problema, pero sólo en el caso de que fuera aplicado por Sun 
en los APIs. Sigo pensando que, como otras tendencias (como el extreme 
programming), estas directivas se definen únicamente por su conveniencia 
práctica, no por encajar como solución a problemas detectados en la OOP.

Un saludo,
Jose.

On Wednesday 06 July 2005 11:33, you wrote:
> Hola,
>
> En el desarrollo de un proyecto, me he encontrado con una situación en la
> que confluyen distintas problemáticas, en las que me vendría bien vuestra
> opinión. A pesar de que sea un poco largo, creo que es necesario que
> explique más o menos pormenorizadamente el contexto del problema.
>
> En lineas generales, el propósito es suplantar la variable de instancia
> "out" accesible por un jsp. El contenido del jsp no se conoce a priori (se
> considera arbitrario), y es conveniente proporcionar a dicho jsp un entorno
> en el que no se devuelva nada por la red, hasta más adelante.
>
> En mi opinión a estas alturas es difícil justificar ningún mecanismo de
> especificación (como la herencia) basada en variables protegidas. Soy
> consciente de que éste no es necesariamente el caso, ya que los jsp son
> servlets generados dinámicamente, y la variable "out" en general sería
> local al método "service" del servlet. Lo comento simplemente porque no es
> infrecuente encontrarse con APIs basadas en esa idea.
>
> Pues bien, parece que, implementando un JspWriter independiente del
> HttpServletResponse, asignándolo a la variable "out" (confiando en que el
> compilador jsp no la declare "final"), y restaurándola posteriormente,
> conseguiría mi propósito.
> Se da el caso de los taglibs utilizados por el jsp puedan utilizar la
> instancia de "PageContext", la cual proporcionaría el JspWriter original a
> través del método "getOut()".
> El siguiente paso entonces es implementar un delegador sobre el
> PageContext, de forma que respete el comportamiento de la instancia
> original, salvo al proveer el JspWriter.
> Al probar dicha implementación y ver que no funciona, me doy cuenta de que
> los taglibs problemáticos son los que acaban llamando a los métodos
> "include" o "forward", y éstos no estaban siendo particularizados.
> El siguiente problema viene por el hecho de que, en contenedor de servlets
> concreto que vengo usando, el compilador JSP (Jasper), hace uso variables
> protegidas en la implementación de dicho método, con lo cual la tarea se
> complica significativamente.
>
> En este punto, la única salida que evitaría la necesidad de "parchear" el
> compilador de JSP, sería utilizar Reflection para obtener las variables
> miembro del PageContext original, quedarme únicamente con los JspWriter,
> reemplazarlos antes del "include", y restaurarlos a continuación.
>
> No sé si anticipáis el resultado (este punto es el único que hace
> referencia al asunto del mensaje).
> La suplantación de la variable miembro falla por un detalle: en Jasper,
> ésta se declara como instancia de la implementación de JspWriter, y no de
> JspWriter. Es decir, no puedo asignar a esa variable otro valor de
> JspWriter, ya que está declarada no como JspWriter, sino como
> JspWriterImpl.
> Este detalle hace difícil que pueda no depender de la implementación del
> compilador JSP concreto.
> Lo único que se me ocurre en este punto es usar "proxies" dinámicos,
> interceptar las llamadas a los métodos de la implementación del JspWriter,
> y suplantarlas con la ejecución del JspWriter sustituto. Como podéis
> anticipar, esto supone un código elegantísimo del tipo:
>
> if  (method.equals("aa")) {
>   result = writer.aa(..);
> else if  (method.equals("bb") {
>   result = writer.bb(..);
> }
>
> Como conclusión, diría que algunos puntos de Effective Java, aparentemente
> recomendaciones, pueden acabar teniendo una importancia no prevista en
> determinadas situaciones.
>
> Un saludo,
> Jose.
>
> [1]
> http://www.informit.com/isapi/product_id~%7B7DE69993-3EF5-4354-9E10-9F8A535
>909F1%7D/content/images/0201310058/samplechapter/blochch7.pdf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: mindfood-unsubscribe@xxxxxxxxxxxxxxx
> For additional commands, e-mail: mindfood-help@xxxxxxxxxxxxxxx