[Geoserver-devel] Rethinking the role of the web-app module

Andrea_Aime4 · November 9, 2011, 6:20pm

Hi,
I'd like to propose a little modifications to the web-app module
that should help when building a customized version of GeoServer.

The current web-app module, as I see it, has the following issues:
- for some reason during the deploy of releases the jar ends up
  containing other jars. E.g. see
  http://repo.opengeo.org/org/geoserver/web/web-app/2.1.2/web-app-2.1.2.jar
  This is actually the .war file with a different name.
  This makes it hard to make a custom build on top of a release, which is
  annoying since most people interested in custom build do want to
  base it on a release.
- the web-app contains some crucial classes (filters), so it's needed,
  but at the same time make choices about the dependencies that
  might be unsuitable for custom builds. E.g., in some custom build
  we might decide that we only need wms and wfs, and only support
  for vector data, plus some assorted extras
  I know, one could use maven exclusion mechanism, but it's imho
  cleaner to add what is needed instead of listing what to remove
  (might be a matter of preference)

What I would like is not having to depend on web-app to start with.
A custom build often has to roll its own web.xml anyways, so I believe
the best way forward would just to move the classes implementing
the filters back in main and have web-app be just the wiring that
builds a .war, and nothing else.
Given that all the pieces in GeoServer are made to build a web app
moving back the filters in main should not cause any trouble (besides
being trivial).

Opinions?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Gabriel_Roldan2 · November 9, 2011, 7:00pm

A big +1.

On a related note, one thing I found difficult when in need to build
an alternate web app for GeoNode was that secureCatalog, as defined in
main's applicationContext.xml, depends on accessRulesDao, defined in
applicationSecurityContext.xml, so it was not easy to depend on an
alternate security configuration.
I don't know much about spring, but it would be great if that
dependency could be inverted. Maybe just by defining secureCatalog in
applicationSecurityContext.xml? so that if anyone needs to do
something different it can treat security as a cross cutting concern
instead of a hard dependency of main?

2c./
Gabriel

On Wed, Nov 9, 2011 at 3:20 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
I'd like to propose a little modifications to the web-app module
that should help when building a customized version of GeoServer.

The current web-app module, as I see it, has the following issues:
- for some reason during the deploy of releases the jar ends up
containing other jars. E.g. see
http://repo.opengeo.org/org/geoserver/web/web-app/2.1.2/web-app-2.1.2.jar
This is actually the .war file with a different name.
This makes it hard to make a custom build on top of a release, which is
annoying since most people interested in custom build do want to
base it on a release.
- the web-app contains some crucial classes (filters), so it's needed,
but at the same time make choices about the dependencies that
might be unsuitable for custom builds. E.g., in some custom build
we might decide that we only need wms and wfs, and only support
for vector data, plus some assorted extras
I know, one could use maven exclusion mechanism, but it's imho
cleaner to add what is needed instead of listing what to remove
(might be a matter of preference)

What I would like is not having to depend on web-app to start with.
A custom build often has to roll its own web.xml anyways, so I believe
the best way forward would just to move the classes implementing
the filters back in main and have web-app be just the wiring that
builds a .war, and nothing else.
Given that all the pieces in GeoServer are made to build a web app
moving back the filters in main should not cause any trouble (besides
being trivial).

Opinions?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · November 9, 2011, 7:29pm

Works for me. If its just the filter classes then I think main is appropriate… if other stuff like the schema files, etc… need to be moved out then perhaps a new module is more appropriate… web-app-base or something.

On Wed, Nov 9, 2011 at 11:20 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’d like to propose a little modifications to the web-app module
that should help when building a customized version of GeoServer.

The current web-app module, as I see it, has the following issues:

for some reason during the deploy of releases the jar ends up
containing other jars. E.g. see
http://repo.opengeo.org/org/geoserver/web/web-app/2.1.2/web-app-2.1.2.jar
This is actually the .war file with a different name.
This makes it hard to make a custom build on top of a release, which is
annoying since most people interested in custom build do want to
base it on a release.

the web-app contains some crucial classes (filters), so it’s needed,
but at the same time make choices about the dependencies that
might be unsuitable for custom builds. E.g., in some custom build
we might decide that we only need wms and wfs, and only support
for vector data, plus some assorted extras
I know, one could use maven exclusion mechanism, but it’s imho
cleaner to add what is needed instead of listing what to remove
(might be a matter of preference)

What I would like is not having to depend on web-app to start with.
A custom build often has to roll its own web.xml anyways, so I believe
the best way forward would just to move the classes implementing
the filters back in main and have web-app be just the wiring that
builds a .war, and nothing else.
Given that all the pieces in GeoServer are made to build a web app
moving back the filters in main should not cause any trouble (besides
being trivial).

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

David_Winslow · November 9, 2011, 7:31pm

related but not relevant: i spent a little time some weeks ago playing with moving the dependency information for community modules back into the poms (instead of whitelisting the dependencies again in release/ext-*.xml). I only did it for the CSS module but the approach is all in the POM and could easily (straightforward, but not automatic) be applied to the other community modules and the supported extensions.

https://github.com/dwins/geoserver/compare/master…assembly

The upshot is that “mvn package” in any community module (set up this way) would produce the zip archive with only runtime dependencies, not provided ones (and we’d just mark core geoserver modules as ‘provided’). cd community && mvn package -PcommunityRelease aggregates those zip files in a single handy directory too. mvn package -Pcss,printing would do the same for just css and printing (for example.)

Eventually I think “going with the flow” of maven a bit more could assist in making the web module more flexible but I haven’t looked at what that would imply.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Nov 9, 2011 at 2:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

A big +1.

On a related note, one thing I found difficult when in need to build
an alternate web app for GeoNode was that secureCatalog, as defined in
main’s applicationContext.xml, depends on accessRulesDao, defined in
applicationSecurityContext.xml, so it was not easy to depend on an
alternate security configuration.
I don’t know much about spring, but it would be great if that
dependency could be inverted. Maybe just by defining secureCatalog in
applicationSecurityContext.xml? so that if anyone needs to do
something different it can treat security as a cross cutting concern
instead of a hard dependency of main?

2c./
Gabriel

On Wed, Nov 9, 2011 at 3:20 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
I’d like to propose a little modifications to the web-app module
that should help when building a customized version of GeoServer.

The current web-app module, as I see it, has the following issues:

for some reason during the deploy of releases the jar ends up
containing other jars. E.g. see
http://repo.opengeo.org/org/geoserver/web/web-app/2.1.2/web-app-2.1.2.jar
This is actually the .war file with a different name.
This makes it hard to make a custom build on top of a release, which is
annoying since most people interested in custom build do want to
base it on a release.

the web-app contains some crucial classes (filters), so it’s needed,
but at the same time make choices about the dependencies that
might be unsuitable for custom builds. E.g., in some custom build
we might decide that we only need wms and wfs, and only support
for vector data, plus some assorted extras
I know, one could use maven exclusion mechanism, but it’s imho
cleaner to add what is needed instead of listing what to remove
(might be a matter of preference)

What I would like is not having to depend on web-app to start with.
A custom build often has to roll its own web.xml anyways, so I believe
the best way forward would just to move the classes implementing
the filters back in main and have web-app be just the wiring that
builds a .war, and nothing else.
Given that all the pieces in GeoServer are made to build a web app
moving back the filters in main should not cause any trouble (besides
being trivial).

Opinions?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Andrea_Aime4 · November 9, 2011, 7:36pm

On Wed, Nov 9, 2011 at 8:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

A big +1.

Nice thanks.

On a related note, one thing I found difficult when in need to build
an alternate web app for GeoNode was that secureCatalog, as defined in
main's applicationContext.xml, depends on accessRulesDao, defined in
applicationSecurityContext.xml, so it was not easy to depend on an
alternate security configuration.
I don't know much about spring, but it would be great if that
dependency could be inverted. Maybe just by defining secureCatalog in
applicationSecurityContext.xml? so that if anyone needs to do
something different it can treat security as a cross cutting concern
instead of a hard dependency of main?

We could move that bean into applicationSecurityContext.xml, but
you'll still have to declare it somewhere otherwise you'll get no
security at all (actually, worse, you won't get any catalog at all, since
that's the top-most wrapper).

Another observation, how do you override the applicationSecurityContext.xml
built into main?
Redefining all the beans in another context file lets you be pray of the
iteration order i the classpath, sometimes the new context file will win,
other times not, depending on the container, filesystem and java version

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Gabriel_Roldan2 · November 9, 2011, 7:51pm

On Wed, Nov 9, 2011 at 4:36 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Wed, Nov 9, 2011 at 8:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

A big +1.

Nice thanks.

On a related note, one thing I found difficult when in need to build
an alternate web app for GeoNode was that secureCatalog, as defined in
main's applicationContext.xml, depends on accessRulesDao, defined in
applicationSecurityContext.xml, so it was not easy to depend on an
alternate security configuration.
I don't know much about spring, but it would be great if that
dependency could be inverted. Maybe just by defining secureCatalog in
applicationSecurityContext.xml? so that if anyone needs to do
something different it can treat security as a cross cutting concern
instead of a hard dependency of main?

We could move that bean into applicationSecurityContext.xml, but
you'll still have to declare it somewhere otherwise you'll get no
security at all (actually, worse, you won't get any catalog at all, since
that's the top-most wrapper).

yeah, of course. The thing is to just have the option.

Another observation, how do you override the applicationSecurityContext.xml
built into main?
Redefining all the beans in another context file lets you be pray of the
iteration order i the classpath, sometimes the new context file will win,
other times not, depending on the container, filesystem and java version

in web.xml:
<param-value>classpath*:/applicationContext.xml
classpath*:/geonodeApplicationSecurityContext.xml</param-value>

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · November 10, 2011, 10:34am

On Wed, Nov 9, 2011 at 8:29 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Works for me. If its just the filter classes then I think main is
appropriate… if other stuff like the schema files, etc… need to be moved
out then perhaps a new module is more appropriate… web-app-base or
something.

You are bringing up an interesting point about the schemas.
The src/main/webapp looks as follows:

Afaik there is no reason for any of these to stay in web-app, we could keep
any one of them in the classpath and publish them from the classpath
via a FilePublisher/Wicket resource like mechanism (a new ClasspathPublisher)?

If we go down that path we could have:

wms host the openlayers stuff, the wms schemas, the sld schemas
wfs host the wfs schemas
wcs host the wcs schemas
wps same
main host xlink, ows, filter, gml and validate, as well as the j_spring* files

This would leave in web-app just the web.xml and the empty
dispatcher-servlet.xml files

How does this sound?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Andrea_Aime4 · November 10, 2011, 2:04pm

On Thu, Nov 10, 2011 at 11:34 AM, Andrea Aime <andrea.aime@anonymised.com…1268…> wrote:

Afaik there is no reason for any of these to stay in web-app, we could keep
any one of them in the classpath and publish them from the classpath
via a FilePublisher/Wicket resource like mechanism (a new ClasspathPublisher)?

Hey, I have this approach a shot, seems to work like a charm.
I won’t give you a patch, moving all the schema files is making for a very large changeset,
but have a look at the work in progress on java files and app context files in the
attached one.

What do you think? Seems rather straightforward to me, and increases the server modularity
quite a bit, giving also modules the ability to publish whatever on the webapp right out
of the classpath (say, for example, that you need a specific javascript library, more schemas
or something like that)

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

(attachments)

classpathPublished.patch (14.1 KB)

Justin_Deoliveira · November 10, 2011, 3:21pm

On Thu, Nov 10, 2011 at 3:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Nov 9, 2011 at 8:29 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Works for me. If its just the filter classes then I think main is
appropriate… if other stuff like the schema files, etc… need to be moved
out then perhaps a new module is more appropriate… web-app-base or
something.

You are bringing up an interesting point about the schemas.
The src/main/webapp looks as follows:

Afaik there is no reason for any of these to stay in web-app, we could keep
any one of them in the classpath and publish them from the classpath
via a FilePublisher/Wicket resource like mechanism (a new ClasspathPublisher)?

If we go down that path we could have:

wms host the openlayers stuff, the wms schemas, the sld schemas

wfs host the wfs schemas

wcs host the wcs schemas

wps same

main host xlink, ows, filter, gml and validate, as well as the j_spring* files

This would leave in web-app just the web.xml and the empty
dispatcher-servlet.xml files

How does this sound?

Very nice! I like it

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · November 10, 2011, 3:30pm

On Thu, Nov 10, 2011 at 7:04 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Nov 10, 2011 at 11:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Afaik there is no reason for any of these to stay in web-app, we could keep
any one of them in the classpath and publish them from the classpath
via a FilePublisher/Wicket resource like mechanism (a new ClasspathPublisher)?

Hey, I have this approach a shot, seems to work like a charm.
I won’t give you a patch, moving all the schema files is making for a very large changeset,
but have a look at the work in progress on java files and app context files in the
attached one.

What do you think? Seems rather straightforward to me, and increases the server modularity
quite a bit, giving also modules the ability to publish whatever on the webapp right out
of the classpath (say, for example, that you need a specific javascript library, more schemas
or something like that)

Sounds good to me. Looked over the patch… i think it might not include all changes? For instance AbstractURLPublisher… i can’t find that class anywhere but it seems the patch contains modifications to it… or am I crazy?

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Gabriel_Roldan2 · November 10, 2011, 4:44pm

Hey Andrea,

as Justin mentioned it looks like you missed at least one commit on
the diff, I guess that could be just because the previous commit
contained all the file moves, so no worries. That said, the purpose
and working is pretty clear and it looks like a great way of
approaching the issue to me.

Have my +1.

Cheers,
Gabriel.

Andrea_Aime4 · November 10, 2011, 8:04pm

On Thu, Nov 10, 2011 at 4:30 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:

What do you think? Seems rather straightforward to me, and increases the server modularity
quite a bit, giving also modules the ability to publish whatever on the webapp right out
of the classpath (say, for example, that you need a specific javascript library, more schemas
or something like that)

Sounds good to me. Looked over the patch… i think it might not include all changes? For instance AbstractURLPublisher… i can’t find that class anywhere but it seems the patch contains modifications to it… or am I crazy?

Doh sorry, rediffed. I still omitted all the schema movements around, just
the code and app context changes

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

(attachments)

classpath.patch (17.1 KB)

Mark_Leslie2 · November 10, 2011, 11:04pm

On 11 November 2011 07:04, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Nov 10, 2011 at 4:30 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

What do you think? Seems rather straightforward to me, and increases the
server modularity
quite a bit, giving also modules the ability to publish whatever on the
webapp right out
of the classpath (say, for example, that you need a specific javascript
library, more schemas
or something like that)

Sounds good to me. Looked over the patch... i think it might not include
all changes? For instance AbstractURLPublisher... i can't find that class
anywhere but it seems the patch contains modifications to it... or am I
crazy?

Doh sorry, rediffed. I still omitted all the schema movements around, just
the code and app context changes
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I think this is a great idea and will make a huge difference for
custom packaging. We haven't come up against this too often, but it's
a maintenance nightmare every time.

If you're collecting +1's, you can have mine.

--
Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com