[Gvsig_desarrolladores] WFS jaxb request SUPORT

[Carlos Sánchez Periñán]

Hola de nuevo Cristian:

Tienes razón con lo de que al hacer el data-binding te puede fallar la 
correspondencia de lo que deberia ser una clase java y lo que no. Para 
esos casos no tienes mas remedio que generarte un fichero de binding 
para personalizar la conversión a clases java. Tendrás que generarte el 
fichero binding estableciendo o bien reglas para cada "element" que 
comience por "_" para que te nombre como Abstract la clase que vaya a 
generar en Java.
Creo que por defecto JAXB te generará interfaces.

El caso es que JAXB tiene un binding por defecto para generar las clases 
java, este es generico a los lenguajes XML, pero vemos que en este caso 
nos fallas con la declaración de las clases abstractas que comienzan con 
"_" al duplicar nombres. Habrá que personalizar el proceso de binding.

Como ejemplo de personalización del data binding en** JAXB te puede 
servir a lo mejor la siguiente declaración de binding externa para 
redefinir el binding por defecto, esto es una aproximación donde habria 
que cambiar los nombres por los correctos tanto del fichero .xsd como de 
las propiedades y elementos declarados:

<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/*xml*/ns/*jaxb*"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jxb:bindings schemaLocation="SchemaWFS.xsd" node="/xs:schema">
<jxb:bindingsnode="//xs:complejoType[@name='_abstractClass']/xs:sequence/xs:AbstractType">
                            <jxb:class name="_abstractClass"/>
                            <jxb:property name="AbstractTypeClass"/>
                    </jxb:bindings>
        </jxb:bindings>
</jxb:bindings>

Un saludo Cristian.

Cristian Rinaldi escribió:
> Carlos: Ante todo muchas gracias por la respuesta.
>
> Carlos Dijo:
>
>         Los estandares (schemas xml) tienen nombres de elementos que
>     empiezan por "_"(guiones bajos) para representas elementos no usables
>     directamente, es decir abstractos, por tanto no pueden traducirse por
>     clases normales. Estas tipos y elementos abstractos, representan las
>     clases abstractas de obligada sustitución por esquemas locales a una
>     aplicación u otros de la especificación que describen elementos menos
>     generales. Por ejemplo <_Feature> es abstracto y ha de ser sustituido
>     por una otra etiqueta con otro o el mismo nombre sin la "_" como por
>     ejemplo <FeatureMember> más especifica que extiende de la clase
>     general
>     abstracta. Por tanto en un fichero XML transmitido por el servicio WFS
>     jamás nos aparecerá una etiqueta con "_", aunque sí lo podrá hacer
>     en un
>     esquema "*.xsd"  como substitutionGroup o extension.
>
>
> Sobre esto tengo mis objeciones, si bien tienes razon sobre lo que 
> dices, en una instancia de XML jamas aparecera un Elemento o Tipo con 
> "_", porque es abstracto. Pero cuando uno realiza un mapeo XML - 
> Objeto (Bean) necesita que esos Tipos con "_" pasen a ser clases 
> Abstractas o Interfaces en la jerarquía de clases. Porque estas clases 
> Abstractas contienen atributos comunes a sus clases derivadas.
> Sin mas, saludos atte. Cristian Rinaldi.
>
>  
>
>
> -- 
> www.juglar.org <http://www.juglar.org>
> "El Java User Group del Litoral Argentino"
>
> @Saludos( mappedBy="GNR" )
> public String saludo(){
>   return new String( "Chinese Democracy" );
> }
> ------------------------------------------------------------------------
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
>   


-- 
 
-----------------------------------------------
Carlos Sánchez Periñán
Equipo de desarrollo gvSIG
Consellería de Infraestructuras y Transporte
Valencia - Spain
-----------------------------------------------