Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.
It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.
Cheers
Andrea Aime
On Mon, 2006-05-08 at 10:35 +0200, Andrea Aime wrote:
Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.
Hi Andrea,
Great stuff, it complements what Justin was saying a while ago about
Spring. This going-from-application-to-component stuff is very
interesting and judging from the perks of Spring that you list, I would
have liked to have had it available a couple of months ago when I did
the Web Processing Service implementation =) Justin hinted at the time
that the geospatial processes that the WPS serves could be implemented
as Spring beans, which was probably a very good idea. However, as a
fairly inexperienced Java developer with a deadline to meet, I found
that Spring demanded me to learn a bit too many new concepts than I had
the time to do. But the Spring perks look great. Anyway, I'm following
this discussion with interest!
By the way, are Spring plans going on in parallel with the FROGS
framework cooperation or has it become part of it?
Regards,
Jonas Johansson
Cheers
Andrea Aime-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Andrea Aime wrote:
Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.
Thanks for the clear writing Andrea. 
It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.
Module breakdown (Sorry for the extra detail, for discussion only):
- Main - check
- Configuration - check
- Security-basic - check
- WFS - check
- WMS - check
- WMS-xxx-handler: maybe "handler" should be format? Other options for plugability...
-- explicitly extend by request type (version negotiation) - isolate WMS_1_0, WMS_1_1 and so on....
-- format types, extend for GIF, JPEG, SVG etc... (aka your example)
-- protocol (is this already covered by Main - SOAP, OWS, etc...)
- Webapp: this would be the program that would bind everything together? Aka a geoserver based application (like the WCS prototype) would make a new one of these?
If possible I would like to keep the idea of "data" module, and as with GeoServer 1.3.x to handle connections to data stores etc...you could call this catalog (but that would get confusin), resources may may be better then "data"...
For the web interaction pages, I always thought each module should provide its own configuration ui, and the bean for the module should indicate the url on which that service is available... Could easily reproduce the current conventions of wfs/config, wms/config, data/config
Jody
Jonas Johansson wrote:
By the way, are Spring plans going on in parallel with the FROGS
framework cooperation or has it become part of it?
Chris Holmes has performed an introduction, but we have yet to have formal contact with the Frogs project
at a Geoserver IRC meeting (or a FROGS meeting for that matter).
Jody
Jody Garnett ha scritto:
Andrea Aime wrote:
Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.Thanks for the clear writing Andrea.
It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.Module breakdown (Sorry for the extra detail, for discussion only):
- Main - check
- Configuration - check
- Security-basic - check
- WFS - check
- WMS - check
- WMS-xxx-handler: maybe "handler" should be format? Other options for plugability...
-- explicitly extend by request type (version negotiation) - isolate WMS_1_0, WMS_1_1 and so on....
-- format types, extend for GIF, JPEG, SVG etc... (aka your example)
-- protocol (is this already covered by Main - SOAP, OWS, etc...)
- Webapp: this would be the program that would bind everything together?
Yes, the binding really just means searching in all the jars for the
spring.xml files and build a context out of them (and this is done by
a 3 lines declaration inside the web.xml file).
Aka a geoserver based application (like the WCS prototype) would make a new one of these?
A Geoserver based application could decide to write a new one of these, yes.
Yet, for a WCS prototype, why not just add a new module, which should contain
also its web user interface, and plug it with the rest?
Do you see now why I was asking about putting web pages in the classpath?
If we can do that, all you really need to do to build your customized geoserver
is to put the jars inside an empty web application.
If possible I would like to keep the idea of "data" module, and as with GeoServer 1.3.x to handle connections to data stores etc...you could call this catalog (but that would get confusin), resources may may be better then "data"...
Hmm... I thought this stuff was handled by the configuration objects.
Can you point me to the classes that would make up this "data" module?
For the web interaction pages, I always thought each module should provide its own configuration ui, and the bean for the module should indicate the url on which that service is available... Could easily reproduce the current conventions of wfs/config, wms/config, data/config
Yes, that was more or less the idea. The only problem is that if the ui
is made of jsp pages we would need to have the modules structures as follows:
module
-- src
-- webapp
----WEB-INF
------module-xxx-struts-config.xml
----page1.jsp
----page2.jsp
And then have some build time routine that takes the "webapp" of each
module and merges them. What I don't like about this approach is that
it makes testing difficult, because you have a build in the middle, you
can't just run some executable from inside your IDE (for a normal
web application we can run Jetty from inside the IDE, but for a modularized
one made with struts, we first need to merge the various modules contributions).
Of couse, with a different framework we won't need to (for example, using Wicket
you don't need to, web pages just stay in the classpath, and you can even
declare pages entry points inside a Spring configuration file because the latest
Wicket has native Spring integration).
Yet, I understand I can't ask people to go thru such a change (architecture and
web framework at the same time).
Cheers
Andrea
Andrea Aime wrote:
Jody Garnett ha scritto:
Andrea Aime wrote:
Hi,
I've just written a document that explains how we could use Spring
and what advantages we would get by using it, along with a modules proposal
on http://docs.codehaus.org/display/GEOSDEV/Spring+proposal.Thanks for the clear writing Andrea.
It would be very nice if people could read, evaluate, discuss, fix, comment it,
even on here on the mailing list.Module breakdown (Sorry for the extra detail, for discussion only):
- Main - check
- Configuration - check
- Security-basic - check
- WFS - check
- WMS - check
- WMS-xxx-handler: maybe "handler" should be format? Other options for plugability...
-- explicitly extend by request type (version negotiation) - isolate WMS_1_0, WMS_1_1 and so on....
-- format types, extend for GIF, JPEG, SVG etc... (aka your example)
-- protocol (is this already covered by Main - SOAP, OWS, etc...)
- Webapp: this would be the program that would bind everything together?Yes, the binding really just means searching in all the jars for the
spring.xml files and build a context out of them (and this is done by
a 3 lines declaration inside the web.xml file).
How does this look exacltly. When the original spring build was set up I only found the facility to load context files matching a particular wildcard. Which was a pain because two modules could not have a context with the same name.
Aka a geoserver based application (like the WCS prototype) would make a new one of these?
A Geoserver based application could decide to write a new one of these, yes.
Yet, for a WCS prototype, why not just add a new module, which should contain
also its web user interface, and plug it with the rest?Do you see now why I was asking about putting web pages in the classpath?
If we can do that, all you really need to do to build your customized geoserver
is to put the jars inside an empty web application.If possible I would like to keep the idea of "data" module, and as with GeoServer 1.3.x to handle connections to data stores etc...you could call this catalog (but that would get confusin), resources may may be better then "data"...
Hmm... I thought this stuff was handled by the configuration objects.
Can you point me to the classes that would make up this "data" module?For the web interaction pages, I always thought each module should provide its own configuration ui, and the bean for the module should indicate the url on which that service is available... Could easily reproduce the current conventions of wfs/config, wms/config, data/config
Yes, that was more or less the idea. The only problem is that if the ui
is made of jsp pages we would need to have the modules structures as follows:module
-- src
-- webapp
----WEB-INF
------module-xxx-struts-config.xml
----page1.jsp
----page2.jspAnd then have some build time routine that takes the "webapp" of each
module and merges them. What I don't like about this approach is that
it makes testing difficult, because you have a build in the middle, you
can't just run some executable from inside your IDE (for a normal
web application we can run Jetty from inside the IDE, but for a modularized
one made with struts, we first need to merge the various modules contributions).
Of couse, with a different framework we won't need to (for example, using Wicket
you don't need to, web pages just stay in the classpath, and you can even
declare pages entry points inside a Spring configuration file because the latest
Wicket has native Spring integration).
Yet, I understand I can't ask people to go thru such a change (architecture and
web framework at the same time).Cheers
Andrea-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
