[Geoserver-devel] workspace local "global" config

GeoServer GeoServer Developer
1

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

Thanks.

-Justin

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

2

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

3

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

4

How about:

“WorkspaceInfo”

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

On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

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

5

Already taken :slight_smile: Or are you implying that all the settings just get rolled into the workspace interface?

On Wed, Dec 14, 2011 at 11:37 PM, David Winslow <dwinslow@anonymised.com> wrote:

How about:

“WorkspaceInfo”

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

On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

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

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

6

Do you have a UI in mind for this? Like where does one make these settings?

Thing that would make the most sense for me would something like have the ‘workspace’ page have an option to ‘override global’ checkbox. If it’s not checked then it doesn’t show any settings (maybe with greyed out / non-changeable list of those settings). If it is then it is a replica of the global settings that it could override, that are then editable.

And are we going to separate the UI at all for the two types of global settings?

Sounds like a great improvement though, along with all the other stuff it looks like people have been up to with security and catalog scalability, to make it so you can have a system of geoservers with a variety of configurations that aren’t tied to standing up particular VM’s. A major step forward for GeoServer.

On Wed, Dec 14, 2011 at 8:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Already taken :slight_smile: Or are you implying that all the settings just get rolled into the workspace interface?

On Wed, Dec 14, 2011 at 11:37 PM, David Winslow <dwinslow@anonymised.com> wrote:

How about:

“WorkspaceInfo”

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

On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

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

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

10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

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

7

Yeah, basically the idea is to follow the same path as this proposal in which we made it possible to override service configuration per workspace.

http://geoserver.org/display/GEOS/GSIP+66±+Workspace+Local+Services

Basically the per workspace configuration stuff would show up on the specific edit page for that workspace. Here are some screen shots of what i had in mind:

https://skitch.com/jdeolive/gtxqs/geoserver-edit-workspace
https://skitch.com/jdeolive/gtxqu/geoserver-edit-workspace-1

-Justin

On Thu, Dec 15, 2011 at 1:39 AM, Chris Holmes <cholmes@anonymised.com> wrote:

Do you have a UI in mind for this? Like where does one make these settings?

Thing that would make the most sense for me would something like have the ‘workspace’ page have an option to ‘override global’ checkbox. If it’s not checked then it doesn’t show any settings (maybe with greyed out / non-changeable list of those settings). If it is then it is a replica of the global settings that it could override, that are then editable.

And are we going to separate the UI at all for the two types of global settings?

Sounds like a great improvement though, along with all the other stuff it looks like people have been up to with security and catalog scalability, to make it so you can have a system of geoservers with a variety of configurations that aren’t tied to standing up particular VM’s. A major step forward for GeoServer.

On Wed, Dec 14, 2011 at 8:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Already taken :slight_smile: Or are you implying that all the settings just get rolled into the workspace interface?

On Wed, Dec 14, 2011 at 11:37 PM, David Winslow <dwinslow@anonymised.com501…> wrote:

How about:

“WorkspaceInfo”

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

On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

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

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

10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

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

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

8

On Thu, Dec 15, 2011 at 12:19 AM, Justin Deoliveira <jdeolive@anonymised.com…1501…> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

It’s been so long since we named something www, we should give it a go again :slight_smile:

Judging from your screenshots later in the thread WorkspaceSettingsInfo might be a
good fit.
At the same time, that’s stuff one can configure also globally, so it’s not only
workspace. SettingsInfo could be a way, or maybe we could split them by
topic and have OrganisationInfo and so on.

I had a go into GeoServer info and I see things that are obvious candidates
(such as ContactInfo) and things that are less.
For example take proxyBaseURL, in a multi-tenancy/Service provider scenario
one might have a single GeoServer for many organisations, each one having
its own public first or second level domain, some might want to use OGC
standard schema references and other not, each one might need to use
a different default charset and so on.

Some of these are organization related (OrganizationInfo?) others are
settings that affect all the services (base urls, we could call those
ServicesInfo?) and so on, others are clearly global such as the JAI
settings (since they affect the JAI singleton) so they have to stay
in GeoServerInfo

Ok, enough ranting for now :-p

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

9

Yes, I was implying that it would make some sense to put workspace-local settings in the WorkspaceInfo interface. It’s not like that interface is particularly overloaded (in the colloquial sense) right now, and the naming seems to make sense.

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

On Wed, Dec 14, 2011 at 8:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Already taken :slight_smile: Or are you implying that all the settings just get rolled into the workspace interface?

On Wed, Dec 14, 2011 at 11:37 PM, David Winslow <dwinslow@anonymised.com> wrote:

How about:

“WorkspaceInfo”

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

On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

Candidates welcome. Thanks.

-Justin

On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

The subject is kind of an oxymoron but I am tasked with continuing on some of the workspace local / virtual service configuration work. The last chunk of work made it possible to configure services separately per workspace. The next chunk involves making the global config configurable per workspace.

Now, one has to ask the question if this makes sense at all, since many of the options are indeed global, and would not / could not be configured local to a workspace. For instance, the jai settings. But some settings might be configurable per workspace, like contact info, verbose exception reporting, etc… so i wanted to start some discussion to try and get an idea on how to proceed.

The first possibility would be to refactor the GeoServerInfo class into two parts, those settings that could be workspace specific, and those that could not. I haven’t thought too much about how this would look but it wold be a significant change to the catalog api, meaning lots of updating of client code.

The second possibility is to follow the same sneaky approach we use for the services and that is return a different GeoServerInfo object based on the local workspace thread local in play. The issue I see here is again the settings that are truly global. A possible approach here could be to wrap the workspace local GeoServerInfo objects in a proxy or wrapper that makes certain fields read only, or perhaps hides them all together. In the UI we could hid those fields all together.

Thoughts/opinions?

I’d go for the split between what’s really global (jai, logs) and what it makes
sense to configure once per workspace (point of contact and the like).
I understand and agree it’s going to take API changes, but it also sets a clear
path forward for the future.
Javadocs should explain clearly who does what so that when adding a new
“global” option one can choose wheter to make it “per worskpace global”
or “universally global”

My 2 cents :slight_smile:

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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

Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

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

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

10

On Thu, Dec 15, 2011 at 7:45 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Dec 15, 2011 at 12:19 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Andrea, I think this way is much cleaner as well. And we can minimize api impact by keeping all the methods on GeoServerInfo intact (but deprecated) for now.

Question about names. What should the new interface be called?

SettingsInfo
LocalSettingsInfo
ServiceSettingsInfo
WWWSettingsInfo

It’s been so long since we named something www, we should give it a go again :slight_smile:

Judging from your screenshots later in the thread WorkspaceSettingsInfo might be a
good fit.
At the same time, that’s stuff one can configure also globally, so it’s not only
workspace. SettingsInfo could be a way, or maybe we could split them by
topic and have OrganisationInfo and so on.

Yeah, while it makes some sense this new interface is going to accessible from the global GeoServerInfo as well… so it can be global or workspace specific as you say.

For now I have gone with SettingsInfo… but am open to something different.

I had a go into GeoServer info and I see things that are obvious candidates
(such as ContactInfo) and things that are less.
For example take proxyBaseURL, in a multi-tenancy/Service provider scenario
one might have a single GeoServer for many organisations, each one having
its own public first or second level domain, some might want to use OGC
standard schema references and other not, each one might need to use
a different default charset and so on.

Yeah, the form in that screen shot was not complete. MOre stuff is pulled in. Here is the entire interface.

https://github.com/jdeolive/geoserver/blob/workspace_settings/src/main/src/main/java/org/geoserver/config/SettingsInfo.java

Basically the only things not pulled into it are:

  • jai
  • coverageAccess
  • updateSequence
  • adminUsername/adminPassword
  • featureTypeCacheSize
  • xmlPostRequestLogBufferSize
  • globalServices

A case could be made for some of them… maybe updateSequence?

Some of these are organization related (OrganizationInfo?) others are
settings that affect all the services (base urls, we could call those
ServicesInfo?) and so on, others are clearly global such as the JAI
settings (since they affect the JAI singleton) so they have to stay
in GeoServerInfo

Ok, enough ranting for now :-p

Thanks for the feedback!

Cheers
Andrea

–

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

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

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

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