R: R: R: R: [Geoserver-devel] R: Geoserver Enterprise

I looked at the Spring docs to refresh my memories,
and saw it also has a data and transaction abstraction layer.
Maybe it can be used to replace the current GeoServer's
transaction system???
Just a thought, I didn't looked into it in depth.
Maybe we could take advantage of the various Spring
functionalities beyound the simple IoC container...
This would be a definitive plus towards its adoption,
but it would make it very pervasive inside both
GeoServer and GeoTools. Maybe too much pervasive...

Bye
Paolo Rizzi

-----Messaggio originale-----
Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: venerdì 4 novembre 2005 19.33
A: "P.Rizzi Ag.Mobilità Ambiente"
Cc: geoserver-devel@lists.sourceforge.net
Oggetto: Re: R: R: R: [Geoserver-devel] R: Geoserver Enterprise

Hmm, I must admit, JBoss looks promising, I think this warrants an
experiment of my own.

I think the nice thing is that both Spring and JBoss are IoC
containers
that let us write POJO's. This is a simple construct but it
allows us to
write container independent code. Which is huge, because if
we want to
jump ship at any time, theoretically most of our objects
should work the
same in a different container.

Another note, both frameworks boast to be lightweight enough
to embedd
in any environment. This mean we may be able to possibly use
both in a
single application.

Some more comments inline.

P.Rizzi Ag.Mobilità Ambiente wrote:
> So it seems we two are quite aligned, I too like Spring and JBoss!!!
>
> I did many test with Spring a few months ago, and almost
decided to use it,
> but then abandoned it in favor of JBoss, because we already
decided to use
> it
> as our application server, so there was no point in using
yet another
> library (Spring).
>
From what I can tell, the main reason for chosing one over
the other at
this time is political.
> From what I've seen so far I can tell that the IoC
container of Spring is
> much more poweful and developed, but JBoss' Microcontainer
will soon reach
> it.
>
> Aspect programming is a great thing. I did some tests
months ago with both
> the Spring aspect framework and JBossAOP. They follow different
> philosophies,
> but I found JBossAOP to be much more powerful.
I have looked at SpringAOP so I cant comment, but I am intrigued and
intend to look at JBossAOP.
>
> JBoss strength is the integration with all other services
(if you need them,
> but you're not obliged to), and in particular it's powerful
Class Loading
> system.
>
> So Spring is more "smart", but JBoss has a much larger "breadth",
> though it's a bit difficult to grasp at first. Also one may have the
> idea that JBoss technologies works only inside the
application server,
> but this is not the case, in fact most of them, work
equally well outside.
> Take a look at this to have an idea of what they're developing the
> Microcontainer for:
>
>
http://jboss.org/jbossBlog/blog/bburke/2005/09/29/JBoss_Microc
ontainer_Embed
> dable_JBoss.txt
>
> Anyway I'm not pushing JBoss, I just want to be sure that
each option
> is taken into account. I like Spring very much, so I'd be
happy if it
> would be chosen. It just seems to be less "enterprise" than JBoss...
I dont really like the name Geoserver "Enterprise". The term
"Enterprise" brings along a lot of preconceptions with it that dont
apply. For instance Enterprise in the java world means that you are
using J2EE, and you dont have to with Spring or JBoss Micro.

Furthermore, our conversations about the architecture seem to
be shaping
geoserver into a much smaller core, with a wealth of services and
utilities "plugged into it". Enterprise software is notorious
for being
very monolithic.

All that being said I am not a marketing consultant so who knows, I
would like to bring the name out for public debate as well.
>
> Bye
> Paolo Rizzi
>
>
> P.S: Can you put up a polling form on the Wiki, or
something like that???
> Because EMail tends to go missing, after a while...

This is a great idea, I am going to look into this.

Justin
>
>
>
>>Spring)
>>
>>I must say I am leaning pretty heavily toward Spring, for a
couple of
>>reasons:
>>
>>1) It is fully featured web application framework
>>2) WebMVC is a nice substitute for struts
>>3) It is integratable with pretty much of the other web
>>technologies out
>>there, including struts
>>4) I have found aspects to be a very nice way of organizing code
>
>
>>However my number one reason for liking Spring is the
>>popularity it is
>>gaining. For instance, this year at OOPSLA Spring received
>>much attention.
>>
>>JBoss Microcontainer)
>>
>>I eagerly await the full evaluation, I have done some
>>research, here are
>>my thoughts.
>>
>> From what I can tell JBoss MicroContainer offers everything
>>that Spring
>>does. However it still seems like JBoss Microcontainer is
>>still the new
>>guy on the scene and most people are still using spring.
>>
>>This is an article comparing the two:
>>
>>http://www.javalobby.org/java/forums/t49723.html
>>
>>Here is an interesting post that referes to JBoss licencing:
>>
>>http://www.javalobby.org/java/forums/m91945483.html
>>
>>So all in all I would have to say that my choice at this moment is
>>definitly Spring.
>>
>>Any one else who has an opinion please chime in.
>>
>>-Justin
>>
>>P.Rizzi Ag.Mobilità Ambiente wrote:
>>
>>>I looked at:
>>> http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
>>>and saw you updated it with more detailed information, very
>>
>>good work!!!
>>
>>>I'm experimenting a bit with JBoss Microcontainer and I
>>
>>hope to be able
>>
>>>to add my experiments' results to the page soon.
>>>
>>>I think we should start a sort of opinion poll.
>>>Obviously you are free to decide as you like, but I think that
>>>any "Humble and Biased" opinion, can be useful anyway.
>>>
>>>So, here follows mine (please imagine an implicit "I think..."
>>>before each affirmation).
>>>
>>>Bye
>>>Paolo Rizzi
>>>
>>>******************************************************************
>>>.) OSGi
>>>It's surely powerful, but not easily "embeddable".
>>>It tends to want having things done in its own manner
>>>and it may conflict with other container (J2EE in particular).
>>>--- I'd not use it. ---
>>>
>>>.) Geronimo / GBeans
>>>Light, flexible and embeddable enough, but it has nothing more
>>>than JBoss / Microcontainer has, and it's not enough mature.
>>>--- I'd not use it. ---
>>>
>>>.) Spring
>>>Very light, flexible and embeddable. It's designed to integrate,
>>>not to conflict, with other containers and technology.
>>>It optionally offers more than the plain container (MVC,
AOP, etc.).
>>>It's quite mature and supported, but maybe there're not many people
>>>"behind" it, apart from its creator.
>>>--- I'd use it. ---
>>>
>>>.) JBoss / Microcontainer
>>>Very light and flexible. The new Microcontainer is embeddable
>>>and it's designed to integrate, not to conflict, with other
>>
>>containers.
>>
>>>JBoss optionally offers a lot more than the plain container
>>
>>(MVC, AOP,
>>
>>>etc.).
>>>It's very mature and supported, and there's a strong
>>
>>support "behind" it.
>>
>>>--- I'd use it. ---
>>>
>>>Licenses details remains to be looked for (but I'm no
>>
>>expert in this).
>>
>>>In the end I'd use JBoss / Microcontainer, because that's
>>
>>what I've used
>>
>>>till now (JBoss, not the Microcontainer).
>>>If for any reason this is judged not to be usable, I'd use Spring.
>>>I see no reason to use Geronimo / GBeans instead of JBoss /
>>
>>Microcontainer.
>>
>>>I'd not use OSGi anyway.
>>>
>>>******************************************************************
>>>
>>>
>>>
>>>>-----Messaggio originale-----
>>>>Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
>>>>Inviato: lunedì 24 ottobre 2005 17.04
>>>>A: "P.Rizzi Ag.Mobilità Ambiente"
>>>>Cc: 'dblasby@anonymised.com'; Gabriel Roldán; "L.Percich
Ag.Mobilità
>>>>Ambiente"; geoserver-devel@lists.sourceforge.net
>>>>Oggetto: Re: R: [Geoserver-devel] R: Geoserver Enterprise
>>>>
>>>>
>>>>Hi Paolo,
>>>>
>>>>I am glad you are interested in this topic. A technology
>>
>>has not yet
>>
>>>>been decided on, still in the evaluation stage. OSGi is just
>>>>the first
>>>>one that I have had time to document. Next I plan to evaluate
>>>>Geronimo.
>>>>
>>>>Please feel free to add JBoss to the list of candidates. It
>>>>you have the
>>>>time I would love if you could write some docs about why you
>>>>think its a
>>>>good way to go.
>>>>
>>>>The list of technologies on the page is by no means complete
>>>>so please
>>>>add anything else you think should be there.
>>>>
>>>>-Justin
>>>>
>>>>P.Rizzi Ag.Mobilità Ambiente wrote:
>>>>
>>>>
>>>>>>Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
>>>>>>Inviato: venerdì 30 settembre 2005 19.20
>>>>>>We are in the process of putting up some wiki space
>>>>
>>>>dedicated to the
>>>>
>>>>
>>>>>>design. It would be nice to start refining some of the great
>>>>>>discussions
>>>>>>that have been going on with OpenSDI and some of things you
>>>>
>>>>guys have
>>>>
>>>>
>>>>>>been doing over the last little while into a architecure and
>>>>>>high level
>>>>>>design.
>>>>>>
>>>>>>Justin
>>>>>
>>>>>Sorry for disappearing in the last weeks, but I've been taken
>>>>>away with exporting data to remote Oracle instances...!!!
>>>>>
>>>>>I looked in the "RnD" Wiki space of GeoServer and saw the:
>>>>> http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
>>>>>page, that seems the most recently updated.
>>>>>
>>>>>The only technology actually analized in depth is OSGi,
>>>>>does it means you already choose it, or simply is it the
first one
>>>>>you addressed???
>>>>>
>>>>>I'd like to add JBoss as a suitable technology, and also a couple
>>>>>of other considerations. May I edit the page???
>>>>>
>>>>>I'm very interested in the proceeding of this and expecially in
>>>>>Dave's sentence:
>>>>> "...ps. from the last meeting, it appears the "data/catalog"
>>>>> portion of the framework will be somewhat like an expanded
>>>>>"DataEngine"
>>>>> (from the IRC meeting)...".
>>>>>I found no reference to this in the Wiki though... Where
>>>>
>>>>can I find it???
>>>>
>>>>
>>>>>Bye
>>>>>Paolo Rizzi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>P.Rizzi Ag.Mobilità Ambiente wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>I read the transcript from yesterday's IRC meeting. Sorry
>>>>>>
>>>>>>we couldnt
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>attend.
>>>>>>>
>>>>>>>I'm sorry, because we probably didn't advertised the IRC
>>
>>enough...
>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>For the last 2 weeks, I have been in Victoria talking with
>>>>>>
>>>>>>the two new
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>TOPP employees (Brent Owens and Justin Deoliveira).
>>>>>>>>
>>>>>>>>We have been discussing a large number of topics, but one
>>>>>>
>>>>>>of the major
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>discussions has been on the Geoserver Enterprise Edition.
>>>>>>>>
>>>>>>>>This is basically a new plug-in and extension-point based
>>>>
>>>>system for
>>>>
>>>>
>>>>>>>>doing Geo-based web application (including things like WFS
>>>>>>
>>>>>>and WMS and
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>WCS). And "customizing" existing applications. For
>>>>>>
>>>>>>example, the SIS
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>stuff "plugging in" to WFS, and geo-wiki things. The new
>>>>
>>>>Enterprise
>>>>
>>>>
>>>>>>>>edition will take geoserver from an application to a
>>
>>platform for
>>
>>>>>>>>developing and customizing web-based geo-applications.
>>>>>>>>
>>>>>>>>We have discussed how we would provide services for most of
>>>>>>>>what's been
>>>>>>>>talked about on the mailing list and the few IRC
>>>>
>>>>meetings. I think
>>>>
>>>>
>>>>>>>>you're going to be very excited about it. We are going to
>>>>>>>>write up our
>>>>>>>>ideas for next week and hope to get some feedback from you.
>>>>>>>
>>>>>>>Great!!! I'll wait to see what you came up with with much
>>>>>>
>>>>>>interest!!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>dave
>>>>>>>
>>>>>>> Bye Paolo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>ps. from the last meeting, it appears the "data/catalog"
>>>>>>>>portion of the
>>>>>>>>framework will be somewhat like an expanded "DataEngine"
>>>>>>
>>>>>>(from the IRC
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>meeting).
>>>>>>>
>>>>>>>I feel this is fundamental, so I'm happy to know we're
>>>>>>
>>>>>>quite tuned on it!!!
>>>>>>
>>>>>>
>>>>>>
>>>>>>>AVVERTENZE AI SENSI DEL D. LGS. 196/2003
>>>>>>>Le informazioni contenute in questo messaggio di posta
>>>>>>
>>>>>>elettronica e/o nel/i
>>>>>>
>>>>>>
>>>>>>
>>>>>>>file/s allegato/i, sono da considerarsi strettamente
>>>>>>
>>>>>>riservate. Il loro
>>>>>>
>>>>>>
>>>>>>
>>>>>>>utilizzo è consentito esclusivamente al destinatario del
>>>>>>
>>>>>>messaggio, per le
>>>>>>
>>>>>>
>>>>>>
>>>>>>>finalità indicate nel messaggio stesso. Qualora riceveste
>>>>>>
>>>>>>questo messaggio
>>>>>>
>>>>>>
>>>>>>
>>>>>>>senza esserne il destinatario, Vi preghiamo cortesemente di
>>>>>>
>>>>>>darcene notizia
>>>>>>
>>>>>>
>>>>>>
>>>>>>>via e-mail e di procedere alla distruzione del
messaggio stesso,
>>>>>>>cancellandolo dal Vostro sistema; costituisce comportamento
>>>>>>
>>>>>>contrario ai
>>>>>>
>>>>>>
>>>>>>
>>>>>>>principi dettati dal D. Lgs. 196/2003 il trattenere il
>>>>>>
>>>>>>messaggio stesso,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>divulgarlo anche in parte, distribuirlo ad altri soggetti,
>>>>>>
>>>>>>copiarlo, od
>>>>>>
>>>>>>
>>>>>>
>>>>>>>utilizzarlo per finalità diverse.
>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>This SF.Net email is sponsored by:
>>>>>>>Power Architecture Resource Center: Free content,
>>>>>>
>>>>>>downloads, discussions,
>>>>>>
>>>>>>
>>>>>>
>>>>>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>>>>>_______________________________________________
>>>>>>>Geoserver-devel mailing list
>>>>>>>Geoserver-devel@lists.sourceforge.net
>>>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Justin Deoliveira
>>>>>>The Open Planning Project
>>>>>>http://topp.openplans.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>AVVERTENZE AI SENSI DEL D. LGS. 196/2003
>>>>>Le informazioni contenute in questo messaggio di posta
>>>>
>>>>elettronica e/o nel/i
>>>>
>>>>
>>>>>file/s allegato/i, sono da considerarsi strettamente
>>>>
>>>>riservate. Il loro
>>>>
>>>>
>>>>>utilizzo è consentito esclusivamente al destinatario del
>>>>
>>>>messaggio, per le
>>>>
>>>>
>>>>>finalità indicate nel messaggio stesso. Qualora riceveste
>>>>
>>>>questo messaggio
>>>>
>>>>
>>>>>senza esserne il destinatario, Vi preghiamo cortesemente di
>>>>
>>>>darcene notizia
>>>>
>>>>
>>>>>via e-mail e di procedere alla distruzione del messaggio stesso,
>>>>>cancellandolo dal Vostro sistema; costituisce comportamento
>>>>
>>>>contrario ai
>>>>
>>>>
>>>>>principi dettati dal D. Lgs. 196/2003 il trattenere il
>>>>
>>>>messaggio stesso,
>>>>
>>>>
>>>>>divulgarlo anche in parte, distribuirlo ad altri soggetti,
>>>>
>>>>copiarlo, od
>>>>
>>>>
>>>>>utilizzarlo per finalità diverse.
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by the JBoss Inc.
>>>>>Get Certified Today * Register for a JBoss Training Course
>>>>>Free Certification Exam for All Training Attendees Through
>>>>
>>>>End of 2005
>>>>
>>>>
>>>>>Visit http://www.jboss.com/services/certification for more
>>>>
>>>>information
>>>>
>>>>
>>>>>_______________________________________________
>>>>>Geoserver-devel mailing list
>>>>>Geoserver-devel@lists.sourceforge.net
>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>
>>>>
>>>>--
>>>>Justin Deoliveira
>>>>The Open Planning Project
>>>>http://topp.openplans.org
>>>>
>>>
>>>
>>>
>>>
>>>
>>>AVVERTENZE AI SENSI DEL D. LGS. 196/2003
>>>Le informazioni contenute in questo messaggio di posta
>>
>>elettronica e/o nel/i
>>
>>>file/s allegato/i, sono da considerarsi strettamente
>>
>>riservate. Il loro
>>
>>>utilizzo è consentito esclusivamente al destinatario del
>>
>>messaggio, per le
>>
>>>finalità indicate nel messaggio stesso. Qualora riceveste
>>
>>questo messaggio
>>
>>>senza esserne il destinatario, Vi preghiamo cortesemente di
>>
>>darcene notizia
>>
>>>via e-mail e di procedere alla distruzione del messaggio stesso,
>>>cancellandolo dal Vostro sistema; costituisce comportamento
>>
>>contrario ai
>>
>>>principi dettati dal D. Lgs. 196/2003 il trattenere il
>>
>>messaggio stesso,
>>
>>>divulgarlo anche in parte, distribuirlo ad altri soggetti,
>>
>>copiarlo, od
>>
>>>utilizzarlo per finalità diverse.
>>>
>>
>>
>>--
>>Justin Deoliveira
>>The Open Planning Project
>>http://topp.openplans.org
>>
>
>
>
>
>
> AVVERTENZE AI SENSI DEL D. LGS. 196/2003
> Le informazioni contenute in questo messaggio di posta
elettronica e/o nel/i
> file/s allegato/i, sono da considerarsi strettamente
riservate. Il loro
> utilizzo è consentito esclusivamente al destinatario del
messaggio, per le
> finalità indicate nel messaggio stesso. Qualora riceveste
questo messaggio
> senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia
> via e-mail e di procedere alla distruzione del messaggio stesso,
> cancellandolo dal Vostro sistema; costituisce comportamento
contrario ai
> principi dettati dal D. Lgs. 196/2003 il trattenere il
messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti,
copiarlo, od
> utilizzarlo per finalità diverse.
>

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.

Hi Paulo,

I agree. These are core pieces of any enterprise infrastructure, we have to question the wisdom of "rolling our own". That being said, many "enterprise" quality solutions just dont cut it and cannot scale to the degree that is needed for GIS applications. I am sure jody will have something to add here :).

However this is easier said then done. Most of the objects that do data access and transactions live in Geotools. Various factories and datastores are not currently written using the IoC paradigm. Which makes having the container supply certain dependencies hard.

As an example, the postgis / jdbc datastore factory creates its own ConnectionPool. Wheras certain application servers / containers have their own implementation of ConnectionPool, and if you want to use the "special facilities" you have to use it.

However, the calls for this kind of architecture in geotools are starting to be made. And since Spring and JBoss Micro follow the golden rule of allowing all your business objects to be simple POJO's, it shouldn't be too hard to transition the necessary classes over to IoC.

Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

I looked at the Spring docs to refresh my memories,
and saw it also has a data and transaction abstraction layer.
Maybe it can be used to replace the current GeoServer's transaction system???
Just a thought, I didn't looked into it in depth.
Maybe we could take advantage of the various Spring
functionalities beyound the simple IoC container...
This would be a definitive plus towards its adoption,
but it would make it very pervasive inside both
GeoServer and GeoTools. Maybe too much pervasive...

Bye
Paolo Rizzi

-----Messaggio originale-----
Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: venerdì 4 novembre 2005 19.33
A: "P.Rizzi Ag.Mobilità Ambiente"
Cc: geoserver-devel@lists.sourceforge.net
Oggetto: Re: R: R: R: [Geoserver-devel] R: Geoserver Enterprise

Hmm, I must admit, JBoss looks promising, I think this warrants an experiment of my own.

I think the nice thing is that both Spring and JBoss are IoC containers that let us write POJO's. This is a simple construct but it allows us to write container independent code. Which is huge, because if we want to jump ship at any time, theoretically most of our objects should work the same in a different container.

Another note, both frameworks boast to be lightweight enough to embedd in any environment. This mean we may be able to possibly use both in a single application.

Some more comments inline.

P.Rizzi Ag.Mobilità Ambiente wrote:

So it seems we two are quite aligned, I too like Spring and JBoss!!!

I did many test with Spring a few months ago, and almost

decided to use it,

but then abandoned it in favor of JBoss, because we already

decided to use

it
as our application server, so there was no point in using

yet another

library (Spring).

From what I can tell, the main reason for chosing one over the other at this time is political.

From what I've seen so far I can tell that the IoC

container of Spring is

much more poweful and developed, but JBoss' Microcontainer

will soon reach

it.

Aspect programming is a great thing. I did some tests

months ago with both

the Spring aspect framework and JBossAOP. They follow different
philosophies,
but I found JBossAOP to be much more powerful.

I have looked at SpringAOP so I cant comment, but I am intrigued and intend to look at JBossAOP.

JBoss strength is the integration with all other services

(if you need them,

but you're not obliged to), and in particular it's powerful

Class Loading

system.

So Spring is more "smart", but JBoss has a much larger "breadth",
though it's a bit difficult to grasp at first. Also one may have the
idea that JBoss technologies works only inside the

application server,

but this is not the case, in fact most of them, work

equally well outside.

Take a look at this to have an idea of what they're developing the
Microcontainer for:

http://jboss.org/jbossBlog/blog/bburke/2005/09/29/JBoss_Microc
ontainer_Embed

dable_JBoss.txt

Anyway I'm not pushing JBoss, I just want to be sure that

each option

is taken into account. I like Spring very much, so I'd be

happy if it

would be chosen. It just seems to be less "enterprise" than JBoss...

I dont really like the name Geoserver "Enterprise". The term "Enterprise" brings along a lot of preconceptions with it that dont apply. For instance Enterprise in the java world means that you are using J2EE, and you dont have to with Spring or JBoss Micro.

Furthermore, our conversations about the architecture seem to be shaping geoserver into a much smaller core, with a wealth of services and utilities "plugged into it". Enterprise software is notorious for being very monolithic.

All that being said I am not a marketing consultant so who knows, I would like to bring the name out for public debate as well.

Bye
Paolo Rizzi

P.S: Can you put up a polling form on the Wiki, or

something like that???

Because EMail tends to go missing, after a while...

This is a great idea, I am going to look into this.

Justin

Spring)

I must say I am leaning pretty heavily toward Spring, for a

couple of

reasons:

1) It is fully featured web application framework
2) WebMVC is a nice substitute for struts
3) It is integratable with pretty much of the other web technologies out there, including struts
4) I have found aspects to be a very nice way of organizing code

However my number one reason for liking Spring is the popularity it is gaining. For instance, this year at OOPSLA Spring received much attention.

JBoss Microcontainer)

I eagerly await the full evaluation, I have done some research, here are my thoughts.

From what I can tell JBoss MicroContainer offers everything that Spring does. However it still seems like JBoss Microcontainer is still the new guy on the scene and most people are still using spring.

This is an article comparing the two:

http://www.javalobby.org/java/forums/t49723.html

Here is an interesting post that referes to JBoss licencing:

http://www.javalobby.org/java/forums/m91945483.html

So all in all I would have to say that my choice at this moment is definitly Spring.

Any one else who has an opinion please chime in.

-Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

I looked at:
http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
and saw you updated it with more detailed information, very

good work!!!

I'm experimenting a bit with JBoss Microcontainer and I

hope to be able

to add my experiments' results to the page soon.

I think we should start a sort of opinion poll.
Obviously you are free to decide as you like, but I think that
any "Humble and Biased" opinion, can be useful anyway.

So, here follows mine (please imagine an implicit "I think..."
before each affirmation).

Bye
Paolo Rizzi

******************************************************************
.) OSGi
It's surely powerful, but not easily "embeddable".
It tends to want having things done in its own manner
and it may conflict with other container (J2EE in particular).
--- I'd not use it. ---

.) Geronimo / GBeans
Light, flexible and embeddable enough, but it has nothing more than JBoss / Microcontainer has, and it's not enough mature.
--- I'd not use it. ---

.) Spring
Very light, flexible and embeddable. It's designed to integrate,
not to conflict, with other containers and technology.
It optionally offers more than the plain container (MVC,

AOP, etc.).

It's quite mature and supported, but maybe there're not many people
"behind" it, apart from its creator.
--- I'd use it. ---

.) JBoss / Microcontainer Very light and flexible. The new Microcontainer is embeddable
and it's designed to integrate, not to conflict, with other

containers.

JBoss optionally offers a lot more than the plain container

(MVC, AOP,

etc.).
It's very mature and supported, and there's a strong

support "behind" it.

--- I'd use it. ---

Licenses details remains to be looked for (but I'm no

expert in this).

In the end I'd use JBoss / Microcontainer, because that's

what I've used

till now (JBoss, not the Microcontainer).
If for any reason this is judged not to be usable, I'd use Spring.
I see no reason to use Geronimo / GBeans instead of JBoss /

Microcontainer.

I'd not use OSGi anyway.

******************************************************************

-----Messaggio originale-----
Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: lunedì 24 ottobre 2005 17.04
A: "P.Rizzi Ag.Mobilità Ambiente"
Cc: 'dblasby@anonymised.com'; Gabriel Roldán; "L.Percich

Ag.Mobilità

Ambiente"; geoserver-devel@lists.sourceforge.net
Oggetto: Re: R: [Geoserver-devel] R: Geoserver Enterprise

Hi Paolo,

I am glad you are interested in this topic. A technology

has not yet

been decided on, still in the evaluation stage. OSGi is just the first one that I have had time to document. Next I plan to evaluate Geronimo.

Please feel free to add JBoss to the list of candidates. It you have the time I would love if you could write some docs about why you think its a good way to go.

The list of technologies on the page is by no means complete so please add anything else you think should be there.

-Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: venerdì 30 settembre 2005 19.20
We are in the process of putting up some wiki space

dedicated to the

design. It would be nice to start refining some of the great discussions that have been going on with OpenSDI and some of things you

guys have

been doing over the last little while into a architecure and high level design.

Justin

Sorry for disappearing in the last weeks, but I've been taken
away with exporting data to remote Oracle instances...!!!

I looked in the "RnD" Wiki space of GeoServer and saw the:
http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
page, that seems the most recently updated.

The only technology actually analized in depth is OSGi,
does it means you already choose it, or simply is it the

first one

you addressed???

I'd like to add JBoss as a suitable technology, and also a couple
of other considerations. May I edit the page???

I'm very interested in the proceeding of this and expecially in
Dave's sentence:
"...ps. from the last meeting, it appears the "data/catalog" portion of the framework will be somewhat like an expanded
"DataEngine" (from the IRC meeting)...".
I found no reference to this in the Wiki though... Where

can I find it???

Bye
Paolo Rizzi

P.Rizzi Ag.Mobilità Ambiente wrote:

I read the transcript from yesterday's IRC meeting. Sorry

we couldnt

attend.

I'm sorry, because we probably didn't advertised the IRC

enough...

For the last 2 weeks, I have been in Victoria talking with

the two new

TOPP employees (Brent Owens and Justin Deoliveira).

We have been discussing a large number of topics, but one

of the major

discussions has been on the Geoserver Enterprise Edition.

This is basically a new plug-in and extension-point based

system for

doing Geo-based web application (including things like WFS

and WMS and

WCS). And "customizing" existing applications. For

example, the SIS

stuff "plugging in" to WFS, and geo-wiki things. The new

Enterprise

edition will take geoserver from an application to a

platform for

developing and customizing web-based geo-applications.

We have discussed how we would provide services for most of what's been
talked about on the mailing list and the few IRC

meetings. I think

you're going to be very excited about it. We are going to write up our
ideas for next week and hope to get some feedback from you.

Great!!! I'll wait to see what you came up with with much

interest!!!

dave

    Bye Paolo

ps. from the last meeting, it appears the "data/catalog" portion of the
framework will be somewhat like an expanded "DataEngine"

(from the IRC

meeting).

I feel this is fundamental, so I'm happy to know we're

quite tuned on it!!!

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del

messaggio stesso,

cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content,

downloads, discussions,

and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through

End of 2005

Visit http://www.jboss.com/services/certification for more

information

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

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira wrote:

Hi Paulo,

I agree. These are core pieces of any enterprise infrastructure, we have to question the wisdom of "rolling our own". That being said, many "enterprise" quality solutions just dont cut it and cannot scale to the degree that is needed for GIS applications. I am sure jody will have something to add here :).

Not really, I know of a few people in the commercial space looking at extending WFS to go for the full strong transaction support (branch, merge, checkpoint). The low level transaction support we got at the DataStore level is not effected which ever way you go (it is glue code that you can back onto JDBC connections, Enterprise stuff from Spring or whatever you have around). Aside: I made sure to factor out the LockingManger from the DataStore API so you guys can experiment as opportunity permits.

You guys will have to fix the geotools factory system to be aware of containers - but you are already moving to a container based system so you should have that flexability already covered.
Oh wait Justin said that, I think you got what you need to know Justin. Just get on trunk so we can cause some damage.

Jody

However this is easier said then done. Most of the objects that do data access and transactions live in Geotools. Various factories and datastores are not currently written using the IoC paradigm. Which makes having the container supply certain dependencies hard.

As an example, the postgis / jdbc datastore factory creates its own ConnectionPool. Wheras certain application servers / containers have their own implementation of ConnectionPool, and if you want to use the "special facilities" you have to use it.

However, the calls for this kind of architecture in geotools are starting to be made. And since Spring and JBoss Micro follow the golden rule of allowing all your business objects to be simple POJO's, it shouldn't be too hard to transition the necessary classes over to IoC.

Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

I looked at the Spring docs to refresh my memories,
and saw it also has a data and transaction abstraction layer.
Maybe it can be used to replace the current GeoServer's transaction system???
Just a thought, I didn't looked into it in depth.
Maybe we could take advantage of the various Spring
functionalities beyound the simple IoC container...
This would be a definitive plus towards its adoption,
but it would make it very pervasive inside both
GeoServer and GeoTools. Maybe too much pervasive...

Bye
Paolo Rizzi

-----Messaggio originale-----
Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: venerdì 4 novembre 2005 19.33
A: "P.Rizzi Ag.Mobilità Ambiente"
Cc: geoserver-devel@lists.sourceforge.net
Oggetto: Re: R: R: R: [Geoserver-devel] R: Geoserver Enterprise

Hmm, I must admit, JBoss looks promising, I think this warrants an experiment of my own.

I think the nice thing is that both Spring and JBoss are IoC containers that let us write POJO's. This is a simple construct but it allows us to write container independent code. Which is huge, because if we want to jump ship at any time, theoretically most of our objects should work the same in a different container.

Another note, both frameworks boast to be lightweight enough to embedd in any environment. This mean we may be able to possibly use both in a single application.

Some more comments inline.

P.Rizzi Ag.Mobilità Ambiente wrote:

So it seems we two are quite aligned, I too like Spring and JBoss!!!

I did many test with Spring a few months ago, and almost

decided to use it,

but then abandoned it in favor of JBoss, because we already

decided to use

it
as our application server, so there was no point in using

yet another

library (Spring).

From what I can tell, the main reason for chosing one over the other at this time is political.

From what I've seen so far I can tell that the IoC

container of Spring is

much more poweful and developed, but JBoss' Microcontainer

will soon reach

it.

Aspect programming is a great thing. I did some tests

months ago with both

the Spring aspect framework and JBossAOP. They follow different
philosophies,
but I found JBossAOP to be much more powerful.

I have looked at SpringAOP so I cant comment, but I am intrigued and intend to look at JBossAOP.

JBoss strength is the integration with all other services

(if you need them,

but you're not obliged to), and in particular it's powerful

Class Loading

system.

So Spring is more "smart", but JBoss has a much larger "breadth",
though it's a bit difficult to grasp at first. Also one may have the
idea that JBoss technologies works only inside the

application server,

but this is not the case, in fact most of them, work

equally well outside.

Take a look at this to have an idea of what they're developing the
Microcontainer for:
    
http://jboss.org/jbossBlog/blog/bburke/2005/09/29/JBoss_Microc
ontainer_Embed

dable_JBoss.txt

Anyway I'm not pushing JBoss, I just want to be sure that

each option

is taken into account. I like Spring very much, so I'd be

happy if it

would be chosen. It just seems to be less "enterprise" than JBoss...

I dont really like the name Geoserver "Enterprise". The term "Enterprise" brings along a lot of preconceptions with it that dont apply. For instance Enterprise in the java world means that you are using J2EE, and you dont have to with Spring or JBoss Micro.

Furthermore, our conversations about the architecture seem to be shaping geoserver into a much smaller core, with a wealth of services and utilities "plugged into it". Enterprise software is notorious for being very monolithic.

All that being said I am not a marketing consultant so who knows, I would like to bring the name out for public debate as well.

Bye
Paolo Rizzi

P.S: Can you put up a polling form on the Wiki, or

something like that???

Because EMail tends to go missing, after a while...

This is a great idea, I am going to look into this.

Justin

Spring)

I must say I am leaning pretty heavily toward Spring, for a

couple of

reasons:

1) It is fully featured web application framework
2) WebMVC is a nice substitute for struts
3) It is integratable with pretty much of the other web technologies out there, including struts
4) I have found aspects to be a very nice way of organizing code

However my number one reason for liking Spring is the popularity it is gaining. For instance, this year at OOPSLA Spring received much attention.

JBoss Microcontainer)

I eagerly await the full evaluation, I have done some research, here are my thoughts.

From what I can tell JBoss MicroContainer offers everything that Spring does. However it still seems like JBoss Microcontainer is still the new guy on the scene and most people are still using spring.

This is an article comparing the two:

http://www.javalobby.org/java/forums/t49723.html

Here is an interesting post that referes to JBoss licencing:

http://www.javalobby.org/java/forums/m91945483.html

So all in all I would have to say that my choice at this moment is definitly Spring.

Any one else who has an opinion please chime in.

-Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

I looked at:
    http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
and saw you updated it with more detailed information, very

good work!!!

I'm experimenting a bit with JBoss Microcontainer and I

hope to be able

to add my experiments' results to the page soon.

I think we should start a sort of opinion poll.
Obviously you are free to decide as you like, but I think that
any "Humble and Biased" opinion, can be useful anyway.

So, here follows mine (please imagine an implicit "I think..."
before each affirmation).

Bye
Paolo Rizzi

******************************************************************
.) OSGi
It's surely powerful, but not easily "embeddable".
It tends to want having things done in its own manner
and it may conflict with other container (J2EE in particular).
--- I'd not use it. ---

.) Geronimo / GBeans
Light, flexible and embeddable enough, but it has nothing more than JBoss / Microcontainer has, and it's not enough mature.
--- I'd not use it. ---

.) Spring
Very light, flexible and embeddable. It's designed to integrate,
not to conflict, with other containers and technology.
It optionally offers more than the plain container (MVC,

AOP, etc.).

It's quite mature and supported, but maybe there're not many people
"behind" it, apart from its creator.
--- I'd use it. ---

.) JBoss / Microcontainer Very light and flexible. The new Microcontainer is embeddable
and it's designed to integrate, not to conflict, with other

containers.

JBoss optionally offers a lot more than the plain container

(MVC, AOP,

etc.).
It's very mature and supported, and there's a strong

support "behind" it.

--- I'd use it. ---

Licenses details remains to be looked for (but I'm no

expert in this).

In the end I'd use JBoss / Microcontainer, because that's

what I've used

till now (JBoss, not the Microcontainer).
If for any reason this is judged not to be usable, I'd use Spring.
I see no reason to use Geronimo / GBeans instead of JBoss /

Microcontainer.

I'd not use OSGi anyway.
******************************************************************

-----Messaggio originale-----
Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: lunedì 24 ottobre 2005 17.04
A: "P.Rizzi Ag.Mobilità Ambiente"
Cc: 'dblasby@anonymised.com'; Gabriel Roldán; "L.Percich

Ag.Mobilità

Ambiente"; geoserver-devel@lists.sourceforge.net
Oggetto: Re: R: [Geoserver-devel] R: Geoserver Enterprise

Hi Paolo,

I am glad you are interested in this topic. A technology

has not yet

been decided on, still in the evaluation stage. OSGi is just the first one that I have had time to document. Next I plan to evaluate Geronimo.

Please feel free to add JBoss to the list of candidates. It you have the time I would love if you could write some docs about why you think its a good way to go.

The list of technologies on the page is by no means complete so please add anything else you think should be there.

-Justin

P.Rizzi Ag.Mobilità Ambiente wrote:

Da: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Inviato: venerdì 30 settembre 2005 19.20
We are in the process of putting up some wiki space

dedicated to the

design. It would be nice to start refining some of the great discussions that have been going on with OpenSDI and some of things you

guys have

been doing over the last little while into a architecure and high level design.

Justin

Sorry for disappearing in the last weeks, but I've been taken
away with exporting data to remote Oracle instances...!!!

I looked in the "RnD" Wiki space of GeoServer and saw the:
    http://docs.codehaus.org/display/GEOS/GeoServer+2.0+Technology
page, that seems the most recently updated.

The only technology actually analized in depth is OSGi,
does it means you already choose it, or simply is it the

first one

you addressed???

I'd like to add JBoss as a suitable technology, and also a couple
of other considerations. May I edit the page???

I'm very interested in the proceeding of this and expecially in
Dave's sentence:
    "...ps. from the last meeting, it appears the "data/catalog" portion of the framework will be somewhat like an expanded
"DataEngine" (from the IRC meeting)...".
I found no reference to this in the Wiki though... Where

can I find it???

Bye
Paolo Rizzi

P.Rizzi Ag.Mobilità Ambiente wrote:

I read the transcript from yesterday's IRC meeting. Sorry

we couldnt

attend.

I'm sorry, because we probably didn't advertised the IRC

enough...

For the last 2 weeks, I have been in Victoria talking with

the two new

TOPP employees (Brent Owens and Justin Deoliveira).

We have been discussing a large number of topics, but one

of the major

discussions has been on the Geoserver Enterprise Edition.

This is basically a new plug-in and extension-point based

system for

doing Geo-based web application (including things like WFS

and WMS and

WCS). And "customizing" existing applications. For

example, the SIS

stuff "plugging in" to WFS, and geo-wiki things. The new

Enterprise

edition will take geoserver from an application to a

platform for

developing and customizing web-based geo-applications.

We have discussed how we would provide services for most of what's been
talked about on the mailing list and the few IRC

meetings. I think

you're going to be very excited about it. We are going to write up our
ideas for next week and hope to get some feedback from you.

Great!!! I'll wait to see what you came up with with much

interest!!!

dave

            Bye Paolo

ps. from the last meeting, it appears the "data/catalog" portion of the
framework will be somewhat like an expanded "DataEngine"

(from the IRC

meeting).

I feel this is fundamental, so I'm happy to know we're

quite tuned on it!!!

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del

messaggio stesso,

cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content,

downloads, discussions,

and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through

End of 2005

Visit http://www.jboss.com/services/certification for more

information

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

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta

elettronica e/o nel/i

file/s allegato/i, sono da considerarsi strettamente

riservate. Il loro

utilizzo è consentito esclusivamente al destinatario del

messaggio, per le

finalità indicate nel messaggio stesso. Qualora riceveste

questo messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di

darcene notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento

contrario ai

principi dettati dal D. Lgs. 196/2003 il trattenere il

messaggio stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti,

copiarlo, od

utilizzarlo per finalità diverse.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.