Chris Campbell escreveu:
> Thanks, Kohsuke and Jerome. I asked the following on Kohsuke's blog,
> but probably would be better to move the discussion here.
>
> 1) I just tried it with the xjc that comes with JDK 6, and the option
> wasn't recognized (says "unrecognized parameter -Xinject-listener-
> code"):
> % xjc -classpath property-listener-injector-1.0.jar -Xinject-listener-
> code catalog.xsd
Hi Chris,
These are the parameters I pass to xjc:
"-nv" "-p" "com.softing.etl.beans" "-d" "./src"
"./xmlschemas/loaderJob.xsd" "-Xinject-listener-code"
Never tried JAXB on JDK 6.0 but I think you've put a space after the dash:
-Xinject-listener- code
>
> However, the plugin works fine if I run it using the xjc that comes
> with JAXB 2.1 RI. So is this plugin dependent on JAXB 2.1? Is there
> a reason why it wouldn't work with the JAXB 2.0 that comes with JDK 6?
>
> 2) (From Mikael Grev...) The property name fired has the first
> character upper case (should be lowercase).
I can't help with this decision but IMHO it could be lowercase.
>
> 3) Why does it only generate "constrained" properties?
> http://java.sun.com/docs/books/tutorial/javabeans/properties/
> constrained.html
I think it's because the plugin is in "beta" stage
>
> These are arguably more complex than the usual "bound" properties:
> http://java.sun.com/docs/books/tutorial/javabeans/properties/bound.html
I agree
>
> Even the way the plugin generates "constrained" properties is not
> quite right, as Mikael pointed out already on Kohsuke's blog. For
> true "constrained" support, it would need to follow the steps listed
> on that tutorial page.
Yes You're right for "true" vetoable support the exception must be
thrown ... no catch statetement at all
>
> Personally, I would prefer that the plugin generate only "bound"
> properties by default. For example:
>
> @XmlTransient
> private final PropertyChangeSupport pcs = new
> PropertyChangeSupport(this);
>
> public String getTitle() {
> return this.title;
> }
>
> public void setTitle(String title) {
> String old = this.title;
> this.title = title;
> this.pcs.firePropertyChange("title", old, title);
> }
>
> Then if the user really wants "constrained" support (usually in
> addition to, but I suppose could be in place of) "bound" support,
> they could specify another argument to get that behavior. For example:
> % xjc -Xinject-bound-properties ...
> % xjc -Xinject-bound-properties -Xinject-constrained-properties ...
> % xjc -Xinject-constrained-properties ...
>
> Jerome or Marcos, any opinions?
I think would be nice if the plugin could get this kind of configuration
(bound or vetoable property option) from some "customization"
(internal/external)
associated with the .xsd file.
I'm just not sure at this moment if this is really possible
> Would either of you be willing to take this on?
Yes I would like to write this part of this plugin because the
application that I'm actually writing
depends on this "conditional" behavior (bound or vetoable decision)
>
> Thanks,
> Chris
Regards
Marcos
>
>
> On Jan 11, 2007, at 7:03 PM, Kohsuke Kawaguchi wrote:
>
>> I moved the plugin from Glassfish workspace to jaxb2-commons.
>>
>> See https://jaxb2-commons.dev.java.net/property-listener-injector/
>>
>> This is mostly the same code that Jerome had.
>>
>> Marcos, it looks like you found a bug in it. If you are interested
>> in looking at the code, I'd be happy to make you a committer.
>> Otherwise, if you can send me a test case, I'd be happy to take a look.
>>
>>
>> Kohsuke Kawaguchi wrote:
>>
>>> Marcos wrote:
>>>
>>>> Hi all,
>>>> I'm trying to write a plugin based on the one developed by Mr.
>>>> Jerome Dochez, found at.:
>>>> http://fisheye5.cenqua.com/browse/glassfish/admin-core/xjc-plugin/
>>>> src/com/sun/tools/xjc/addon/property_listener_injector/
>>>> PluginImpl.java?r1=1.1&r2=1.1.2.1
>>>
>>> We are just talking about moving this to jaxb2-commons.
>>>
>>>> JAXB's binding compiler generate setter methods for all elements
>>>> found in the .xsd file
>>>> but I would like to replace some parts to suit my needs .... as
>>>> follows.:
>>>> Before.: (Without the plugin)
>>>> /**
>>>> * Sets the value of the returnCode property.
>>>> *
>>>> * @param value
>>>> * allowed object is
>>>> * {_at_link String }
>>>> * */
>>>> public void setReturnCode(String value) {
>>>> this.returnCode = value;
>>>> }
>>>> After.: (Using the plugin)
>>>> /* PropertyChangeSupport inserted by my own plugin.*/
>>>> private PropertyChangeSupport changes = new
>>>> PropertyChangeSupport(this);
>>>> /**
>>>> * Sets the value of the returnCode property.
>>>> *
>>>> * @param value
>>>> * allowed object is
>>>> * {_at_link String }
>>>> * */
>>>> public void setReturnCode(String value) {
>>>> String oldReturnCode = this.returnCode; // This must be
>>>> inserted by my plugin
>>>> this.returnCode = value; // I'm
>>>> not sure if I can invoke the default implementation of JAXB to
>>>> retrieve this line of code ...
>>>> changes.firePropertyChange ("returnCode", oldReturnCode,
>>>> returnCode); // This must be inserted by my plugin
>>>> }
>>>> I know that each plugin has 02 interesting hook methods.:
>>>> onActivated (Options opt)
>>>> run (Outline model, Options opt, ErrorHandler)
>>>> How can I use these methods and JAXB RI API to inject the piece of
>>>> code that I need ?
>>>
>>> It really depends on what kind of code you want to inject. Why
>>> don't you start by looking at Jerome's code and modify it to fit
>>> your needs?
>>
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>