Hi Jerome,
[Attempting to cc the users_at_jaxb.dev.java.net list...]
On Jan 3, 2007, at 9:24 PM, Jerome Dochez wrote:
> yes I have written such a XJC plugin, it's part of the glassfish v3
> code so far but I think it would make sense to make it more public.
>
I assume you're referring to this:
http://fisheye5.cenqua.com/browse/glassfish/admin-core/xjc-plugin/src/
com/sun/tools/xjc/addon/property_listener_injector/PluginImpl.java?
r=GF_V3_PREWORK_BRANCH
Looks great; do you think it would be much work to make a more
standalone version? It seems there are some dependencies on other
APIs, so I'm just wondering how small it could be made.
> There are a few more bugs/issues to work around, I need to work
> with Koshuke but this would be doable pretty soon. when do you need
> it ?
>
For the purposes of my prototype, I'd like to use it ASAP. Without
property change support in the JAX-WS generated beans, I have to
resort to copying those beans to/from special ones that *do* have
property change support, which is ugly.
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)?
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.
>>
>>
>