Hi all,
I've been lurking with great interest on this list and would like to
offer a slightly different view on this subject. I'm also in the
middle of rewriting two servlets that take soap documents (jaxb2
objects) and save and load a "deal" object and return it (as a jaxb2
object marshalled over the http response) to the client.
Annotations, and their use in libraries such as ejb3, are here because
we went down the following road:
1. webapps/ejb/hibernate/struts/you name it needed a heap of
configuration to go alongside the java classes
2. this configuration was in the form of xml files that were bundled
with the java classes in some sort of deployment
3. developers found having to keep the xml files and java code in sync
less than ideal, and the toolsets (ides) never really did their part
to make it any easier
4. tools like xdoclet, ejbgen, vdoclet, etc etc came along to use the
flexibility of the javadoc engine to generate the xml files based on
javadoc comments and as such keep the configuration with the source
5. jdk1.5 annotations came along to add type safety and several other
features to the functionality that was being used by javadoc engine
based generators.
Where am I going with this? Essentially I see the reason that people
don't like xml descriptors is that the configuration is separate from
the code. One courld argue that the same problem exists with a plugin
that annotates the generated jaxb classes with hibernate configuration
- the configuration is still separate from the code. The argument
against this is that the real source is the xml schema, and so it
makes sense to put the code in there. The reason I don't like this
approach is that we publish our xml schemas to external parties and
for a couple of reasons I don't want to put my o/r (and x/o, x/r)
mapping in there.
What I would like is a generator that could take existing classes as
as starting point. Eg, consider I have the schema:
<xsd:schema>
<xsd:element name="Foo">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Bar" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
then that is going to generate something like:
@XmlRootElement
class Foo
{
@XmlElement(name="Bar")
String bar;
}
what I'd like to be able to do is then edit that:
@Entity
@Table(name="foo_tbl")
@XmlRootElement
class Foo
{
@Column(name="bar_column")
@XmlElement(name="Bar")
String bar;
}
and then suppose I changed the schema:
<xsd:schema>
<xsd:element name="Foo">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Bar" type="xsd:string" />
<xsd:element name="AnotherBar" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
I'd like the generator to use the exsting source and then spit out:
@Entity
@Table(name="foo_tbl")
@XmlRootElement
class Foo
{
@Column(name="bar_column")
@XmlElement(name="Bar")
String bar;
@XmlElement(name="AnotherBar")
String anotherBar;
}
I realise that this is a very simple example and that if you changed
the schema more significantly then it wouldn't work, but I'm talking
about a production schema where changes would have to be backward
compatible anyway.
I also realise that I'm no longer talking about a generator, but
instead am talking about an xml schema/java code one way synchonizer.
The reason I think this is a better option is that it provides far
greater flexibility.
For our swing apps we use JFormDesigner which has a similar (although
more simple) approach. I think that by offering this option many
plugins could be replaced by altering the first cut of generated code.
Going back to my current task of intergrating ejb3 annotations into
jaxb classes. I've made the decision that our schema isn't going to
change so significantly that I cant make the corresponding changes to
the generated jaxb classes by hand, and I have checked in my generated
classes and annotated them by hand (mind you I'm also in a situation
where I cant change the schema, and I cant change the database, so
these annotations are starting to get quite difficult).
Anyway - some food for thought. What do others think of this approach
(ignore for now the difficulty of implementing it).
cheers
dim
On 3/17/06, Aleksei Valikov <valikov_at_gmx.net> wrote:
> Hi
>
> > I see quite a lot of interest in the EJB3 plugin, and volunteers. It
> > would be great if we can make something happen.
> >
> > One possibility is for some of the interested folks that can actually
> > spend some time on this (like Scott, Lucus, and Dennis? --- I remember
> > seeing a few more folks around this topic) to get started on this.
> >
> > They can do so in jaxb2-commons in the beginning (perhaps with the
> > eventual goal of becoming hyperjaxb3), or if you feel comfortable
> > enough, they can do so in the hyperjaxb3 project. I see that there's no
> > such project yet, so maybe they can create one?
> >
> > Then you can hang around in the list and give your feedback.
> >
> > I have a feeling that once this work gets started, we'll see more
> > interest in it.
>
> For those interested, I've created a new hyperjaxb3 project:
>
> https://hyperjaxb3.dev.java.net/
>
> Bye.
> /lexi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>