Issues with arbitrary transformation of boolean to String

[Ioannis Mavroukakis]

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

   <xs:element name="Foo">
         <xs:complexType>
             <xs:complexContent>
                     <xs:attribute name="bar" type="xs:string"/>
             </xs:complexContent>
         </xs:complexType>
  </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for  
business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a  
WSDL call.

I thought that I could perhaps use a custom binding to do my biding  
and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/
xsd:complexContent/xsd:attribute[@name='bar']">
             <property>
                 <baseType>
                     <javaType name="java.lang.String"
                     
parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                     
printMethod="com.transform.PartnerTransform.printStringToBoolean" />
                 </baseType>
             </property>
         </bindings>

However I quickly realised that my cunning plan to assign another  
XMLAdapter while initialising the marshaller for each use case was  
blown out of the water
as the adapter is randomly named by xjc, and touching the generated  
classes is a no-no.

Therefore, the grand question here is , is there some arcane way to  
make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wolfgang Laun-2]

If the XML is a single letter, then parse must convert from string to boolean, print vice versa. And the javaType name is java.lang.Boolean.

-W

On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

 <xs:element name="Foo">
       <xs:complexType>
           <xs:complexContent>
                   <xs:attribute name="bar" type="xs:string"/>
           </xs:complexContent>
       </xs:complexType>
 </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a WSDL call.

I thought that I could perhaps use a custom binding to do my biding and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
           <property>
               <baseType>
                   <javaType name="java.lang.String"
                   parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                   printMethod="com.transform.PartnerTransform.printStringToBoolean" />
               </baseType>
           </property>
       </bindings>

However I quickly realised that my cunning plan to assign another XMLAdapter while initialising the marshaller for each use case was blown out of the water
as the adapter is randomly named by xjc, and touching the generated classes is a no-no.

Therefore, the grand question here is , is there some arcane way to make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ioannis Mavroukakis]

No the XML will be a String 0 or 1, but what I want to transform it to, is String S or N respectively :-)

Thanks!

Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert from string to boolean, print vice versa. And the javaType name is java.lang.Boolean.

-W

On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

 <xs:element name="Foo">
       <xs:complexType>
           <xs:complexContent>
                   <xs:attribute name="bar" type="xs:string"/>
           </xs:complexContent>
       </xs:complexType>
 </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a WSDL call.

I thought that I could perhaps use a custom binding to do my biding and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
           <property>
               <baseType>
                   <javaType name="java.lang.String"
                   parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                   printMethod="com.transform.PartnerTransform.printStringToBoolean" />
               </baseType>
           </property>
       </bindings>

However I quickly realised that my cunning plan to assign another XMLAdapter while initialising the marshaller for each use case was blown out of the water
as the adapter is randomly named by xjc, and touching the generated classes is a no-no.

Therefore, the grand question here is , is there some arcane way to make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Ioannis Mavroukakis]

I should also add, that on top of that, I need to be able to pass at runtime an XMLAdapter that will override this functionality,

so that String 0 or 1 can be mapped to any other textual representation :-/

Y.

On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to transform it to, is String S or N respectively :-)

Thanks!

Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert from string to boolean, print vice versa. And the javaType name is java.lang.Boolean.

-W

On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

 <xs:element name="Foo">
       <xs:complexType>
           <xs:complexContent>
                   <xs:attribute name="bar" type="xs:string"/>
           </xs:complexContent>
       </xs:complexType>
 </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a WSDL call.

I thought that I could perhaps use a custom binding to do my biding and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
           <property>
               <baseType>
                   <javaType name="java.lang.String"
                   parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                   printMethod="com.transform.PartnerTransform.printStringToBoolean" />
               </baseType>
           </property>
       </bindings>

However I quickly realised that my cunning plan to assign another XMLAdapter while initialising the marshaller for each use case was blown out of the water
as the adapter is randomly named by xjc, and touching the generated classes is a no-no.

Therefore, the grand question here is , is there some arcane way to make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Wolfgang Laun-2]

I think what you need is

<jxb:bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
  <jxb:property>
    <jxb:baseType>
      <jxb:javaType name="java.lang.String"
           parseMethod="com.Transform.parse01ToString"
           printMethod="com.Transform.printStringTo01" />
    </jxb:baseType>
  </jxb:property>
</jxb:bindings>

which converts "0" or "1" in the XML to whatever the com.Transform decides:

package com;
import java.util.*;
public class Transform {
    private static String ouiChar;
    private static String nonChar;
    public static void setOuiNon( String oui, String non ){
        ouiChar = oui;
        nonChar = non;
    }
    public static String parse01ToString( String value ){
        return value.equals( "0" ) ? nonChar : ouiChar;
    }
    public static String printStringTo01( String impl ){
        return impl.equals( ouiChar ) ? "1" : "0";
    }
}

All you have to do, is call the static method to define the "oui" or "non" character.

Although I don't see why the application cannot handle the "0" or "1". Whatever.

-W

On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

I should also add, that on top of that, I need to be able to pass at runtime an XMLAdapter that will override this functionality,

so that String 0 or 1 can be mapped to any other textual representation :-/

Y.

On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to transform it to, is String S or N respectively :-)

Thanks!

Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert from string to boolean, print vice versa. And the javaType name is java.lang.Boolean.

-W

On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

 <xs:element name="Foo">
       <xs:complexType>
           <xs:complexContent>
                   <xs:attribute name="bar" type="xs:string"/>
           </xs:complexContent>
       </xs:complexType>
 </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a WSDL call.

I thought that I could perhaps use a custom binding to do my biding and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
           <property>
               <baseType>
                   <javaType name="java.lang.String"
                   parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                   printMethod="com.transform.PartnerTransform.printStringToBoolean" />
               </baseType>
           </property>
       </bindings>

However I quickly realised that my cunning plan to assign another XMLAdapter while initialising the marshaller for each use case was blown out of the water
as the adapter is randomly named by xjc, and touching the generated classes is a no-no.

Therefore, the grand question here is , is there some arcane way to make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Ioannis Mavroukakis]

Hi Wolfgang,

Thanks for that, I had gotten as far as this. The reason why 0/1 cannot be handled is that the wsdl endpoint has different definitions for true/false (S and N respectively. It's how it is and I cannot change it :-). 

My main issue is that I want to be able to supply an XmlAdaptor per use case, defining a different Transform class. I can see how this is done on the api but as xjc is generating and annotating the source, I cannot see how I could overide the generated Adaptor at runtime. It would be nice if I could instruct xjc to generate an adaptor with a specific name which I could then unset and set with another one.

Y.  

On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:

I think what you need is

<jxb:bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
  <jxb:property>
    <jxb:baseType>
      <jxb:javaType name="java.lang.String"
           parseMethod="com.Transform.parse01ToString"
           printMethod="com.Transform.printStringTo01" />
    </jxb:baseType>
  </jxb:property>
</jxb:bindings>

which converts "0" or "1" in the XML to whatever the com.Transform decides:

package com;
import java.util.*;
public class Transform {
    private static String ouiChar;
    private static String nonChar;
    public static void setOuiNon( String oui, String non ){
        ouiChar = oui;
        nonChar = non;
    }
    public static String parse01ToString( String value ){
        return value.equals( "0" ) ? nonChar : ouiChar;
    }
    public static String printStringTo01( String impl ){
        return impl.equals( ouiChar ) ? "1" : "0";
    }
}

All you have to do, is call the static method to define the "oui" or "non" character.

Although I don't see why the application cannot handle the "0" or "1". Whatever.

-W

On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

I should also add, that on top of that, I need to be able to pass at runtime an XMLAdapter that will override this functionality,

so that String 0 or 1 can be mapped to any other textual representation :-/

Y.

On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to transform it to, is String S or N respectively :-)

Thanks!

Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert from string to boolean, print vice versa. And the javaType name is java.lang.Boolean.

-W

On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello fellow listers,

I've got the following conundrum I'd like some help with.

Assume this schema (shortened for brevity)

 <xs:element name="Foo">
       <xs:complexType>
           <xs:complexContent>
                   <xs:attribute name="bar" type="xs:string"/>
           </xs:complexContent>
       </xs:complexType>
 </xs:element>

In reality, bar is a boolean attribute (stay with me) which I need for business reasons to convert to a single character lexical
equivalent of true/false in another language, for transport over a WSDL call.

I thought that I could perhaps use a custom binding to do my biding and extend that for different use cases hence

<bindings node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
           <property>
               <baseType>
                   <javaType name="java.lang.String"
                   parseMethod="com.transform.PartnerTransform.parseBooleanToString"
                   printMethod="com.transform.PartnerTransform.printStringToBoolean" />
               </baseType>
           </property>
       </bindings>

However I quickly realised that my cunning plan to assign another XMLAdapter while initialising the marshaller for each use case was blown out of the water
as the adapter is randomly named by xjc, and touching the generated classes is a no-no.

Therefore, the grand question here is , is there some arcane way to make jaxb do that, or should I be looking at a different solution?

Thanks!

Yiannis


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[No 0ne]

On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
> Hi Wolfgang,
> Thanks for that, I had gotten as far as this. The reason why 0/1
> cannot be handled is that the wsdl endpoint has different definitions
> for true/false (S and N respectively. It's how it is and I cannot
> change it :-).
> My main issue is that I want to be able to supply an XmlAdaptor per
> use case, defining a different Transform class.
Make the Transform class implement "setTrueFalseTransliteration(char
ouiChar, char nonChar)" and adjust the true/false characters accordingly
with your use case (before serializing/deserializing your XML)?  

> I can see how this is done on the api but as xjc is generating and
> annotating the source, I cannot see how I could overide the generated
> Adaptor at runtime. It would be nice if I could instruct xjc to
> generate an adaptor with a specific name which I could then unset and
> set with another one.
Repeating the suggestion above at a more generalized level: why cant you
keep the name constant but change the runtime *behaviour* of your
transformer accordingly to your needs?
>
> Y.  
no0ne

>
> On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:
>
>
>
> > I think what you need is
> >
> > <jxb:bindings
> > node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
> >   <jxb:property>
> >     <jxb:baseType>
> >       <jxb:javaType name="java.lang.String"
> >            parseMethod="com.Transform.parse01ToString"
> >            printMethod="com.Transform.printStringTo01" />
> >     </jxb:baseType>
> >   </jxb:property>
> > </jxb:bindings>
> >
> > which converts "0" or "1" in the XML to whatever the com.Transform
> > decides:
> >
> > package com;
> > import java.util.*;
> > public class Transform {
> >     private static String ouiChar;
> >     private static String nonChar;
> >     public static void setOuiNon( String oui, String non ){
> >         ouiChar = oui;
> >         nonChar = non;
> >     }
> >     public static String parse01ToString( String value ){
> >         return value.equals( "0" ) ? nonChar : ouiChar;
> >     }
> >     public static String printStringTo01( String impl ){
> >         return impl.equals( ouiChar ) ? "1" : "0";
> >     }
> > }
> >
> > All you have to do, is call the static method to define the "oui" or
> > "non" character.
> >
> > Although I don't see why the application cannot handle the "0" or
> > "1". Whatever.
> >
> > -W
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
> > <imavroukakis@...> wrote:
> >         I should also add, that on top of that, I need to be able to
> >         pass at runtime an XMLAdapter that will override this
> >         functionality,
> >         so that String 0 or 1 can be mapped to any other textual
> >         representation :-/
> >        
> >        
> >         Y.
> >        
> >        
> >         On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:
> >        
> >         > No the XML will be a String 0 or 1, but what I want to
> >         > transform it to, is String S or N respectively :-)
> >         >
> >         >
> >         > Thanks!
> >         >
> >         >
> >         > Yiannis
> >         >
> >         > On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:
> >         >
> >         > > If the XML is a single letter, then parse must convert
> >         > > from string to boolean, print vice versa. And the
> >         > > javaType name is java.lang.Boolean.
> >         > >
> >         > > -W
> >         > >
> >         > >
> >         > > On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
> >         > > <imavroukakis@...> wrote:
> >         > >         Hello fellow listers,
> >         > >        
> >         > >         I've got the following conundrum I'd like some
> >         > >         help with.
> >         > >        
> >         > >         Assume this schema (shortened for brevity)
> >         > >        
> >         > >          <xs:element name="Foo">
> >         > >                <xs:complexType>
> >         > >                    <xs:complexContent>
> >         > >                            <xs:attribute name="bar"
> >         > >         type="xs:string"/>
> >         > >                    </xs:complexContent>
> >         > >                </xs:complexType>
> >         > >          </xs:element>
> >         > >        
> >         > >         In reality, bar is a boolean attribute (stay
> >         > >         with me) which I need for business reasons to
> >         > >         convert to a single character lexical
> >         > >         equivalent of true/false in another language,
> >         > >         for transport over a WSDL call.
> >         > >        
> >         > >         I thought that I could perhaps use a custom
> >         > >         binding to do my biding and extend that for
> >         > >         different use cases hence
> >         > >        
> >         > >         <bindings
> >         > >         node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
> >         > >                    <property>
> >         > >                        <baseType>
> >         > >                            <javaType
> >         > >         name="java.lang.String"
> >         > >        
> >         > >          parseMethod="com.transform.PartnerTransform.parseBooleanToString"
> >         > >        
> >         > >          printMethod="com.transform.PartnerTransform.printStringToBoolean" />
> >         > >                        </baseType>
> >         > >                    </property>
> >         > >                </bindings>
> >         > >        
> >         > >         However I quickly realised that my cunning plan
> >         > >         to assign another XMLAdapter while initialising
> >         > >         the marshaller for each use case was blown out
> >         > >         of the water
> >         > >         as the adapter is randomly named by xjc, and
> >         > >         touching the generated classes is a no-no.
> >         > >        
> >         > >         Therefore, the grand question here is , is there
> >         > >         some arcane way to make jaxb do that, or should
> >         > >         I be looking at a different solution?
> >         > >        
> >         > >         Thanks!
> >         > >        
> >         > >         Yiannis
> >         > >        
> >         > >        
> >         > >         ---------------------------------------------------------------------
> >         > >         To unsubscribe, e-mail:
> >         > >         users-unsubscribe@...
> >         > >         For additional commands, e-mail:
> >         > >         users-help@...
> >         > >        
> >         > >
> >         > >
> >         > > ______________________________________________________________________
> >         > > This email has been scanned by the MessageLabs Email
> >         > > Security System.
> >         > > For more information please visit
> >         > > http://www.messagelabs.com/email 
> >         > > ______________________________________________________________________
> >         >
> >         >
> >        
> >        
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security
> > System.
> > For more information please visit http://www.messagelabs.com/email 
> > ______________________________________________________________________
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ioannis Mavroukakis]

Hello :-)

I suppose I could but what I want to achieve is plugability as not all  
use cases will need this transform but All of them will use Foo. Hence  
in the packages of these use cases I want to be able to redefine the  
adapter.. Does that make sense?

On 23 Sep 2009, at 22:24, No 0ne <no0ne@...> wrote:

> On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
>> Hi Wolfgang,
>> Thanks for that, I had gotten as far as this. The reason why 0/1
>> cannot be handled is that the wsdl endpoint has different definitions
>> for true/false (S and N respectively. It's how it is and I cannot
>> change it :-).
>> My main issue is that I want to be able to supply an XmlAdaptor per
>> use case, defining a different Transform class.
> Make the Transform class implement "setTrueFalseTransliteration(char
> ouiChar, char nonChar)" and adjust the true/false characters  
> accordingly
> with your use case (before serializing/deserializing your XML)?
>
>> I can see how this is done on the api but as xjc is generating and
>> annotating the source, I cannot see how I could overide the generated
>> Adaptor at runtime. It would be nice if I could instruct xjc to
>> generate an adaptor with a specific name which I could then unset and
>> set with another one.
> Repeating the suggestion above at a more generalized level: why cant  
> you
> keep the name constant but change the runtime *behaviour* of your
> transformer accordingly to your needs?
>>
>> Y.
> no0ne
>
>>
>> On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:
>>
>>
>>
>>> I think what you need is
>>>
>>> <jxb:bindings
>>> node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/
>>> xsd:attribute[@name='bar']">
>>>  <jxb:property>
>>>    <jxb:baseType>
>>>      <jxb:javaType name="java.lang.String"
>>>           parseMethod="com.Transform.parse01ToString"
>>>           printMethod="com.Transform.printStringTo01" />
>>>    </jxb:baseType>
>>>  </jxb:property>
>>> </jxb:bindings>
>>>
>>> which converts "0" or "1" in the XML to whatever the com.Transform
>>> decides:
>>>
>>> package com;
>>> import java.util.*;
>>> public class Transform {
>>>    private static String ouiChar;
>>>    private static String nonChar;
>>>    public static void setOuiNon( String oui, String non ){
>>>        ouiChar = oui;
>>>        nonChar = non;
>>>    }
>>>    public static String parse01ToString( String value ){
>>>        return value.equals( "0" ) ? nonChar : ouiChar;
>>>    }
>>>    public static String printStringTo01( String impl ){
>>>        return impl.equals( ouiChar ) ? "1" : "0";
>>>    }
>>> }
>>>
>>> All you have to do, is call the static method to define the "oui" or
>>> "non" character.
>>>
>>> Although I don't see why the application cannot handle the "0" or
>>> "1". Whatever.
>>>
>>> -W
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
>>> <imavroukakis@...> wrote:
>>>        I should also add, that on top of that, I need to be able to
>>>        pass at runtime an XMLAdapter that will override this
>>>        functionality,
>>>        so that String 0 or 1 can be mapped to any other textual
>>>        representation :-/
>>>
>>>
>>>        Y.
>>>
>>>
>>>        On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:
>>>
>>>> No the XML will be a String 0 or 1, but what I want to
>>>> transform it to, is String S or N respectively :-)
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> Yiannis
>>>>
>>>> On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:
>>>>
>>>>> If the XML is a single letter, then parse must convert
>>>>> from string to boolean, print vice versa. And the
>>>>> javaType name is java.lang.Boolean.
>>>>>
>>>>> -W
>>>>>
>>>>>
>>>>> On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
>>>>> <imavroukakis@...> wrote:
>>>>>        Hello fellow listers,
>>>>>
>>>>>        I've got the following conundrum I'd like some
>>>>>        help with.
>>>>>
>>>>>        Assume this schema (shortened for brevity)
>>>>>
>>>>>         <xs:element name="Foo">
>>>>>               <xs:complexType>
>>>>>                   <xs:complexContent>
>>>>>                           <xs:attribute name="bar"
>>>>>        type="xs:string"/>
>>>>>                   </xs:complexContent>
>>>>>               </xs:complexType>
>>>>>         </xs:element>
>>>>>
>>>>>        In reality, bar is a boolean attribute (stay
>>>>>        with me) which I need for business reasons to
>>>>>        convert to a single character lexical
>>>>>        equivalent of true/false in another language,
>>>>>        for transport over a WSDL call.
>>>>>
>>>>>        I thought that I could perhaps use a custom
>>>>>        binding to do my biding and extend that for
>>>>>        different use cases hence
>>>>>
>>>>>        <bindings
>>>>>        node="/xsd:schema/xsd:element[@name='Foo']/
>>>>> xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
>>>>>                   <property>
>>>>>                       <baseType>
>>>>>                           <javaType
>>>>>        name="java.lang.String"
>>>>>
>>>>>          
>>>>> parseMethod="com.transform.PartnerTransform.parseBooleanToString"
>>>>>
>>>>>          
>>>>> printMethod=
>>>>> "com.transform.PartnerTransform.printStringToBoolean" />
>>>>>                       </baseType>
>>>>>                   </property>
>>>>>               </bindings>
>>>>>
>>>>>        However I quickly realised that my cunning plan
>>>>>        to assign another XMLAdapter while initialising
>>>>>        the marshaller for each use case was blown out
>>>>>        of the water
>>>>>        as the adapter is randomly named by xjc, and
>>>>>        touching the generated classes is a no-no.
>>>>>
>>>>>        Therefore, the grand question here is , is there
>>>>>        some arcane way to make jaxb do that, or should
>>>>>        I be looking at a different solution?
>>>>>
>>>>>        Thanks!
>>>>>
>>>>>        Yiannis
>>>>>
>>>>>
>>>>>        
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>>        To unsubscribe, e-mail:
>>>>>        users-unsubscribe@...
>>>>>        For additional commands, e-mail:
>>>>>        users-help@...
>>>>>
>>>>>
>>>>>
>>>>> ______________________________________________________________________

 

>>>>> This email has been scanned by the MessageLabs Email
>>>>> Security System.
>>>>> For more information please visit
>>>>> http://www.messagelabs.com/email
>>>>> ______________________________________________________________________
 

>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ______________________________________________________________________
 

>>> This email has been scanned by the MessageLabs Email Security
>>> System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
 

>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wolfgang Laun-2]

Foo uses some AdapterN, where N might change, but all AdapterN variants use the Transform methods parseX and printX. Since this remains the same class for all variants, you can set its behaviour, to do whatever is appropriate. Setting the output values identical to the input values you achieve a no-op.
-W

On Thu, Sep 24, 2009 at 10:20 AM, Ioannis Mavroukakis <imavroukakis@...> wrote:

Hello :-)

I suppose I could but what I want to achieve is plugability as not all use cases will need this transform but All of them will use Foo. Hence in the packages of these use cases I want to be able to redefine the adapter.. Does that make sense?

On 23 Sep 2009, at 22:24, No 0ne <no0ne@...> wrote:

On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:

Hi Wolfgang,
Thanks for that, I had gotten as far as this. The reason why 0/1
cannot be handled is that the wsdl endpoint has different definitions
for true/false (S and N respectively. It's how it is and I cannot
change it :-).
My main issue is that I want to be able to supply an XmlAdaptor per
use case, defining a different Transform class.

Make the Transform class implement "setTrueFalseTransliteration(char
ouiChar, char nonChar)" and adjust the true/false characters accordingly
with your use case (before serializing/deserializing your XML)?

I can see how this is done on the api but as xjc is generating and
annotating the source, I cannot see how I could overide the generated
Adaptor at runtime. It would be nice if I could instruct xjc to
generate an adaptor with a specific name which I could then unset and
set with another one.

Repeating the suggestion above at a more generalized level: why cant you
keep the name constant but change the runtime *behaviour* of your
transformer accordingly to your needs?

Y.

no0ne

On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:

I think what you need is

<jxb:bindings
node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
 <jxb:property>
  <jxb:baseType>
    <jxb:javaType name="java.lang.String"
         parseMethod="com.Transform.parse01ToString"
         printMethod="com.Transform.printStringTo01" />
  </jxb:baseType>
 </jxb:property>
</jxb:bindings>

which converts "0" or "1" in the XML to whatever the com.Transform
decides:

package com;
import java.util.*;
public class Transform {
  private static String ouiChar;
  private static String nonChar;
  public static void setOuiNon( String oui, String non ){
      ouiChar = oui;
      nonChar = non;
  }
  public static String parse01ToString( String value ){
      return value.equals( "0" ) ? nonChar : ouiChar;
  }
  public static String printStringTo01( String impl ){
      return impl.equals( ouiChar ) ? "1" : "0";
  }
}

All you have to do, is call the static method to define the "oui" or
"non" character.

Although I don't see why the application cannot handle the "0" or
"1". Whatever.

-W






On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
      I should also add, that on top of that, I need to be able to
      pass at runtime an XMLAdapter that will override this
      functionality,
      so that String 0 or 1 can be mapped to any other textual
      representation :-/


      Y.


      On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to
transform it to, is String S or N respectively :-)


Thanks!


Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert
from string to boolean, print vice versa. And the
javaType name is java.lang.Boolean.

-W


On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
      Hello fellow listers,

      I've got the following conundrum I'd like some
      help with.

      Assume this schema (shortened for brevity)

       <xs:element name="Foo">
             <xs:complexType>
                 <xs:complexContent>
                         <xs:attribute name="bar"
      type="xs:string"/>
                 </xs:complexContent>
             </xs:complexType>
       </xs:element>

      In reality, bar is a boolean attribute (stay
      with me) which I need for business reasons to
      convert to a single character lexical
      equivalent of true/false in another language,
      for transport over a WSDL call.

      I thought that I could perhaps use a custom
      binding to do my biding and extend that for
      different use cases hence

      <bindings
      node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
                 <property>
                     <baseType>
                         <javaType
      name="java.lang.String"

       parseMethod="com.transform.PartnerTransform.parseBooleanToString"

       printMethod="com.transform.PartnerTransform.printStringToBoolean" />
                     </baseType>
                 </property>
             </bindings>

      However I quickly realised that my cunning plan
      to assign another XMLAdapter while initialising
      the marshaller for each use case was blown out
      of the water
      as the adapter is randomly named by xjc, and
      touching the generated classes is a no-no.

      Therefore, the grand question here is , is there
      some arcane way to make jaxb do that, or should
      I be looking at a different solution?

      Thanks!

      Yiannis


      ---------------------------------------------------------------------
      To unsubscribe, e-mail:
      users-unsubscribe@...
      For additional commands, e-mail:
      users-help@...



______________________________________________________________________

This email has been scanned by the MessageLabs Email
Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________

______________________________________________________________________

This email has been scanned by the MessageLabs Email Security
System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ioannis Mavroukakis]

That's correct, so since N changes, how do I know which N to set it's  
behaviour for?



On 24 Sep 2009, at 11:09, Wolfgang Laun wrote:

> Foo uses some AdapterN, where N might change, but all AdapterN  
> variants use the Transform methods parseX and printX. Since this  
> remains the same class for all variants, you can set its behaviour,  
> to do whatever is appropriate. Setting the output values identical  
> to the input values you achieve a no-op.
> -W
>
> On Thu, Sep 24, 2009 at 10:20 AM, Ioannis Mavroukakis <imavroukakis@...
> > wrote:
> Hello :-)
>
> I suppose I could but what I want to achieve is plugability as not  
> all use cases will need this transform but All of them will use Foo.  
> Hence in the packages of these use cases I want to be able to  
> redefine the adapter.. Does that make sense?
>
> On 23 Sep 2009, at 22:24, No 0ne <no0ne@...> wrote:
>
> On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
> Hi Wolfgang,
> Thanks for that, I had gotten as far as this. The reason why 0/1
> cannot be handled is that the wsdl endpoint has different definitions
> for true/false (S and N respectively. It's how it is and I cannot
> change it :-).
> My main issue is that I want to be able to supply an XmlAdaptor per
> use case, defining a different Transform class.
> Make the Transform class implement "setTrueFalseTransliteration(char
> ouiChar, char nonChar)" and adjust the true/false characters  
> accordingly
> with your use case (before serializing/deserializing your XML)?
>
> I can see how this is done on the api but as xjc is generating and
> annotating the source, I cannot see how I could overide the generated
> Adaptor at runtime. It would be nice if I could instruct xjc to
> generate an adaptor with a specific name which I could then unset and
> set with another one.
> Repeating the suggestion above at a more generalized level: why cant  
> you
> keep the name constant but change the runtime *behaviour* of your
> transformer accordingly to your needs?
>
> Y.
> no0ne
>
>
> On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:
>
>
>
> I think what you need is
>
> <jxb:bindings
> node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/
> xsd:attribute[@name='bar']">
>  <jxb:property>
>   <jxb:baseType>
>     <jxb:javaType name="java.lang.String"
>          parseMethod="com.Transform.parse01ToString"
>          printMethod="com.Transform.printStringTo01" />
>   </jxb:baseType>
>  </jxb:property>
> </jxb:bindings>
>
> which converts "0" or "1" in the XML to whatever the com.Transform
> decides:
>
> package com;
> import java.util.*;
> public class Transform {
>   private static String ouiChar;
>   private static String nonChar;
>   public static void setOuiNon( String oui, String non ){
>       ouiChar = oui;
>       nonChar = non;
>   }
>   public static String parse01ToString( String value ){
>       return value.equals( "0" ) ? nonChar : ouiChar;
>   }
>   public static String printStringTo01( String impl ){
>       return impl.equals( ouiChar ) ? "1" : "0";
>   }
> }
>
> All you have to do, is call the static method to define the "oui" or
> "non" character.
>
> Although I don't see why the application cannot handle the "0" or
> "1". Whatever.
>
> -W
>
>
>
>
>
>
> On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
> <imavroukakis@...> wrote:
>       I should also add, that on top of that, I need to be able to
>       pass at runtime an XMLAdapter that will override this
>       functionality,
>       so that String 0 or 1 can be mapped to any other textual
>       representation :-/
>
>
>       Y.
>
>
>       On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:
>
> No the XML will be a String 0 or 1, but what I want to
> transform it to, is String S or N respectively :-)
>
>
> Thanks!
>
>
> Yiannis
>
> On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:
>
> If the XML is a single letter, then parse must convert
> from string to boolean, print vice versa. And the
> javaType name is java.lang.Boolean.
>
> -W
>
>
> On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
> <imavroukakis@...> wrote:
>       Hello fellow listers,
>
>       I've got the following conundrum I'd like some
>       help with.
>
>       Assume this schema (shortened for brevity)
>
>        <xs:element name="Foo">
>              <xs:complexType>
>                  <xs:complexContent>
>                          <xs:attribute name="bar"
>       type="xs:string"/>
>                  </xs:complexContent>
>              </xs:complexType>
>        </xs:element>
>
>       In reality, bar is a boolean attribute (stay
>       with me) which I need for business reasons to
>       convert to a single character lexical
>       equivalent of true/false in another language,
>       for transport over a WSDL call.
>
>       I thought that I could perhaps use a custom
>       binding to do my biding and extend that for
>       different use cases hence
>
>       <bindings
>       node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/
> xsd:complexContent/xsd:attribute[@name='bar']">
>                  <property>
>                      <baseType>
>                          <javaType
>       name="java.lang.String"
>
>        
> parseMethod="com.transform.PartnerTransform.parseBooleanToString"
>
>        
> printMethod="com.transform.PartnerTransform.printStringToBoolean" />
>                      </baseType>
>                  </property>
>              </bindings>
>
>       However I quickly realised that my cunning plan
>       to assign another XMLAdapter while initialising
>       the marshaller for each use case was blown out
>       of the water
>       as the adapter is randomly named by xjc, and
>       touching the generated classes is a no-no.
>
>       Therefore, the grand question here is , is there
>       some arcane way to make jaxb do that, or should
>       I be looking at a different solution?
>
>       Thanks!
>
>       Yiannis
>
>
>        
> ---------------------------------------------------------------------
>       To unsubscribe, e-mail:
>       users-unsubscribe@...
>       For additional commands, e-mail:
>       users-help@...
>
>
>
> ______________________________________________________________________
>
>
> This email has been scanned by the MessageLabs Email
> Security System.
> For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
>
>
>
>
>
>
> ______________________________________________________________________
>
>
> This email has been scanned by the MessageLabs Email Security
> System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wolfgang Laun-2]

You just change com.transform.PartnerTransform, according to my (abbreviated: com.Transform) version, You DO NOT have to touch or worry about AdapterN.
-W

On Thu, Sep 24, 2009 at 12:37 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

That's correct, so since N changes, how do I know which N to set it's behaviour for?



On 24 Sep 2009, at 11:09, Wolfgang Laun wrote:

Foo uses some AdapterN, where N might change, but all AdapterN variants use the Transform methods parseX and printX. Since this remains the same class for all variants, you can set its behaviour, to do whatever is appropriate. Setting the output values identical to the input values you achieve a no-op.
-W

On Thu, Sep 24, 2009 at 10:20 AM, Ioannis Mavroukakis <imavroukakis@...> wrote:
Hello :-)

I suppose I could but what I want to achieve is plugability as not all use cases will need this transform but All of them will use Foo. Hence in the packages of these use cases I want to be able to redefine the adapter.. Does that make sense?

On 23 Sep 2009, at 22:24, No 0ne <no0ne@...> wrote:

On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
Hi Wolfgang,
Thanks for that, I had gotten as far as this. The reason why 0/1
cannot be handled is that the wsdl endpoint has different definitions
for true/false (S and N respectively. It's how it is and I cannot
change it :-).
My main issue is that I want to be able to supply an XmlAdaptor per
use case, defining a different Transform class.
Make the Transform class implement "setTrueFalseTransliteration(char
ouiChar, char nonChar)" and adjust the true/false characters accordingly
with your use case (before serializing/deserializing your XML)?

I can see how this is done on the api but as xjc is generating and
annotating the source, I cannot see how I could overide the generated
Adaptor at runtime. It would be nice if I could instruct xjc to
generate an adaptor with a specific name which I could then unset and
set with another one.
Repeating the suggestion above at a more generalized level: why cant you
keep the name constant but change the runtime *behaviour* of your
transformer accordingly to your needs?

Y.
no0ne


On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:



I think what you need is

<jxb:bindings
node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
 <jxb:property>
 <jxb:baseType>
   <jxb:javaType name="java.lang.String"
        parseMethod="com.Transform.parse01ToString"
        printMethod="com.Transform.printStringTo01" />
 </jxb:baseType>
 </jxb:property>
</jxb:bindings>

which converts "0" or "1" in the XML to whatever the com.Transform
decides:

package com;
import java.util.*;
public class Transform {
 private static String ouiChar;
 private static String nonChar;
 public static void setOuiNon( String oui, String non ){
     ouiChar = oui;
     nonChar = non;
 }
 public static String parse01ToString( String value ){
     return value.equals( "0" ) ? nonChar : ouiChar;
 }
 public static String printStringTo01( String impl ){
     return impl.equals( ouiChar ) ? "1" : "0";
 }
}

All you have to do, is call the static method to define the "oui" or
"non" character.

Although I don't see why the application cannot handle the "0" or
"1". Whatever.

-W






On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
     I should also add, that on top of that, I need to be able to
     pass at runtime an XMLAdapter that will override this
     functionality,
     so that String 0 or 1 can be mapped to any other textual
     representation :-/


     Y.


     On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to
transform it to, is String S or N respectively :-)


Thanks!


Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert
from string to boolean, print vice versa. And the
javaType name is java.lang.Boolean.

-W


On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
     Hello fellow listers,

     I've got the following conundrum I'd like some
     help with.

     Assume this schema (shortened for brevity)

      <xs:element name="Foo">
            <xs:complexType>
                <xs:complexContent>
                        <xs:attribute name="bar"
     type="xs:string"/>
                </xs:complexContent>
            </xs:complexType>
      </xs:element>

     In reality, bar is a boolean attribute (stay
     with me) which I need for business reasons to
     convert to a single character lexical
     equivalent of true/false in another language,
     for transport over a WSDL call.

     I thought that I could perhaps use a custom
     binding to do my biding and extend that for
     different use cases hence

     <bindings
     node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
                <property>
                    <baseType>
                        <javaType
     name="java.lang.String"

      parseMethod="com.transform.PartnerTransform.parseBooleanToString"

      printMethod="com.transform.PartnerTransform.printStringToBoolean" />
                    </baseType>
                </property>
            </bindings>

     However I quickly realised that my cunning plan
     to assign another XMLAdapter while initialising
     the marshaller for each use case was blown out
     of the water
     as the adapter is randomly named by xjc, and
     touching the generated classes is a no-no.

     Therefore, the grand question here is , is there
     some arcane way to make jaxb do that, or should
     I be looking at a different solution?

     Thanks!

     Yiannis


     ---------------------------------------------------------------------
     To unsubscribe, e-mail:
     users-unsubscribe@...
     For additional commands, e-mail:
     users-help@...



______________________________________________________________________


This email has been scanned by the MessageLabs Email
Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________








______________________________________________________________________


This email has been scanned by the MessageLabs Email Security
System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ioannis Mavroukakis]

Doh! <facepalm> now did I notice that the behaviour method is static..this makes sense, thanks Wolfgang.

On 24 Sep 2009, at 11:43, Wolfgang Laun wrote:

You just change com.transform.PartnerTransform, according to my (abbreviated: com.Transform) version, You DO NOT have to touch or worry about AdapterN.
-W

On Thu, Sep 24, 2009 at 12:37 PM, Ioannis Mavroukakis <imavroukakis@...> wrote:

That's correct, so since N changes, how do I know which N to set it's behaviour for?



On 24 Sep 2009, at 11:09, Wolfgang Laun wrote:

Foo uses some AdapterN, where N might change, but all AdapterN variants use the Transform methods parseX and printX. Since this remains the same class for all variants, you can set its behaviour, to do whatever is appropriate. Setting the output values identical to the input values you achieve a no-op.
-W

On Thu, Sep 24, 2009 at 10:20 AM, Ioannis Mavroukakis <imavroukakis@...> wrote:
Hello :-)

I suppose I could but what I want to achieve is plugability as not all use cases will need this transform but All of them will use Foo. Hence in the packages of these use cases I want to be able to redefine the adapter.. Does that make sense?

On 23 Sep 2009, at 22:24, No 0ne <no0ne@...> wrote:

On Wed, 2009-09-23 at 19:53 +0100, Ioannis Mavroukakis wrote:
Hi Wolfgang,
Thanks for that, I had gotten as far as this. The reason why 0/1
cannot be handled is that the wsdl endpoint has different definitions
for true/false (S and N respectively. It's how it is and I cannot
change it :-).
My main issue is that I want to be able to supply an XmlAdaptor per
use case, defining a different Transform class.
Make the Transform class implement "setTrueFalseTransliteration(char
ouiChar, char nonChar)" and adjust the true/false characters accordingly
with your use case (before serializing/deserializing your XML)?

I can see how this is done on the api but as xjc is generating and
annotating the source, I cannot see how I could overide the generated
Adaptor at runtime. It would be nice if I could instruct xjc to
generate an adaptor with a specific name which I could then unset and
set with another one.
Repeating the suggestion above at a more generalized level: why cant you
keep the name constant but change the runtime *behaviour* of your
transformer accordingly to your needs?

Y.
no0ne


On 23  2009, at 18:56, Wolfgang Laun <wolfgang.laun@...> wrote:



I think what you need is

<jxb:bindings
node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:attribute[@name='bar']">
 <jxb:property>
 <jxb:baseType>
   <jxb:javaType name="java.lang.String"
        parseMethod="com.Transform.parse01ToString"
        printMethod="com.Transform.printStringTo01" />
 </jxb:baseType>
 </jxb:property>
</jxb:bindings>

which converts "0" or "1" in the XML to whatever the com.Transform
decides:

package com;
import java.util.*;
public class Transform {
 private static String ouiChar;
 private static String nonChar;
 public static void setOuiNon( String oui, String non ){
     ouiChar = oui;
     nonChar = non;
 }
 public static String parse01ToString( String value ){
     return value.equals( "0" ) ? nonChar : ouiChar;
 }
 public static String printStringTo01( String impl ){
     return impl.equals( ouiChar ) ? "1" : "0";
 }
}

All you have to do, is call the static method to define the "oui" or
"non" character.

Although I don't see why the application cannot handle the "0" or
"1". Whatever.

-W






On Wed, Sep 23, 2009 at 6:29 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
     I should also add, that on top of that, I need to be able to
     pass at runtime an XMLAdapter that will override this
     functionality,
     so that String 0 or 1 can be mapped to any other textual
     representation :-/


     Y.


     On 23 Sep 2009, at 17:27, Ioannis Mavroukakis wrote:

No the XML will be a String 0 or 1, but what I want to
transform it to, is String S or N respectively :-)


Thanks!


Yiannis

On 23 Sep 2009, at 17:15, Wolfgang Laun wrote:

If the XML is a single letter, then parse must convert
from string to boolean, print vice versa. And the
javaType name is java.lang.Boolean.

-W


On Wed, Sep 23, 2009 at 4:51 PM, Ioannis Mavroukakis
<imavroukakis@...> wrote:
     Hello fellow listers,

     I've got the following conundrum I'd like some
     help with.

     Assume this schema (shortened for brevity)

      <xs:element name="Foo">
            <xs:complexType>
                <xs:complexContent>
                        <xs:attribute name="bar"
     type="xs:string"/>
                </xs:complexContent>
            </xs:complexType>
      </xs:element>

     In reality, bar is a boolean attribute (stay
     with me) which I need for business reasons to
     convert to a single character lexical
     equivalent of true/false in another language,
     for transport over a WSDL call.

     I thought that I could perhaps use a custom
     binding to do my biding and extend that for
     different use cases hence

     <bindings
     node="/xsd:schema/xsd:element[@name='Foo']/xsd:complexType/xsd:complexContent/xsd:attribute[@name='bar']">
                <property>
                    <baseType>
                        <javaType
     name="java.lang.String"

      parseMethod="com.transform.PartnerTransform.parseBooleanToString"

      printMethod="com.transform.PartnerTransform.printStringToBoolean" />
                    </baseType>
                </property>
            </bindings>

     However I quickly realised that my cunning plan
     to assign another XMLAdapter while initialising
     the marshaller for each use case was blown out
     of the water
     as the adapter is randomly named by xjc, and
     touching the generated classes is a no-no.

     Therefore, the grand question here is , is there
     some arcane way to make jaxb do that, or should
     I be looking at a different solution?

     Thanks!

     Yiannis


     ---------------------------------------------------------------------
     To unsubscribe, e-mail:
     users-unsubscribe@...
     For additional commands, e-mail:
     users-help@...



______________________________________________________________________


This email has been scanned by the MessageLabs Email
Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________








______________________________________________________________________


This email has been scanned by the MessageLabs Email Security
System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________