On Mar 7, 2008, at 5:28 PM, Ole Ersoy wrote:
Just some comments on the EMF part inline:
Then there are lots of ways of mixing these up. I don't think
there's any right answer. I do think (1) tends to be simpler code
but harder configuration. IMO Spring is definitely oriented
towards supporting (1). With the xbean-spring generated schema we
could easily do a version of (2) where we generate data objects
from the schema using jaxb and add a lifecycle "start" method to
create the component. This could eliminate spring entirely. Then
we could tweak the schema to make it easier to configure stuff if
we wanted. I haven't grasped the EMF approach well enough to see
exactly where it fits into this spectrum of choices.
Man - after having read this I thought "Cool - He totally gets the
EMF approach". It's very similar, if not exactly what you just
said. I'll just do a few lines summarizing the tutorial trace I
sent out:
- Grab the xbean xsd schema.
- Generate the model classes (Interfaces and Implementations) from it.
- Load server.xml binding the instances of the configuration
classes to server.xml elements
This is probably the same thing we would be doing with JAXB, except
maybe for the implementation of the Data Object Model. With EMF we
generated classes that match the complex types defined in the xbean
schema. When EMF loads server.xml it creates instances of these
classes using a generated factory. We then get instances of these
classes from the resource used to load them and use these instances
per their generated interfaces. So for example:
AuthenticatorType authenticatorType = resource.getObject("server/
authenticatorType");
Now you can access the properties of the authenticatorType per the
interface that was generated for it (Just getters and setters for
the properties on the AuthenticatorType).
Just a little more elaboration....AuthenticatorType is a
ComplexType definition in the xbean schema. EMF generated the
corresponding class implementation and interface for it,
AuthenticatorType (Interface) and AuthenticatorTypeImpl
(implementation).
So when EMF is reading server.xml, it says "Ahh - there's an
element in here that corresponds to AuthenticatorType. Lets create
an instance of AuthenticatorType and bind it to the corresponding
server.xml element, resulting in the data in that element being
made available on the AuthenticatorType instance", and then it
continues building the graph that way.
So the difference between EMF and say just loading server.xml using
DOM4J is that we get to retrieve instances of objects that have a
defined type. If we were to load it using DOM4J, we would have to
navigate the configuration model more "reflectively", using the
DOM4J API. I think JAXB and DOM4J are similar, but I used DOM4J
since I'm more familiar with it.
You should look at jaxb :-) The guys who are working on the eclipse
plugin for editing geronimo plans are abandoning EMF in favor of
jaxb. The simplest use of jaxb is to generate java objects from a
schema, but then you can change these generated java objects quite a
lot and still have the automatic 2 way mapping between xml and pojos
still work. DOM4j is more like using a SAX parser :-)
thanks
david jencks
Hope that helps.
Cheers,
- Ole
