directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Why I think Spring + xbean is wrong ...
Date Sat, 08 Mar 2008 07:49:59 GMT

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
>
>
>
>
>
>


Mime
View raw message