directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [Configuration] More on EMF Resource Loading
Date Fri, 07 Mar 2008 15:40:00 GMT
> The good thing with xbean (yes, there are some pros, even if I think 
> cons are prevailing) is that it generates a XSD, which is the reference 
> we never had before.

Yeah it's pretty slick.

>> The spring namespace can be jettisoned, etc...Anyways, before I do 
>> more work I'll describes the steps for loading server.xml:
>>    /**
>>     * Test ApacheDS Configuration Loading
>>     */
>>    public void testLoadServerXML()
>>    {
>>         File serverDotXML = new File("src/main/resources/server.xml");
>>        ResourceSet resourceSet = new ResourceSetImpl();
>> resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put
>>         (_1Package.eNS_PREFIX,          new _1ResourceFactoryImpl());
>>               resourceSet.getPackageRegistry().put
>>         (_1Package.eNS_URI,          _1Package.eINSTANCE);
>>              Resource serverXMLResource =            resourceSet.
>>            createResource(
>>                    URI.
>>                    createFileURI(serverDotXML.getAbsolutePath()));
>>              //Get the root configuration object
>>        //Get a contained object using a fragment
>>        //etc.
>>    }
>> Once the serverXMLResource is loaded, the instances of the server 
>> configuration objects can be gotten from it using like this:
>> serverXMLResource.getObject("nameOfConfigurationObject");
>> Does this look appealing so far? 
> Well, basically, this is something like that we want to have, yes. I 
> don't like the syntax (to much _1, 

Yes - I left the _1 in there to keep the tutorial trace as simple as possible.  This _1 corresponds
to the namespace prefix of the model's namespace.  Since the schema currently has multiple
namespaces, and EMF needed to assign one to the ecore model, it chose _1.  However, fixing
this is as simple as opening up the .ecore model and changing the namespace prefix in the
properties editor.  I would choose something like adsConfig.  This would now be used instead
of the _1.  So instead of _1Package, it would be AdsConfigPackage.

to much work to be done before being 
> able to do the getObject...), but I'm pretty sure we can keep it more 
> simple.
> For instance, those lines :
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put
>        (_1Package.eNS_PREFIX,          new _1ResourceFactoryImpl());
>             resourceSet.getPackageRegistry().put
>        (_1Package.eNS_URI,          _1Package.eINSTANCE);
> seems to be totally superfluous, 

You are right.  After generation these can be put in a utility library and you could call
something like ConfigurationUtil.load() to load  to get the root configuration object.

> as the mapping between 
> _1Package.eNS_PREFIX and _1ResourceFactoryImpl seems to be mandatory, 
> and could have been injected into the ResourceSetImpl() constructor. 
> They don't need to be explicit

Sure - For our purposes that's it.  If for some reason you wanted to load other files as well,
they would have to follow a similar registration approach....

>> I need to make 1 correction about my earlier assessment.  I said we 
>> could just create an instance of the ADS configuration like this:
>> ADSConfiguraiton adsConfiguraiton = new ADSConfiguration();
>> and the server could run using just the defaults contained / generated 
>> into each configuration class.  That would be true if all the 
>> configuration were contained in single instance, but obviosly we'd 
>> want a graph.  So if the graph were built up manually, the same would 
>> be true...Anyways the configuration graph would have to be built 
>> manually or by the EMF Resource Loading mechanism.
> Yes, this is a graph, and a complex one. If we can't get it built 
> directly by EMF, using the XSD, then i would say that it's not what we 
> will use.

Well we are using EMF to generate the beans corresponding to the ComplexType definitions in
the XSD.  Then when loading server.xml EMF does the parsing and creates instances of these
beans and binds the server.xml element attributes to the corresponding bean values.  So in
other words it does what Spring does, but now the Beans are just pure configuration beans.
 Their only purpose is to provide configuration data contained in server.xml.

So if you load server.xml using EMF then you have the Graph.  So EMF does build the graph.

Sometimes during testing of an individual component though, we don't need the whole graph.
 We just need the default values in, for example, AuthenticatorType.  So when testing that
component we just create an instance of AuthenticatorType like this:

AuthenticatorType authenticatorType = _1Factory.eINSTANCE.createAuthenticatorType();

Side note: Remember that if we change the _1 prefix on the ecore model to adsconfig the above
would be AdsConfigFactory.eINSTANCE instead....

If the default values for authenticator type's properties were set in the XSD (XML Schema)
then those have been generated onto the AuthenticatorTypeImpl and are returned when calling
get...().  So this saves time in the sense that Mock objects don't have to be created.  You
can use the real server configuration object and it's corresponding defaults values generated
from the XSD.

> Things are never simple ... :)

Still not too far off right? :-)

So, to summarize, when doing component development we could place server.xml in src/main/resources
and load it using 

Resource resource = ADSMavenConfigurationUtilities.load();

which would return the resource containing server.xml.  Then to get a particular configuration
object you could do 
AuthenticatorType authenticatorType = resource.getObject("/server/authenticatorType");

Note that I just made up the URI fragment "/server/authenticatorType", but you get idea.

So now the big question is, does everyone like developing like this?  Since the configuration
data is now separate from classes that provide services, those classes have to get the configuration
data the same way we retrieved it above.  I personally prefer this, but I'm sure there are
others that like the Spring based approach.  Something to mull over.

- Ole

View raw message