Could be interesting to check out: http://www.springframework.org/node/562
Looks like we picked well to go with Spring, and now that choices doesn't preclude OSGi http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
One of these days we should get around to naming it GeoServer 2.0
If anyone investigates let the list know what you find.
Chris
Spent a bit of time looking into this experimenting a bit, since I have
always been interested in osgi (and turning GeoSever into an actual
framework :)).
Pros:
* Equinox server side implementation seems to be mature now, when I
looked into this last the project was just being started, what this mean
s is that theoretically we can embed an osgi runtime in any servlet
container. In practice... not sure if issues would arise.
* the spring / osgi model follows more or less the same model that we
have adopted with spring. Modularizing bean definitions in separate
application definitions, and using an "extension point" model of
programming.
Cons:
* It still requires some major refactoring in GeoServer. While in the
last major rearchitecture we split things up and made the code modular
breaking out nicely defined modules, module != compontent. There are
still dependencies and assumptions that would not fly in an osgi
environment.
For instance there is code in geoserver that pretty much assumes that
wfs and wms are always around, and they feed off of each other, well at
least wms feeds off of wfs. Which kinds of defeats the whole purpose of
osgi, the ability to dynamically load and unload services or components
at runtime.
I still dont see this coming anytime soon for the following reasons:
* the only win is a truly dynamic module/component system, which i dont
really see anyone having a business case for
* it would require us to actually turn geoserver into a framework for
people to develop applications with, again unlikely as our development
is typically 100% "user feature" based
* if there is anything i have learned about architecture changes, is
that they involve a time period of "moving backward" for a significant
time period, dealing with regressions, etc...
* there are bigger fish to fry, namely config + ui. Although perhaps if
we do them right they could be done in a way that would lend themselves
to an osgi environment
Anyways, just thought I would share my findings. Pretty cool stuff at a
technical level... hopefully some day we will get to use it :). Although
I think it will be called GeoServer 3.0 
-Justin
Chris Holmes wrote:
Could be interesting to check out: http://www.springframework.org/node/562
Looks like we picked well to go with Spring, and now that choices
doesn't preclude OSGi
http://docs.codehaus.org/display/GEOS/GeoServer+2.0+TechnologyOne of these days we should get around to naming it GeoServer 2.0
If anyone investigates let the list know what you find.
Chris
!DSPAM:4007,4753399323591628642973!
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4!DSPAM:4007,4753399323591628642973!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,4753399323591628642973!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Cool, thanks for the evaluation Justin.
I think your conclusions are right on. I do think it'd be good to maybe map out the service dependencies, like the wms and wfs depending on one another, and in the config/ui rewrite maybe try to prepare things better for some osgi thing in the future, where module does equal componenet.
Chris
Justin Deoliveira wrote:
Spent a bit of time looking into this experimenting a bit, since I have
always been interested in osgi (and turning GeoSever into an actual
framework :)).Pros:
* Equinox server side implementation seems to be mature now, when I
looked into this last the project was just being started, what this mean
s is that theoretically we can embed an osgi runtime in any servlet
container. In practice... not sure if issues would arise.* the spring / osgi model follows more or less the same model that we
have adopted with spring. Modularizing bean definitions in separate
application definitions, and using an "extension point" model of
programming.Cons:
* It still requires some major refactoring in GeoServer. While in the
last major rearchitecture we split things up and made the code modular
breaking out nicely defined modules, module != compontent. There are
still dependencies and assumptions that would not fly in an osgi
environment.For instance there is code in geoserver that pretty much assumes that
wfs and wms are always around, and they feed off of each other, well at
least wms feeds off of wfs. Which kinds of defeats the whole purpose of
osgi, the ability to dynamically load and unload services or components
at runtime.I still dont see this coming anytime soon for the following reasons:
* the only win is a truly dynamic module/component system, which i dont
really see anyone having a business case for
* it would require us to actually turn geoserver into a framework for
people to develop applications with, again unlikely as our development
is typically 100% "user feature" based
* if there is anything i have learned about architecture changes, is
that they involve a time period of "moving backward" for a significant
time period, dealing with regressions, etc...
* there are bigger fish to fry, namely config + ui. Although perhaps if
we do them right they could be done in a way that would lend themselves
to an osgi environmentAnyways, just thought I would share my findings. Pretty cool stuff at a
technical level... hopefully some day we will get to use it :). Although
I think it will be called GeoServer 3.0-Justin
Chris Holmes wrote:
Could be interesting to check out: http://www.springframework.org/node/562
Looks like we picked well to go with Spring, and now that choices
doesn't preclude OSGi
http://docs.codehaus.org/display/GEOS/GeoServer+2.0+TechnologyOne of these days we should get around to naming it GeoServer 2.0
If anyone investigates let the list know what you find.
Chris
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4!DSPAM:4007,4753399323591628642973!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,4753399323591628642973!