Julio.A.Mistral_at_wellsfargo.com wrote:
> Hi -
>
> Unfortunately, I can't sign the SCA because of restrictions here at
> Wells Fargo :(
OK. Well, that's very unfortunate.
> To answer your question, I need to move classes around after they were
> created using _class because in my case I really can't use bindings.
> You see, because of regulations in the bank, we're required to put EVERY
> SOAP method in its own namespace with it's own XSD file (we have over
> 40+ XSD files). So, it's really unfeasible to create a bindings file
> with over 40+ global bindings to place the domain objects and messages
> in the proper package structure, but it's easy to do programmatically in
> a custom pluggin.
I see. I wonder if you can programatically create binding files, or
programatically add binding declarations to a parsed XSOM tree. That
might be just as easily doable, especially with SCD support.
> Speaking of bindings file, I've been trying to use SCD and <xjc:simple
> /> to eliminate all occurrences of JAXBElement in the generated classes
> with no luck. Here's my binding:
>
> <jxb:bindings version="2.0"
> xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
>
> xmlns:cvcommon="http://service.wellsfargo.com/provider/cashVault/profile
> /common"
> jxb:extensionBindingPrefixes="xjc">
>
> <jxb:bindings scd="/*::cvcommon:*">
> <jxb:globalBindings>
> <xjc:simple />
> </jxb:globalBindings>
> </jxb:bindings>
>
> </jxb:bindings>
>
> But when I generate the classes, I still get JAXBElement everywhere.
> Any suggestions?
Sine you are using 2.1, you can just write:
<jxb:bindings version="2.0" ...>
<jxb:globalBindings>
<xjc:simple>
</jxb:globalBindings>
</jxb:bindings>
to get the simple binding to work.
If you don't see any change in the code generation behavior after this
switch, it sounds like somehow the customization is not taking effect.
And if so, that's a bug.
Also note that the simple binding mode does not always completely
eliminate JAXBElements. So perhaps you are just seeing a reduced number
of them.
>
>
> Julio A. Mistral
> Cash Vault Systems
> 415.243.6087
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based on
> this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
> -----Original Message-----
> From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
> Sent: Tuesday, December 19, 2006 03:18 PM
> To: dev_at_jaxb2-commons.dev.java.net
> Subject: Re: Re-Post: Finer grained controll over the code model.
>
> Julio.A.Mistral_at_wellsfargo.com wrote:
>> Hi,
>>
>> I'm new to XJC plugin development and so I'm unsure about what I've
> been
>> doing is the correct way to go. Basically, I've been adding the
>> following methods to sun.codemodel classes to have finer control over
>> the generated classes:
>>
>> JPackage
>> 1. public void add( JDefinedClass class ): Adds the provided class
> to
>> the package
>
> You are supposed to create JDefinedClass by calling JPackage._class.
>
> Why do you want to move it around after it's created?
>
>> 3. public JMethod removeMethod(String name, JType[] params): Removes
>> the method from the classes method list and returns a reference of the
>> removed method, or null if the method doesn't exist.
>
> This I think we can add. Would you be interested in signing SCA and
> sending us the patch?
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com