R: [Geoserver-devel] Multiple GeoServers

>>On Feb 11, 2006, at 8:44 PM, Stephen Taylor wrote:
>>
>>
>>>Hello all,
>>>
>>>Is it currently possible to run more than one GeoServer on the same
>>>machine, with different datastores and different levels of
>>>functionality
>>>(for example, one server with 'Basic' functionality and one with
>>>transactions enabled)? I can't seem to find any mention of
this in the
>>>documentation.
>>>
>>>Thanks very much,
>>>
>>>Stephen Taylor

It's really not a matter of GeoServer, but of the container used for it.
You should look in the documentation for Tomcat, if you like that container,
and see what it says about running two versions of the same WAR.
There's nothing special in GeoServer that makes it different from any other
WAR archive you can deploy in a container.
From your question it seems that you only want to deploy two different
instances
of the same version of GeoServer and not two different versions, like having
a 1.3.0 and a 1.2.0 running inside the same container. That would have been
more difficult.
The only thing that could be a problem are singletons, and I can't rembember
if there are any in GeoServer. Maybe DataStores/Transaction can soffer, but
I'm not sure.
If this is the case you have to ensure that the container runs the two
instances inside
two different JVMs, or at least that it uses two different class loaders.
Also watch out for the file commons-logging.jar because it may cause
conflicts between
the one present inside GeoServer and the one installed in Tomcat.
Having GeoServer packaged inside a compressed WAR archive is very handy, but
when it comes
to advanced deployments it can be better to unpack it in a WAR directory,
so you can modified and/or add/remove files/libraries with much more ease.

Bye
Paolo Rizzi

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.

P.Rizzi Ag.Mobilità Ambiente wrote:

of the same version of GeoServer and not two different versions, like having
a 1.3.0 and a 1.2.0 running inside the same container. That would have been
more difficult.
The only thing that could be a problem are singletons, and I can't rembember
if there are any in GeoServer. Maybe DataStores/Transaction can soffer, but
I'm not sure.
  

GeoServer puts all its "singletons" in the application context - so we should be good here. If you find anything
that breaks let us know.

Jody

Paolo,

I get your drift … the answer is Yes, there could potnetially be problems with multiple Geoserver instances affecting each other. Singletons are used within Geotools (some of the Factory code used to … the XML code definititely does). This could create some issues with both shared transactions, shared schema parses (naming conflicts) … or even shared DataStore instances (SDE connections are singletons too I think).

Hope this helps start your list … sorry for the bad news,

David

On 2/14/06, Jody Garnett <jgarnett@anonymised.com> wrote:

P.Rizzi Ag.Mobilità Ambiente wrote:

of the same version of GeoServer and not two different versions, like having
a 1.3.0 and a 1.2.0 running inside the same container. That would have been
more difficult.
The only thing that could be a problem are singletons, and I can’t rembember
if there are any in GeoServer. Maybe DataStores/Transaction can soffer, but
I’m not sure.

GeoServer puts all its “singletons” in the application context - so we
should be good here. If you find anything
that breaks let us know.

Jody


This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
[http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642](http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642)


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

David Zwiers wrote:

Paolo,

I get your drift ... the answer is Yes, there could potnetially be
problems with multiple Geoserver instances affecting each other.
Singletons are used within Geotools (some of the Factory code used to
... the XML code definititely does). This could create some issues with
both shared transactions, shared schema parses (naming conflicts) ... or
even shared DataStore instances (SDE connections are singletons too I
think).

Hi all

I am not sure if I agree that this is a problem, at least not in tomcat.

In tomcat there is a hierarchy of classloaders. A static variable is
only available in the current classloader and all it's children classloader.

Each context have it's own classloader, so neither the classpath or the
static intances is shared unless they have been set in a common parent
classloader.

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

Using the jboss unified classloader might be a problem in jboss, but you
can either change to use the tomcat classloader, or scope the classpath
using your jboss-web.xml
I have about zero experience with jetty, but I assume it is similar to
the two mentioned above.

So geoserver/ and geoserver2/ does not share static variables or
jar/classes added in WEB-INF/lib.

I hope I haven't missed anything vital in the discussion.

Magne

Hope this helps start your list ... sorry for the bad news,

David

On 2/14/06, *Jody Garnett* <jgarnett@anonymised.com
<mailto:jgarnett@anonymised.com>> wrote:

    P.Rizzi Ag.Mobilità Ambiente wrote:
    > of the same version of GeoServer and not two different versions,
    like having
    > a 1.3.0 and a 1.2.0 running inside the same container. That would
    have been
    > more difficult.
    > The only thing that could be a problem are singletons, and I can't
    rembember
    > if there are any in GeoServer. Maybe DataStores/Transaction can
    soffer, but
    > I'm not sure.
    >
    GeoServer puts all its "singletons" in the application context - so we
    should be good here. If you find anything
    that breaks let us know.

    Jody

    -------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc. Do you grep through
    log files
    for problems? Stop! Download the new AJAX search engine that makes
    searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
    http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 <http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642>
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel
    <https://lists.sourceforge.net/lists/listinfo/geoserver-devel&gt;

Hi all,

I'm new to GeoServer and would like to use it, or modify it, to handle
circular-arc and other non-standard geometries imported from an Oracle
database. My knowledge of the codebase is so far slight, so I have been
unable to find which classes, if any, in the source code for GeoServer
and/or GeoTools would need to be modified in order to transform circular-arc
data so that GeoTools/GeoServer can understand it. I'm pretty sure that
FeatureReader must be calling classes that transform data, but don't know how
exactly.

The geometry data in a typical feature/row from my data is

SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 4, 4, 1, 2, 1, 3, 2,
2, 7,
2, 2, 11, 2, 1), SDO_ORDINATE_ARRAY(213384.927, 599385.252, 213286.163,
599553.
117, 213271.298, 599575.081, 213253.785, 599594.997, 213210.193,
599656.786, 213
186.753, 599728.679, 213138.458, 599899.775))

where the first triple '1, 4, 4' of the SDO_ELEM_INFO_ARRAY indicates a
'compound line-string', i.e., a line string comprising both straight line
segments and circular arcs. The second '4' in this triple indicates that the
compound line-string has four sub-elements, the triples for which in the same
array are '1, 2, 1', '3, 2, 2', '7, 2, 2', and '11, 2, 1' respectively: a
triple of the form 'X, 2, 1' indicates a line-string of line segments, and
the
form 'X, 2, 2' indicates a connected sequence of circular arcs.

What I need to do is transform, within GeoServer or GeoTools, the compound
line-string into an approximately equivalent line-string comprised
entirely of
line segments, with no circular arcs. As far as I know, this can be achieved
simply by replacing the SDO_ELEM_INFO_ARRAY with a single triple (1, 2, 1).

I suspect that code for such a transformation already exists within GeoTools
or GeoServer, but I've spent several days searching through the design
documentation and source code, to no avail. I would be very grateful to
anyone
who can point me to the appropriate class - and they would also be hastening
adoption of open-source tools by the Australian ACT government!

Thanks very much in advance,

Stephen Taylor

Ok, I can point you at the code that does the reading of Oracle geometries, but I'm not sure that I quite understand what you want to do...

The class that does the geometry reading is: http://svn.geotools.org/geotools/trunk/gt/plugin/oraclespatial/src/org/geotools/data/oracle/attributeio/SDOAttributeIO.java
it currently uses:
http://svn.geotools.org/geotools/trunk/gt/plugin/oraclespatial/src/org/geotools/data/oracle/sdo/SDO.java
which was written by refractions to replace Oracle's SDO code. There is also an older version that just uses the Oracle SDO code.

So you may be able to modify that class to also read the compound stuff.

Though if you're doing that, the better route might be to improve JTS to do so, if it doesn't already. David, does JTS make any attempt to handle circular-arc stuff? Or does it just do the same things gt2 does? I'm pretty sure we're planning on having the oracle data reading be done by JTS directly. (when we do that port it might make sense to use packed coordinate sequences for better speed?)

Stephen, the one part of your post that confuses me is:

> What I need to do is transform, within GeoServer or GeoTools, the compound
> line-string into an approximately equivalent line-string comprised
> entirely of
> line segments, with no circular arcs. As far as I know, this can be achieved
> simply by replacing the SDO_ELEM_INFO_ARRAY with a single triple (1, 2, 1).

How are you proposing going about replacing the SDO_ELEM_INFO_ARRAY? Is there a call you can make to oracle to do it? Or are you looking for code that makes the arc in GeoTools and then turns it in to line strings? I'm pretty sure the latter does not exist. The former is actually kind of tricky, since there's not a straightforward mechanism to make such calls to Oracle.

I could be totally wrong, but it also seems to me that if you are just replacing the SDO_ELEM_INFO_ARRAY with 1,2,1, that it wouldn't very closely approximate the curves. Like it would just draw straight lines between the various points, instead of coming up with shorter lines that closer approximate the arc. But I also could just be understanding things completely wrong. It just seems like you'd need a function of some sort to do the transform in oracle, instead of just replacing the element info array...

Chris

staylor@anonymised.com wrote:

Hi all,

I'm new to GeoServer and would like to use it, or modify it, to handle
circular-arc and other non-standard geometries imported from an Oracle
database. My knowledge of the codebase is so far slight, so I have been
unable to find which classes, if any, in the source code for GeoServer
and/or GeoTools would need to be modified in order to transform circular-arc
data so that GeoTools/GeoServer can understand it. I'm pretty sure that
FeatureReader must be calling classes that transform data, but don't know how
exactly.

The geometry data in a typical feature/row from my data is

SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 4, 4, 1, 2, 1, 3, 2,
2, 7,
2, 2, 11, 2, 1), SDO_ORDINATE_ARRAY(213384.927, 599385.252, 213286.163,
599553.
117, 213271.298, 599575.081, 213253.785, 599594.997, 213210.193,
599656.786, 213
186.753, 599728.679, 213138.458, 599899.775))

where the first triple '1, 4, 4' of the SDO_ELEM_INFO_ARRAY indicates a
'compound line-string', i.e., a line string comprising both straight line
segments and circular arcs. The second '4' in this triple indicates that the
compound line-string has four sub-elements, the triples for which in the same
array are '1, 2, 1', '3, 2, 2', '7, 2, 2', and '11, 2, 1' respectively: a
triple of the form 'X, 2, 1' indicates a line-string of line segments, and
the
form 'X, 2, 2' indicates a connected sequence of circular arcs.

What I need to do is transform, within GeoServer or GeoTools, the compound
line-string into an approximately equivalent line-string comprised
entirely of
line segments, with no circular arcs. As far as I know, this can be achieved
simply by replacing the SDO_ELEM_INFO_ARRAY with a single triple (1, 2, 1).

I suspect that code for such a transformation already exists within GeoTools
or GeoServer, but I've spent several days searching through the design
documentation and source code, to no avail. I would be very grateful to
anyone
who can point me to the appropriate class - and they would also be hastening
adoption of open-source tools by the Australian ACT government!

Thanks very much in advance,

Stephen Taylor

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com