Kohsuke Kawaguchi escreveu:
> Chris Campbell wrote:
>
>> A couple questions... I found this forum posting (and corresponding
>> bug report) that suggests that XJC plugins can't currently be used
>> by wsimport, which is what I really need:
>> http://forums.java.net/jive/thread.jspa?
>> forumID=46&threadID=14686&messageID=103878
>> https://jax-ws.dev.java.net/issues/show_bug.cgi?id=11
>>
>> Is this still true today? Is there any workaround (like putting the
>> plugin jar on the classpath of the wsimport ant task)?
>
>
> We could fix that. Do we have an issue number for that?
I'm anxiously waiting this improvement ;-), because I have a bunch of
classes that need bound properties ;-(
I'm not really a specialist but I can help if necessary ....
Regards
Marcos
>
>> Also, from what I've seen of your nifty plugin, in order to force
>> the injection one must do the following:
>> - have the plugin jar on the classpath
>> - pass -Xinject-listener-code to xjc
>>
>> Does the schema also need to list "http://jaxb.dev.java.net/plugin/
>> listener-injector" as an extension namespace, or can that be skipped
>> for this particular plugin? I'm hoping for the latter, because
>> otherwise that would be yet another thing that wsimport would need
>> to know how to do.
>>
>> Thanks,
>> Chris
>>
>>> jerome
>>> Kohsuke Kawaguchi wrote:
>>>
>>>> Chris Campbell wrote:
>>>>
>>>>> Hi Kohsuke,
>>>>>
>>>> [snip]
>>>>
>>>>> As much as possible we'd like to leverage existing standards/
>>>>> projects such as JAX-WS (and JAXB), JPA, etc, but often we find
>>>>> that things get hairy at the boundaries between these APIs.
>>>>>
>>>>> For example, suppose we want to use JPA (on the server tier) to
>>>>> load a bunch of customer records from our database (as POJOs),
>>>>> then we have use JAX-WS to setup a @WebMethod like this:
>>>>> @WebMethod
>>>>> public List<Customer> getAllCustomers() {...}
>>>>>
>>>>> Now on the client side, we have our JAX-WS client code that calls
>>>>> into that web service endpoint, and JAX-WS unmarshals the List of
>>>>> Customer objects on the client side. So far so good. But in an
>>>>> ideal Swing application, to use those Customer objects as the
>>>>> model (in an MVC sense) would require treating them as full-
>>>>> fledged Java Beans, with property change support and all.
>>>>
>>>>
>>>> Right.
>>>>
>>>>
>>>>> Today JAX-WS/JAXB (wsimport/xjc) will generate the following, e.g.:
>>>>> private String name;
>>>>> public String getName() { return name; }
>>>>> public void setName(String name) { this.name = name; }
>>>>>
>>>>> To use these as proper beans in our Swing client, ideally we'd
>>>>> like full property change support in the generated classes, e.g.:
>>>>> private PropertyChangeSupport pcs;
>>>>> private String name;
>>>>> public String getName() { return name; }
>>>>> public void setName(String name) {
>>>>> String old = this.name;
>>>>> this.name = name;
>>>>> pcs.firePropertyChange("name", old, name);
>>>>> }
>>>>> public void addPropertyChangeListener(...) {...}
>>>>> public void removePropertyChangeListener(...) {...}
>>>>>
>>>>> So clearly today JAX-WS/JAXB does not give us what we want, but
>>>>> the question is: is there some way to add this behavior by
>>>>> default to a future version of JAX-WS/JAXB? Or better yet, is
>>>>> there a way we can accomplish this now by providing some sort of
>>>>> private extension (that could be used by NetBeans, for example)?
>>>>
>>>>
>>>> Yes. The JAXB RI has a extension mechanism where user-written
>>>> plugins could change the code generation behavior, so that people
>>>> can do kind of stuff that you are just describing.
>>>>
>>>> I cc-ed this e-mail to Jerome, who I believe is developing (or has
>>>> developed) a plugin that does something like this. Today it's a
>>>> part of Glassfish build, but we've been talking about moving it
>>>> into its own project.
>>>>
>>>> I'm not completely up to the status of the project, but I think
>>>> it's something you might be interested. If we can join the effort
>>>> it would be even better.
>>>>
>>>>> I have a few other questions in this area, but I'll save them for
>>>>> another day :)
>>>>
>>>>
>>>> If we can move this discussion to users_at_jaxb.dev.java.net, that
>>>> would be really great. I'd like these discussions to be archived
>>>> for other users, because they often have similar questions.
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>
>