JAXB 3 with property change support in setter methods

Question

In the past there existed the property-listener-injector plugin for the org.jvnet.jaxb2maven plugin. One can still find the plugin in maven central repo : org.jvnet.jaxb2-commons:property-listener-injector:1.0 and with google search many forum posts that relate to this.

Now Rick O'Sullivan did a great job and adapted the jaxb-maven.plugin to jakarta namespace and jaxb 3/jaxb 4. I found his answer to a related question here: https://stackoverflow.com/a/74909223/14565514 Many thanks for that - I tried out and it's working very good. Although I am asking I you see a possibility to merge it back to the original repo instead of maintaining a fork?

But the real question is that I am missing the property-listener-injector plugin. To Rick O'Sullivans defense it is also not existend anymore on Alexey Valikov (aka Highsource) repo - at least I couldn find it in the list of JAXB2 basic plugins here : https://github.com/highsource/jaxb-tools#jaxb2-basics

Is there a possibility to get jakarta namespace and property change support in setter methods with JAXB 3 (or 4) and maven? Do I have overseen something?

I tried the approach mentioned a long time ago here https://www.java-forum.org/thema/propertychangelistener-generieren-mit-jaxb-xjc.124023/ This is from 2011 and understandable not compatible with jaxb 3 or jakarta namespace.

Many other similar forum/blog posts can be found with google search but all are rather out dated.

Any help or hint is appreciated! - Thanks in advance

Answer 1

A new PropertyListenerPlugin has been added to HiSrc BasicJAXB. It will be included in the next release (no ETA).

Answer 2

I already said in the comment: I will give it definitely a try. Since comments are restricted in amount of characters I'll answere here to the answer of Rick.

I found a solution by extending the generated classes and overwrite the setters as suggested here: Jaxb 2 user guide See section about adding behaviours.

This is JAXB 2 but the approach is somewhat general. The only "problem" is then when the unmarshaller reads in an XML document it will, per default, generate a model consisting only of the generated and not the extended classes. This can be corrected by defining the ObjectFactory and then pass the ObjectFactoryExtended.

 unmarshaller.setProperty("org.glassfish.jaxb.core.ObjectFactory", //$NON-NLS-1$
                new ObjectFactoryEx());

The concrete property String depends on which JAXB implementation is used.

That introduces another layer into my project but for now that is ok. If your plugin is released then I will give it a try and try to remove this additional layer if possible.

Out of curiosity - I have a question though: I saw that the original org.jvnet jaxb maven plugins have a lot of forks. I assume due to the lack of JAXB 3/4 support. Wouldn't it be "better" instead of doeing a fork to support the original repo and go for a merge request there? What are youre reasons for a fork instead of doeing the work in the original repo?