Hi Chris,
Just on the Connection Pooling topic, I have commited the initial version of connection pooling for the Oracle data source. It should be completely interoperable with the PostGis data source as I did not need to use any Oracle specific code.
For Oracle documentation, the connection properties are:
dbtype - Must be "oracle" for the Oracle data source.
host - The machine which the Oracle instance is running on.
port - The port the Oracle instance is running on, default is 1521.
instance - The Oracle instance name, should be the same as the SERVICE ID.
user - The user to connect with.
passwd - the password to connect with.
table - The name of the Oracle table to load the features from, must have an SDO_GEOMETRY column.
You probably should also have note in there saying that classes12.jar and sdoapi.jar are both required to be in the classpath.
If you need more info that that let me know. A point release announcing Oracle support would be great.
BTW, the Oracle datasource now supports full spatial filters in the DB, apart from the distance filters.
Sean
-----Original Message-----
From: Chris Holmes [mailto:cholmes@anonymised.com]
Sent: Saturday, 9 August 2003 9:49 AM
To: Jody Garnett
Cc: geoserver-devel@lists.sourceforge.net
Subject: [Geoserver-devel] Re: just committed updated geoserverOn Fri, 8 Aug 2003, Jody Garnett wrote:
> Hey Chris -
>
> My first thought is we should move this interesting conversation to
> the devel list.
> (But you might not want to get everyones hopes upSo
I'll let you
> forward this email if you want...
Certainly. I'm fine with getting people's hopes up as long
as we can meet them, which I'm sure we can.> >>Can you run the GeoServer release schedule past me? Are we just
> >>waiting for geotools2 now?
> >>
> So Near as I can tell we are aiming for an End of September
1.0 beta.
> With the following general todo list...
>
> Required for 1.0:
> - Connection Pooling (JDBC 3.0 Seems to provide support hooks)
> - I "released" geotools2 jar
>
> Wishes for 1.0:
> - multiple namespace support hacks for GMLBuilder or
GMLProducer with
> proper namespace support
> - Shapefile based Unit Tests
> - Code Clean up
Also
- Full filtering with postgis's new geos code. It looks
like postgis might be going to 1.0 pretty soon? Even if it
doesn't, it'd be nice to do overlaps and intersects and all
the spatial filtering in the db, instead of creating geotools
features and filtering out with jts.
- more examples of writing queries
- A new GeoClient release? (this one's out of my hands though)> Defer to 1.1
> - GMLProducer with complex features support
> (will require a Datasource with complex features support)
> - Database backed Locking
> - GMLProducer with
(or later) - integrated WMS>
>
> >>
> >>
> >I was aiming for 1.0 by the end of september. I'd to release it a
> >bit after geotools, and there's a few more issues to resolve.
> >Connection Pooling is vital for 1.0 in my opinion. I'd _like_ to
> >move the gml generation from GMLBuilder, which is officially the
> >hackiest class ever, to the new gml producer. But the nice thing
> >about gml builder is that it _works_, even if it's not
pretty. There
> >are however two things that it just can not handle. One
is multiple
> >namespaces in the same response, which I guess isn't necessary for
> >1.0, since we're already doing better namespace handling than the
> >spec author's wfs. But I would like it fixed, since if someone
> >requests cdf:Nulls and cgf:Lines then the namespace for
one will be
> >wrong, as the prefixes and namespaces aren't declared correctly.
> >Fixing that in gml builder is possible, but would require
even more
> >hacks, which I don't really want to do, as it'd take quite
a bit of
> >testing and figuring out. The other thing that GMLBuilder
just can't
> >handle at all is complex features. I was going to try to motivate
> >these before 1.0, but I'm not sure if I'll have time. The new gml
> >producer should make it pretty easy to do, but then we
also need to
> >figure out a datasource that'll support it, a schema for
foreign keys
> >in postgis or something. I think complex features will
also require
> >some work on filters as well. So I may hold that off
until after the
> >1.0 release. I also need to set up an oracle database so
_I_ can test Sean's work and write some documentation for using it.
> >
> I may be able to provide some help there - I will be looking at his
> work in september and running some tests at this end. Of course I
> will be trying to add locking support but that is another story.
That'd be great. I have to install an os on a computer, and
then install oracle, which by the looks of it isn't the most
fun install out there, and then figure out spatial stuff.
The main thing is to write up a section in the documentation
of how to use the oracle datasource, what params are needed
in info.xml. If you'd like to do that Sean I could announce
oracle support on the site, we could put out another point
release. I've just been meaning to test it myself and write
it up, but haven't gotten to it.> > And I'd also like to finish a Dispatcher servlet that
will allow
> >users to post to there and use the same root address. So that's
> >basically what's on my plate for 1.0, and I'd
> >
> I am not sure I understand the dispatcher servlet
The idea is to provide one access point to clients. By the
looks of it some try to send all their requests to the same
url, as if it's a cgi script, even though our capabilities
document states where they should be.
There was an email a bit ago called 'Connecting to GeoServer
through FME viewer...' awhile back, where he was saying that
fme would ask for requests like
http://server/geoserver/GetCapabilities?request=GetCapabilities
and then
http://server/geoserver/GetCapabilities?request=GetFeature&typ
eName=water.And of course geoserver croaked on it. The dispatcher would allow:
http://server/geoserver/Dispatcher?request=GetCapabilities
and then
http://server/geoserver/Dispatcher?request=GetFeature&typeName=water.to work just fine, as it figures out the request and forwards
it along to the appropriate servlet. I did an initial fix in
cvs, but the guys who originally wrote it never got back to
me, so I'm not sure if it's working, and I need to set up a
windows box to test out the FME viewer. It should be pretty
easy to finish up, I just need to add the transaction
operations and fix up the post requests.> - one idea I have had
> is a WFS DataSource which would allow the use of GeoServer
as a Proxy
> and allow geotool2 based clients an easy communication path.
Yes, I've been kicking around similar ideas for awhile.
There's lots of fun things in that vein. Another thing that
would be nice is to write a geotools interface that is just
like a wfs, that would handle figuring out which actual
datasources to send it to, handle all the locking and
whatnot. Basically to move all the data logic to geotools,
and to have geoserver be even thinner, just handle the
translation of xml to java objects and back. It'll also be
cool if we ever integrate with deegree, since then we can
just kick features back and forth between our servers as
well. But yes, go forth and code up the Proxy if you feel like it.> >also like to do some massive code clean-up, as a lot of
geoserver is
> >pretty messy and contains some coding practices of mine and Rob's
> >that
> just aren't the best. I guess it's not as important as
geotools, as
> it's not a toolkit, but I'd still like clean nice code before 1.0.
> The other piece of clean-up is unit tests, which I can
actually do now
> that I've got shapefile support in (we don't have a public postgis
> instance, and I didn't want to require sql script creation, but all
> responses need a db backend).
> >
> >
> >
> >>>I'm also contemplating splitting geotools.jar up into
it's components for the geoserver cvs, but I'm not sure about
it. Ok, I gotta get outta here and get some food, as I'm starving.
> >>>
> >>>
> >> would try to refrain - just for the sake of your
installation process. It is easier for your user's to confirm
one version number than five.
> >>
> >>
> >Yeah, you're right. Though I am still contemplating
having seperate ones for oracle and shapefile. This is
partially due to laziness, however, as then I don't have to
figure out my weird problem with shapefile right now, since
it works if it's a seperate jar. It'd also nicely emphasize
the pluggable nature of datasources, that if one writes the
geotools datasource right it can just be plugged right in.
So it'd be core/defaultcore/gml/filter/postgis and maybe
resources (I need to work out logger issues, I don't really
like the updated geotools one) in geotools.jar, and
shapefile, oracle and eventually arcsde, mysql, ect. on their own.
> >
> I was looking over the code - the shapefile jar provides a manafest
> that registers the plugin for the DatasourceFinder class. How is
> registration handled when the shapefile datasource is
included in the
> geoserver jar?
When rolling my own jar I just make a new
org.geotools.datasourceSpi (or whatever the file is called)
in the manifest, with entries for the postgis and the
shapefile factories. And it worked fine before the geotools
upgrade, but now gives me problems. For a bit I couldn't get
either postgis or shapefile to work, but now postgis will
work, shapefile is just proving tricky. I may be writing the
line wrong or something, I just need to play with it some more.Chris
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites
including Data Reports, E-commerce, Portals, and Forums are
available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet
_072303_01/01
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel