Re: [Geoserver-devel] linux start scripts
Justin Deoliveira ha scritto:
> Well I think it makes sense to put the script somewhere in svn...
> probably along side the regular startup.sh script.
Yeah, I also believe it would be nice to have those scripts
end up in the -bin release packages, it's something I've
seen in other software as well and it's handy ("if you need
to start it as a service use one of this scripts").
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3949) Add New Store causes NullPointerException
Add New Store causes NullPointerException - Key: GEOS-3949 URL: http://jira.codehaus.org/browse/GEOS-3949 Project: GeoServer Issue Type: Bug Components: Wicket UI Affects Versions: 2.0.1 Environment: Mac OS X 10.6 Reporter: Tom MacWright Assignee: Andrea Aime Attachments: geoserver_traceback.txt Creating a new Web Feature Server Store in a workspace called 'drupal' and with the namespace 'http://drupal.org/project/wfs' causes a NullPointerException that repeats regardless of what actions precede it. Traceback attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3948) Improve resource name validation for RESTConfig
Improve resource name validation for RESTConfig --- Key: GEOS-3948 URL: http://jira.codehaus.org/browse/GEOS-3948 Project: GeoServer Issue Type: Improvement Components: REST Affects Versions: 2.0.1 Reporter: David Winslow Assignee: Andrea Aime As discussed in GEOS-3755, it would be useful for the RESTConfig service to raise an error instead of continuing when a request is made that would create a configuration that breaks GeoServer output. For example, naming a featuretype "i have spaces" would result in invalid XML output for various WMS and WFS requests. Attached is a patch that starts working on this by extending the validation done within CatalogImpl, but I think there's still room for discussion about how to implement this (could it share validation rules with the web ui somehow? does the validation need to happen in RESTConfig itself so that we can adjust names to get things working? etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Oracle Georaster support
Let me invite you as a blog contributor; accept the invite and try again. Jody On 07/05/2010, at 2:17 AM, christian.muel...@nvoe.at wrote: > You mean something like that > > http://geotoolsnews.blogspot.com/ > > Upps, I have never done this before :-) > > Anyways, its time to learn it. I have a google account, but I do not > see the geotools blog. > > For geoserver, the blog looks different, and I cannot login. > > > > > > Quoting Andrea Aime : > >> christian.muel...@nvoe.at ha scritto: >>> The imagemosaic-jdbc module adds Oracle Georaster support without >>> using an Oracle Specific API. No problems with the build process , >>> at runtime , only the oracle jdbc driver has to be in the class >>> path. >>> >>> Geoserver documentation is here >>> >>> http://docs.geoserver.org/stable/en/user/data/oraclegeoraster.html >>> >>> Geotools documentation is here >>> >>> http://docs.codehaus.org/display/GEOTDOC/Oracle+GeoRaster+Plugin >>> >>> Should I make an announcement on the user lists ? >> >> Imho it's worth a blog post :-) >> >> If you're shy you can create a draft of it, send it to the list, >> and we can probably review and post it. >> Otherwise we give you access, you create the blog post, someone >> reviews it, and then we publish it. >> >> Cheers >> Andrea >> >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. > > > > > This message was sent using IMP, the Internet Messaging Program. > > > > -- > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Oracle Georaster support
You mean something like that http://geotoolsnews.blogspot.com/ Upps, I have never done this before :-) Anyways, its time to learn it. I have a google account, but I do not see the geotools blog. For geoserver, the blog looks different, and I cannot login. Quoting Andrea Aime : > christian.muel...@nvoe.at ha scritto: >> The imagemosaic-jdbc module adds Oracle Georaster support without >> using an Oracle Specific API. No problems with the build process , >> at runtime , only the oracle jdbc driver has to be in the class >> path. >> >> Geoserver documentation is here >> >> http://docs.geoserver.org/stable/en/user/data/oraclegeoraster.html >> >> Geotools documentation is here >> >> http://docs.codehaus.org/display/GEOTDOC/Oracle+GeoRaster+Plugin >> >> Should I make an announcement on the user lists ? > > Imho it's worth a blog post :-) > > If you're shy you can create a draft of it, send it to the list, > and we can probably review and post it. > Otherwise we give you access, you create the blog post, someone > reviews it, and then we publish it. > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. This message was sent using IMP, the Internet Messaging Program. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Oracle Georaster support
christian.muel...@nvoe.at ha scritto: > The imagemosaic-jdbc module adds Oracle Georaster support without > using an Oracle Specific API. No problems with the build process , at > runtime , only the oracle jdbc driver has to be in the class path. > > Geoserver documentation is here > > http://docs.geoserver.org/stable/en/user/data/oraclegeoraster.html > > Geotools documentation is here > > http://docs.codehaus.org/display/GEOTDOC/Oracle+GeoRaster+Plugin > > Should I make an announcement on the user lists ? Imho it's worth a blog post :-) If you're shy you can create a draft of it, send it to the list, and we can probably review and post it. Otherwise we give you access, you create the blog post, someone reviews it, and then we publish it. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Oracle Georaster support
The imagemosaic-jdbc module adds Oracle Georaster support without using an Oracle Specific API. No problems with the build process , at runtime , only the oracle jdbc driver has to be in the class path. Geoserver documentation is here http://docs.geoserver.org/stable/en/user/data/oraclegeoraster.html Geotools documentation is here http://docs.codehaus.org/display/GEOTDOC/Oracle+GeoRaster+Plugin Should I make an announcement on the user lists ? This message was sent using IMP, the Internet Messaging Program. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] linux start scripts
Well I think it makes sense to put the script somewhere in svn... probably along side the regular startup.sh script. And yeah mentioning it in the documentation would be good. I would say the Linux installation section would probably be more appropriate than production section, but no strong opinion. -Justin On 5/6/10 3:11 AM, christian.muel...@nvoe.at wrote: > Hi, Lennart developped a geoserver start script for Ubunutu. I have > one for SUSE and I can make one for CentOS. > > Does it make sense to add these scripts to the sphinx doc, "running > geoserver in a production environment". > > > > > This message was sent using IMP, the Internet Messaging Program. > > > > -- > ___ > 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. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] First WMS cascading patch ready
Justin Deoliveira ha scritto: > Nice patch! Big but very clean. > > The only minor suggestion/note i have is that > WMSLayerINfoImpl.getWMSLayer() does a lot of work inline. The other > ResourceInfoImpl classes delegate out to ResourcePool for all resource > loading operations. It would be nice to follow that same pattern. > Especially if the proposal to make the catalog classes pure java beans > ever comes to light. I've updated the patch as you described, and also added in full support for REST Config mimicking (well, actually blatantly copying and adapting) the behavior of data stores and feature types. I also added the same level of testing as the rest of the rest code to the new resource. That made the patch grow quite a bit to a whopping 259k, but... oh well, at this point it's pretty much complete. The only thing that's actually missing is documentation, but I think I'll wait for the dust to settle before tacking that. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-3947) Black png output and gif errors for GeoTIFF coverages
Black png output and gif errors for GeoTIFF coverages - Key: GEOS-3947 URL: http://jira.codehaus.org/browse/GEOS-3947 Project: GeoServer Issue Type: Bug Affects Versions: 2.1.x Reporter: Alessio Fabiani Assignee: Simone Giannecchini -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Creating feature types from SQL queries: a plan for GeoServer
christian.muel...@nvoe.at ha scritto: > I do not insist on this proposal. > > Do we have something like a "resource pool callback" at the moment. There is a ResourcePool.Listener, but at the moment it provides only callbacks for resource disposal, not for resource creation. My plan was to increase that listener to allow post-creation callbacks, to configure the stores right after the pool generates them (which might happen on startup, but also any time the pool destroys them to make space in the caches) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Creating feature types from SQL queries: a plan for GeoServer
I do not insist on this proposal.
Do we have something like a "resource pool callback" at the moment.
I did a workaround, subclassing DB2DataStoreFactory and overriding
createDataStoreInternal(..), but this is nasty and I have to change
the geoserver configuration in the future.
Is there another possibility I have not discovered ?
Quoting Andrea Aime :
> christian.muel...@nvoe.at ha scritto:
>> I have an additional proposal. What about a plugin mechanism
>>
>> public interface VirtualTableProvider {
>> public Set createVirtualTables(Connection con)
>> throws SQLException
>> }
>>
>> having a dummy implementation returning an empty list.
>>
>> Of course, this means a new optional datastore param
>> "VirtualTableProviderClassName".
>>
>> I did something similar with the PregeneralizedDataStore. The
>> default implementation reads from an xml file, for my project I
>> created another plugin fetching this information from DB2.
>>
>> Opinions
>
> Something like this could be used at the datastore level, and yes,
> GeoServer could inject in a version that reads from its own catalog
> in order to still support GUI configuration of new types.
>
> We would still need a resource pool callback to inject in the
> virtual table provider. I'd prefer a setter in the jdbcdatastore
> class as opposed to a datastore parameter specifying a class,
> the latter is way too much convoluted.
>
> What I don't like about this option is that it makes using
> virtual tables harder for the gt2 programmer. The code would go
> from:
>
> store.addVirtualTable(virtualTable)
>
> to
>
> ((DefaultVirtualTableProvider)
> store.getVirtualTableProvider()).add(virtualTable)
>
> (I'm assuming the provider replaces the current vt handling,
> having both of them would be more confusing).
>
> If you want a plugin that reads from the database you could
> roll your own GeoSErver module that uses the above cited
> resource pool callback to configure your virtual tables.
> That might not suit your use case fully though, my guess
> is that you want your provider to make queries to the database
> every time it's asked for a virtual table, whilst what
> I'm suggesting would be a one off operation that would
> not react to changes in the underlying database.
>
> If you really want to go your way state that in a public
> proposal on the gt2 devel soon (I wanted to apply the
> existing virtual table patch, to trunk only, this week).
> I honestly don't like it much, but I will not vote it
> down either (a -0 position, don't like it, but not
> strongly opposed either).
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
This message was sent using IMP, the Internet Messaging Program.
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] linux start scripts
Hi, Lennart developped a geoserver start script for Ubunutu. I have one for SUSE and I can make one for CentOS. Does it make sense to add these scripts to the sphinx doc, "running geoserver in a production environment". This message was sent using IMP, the Internet Messaging Program. -- ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Creating feature types from SQL queries: a plan for GeoServer
christian.muel...@nvoe.at ha scritto:
> I have an additional proposal. What about a plugin mechanism
>
> public interface VirtualTableProvider {
> public Set createVirtualTables(Connection con)
> throws SQLException
> }
>
> having a dummy implementation returning an empty list.
>
> Of course, this means a new optional datastore param
> "VirtualTableProviderClassName".
>
> I did something similar with the PregeneralizedDataStore. The default
> implementation reads from an xml file, for my project I created
> another plugin fetching this information from DB2.
>
> Opinions
Something like this could be used at the datastore level, and yes,
GeoServer could inject in a version that reads from its own catalog
in order to still support GUI configuration of new types.
We would still need a resource pool callback to inject in the
virtual table provider. I'd prefer a setter in the jdbcdatastore
class as opposed to a datastore parameter specifying a class,
the latter is way too much convoluted.
What I don't like about this option is that it makes using
virtual tables harder for the gt2 programmer. The code would go
from:
store.addVirtualTable(virtualTable)
to
((DefaultVirtualTableProvider)
store.getVirtualTableProvider()).add(virtualTable)
(I'm assuming the provider replaces the current vt handling,
having both of them would be more confusing).
If you want a plugin that reads from the database you could
roll your own GeoSErver module that uses the above cited
resource pool callback to configure your virtual tables.
That might not suit your use case fully though, my guess
is that you want your provider to make queries to the database
every time it's asked for a virtual table, whilst what
I'm suggesting would be a one off operation that would
not react to changes in the underlying database.
If you really want to go your way state that in a public
proposal on the gt2 devel soon (I wanted to apply the
existing virtual table patch, to trunk only, this week).
I honestly don't like it much, but I will not vote it
down either (a -0 position, don't like it, but not
strongly opposed either).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
