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?
> 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
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com