directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Configuration] More on EMF Resource Loading
Date Fri, 07 Mar 2008 10:10:43 GMT
Ole Ersoy wrote:
> Hey Guys,
> I'm trying to load server.xml right now.  It's not loading.  I'm sure 
> it's something trivial.  I've done this a gazillion times, but have 
> been thinking in Javascript and Web Design for the last 3 months, so I 
> need to brush off some rust.  Also, if I do figure it out, and we 
> decide to use EMF, is the server.xml structure going to change?  
Not so much. We have tried to stabilize it since we are targeting 2.0.

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.
> 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, to much work to be done before being 
able to do the getObject...), but I'm pretty sure we can keep it more 

For instance, those lines :

ResourceSet resourceSet = new ResourceSetImpl();
        (_1Package.eNS_PREFIX,          new _1ResourceFactoryImpl());
        (_1Package.eNS_URI,          _1Package.eINSTANCE);

seems to be totally superfluous, 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
> 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.

Things are never simple ... :)

cordialement, regards,
Emmanuel L├ęcharny

View raw message