[Geoserver-users] Some considerations on WEB-UI modularization

Alessio_Fabiani · August 9, 2006, 8:30am

Hi guys,
in my sparetime I have done some researches and some experimentations on the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a certain module directly inside the module JAR. That means that a module, like WCS, WPS, WCaS, ecc…, should be plugged into GeoServer by simply adding the JAR to the classpath, and automatically deployed wihtout touching anything of the GeoServer core.

My first try was to maintain the actual architecture as much as possible for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which overrides the standard Struts ActionServlet, and allows a user to automatically load moultiple struts-config files in a way like this:

action org.vfny.geoserver.config.MultipleActionServlet config /WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts-config.xml debug 2 detail 2 2

in such a way you can easily define the form beans, actions and everything inside a separated module.jar:WEB-INF/struts-config.xml. The configuration is automatically joined to the main struts-config. This is actually working very well in the 1.4.x WCS branch.
The problem is for the JSP pages … at this time I’m not able yet to let the Web Container capable of getting the JSP pages directly from the module jar file. I don’t know if this is possible … however exactly the same approach I used whith Struts can be used with other Frameworks supported by Spring like JSF, Wicket (as suggested by Andrea), Tapestry and so on. The advantage of using other frameworks instead of Struts is that they can provide a different way to render the web pages (expecially for Wicket).

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

Gabriel_Roldan2 · August 9, 2006, 1:53pm

Seriously, I would love to spend some time researching the possibility of
using JMX to manage geoserver and abstract out the ui from the configuration
services. I guess there are some stuff out there to expose MBeans as
webservices or such. I know the idea still seems vague, but wouldn't it be
great having configuration services and a number of configuration clients?
(uDig, <web frameworks stack>, etc)

Before deciding on a new config strategy I guess this would worth a bit of
research/prototyping.

Gabriel.

On Wednesday 09 August 2006 10:30, Alessio Fabiani wrote:

Hi guys,
in my sparetime I have done some researches and some experimentations on
the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a certain
module directly inside the module JAR. That means that a module, like WCS,
WPS, WCaS, ecc..., should be plugged into GeoServer by simply adding the
JAR to the classpath, and automatically deployed wihtout touching anything
of the GeoServer core.

My first try was to maintain the actual architecture as much as possible
for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which
overrides the standard Struts ActionServlet, and allows a user to
automatically load moultiple struts-config files in a way like this:

   
   <servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.vfny.geoserver.config.MultipleActionServlet
</servlet-class>
    <init-param>
      <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts-
config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>debug</param-name>
      <param-value>2</param-value>
    </init-param>
    <init-param>
      <param-name>detail</param-name>
      <param-value>2</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
  </servlet>

in such a way you can easily define the form beans, actions and everything
inside a separated module.jar:WEB-INF/struts-config.xml. The configuration
is automatically joined to the main struts-config. This is actually working
very well in the 1.4.x WCS branch.
The problem is for the JSP pages ... at this time I'm not able yet to let
the Web Container capable of getting the JSP pages directly from the module
jar file. I don't know if this is possible ... however exactly the same
approach I used whith Struts can be used with other Frameworks supported by
Spring like JSF, Wicket (as suggested by Andrea), Tapestry and so on. The
advantage of using other frameworks instead of Struts is that they can
provide a different way to render the web pages (expecially for Wicket).

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

Andrea_Aime4 · August 9, 2006, 1:24pm

Gabriel Roldán ha scritto:

Seriously, I would love to spend some time researching the possibility of using JMX to manage geoserver and abstract out the ui from the configuration services. I guess there are some stuff out there to expose MBeans as webservices or such. I know the idea still seems vague, but wouldn't it be great having configuration services and a number of configuration clients? (uDig, <web frameworks stack>, etc)

Heh... Spring is able to provide JMX access for every bean configured
in the spring context, but storing the modifications to them is another story.

I still have to see a solution to this, does anyone know of a generic solution
that allows to persist the changes and not only to to allow for runtime
inspection and volatile change.

See also this thread:
http://forum.springframework.org/archive/index.php/t-22474.html

Apparently JMX persistance is "optional" and everybody does its own.
On this jboss forum it is told that jboss has partial support for it, but it seems
to be something "custom", not portable:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954979

See also this Sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=5108724

Cheers
Andrea Aime

Corey_Puffalt · August 9, 2006, 2:50pm

I agree. While I like the idea of a web interface to configure GeoServer I’d like it to be less tightly coupled. I’d rather see the configuration exposed as either JMX beans or a simple REST-type interface with a separate configuration client rather than tightly coupling a particular web configuration interface. This would make it easy to automate configuration.

Corey

On 8/9/06, Gabriel Roldán <groldan@anonymised.com> wrote:

Seriously, I would love to spend some time researching the possibility of
using JMX to manage geoserver and abstract out the ui from the configuration
services. I guess there are some stuff out there to expose MBeans as
webservices or such. I know the idea still seems vague, but wouldn’t it be
great having configuration services and a number of configuration clients?
(uDig, , etc)

Before deciding on a new config strategy I guess this would worth a bit of
research/prototyping.

Gabriel.

Chris_Holmes1 · August 9, 2006, 4:14pm

Yeah, I think most everyone agrees with this thought. Have a core config that's really easy to develop against, so that it becomes easy to swap in and out configuration clients. Note that the current set up is actually highly decoupled, to the point of going a bit too far. But I think we've learned lessons on how to keep it decoupled and make it easier to maintain.

I'd also posit that we should redo the config before we do the web admin tool. I think/hope that getting the config in order will make it easier for us to build out the web admin tool.

Chris

Corey Puffalt wrote:

I agree. While I like the idea of a web interface to configure GeoServer I'd like it to be less tightly coupled. I'd rather see the configuration exposed as either JMX beans or a simple REST-type interface with a separate configuration client rather than tightly coupling a particular web configuration interface. This would make it easy to automate configuration..

Corey

On 8/9/06, *Gabriel Roldán* <groldan@anonymised.com <mailto:groldan@anonymised.com>> wrote:

    Seriously, I would love to spend some time researching the
    possibility of
    using JMX to manage geoserver and abstract out the ui from the
    configuration
    services. I guess there are some stuff out there to expose MBeans as
    webservices or such. I know the idea still seems vague, but wouldn't
    it be
    great having configuration services and a number of configuration
    clients?
    (uDig, <web frameworks stack>, etc)

    Before deciding on a new config strategy I guess this would worth a
    bit of
    research/prototyping.

    Gabriel.

!DSPAM:1003,44d9f6d164449771116852!

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

-------------------------------------------------------------------------
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

!DSPAM:1003,44d9f6d164449771116852!

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

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

!DSPAM:1003,44d9f6d164449771116852!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Andrea_Aime4 · August 9, 2006, 4:21pm

Chris Holmes ha scritto:

Yeah, I think most everyone agrees with this thought. Have a core config that's really easy to develop against, so that it becomes easy to swap in and out configuration clients. Note that the current set up is actually highly decoupled, to the point of going a bit too far. But I think we've learned lessons on how to keep it decoupled and make it easier to maintain.

I'd also posit that we should redo the config before we do the web admin tool. I think/hope that getting the config in order will make it easier for us to build out the web admin tool.

Hum, I see problems here in the possible release date.
Forces:
* can we release 1.4.0 without modularizing the UI? Does it make sense?
* gt2 2.3.x wants to do a release soon, but it should be tested
at least with geoserver and udig
* geoserver won't really test the new features in 2.3.x until the wcs
branch hits the trunk and everybody starts fiddling with it
* wcs branch won't be merged onto trunk until 1.4.0 is out (or not?)

So it seems delaying 1.4.0 release will delay gt2 2.3.0 which in turn
would delay even more the feature model branch merge... oh my...
that's why I was concentrating on giving a modular face to our
current configuration system

A configuration system overhaul would take quite a bit of time, there's not
even a design around, and it would delay even more all the rest.
I'm concerned

Cheers
Andrea Aime

Chris_Holmes1 · August 9, 2006, 4:54pm

Andrea Aime wrote:

Chris Holmes ha scritto:

Yeah, I think most everyone agrees with this thought. Have a core config that's really easy to develop against, so that it becomes easy to swap in and out configuration clients. Note that the current set up is actually highly decoupled, to the point of going a bit too far. But I think we've learned lessons on how to keep it decoupled and make it easier to maintain.

I'd also posit that we should redo the config before we do the web admin tool. I think/hope that getting the config in order will make it easier for us to build out the web admin tool.

Hum, I see problems here in the possible release date.
Forces:
* can we release 1.4.0 without modularizing the UI? Does it make sense?

I think it's fine. We're evolving towards completely modular, and 1.4.0 is a step in that direction.

* gt2 2.3.x wants to do a release soon, but it should be tested
at least with geoserver and udig
* geoserver won't really test the new features in 2.3.x until the wcs
branch hits the trunk and everybody starts fiddling with it

I think a WCS release off of branch should get some good testing. People are already fiddling with it, and that will increase with a release.

* wcs branch won't be merged onto trunk until 1.4.0 is out (or not?)

This is true. I think we can even do a 1.5.0 release without a fully modular architecture - wcs stuff will just become a part of core. I see this as going faster, since it's already mostly done.

So it seems delaying 1.4.0 release will delay gt2 2.3.0 which in turn
would delay even more the feature model branch merge... oh my...
that's why I was concentrating on giving a modular face to our
current configuration system

A configuration system overhaul would take quite a bit of time, there's not
even a design around, and it would delay even more all the rest.
I'm concerned

So the fundamental difference I see is that I think it's ok to release 1.4.0 and even 1.5.0 without a modular UI. If some volunteer steps up to rewrite the web admin with wicket or some such I'd be happy with that, it could even go fast since you could use the existing html pages that are generated from the jsps, and just stick on the right bindings.

best regards,

Chris

Cheers
Andrea Aime

!DSPAM:1003,44da0bdc74711429667743!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Andrea_Aime4 · August 9, 2006, 7:01pm

Chris Holmes ha scritto:

A configuration system overhaul would take quite a bit of time, there's not
even a design around, and it would delay even more all the rest.
I'm concerned

So the fundamental difference I see is that I think it's ok to release 1.4.0 and even 1.5.0 without a modular UI. If some volunteer steps up to rewrite the web admin with wicket or some such I'd be happy with that, it could even go fast since you could use the existing html pages that are generated from the jsps, and just stick on the right bindings.

Hmm... during my first days or vacation (starting August 21) I was already planning on doing a proof of
concept modular UI against wicket and facelets (p.o.c. means just a demo to check it
it's really possible to get that "drop me a jar" kind of pluggability on the UI or not).

In any case, you're right that switching should be quick enough given that the functionality
and html are already there, we just need to change the framework.

Cheers
Andrea

Justin_Deoliveira · August 9, 2006, 11:48pm

Very cool,

This would be a major step in the right direction for the current
geoserver ui. The JSP thing is a bummer for sure. It wouldn't be hard to
write a little class that on server startup copied all jsp resources on
the classpath into the WEB-INF directory. What do people think?

-Justin

Alessio Fabiani wrote:

Hi guys,
in my sparetime I have done some researches and some experimentations on
the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a
certain module directly inside the module JAR. That means that a module,
like WCS, WPS, WCaS, ecc..., should be plugged into GeoServer by simply
adding the JAR to the classpath, and automatically deployed wihtout
touching anything of the GeoServer core.

My first try was to maintain the actual architecture as much as possible
for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which
overrides the standard Struts ActionServlet, and allows a user to
automatically load moultiple struts-config files in a way like this:

   
   <servlet>
    <servlet-name>action</servlet-name>

<servlet-class>org.vfny.geoserver.config.MultipleActionServlet</servlet-class>
    <init-param>
      <param-name>config</param-name>

<param-value>/WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>debug</param-name>
      <param-value>2</param-value>
    </init-param>
    <init-param>
      <param-name>detail</param-name>
      <param-value>2</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
  </servlet>

in such a way you can easily define the form beans, actions and
everything inside a separated module.jar:WEB-INF/struts-config.xml. The
configuration is automatically joined to the main struts-config. This is
actually working very well in the 1.4.x WCS branch.
The problem is for the JSP pages ... at this time I'm not able yet to
let the Web Container capable of getting the JSP pages directly from the
module jar file. I don't know if this is possible ... however exactly
the same approach I used whith Struts can be used with other Frameworks
supported by Spring like JSF, Wicket (as suggested by Andrea), Tapestry
and so on. The advantage of using other frameworks instead of Struts is
that they can provide a different way to render the web pages
(expecially for Wicket).

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

---------------------------------------------------------
!DSPAM:1004,44d99dcf40422095110867!

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

-------------------------------------------------------------------------
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

!DSPAM:1004,44d99dcf40422095110867!

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

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

!DSPAM:1004,44d99dcf40422095110867!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Chris_Holmes1 · August 10, 2006, 12:59am

Justin Deoliveira wrote:

Very cool,

This would be a major step in the right direction for the current
geoserver ui. The JSP thing is a bummer for sure. It wouldn't be hard to
write a little class that on server startup copied all jsp resources on
the classpath into the WEB-INF directory. What do people think?

Well, I think that's what the JSPCompiler does, but it starts when you first go to the localhost:8080/geoserver, instead of when the server starts. I wouldn't want the compilation to hold up the start of the server, but if we stuck it in a low priority thread that could work. Could also do that when we start the welcome page.

I think with wicket or tapestry, however, we won't need to use jsps. I could be wrong, but I think they let you code much more straight html.

Chris

-Justin

Alessio Fabiani wrote:

Hi guys,
in my sparetime I have done some researches and some experimentations on
the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a
certain module directly inside the module JAR. That means that a module,
like WCS, WPS, WCaS, ecc..., should be plugged into GeoServer by simply
adding the JAR to the classpath, and automatically deployed wihtout
touching anything of the GeoServer core.

My first try was to maintain the actual architecture as much as possible
for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which
overrides the standard Struts ActionServlet, and allows a user to
automatically load moultiple struts-config files in a way like this:

   
   <servlet>
    <servlet-name>action</servlet-name>
   <servlet-class>org.vfny.geoserver.config.MultipleActionServlet</servlet-class>
    <init-param>
      <param-name>config</param-name>
     <param-value>/WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <init-param>
      <param-name>debug</param-name>
      <param-value>2</param-value>
    </init-param>
    <init-param>
      <param-name>detail</param-name>
      <param-value>2</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
  </servlet>

in such a way you can easily define the form beans, actions and
everything inside a separated module.jar:WEB-INF/struts-config.xml. The
configuration is automatically joined to the main struts-config. This is
actually working very well in the 1.4.x WCS branch.
The problem is for the JSP pages ... at this time I'm not able yet to
let the Web Container capable of getting the JSP pages directly from the
module jar file. I don't know if this is possible ... however exactly
the same approach I used whith Struts can be used with other Frameworks
supported by Spring like JSF, Wicket (as suggested by Andrea), Tapestry
and so on. The advantage of using other frameworks instead of Struts is
that they can provide a different way to render the web pages
(expecially for Wicket).

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

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

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

-------------------------------------------------------------------------
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

!DSPAM:1004,44d99dcf40422095110867!

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

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

!DSPAM:1004,44d99dcf40422095110867!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · August 10, 2006, 1:07am

This wouldn't be compiling the jsp files, just copying them to the
WEB-INF directory, to later be compiled on demand.

-Justin

Chris Holmes wrote:

Justin Deoliveira wrote:

Very cool,

This would be a major step in the right direction for the current
geoserver ui. The JSP thing is a bummer for sure. It wouldn't be hard to
write a little class that on server startup copied all jsp resources on
the classpath into the WEB-INF directory. What do people think?

Well, I think that's what the JSPCompiler does, but it starts when you
first go to the localhost:8080/geoserver, instead of when the server
starts. I wouldn't want the compilation to hold up the start of the
server, but if we stuck it in a low priority thread that could work.
Could also do that when we start the welcome page.

I think with wicket or tapestry, however, we won't need to use jsps. I
could be wrong, but I think they let you code much more straight html.

Chris

-Justin

Alessio Fabiani wrote:

Hi guys,
in my sparetime I have done some researches and some experimentations on
the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a
certain module directly inside the module JAR. That means that a module,
like WCS, WPS, WCaS, ecc..., should be plugged into GeoServer by simply
adding the JAR to the classpath, and automatically deployed wihtout
touching anything of the GeoServer core.

My first try was to maintain the actual architecture as much as possible
for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which
overrides the standard Struts ActionServlet, and allows a user to
automatically load moultiple struts-config files in a way like this:

   
   <servlet>
    <servlet-name>action</servlet-name>

<servlet-class>org.vfny.geoserver.config.MultipleActionServlet</servlet-class>

    <init-param>
      <param-name>config</param-name>

<param-value>/WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts-config.xml</param-value>

    </init-param>
    <init-param>
      <param-name>debug</param-name>
      <param-value>2</param-value>
    </init-param>
    <init-param>
      <param-name>detail</param-name>
      <param-value>2</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
  </servlet>

in such a way you can easily define the form beans, actions and
everything inside a separated module.jar:WEB-INF/struts-config.xml. The
configuration is automatically joined to the main struts-config. This is
actually working very well in the 1.4.x WCS branch.
The problem is for the JSP pages ... at this time I'm not able yet to
let the Web Container capable of getting the JSP pages directly from the
module jar file. I don't know if this is possible ... however exactly
the same approach I used whith Struts can be used with other Frameworks
supported by Spring like JSF, Wicket (as suggested by Andrea), Tapestry
and so on. The advantage of using other frameworks instead of Struts is
that they can provide a different way to render the web pages
(expecially for Wicket).

--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

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

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

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

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

!DSPAM:1004,44d99dcf40422095110867!

-------------------------------------------------------------------------
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

!DSPAM:1004,44da854b122151665516417!

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

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

!DSPAM:1004,44da854b122151665516417!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Alessio_Fabiani · August 10, 2006, 7:47am

If the Andrea experiment with wicket will be fine, I would like very much this solutions because is elegant and clean (and I would be happy to help him of course) … however I think that there is a solution to use JSPs inside JARs too … after a deep study of the Struts code what we can do is the following:

In the Struts config add the following property
write OurFactory which extends the Struts DefinitionsFactory and allows the user to specify for the tiles-defs.xml a string like this
/WEB-INF/tiles-defs.xml,classpath*:/WEB-INF/tiles-defs.xml
so that we can read the tile definitions inside the classpath
override few methods of the org.apache.struts.tiles.TilesRequestProcessor class writing this

in order to let it do something like this:
instead of
URL url = getServletContext().getResource()
this
if (previous url is null)
URL url = getClass().getClassLoader().getResource()
which returns an URL inside the classpath.

On 8/10/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

This wouldn’t be compiling the jsp files, just copying them to the
WEB-INF directory, to later be compiled on demand.

-Justin

Chris Holmes wrote:

Justin Deoliveira wrote:

Very cool,

This would be a major step in the right direction for the current
geoserver ui. The JSP thing is a bummer for sure. It wouldn’t be hard to
write a little class that on server startup copied all jsp resources on
the classpath into the WEB-INF directory. What do people think?
Well, I think that’s what the JSPCompiler does, but it starts when you
first go to the localhost:8080/geoserver, instead of when the server
starts. I wouldn’t want the compilation to hold up the start of the
server, but if we stuck it in a low priority thread that could work.
Could also do that when we start the welcome page.

I think with wicket or tapestry, however, we won’t need to use jsps. I
could be wrong, but I think they let you code much more straight html.

Chris

-Justin

Alessio Fabiani wrote:

Hi guys,
in my sparetime I have done some researches and some experimentations on
the modularization of WEB-UI for GeoServer.
The concept is that we would like to put the User Interface for a
certain module directly inside the module JAR. That means that a module,
like WCS, WPS, WCaS, ecc…, should be plugged into GeoServer by simply
adding the JAR to the classpath, and automatically deployed wihtout
touching anything of the GeoServer core.

My first try was to maintain the actual architecture as much as possible
for the User Interface, i.e. Struts integrated with Spring.
I did almost everything by creating a MultipleActionServlet class which
overrides the standard Struts ActionServlet, and allows a user to
automatically load moultiple struts-config files in a way like this:
action
org.vfny.geoserver.config.MultipleActionServlet
config
/WEB-INF/struts-config.xml,classpath*:/WEB-INF/struts- config.xml
debug 2 detail 2 2
in such a way you can easily define the form beans, actions and
everything inside a separated module.jar:WEB-INF/struts-config.xml. The
configuration is automatically joined to the main struts-config. This is
actually working very well in the 1.4.x WCS branch.
The problem is for the JSP pages … at this time I’m not able yet to
let the Web Container capable of getting the JSP pages directly from the
module jar file. I don’t know if this is possible … however exactly
the same approach I used whith Struts can be used with other Frameworks
supported by Spring like JSF, Wicket (as suggested by Andrea), Tapestry
and so on. The advantage of using other frameworks instead of Struts is
that they can provide a different way to render the web pages
(expecially for Wicket).

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

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

!DSPAM:1004,44d99dcf40422095110867!

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

!DSPAM:1004,44da854b122151665516417!

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

!DSPAM:1004,44da854b122151665516417!

–
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

jive · August 10, 2006, 12:24pm

Corey Puffalt wrote:

I agree. While I like the idea of a web interface to configure GeoServer I'd like it to be less tightly coupled. I'd rather see the configuration exposed as either JMX beans or a simple REST-type interface with a separate configuration client rather than tightly coupling a particular web

Interestingly enough you can split up the code to do this, the existing config part of the client only communicates with DTO beans (designed to be played with JMX). The application itself is completely driven from these beans as well.

But we have not found a good JMX console so nobody has been interested.
Jody

jive · August 10, 2006, 12:27pm

Chris Holmes wrote:

Yeah, I think most everyone agrees with this thought. Have a core config that's really easy to develop against, so that it becomes easy to swap in and out configuration clients. Note that the current set up is actually highly decoupled, to the point of going a bit too far. But I think we've learned lessons on how to keep it decoupled and make it easier to maintain.

I would point out that the widget based approach would actually tightly couple the config and web application - aka the web application would need to learn to respond to events sent over from the
client widgets. It would be interesting to see how pure this split is, and if it could be managed via an API.

Andrea dare I ask how model to client notification is handled?

I'd also posit that we should redo the config before we do the web admin tool. I think/hope that getting the config in order will make it easier for us to build out the web admin tool.

See the planned Preference Model, but seriously we should try this out with new modules first.
Jody

Andrea_Aime4 · August 10, 2006, 1:18pm

Jody Garnett ha scritto:

Chris Holmes wrote:

Yeah, I think most everyone agrees with this thought. Have a core config that's really easy to develop against, so that it becomes easy to swap in and out configuration clients. Note that the current set up is actually highly decoupled, to the point of going a bit too far. But I think we've learned lessons on how to keep it decoupled and make it easier to maintain.

I would point out that the widget based approach would actually tightly couple the config and web application - aka the web application would need to learn to respond to events sent over from the
client widgets.

Client widgets? Hum, doing a page with Wicket or JSF is much alike having
a set of listeners in Swing. Sure they are code and not UI description,
but they are still part of the UI.
These widgets are not to be intended as client side widgets as in "browser
widgets", they are abstraction built on top of http, forms, javascript and
eventually ajax so that you don't have to deal with the details.

It would be interesting to see how pure this split is, and if it could be managed via an API.

I don't follow you. Mind to reword this?

Andrea dare I ask how model to client notification is handled?

Model to client? This is a web app, there's no notification unless you
want to do something that leverages ajax in a way such as gmail is doing.
I'm probably misunderstanding what you mean, explainations needed here too

Cheers
Andrea

Andrea_Aime4 · August 10, 2006, 1:24pm

Corey Puffalt ha scritto:

I agree. While I like the idea of a web interface to configure GeoServer I'd like it to be less tightly coupled. I'd rather see the configuration exposed as either JMX beans or a simple REST-type interface with a separate configuration client rather than tightly coupling a particular web configuration interface. This would make it easy to automate configuration.

We can have both in fact, a default and friendly user interface and
expose bean thru JMX as well. I still have to see a JMX console that looks
good and is usable, simply because it reflects a too low level model.

Take for example jconsole, it allows you to monitor heap and whatnot
of a java application. There is a pure jmx view you can use, but I never
found it useful, the other screens on the app do use the same info provided
thru jmx but present them in a friendly and useful way. See:
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

In my opinion, JMX may be viewed as a remoting tecnology, but it's not
a substitute for a well thought user interface.

Cheers
Andrea Aime

jive · August 11, 2006, 8:15am

Andrea Aime wrote:

Client widgets? Hum, doing a page with Wicket or JSF is much alike having
a set of listeners in Swing.

Indeed, and Swing is fairly intrusive on the model it is adjusting is it not? I have seen
some nice use of a TreeModel as an adapter ... but of Swing objects try to listen directly
to model objects (in this case the GeoServer application), I just want to be sure that the
GeoServer application is never stuck listening to a widget ...

I should reserver comment until I still a prototype, I do not have enough experience on this one.

Sure they are code and not UI description, but they are still part of the UI.
These widgets are not to be intended as client side widgets as in "browser
widgets", they are abstraction built on top of http, forms, javascript and
eventually ajax so that you don't have to deal with the details.

Yep got it, even if the details are firmly sheltered away (leaving me with a Swing like scenario)
I would like to know how geoserver exposes its configuration API, if it can be remoted, if the
user interface is "hands off" and only making use of the remote API and so on ...

I guess it is a choice between:
- treating each module as its own stack with setting persistence (we can encourage use of shared persistence), running services, and configuration ui
- treating each module as a stack from setting, to running service, to configuration API, and then a seperate user interface that makes use of that API.

I would lake to maintain a layered architecture here, just within each module.

Aside: comparison with the JMX card(s) - that seem like a waste of time about now?
- treating each module as its own stack w/ persistence and an a config API, in case of JMX bean under management console
- treating each module as its own with JMX Bean for settings, under management console with storing handled by provided by a persistence service

I wish I had time to go into this more today, there are several steps to going from a module system to something more complete ... we should consider them in order
rather then just where our pain in the current design is (the answers of one effect the others).

It would be interesting to see how pure this split is, and if it could be managed via an API.

I don't follow you. Mind to reword this?

I hope the above rewording has helped.

Andrea dare I ask how model to client notification is handled?

Model to client? This is a web app, there's no notification unless you
want to do something that leverages ajax in a way such as gmail is doing.
I'm probably misunderstanding what you mean, explainations needed here too

Basically I do not want the module becoming dependent on its user interface code - for anything. Woried about the layer boundry
Jody

jive · August 11, 2006, 8:18am

Andrea Aime wrote:

In my opinion, JMX may be viewed as a remoting tecnology, but it's not
a substitute for a well thought user interface.

I have basically reached the same conclusion - I do not think JMX would make for a positive GeoServer experience.

However, I do think we need to out some configuration options as JMX Beans: specifically the ones that a need to be tweaked by a sys admin (database connections and so on).

Cheers,
Jody

Alessio_Fabiani · August 11, 2006, 8:26am

Hi all,
does make sense to you the following use of JMX interfaces:
1 - create an MBean for each GeoServer module which exposes methods like some statistics, update, save, reload, and so on …
2 - when the MBean invokes one of those methods, the GeoServer module retrieves the ServletContext (should be quite easy to do that) and interacts with DTO objects and catalog performing all the operations.

This solution is very quick and easy to implement, but before we should start thinking on a better modularization of GeoServer

On 8/11/06, Jody Garnett <jgarnett@anonymised.com> wrote:

Andrea Aime wrote:

Client widgets? Hum, doing a page with Wicket or JSF is much alike having
a set of listeners in Swing.
Indeed, and Swing is fairly intrusive on the model it is adjusting is it
not? I have seen
some nice use of a TreeModel as an adapter … but of Swing objects try
to listen directly
to model objects (in this case the GeoServer application), I just want
to be sure that the
GeoServer application is never stuck listening to a widget …

I should reserver comment until I still a prototype, I do not have
enough experience on this one.

Sure they are code and not UI description, but they are still part of
the UI.
These widgets are not to be intended as client side widgets as in
“browser
widgets”, they are abstraction built on top of http, forms, javascript
and
eventually ajax so that you don’t have to deal with the details.
Yep got it, even if the details are firmly sheltered away (leaving me
with a Swing like scenario)
I would like to know how geoserver exposes its configuration API, if it
can be remoted, if the
user interface is “hands off” and only making use of the remote API and
so on …

I guess it is a choice between:

treating each module as its own stack with setting persistence (we can
encourage use of shared persistence), running services, and configuration ui

treating each module as a stack from setting, to running service, to
configuration API, and then a seperate user interface that makes use
of that API.

I would lake to maintain a layered architecture here, just within each
module.

Aside: comparison with the JMX card(s) - that seem like a waste of time
about now?

treating each module as its own stack w/ persistence and an a config
API, in case of JMX bean under management console

treating each module as its own with JMX Bean for settings, under
management console with storing handled by provided by a persistence service

I wish I had time to go into this more today, there are several steps to
going from a module system to something more complete … we should
consider them in order
rather then just where our pain in the current design is (the answers of
one effect the others).

It would be interesting to see how pure this split is, and if it
could be managed via an API.
I don’t follow you. Mind to reword this?
I hope the above rewording has helped.
Andrea dare I ask how model to client notification is handled?
Model to client? This is a web app, there’s no notification unless you
want to do something that leverages ajax in a way such as gmail is doing.
I’m probably misunderstanding what you mean, explainations needed here
too
Basically I do not want the module becoming dependent on its user
interface code - for anything. Woried about the layer boundry
Jody

–

Eng. Alessio Fabiani
Vice President/CTO GeoSolutions

http://www.geo-solutions.it

jive · August 10, 2006, 12:21pm

Hi Gabriel and Andrea,

Gabriel I spent some asking people to look at JMX initially for GeoServer, and then again a couple months ago
as 1.4 started taking shape. The protocol does not specify if the configuration is saved or not ...

I am unsure if:
- the service being configured is expected to save its settings
- another service around the system should capture, persist, and possible version the JMX beans
- or if the answers to these questions is only something you see/get in a real commercial deployment (like websphere )

Heh... Spring is able to provide JMX access for every bean configured
in the spring context, but storing the modifications to them is another story.

I had hoped with the definition of a Preference module (see Jesse's proposal) we could try out two ideas:
1. An easy way for modules to externalize their settings and remain independent of database or file based persistence (death to data dir!)
2. An experimental module to watch the JMX beans and save them (and version?) without client modules having a clue

But the first step is preference model Hi Jesse, hopefully you get to hack with us again soon.

I still have to see a solution to this, does anyone know of a generic solution
that allows to persist the changes and not only to to allow for runtime
inspection and volatile change.

I think JMX is neutral on the topic leaving a way for application containers to compete.

See also this thread:
http://forum.springframework.org/archive/index.php/t-22474.html

Apparently JMX persistance is "optional" and everybody does its own.
On this jboss forum it is told that jboss has partial support for it, but it seems
to be something "custom", not portable:

Understanding middleware

See also this Sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=5108724

Thanks for the links Andrea, and yes my ideas for the preference module would fall under "everybody does its own".
Jody