directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: Why I think Spring + xbean is wrong ...
Date Sat, 08 Mar 2008 01:28:39 GMT
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.

- Ole

View raw message