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 drastically.
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.
Cheers,
- Ole
