Hi Andrea,
I read through the logs and let me just say thank you, This is the first time someone has given me any critical feedback of this kind. Which is scary since what I set up is pretty primitive. So let me try to address some of your questions as I read them in the log.
I agree that the spring system set up currently will not acheive the component / service management we all want. The reason being that I dont see this is a realistic goal in the short term. There are many issues with GeoServer / Geotools that need to be addressed before we can make it to that point. Which I think are totally independent of which plugin system / platform / application framework we choose.
I think you know geotools well enough to know that there are so many backwards dependencies among the main modules that the codebase would not behave well broken up into components. Also there is no way to inject custom components into the code base. As an example Just remember the hoops that Jesse had to go through in order to supply a custom GeometryFactory which he could use to create Geometries optimized for rendering, which I am not sure he was ever actually able to do or not.
And in GeoServer, it doesnt really get any better. The application is very tied to the Servlet API and HTTP. One thing people ask about is the ability to do web services instaed of http, etc... GeoServer doesn';t really integrate all that well with the other J2EE technologies.
So, sorry for the rant. The point of all this is that I see a rewrite / rearchitecture of key parts of the codebases as more important that a dynamic component system. The ability to wire things together with spring contexts at build time is better then what was there before. So right now it is just assumed that all the contexts are around at runtime, and wont be changing.
However I see lots of support in the api for being able to acheive much of what you need to build services. Spring is a pretty darn good container implementation offering dependency management,lifecycle support, resource management, etc.... The spring ApplicationContext interface has many implemetnations that offer refreshable / dynamic context loading, acceess to context events, etc...
I think the problem that you are haveing is just with my half-ass effort of trying to port geoserver over to it. Basically I had to try and do it without actually changeing the code base in order to keep things stable. Most of my knowledge is in still in the research stage as I havent had much of a chance to use it to do the geoserver rearchitecture I have been speaking of. To be honest with you if given free reign I would have gutted the codebase and used OSGi as the plugin framework :). Speaking of which, I think that using OSGi as the component framework much better suits some of our longer term goals.
So once again, I apologize for the rant, I hope I was able to answer some of your questions / concerns. Following a chat between three people in irc logs is harder then some people might think :). If not I would more then happily be available to chat on IRC or skype or something over the weekend and continue discussion.
-Justin
Andrea Aime - casa wrote:
Hi Justin,
I'm wondering if you had time to read the short Spring chat we had yesterday, published
somewhere on the geoserver wiki (sorry, I can't connect to it now, it should be in "geostuff"
anyway if I understood properly what Jody told me).
Can you provide some feedback on it? I really need a few use cases for the module/plugin
system so that I know what is our target.
Cheers
Andrea
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com