Application: gvSIG desktop

Hola, veo en el cambio asociado del SVN que no se ha aplicado el parche completo, ya que afectaba a WMSProtocolHandlerFactory.java y a SEDownloaderTask.java, pero sólo se ha aplicado la parte correspondiente a WMSProtocolHandlerFactory.

Por otra parte Joaquín no entiendo porqué se usa readFully en vez de read en WMSProtocolHandlerFactory. Ya me imagino que hay una razón detrás (ya que lo has restaurado de esta forma), pero me cuesta entenderlo, porque según la definición de readFully se lanza una excepción (EOFException) si los datos del input stream son menores que el tamaño del buffer, por lo que entiendo que si hay un getCapabilities muy corto no se leería correctamente.

Cesar Martinez Izquierdo wrote:

Hola, veo en el cambio asociado del SVN que no se ha aplicado el parche completo, ya que afectaba a WMSProtocolHandlerFactory.java y a SEDownloaderTask.java, pero sólo se ha aplicado la parte correspondiente a WMSProtocolHandlerFactory.

Uppsss, lo del SEDownloaderTask se me ha escapado al hacer una vuelta atras en mi workspace de ese proyecto.
Lo vuelvo a meter.

Por otra parte Joaquín no entiendo porqué se usa readFully en vez de read en WMSProtocolHandlerFactory. Ya me imagino que hay una razón detrás (ya que lo has restaurado de esta forma), pero me cuesta entenderlo, porque según la definición de readFully se lanza una excepción (EOFException) si los datos del input stream son menores que el tamaño del buffer, por lo que entiendo que si hay un getCapabilities muy corto no se leería correctamente.

Pues lo de la excepcion con un capabilities corto no se me habia ocurrido.
He restaurado el readFully por que el read normal salta cuando se terminan de leer los datos que hay en ese momento en el socket. Esto ocasiona que si llegan fragmentado el capabilities en varios paquetes y entre alguno de ellos hay un retardo, salte el read sin leer los datos. Nos estaba pasando con un servidor que solo se leian unos 50 caracteres y el resto del buffer a ceros por que saltaba el read al no haber mas caracteres que leer, y sin embargo el readfully se esperaba a que estuviesen todos. Basicamente lo he dejado por que antes iba, pero por lo que comentas tambien puede ser fuente de problemas. Habra que repasarlo...

De todos modos deberia eliminarse ese codigo de WMSProtocolHandlerFactory para pasar a usar solo el Downloader, ya vere a ver como me las arreglo con esto.

Hola Joaquín, una solución al problema del read/readFully sería envolver el DataInputStream con un BufferedInputStream y usar el método read de este último:
https://docs.oracle.com/javase/7/docs/api/java/io/BufferedInputStream.html#read%28byte[],%20int,%20int%29
Según la documentación, llama a read las veces que sea necesario hasta que se obtenga un EOF o se lea el número de bytes requeridos.

Cesar Martinez Izquierdo wrote:

Hola Joaquín, una solución al problema del read/readFully sería envolver el DataInputStream con un BufferedInputStream y usar el método read de este último:
https://docs.oracle.com/javase/7/docs/api/java/io/BufferedInputStream.html#read%28byte[],%20int,%20int%29
Según la documentación, llama a read las veces que sea necesario hasta que se obtenga un EOF o se lea el número de bytes requeridos.

Bastante mas seguro que lo del readFully.
Ya esta metido.

Gracias.