directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [Configuration] Suppose EMF is Used...
Date Fri, 07 Mar 2008 19:20:54 GMT
Alex Karasulu wrote:
> This is acceptable as long as we can separate it as another way to wire 
> the server together.  It cannot impose specifics on the components 
> themselves.  This way there is no direct dependence on the wiring 
> technology be it Spring, EMF or OSGi.

I think the OSGi part would work out well, since it works well for all the eclipse plugins
that use EMF, but as far as I can tell, it's an either Spring or EMF / JAXP approach.  

Suppose I'm a component that needs configuration.  Before Spring would just inject me and
I'm good to go.  With EMF creating all the configuration beans, I now somehow have to get
access to the bean representing the root element in server.xml, and then I can go from there
navigating the configuration graph DOM style or using URI fragments.

So I would expect there to be a central server component (Maybe even the component with main()
), that first loads the server configuration and then stores a reference to it in a server
Context object, similar to a servlet context.  Then as the server continues to create core
components (So now the central server component is creating them rather than Spring), it passes
the context to each one, and the components service themselves from there.

So I think if OSGi were used it's role would be to manage this sequence.  Maybe spring could
do it.  I need to get a lot better at it before I can provide an answer.  Anyone know?  If
it could then we have the best of both worlds.  Actually now that I'm thinking about it, what
is required is for Spring to have some sort of post constructor routine.  If it has that then
this could be called to load the server.xml using EMF.  It could then inject a reference to
the bean corresponding to the root element in server.xml, giving all the other components
configuration data access.

There is still an important difference though.  The components have to lookup the configuration
data they need themselves.  Spring is no longer injecting references and primitive properties.

To me it looks like a fairly significant cost factor and a big bang in and of itself, which
has to be weighed against the issues Emmanuel is experiencing.  

I'll just try to "Imagineer" / do a thought experiment on what is happening with Emmanuel's
development effort.  He wants to test out a component.  It has a bunch of references and primitives
being injected by Spring.  So the only way to test is to use Spring to initialize the component.
 The components that are references to this component, also go through a similar process.
 So if there is a little hickup somewhere, it causes Emmanuel to have to spend a lot of time
hunting through all the Spring wiring to try to figure out what the issue is, just to do a
little testing.

So if I understand correctly, that's the heart of the issue.  As the spring configuration
/ wiring grows it just gets more and more hairy to do simply component development, partly
do to the xml markup Spring uses.

So the way an EMF type approach solves this is that there is only a single object that has
configuration information.  That means that when testing component A, as far as configuration
goes it only needs to work with that one object.  If I'm right, with Spring, the configuration
that that one component needs, is injected into a bunch of other components.  So all of a
sudden the amount of collaboration needed for the development of one component just went up

Anyways If I'm right about this, then I think seriously considering an EMF type of approach
is worth it.  I think it will save the project from getting "Heavier and Heavier" as it approaches
the speed of light...type thing.  I'm hoping it's easy to blow holes in the arguments though,
because it will be a fairly large refactoring effort.

- Ole

View raw message