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.
Hope that helps.
Cheers,
- Ole
