Hi,
I would like to hear comments on:
http://jira.codehaus.org/browse/GEOS-853
since in 1.4.0 and 1.5.0beta
absolute file path handling is broken (again...).
And I'm speaking about shapefiles, not about coverages here 
Cheers
Andrea
Your fix sounds good.
A last final change was made to 1.4 before release to fix another issue that expected the data to be under [data_dir]/data/
I will check if I ported it over to 1.5 (might of forgotten in the haste to get 1.4.0 out) and if it isn't there I will add it in.
What I would also like to see is error messages come up when the person hits submit for the datastore, instead of waiting all the way until the feature type editor.
Also a descriptive note in the UI when the person is adding a datastore that will print out the current datastore location and describe a couple of relative paths.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Hi,
I would like to hear comments on:
http://jira.codehaus.org/browse/GEOS-853since in 1.4.0 and 1.5.0beta
absolute file path handling is broken (again...).
And I'm speaking about shapefiles, not about coverages hereCheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Brent Owens ha scritto:
Your fix sounds good.
A last final change was made to 1.4 before release to fix another issue that expected the data to be under [data_dir]/data/
I will check if I ported it over to 1.5 (might of forgotten in the haste to get 1.4.0 out) and if it isn't there I will add it in.What I would also like to see is error messages come up when the person hits submit for the datastore, instead of waiting all the way until the feature type editor.
Also a descriptive note in the UI when the person is adding a datastore that will print out the current datastore location and describe a couple of relative paths.
Yup, all nice ideas, especially not having to wait, one thing that
made me mad with coverages too.
Open the jira issues for these 
Cheers
Andrea
It sounds like you have this issue under control, but while on the topic
I will bring it up.
On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.
Anyways, the way it works is that a resource loader is created in the
container at startup and configured with multiple paths to load data
from. The primary one being the data directory. Similar to how system
paths work when you type commands at the command line.
So when a class needs to load a file:
class MyClass {
GeoServerResourceLoader loader;
public MyClass( GeoServerResourceLoader loader ) {
this.loader = loader;
}
public void foo() {
File file = loader.find( "foo.shp" );
}
}
Which is kind of nice because you only have to worry about paths once.
If my memory servers me correct there are a couple of places in
GeoServer where file paths are played with. I even remember one checking
for the existance of the work "data" in the path!!
Also, I found this to be a nice way to stay backwards compatable with
the old data directory style. Essentially just adding two locations (
WEB-INF, and the set data directory ) for loading resources.
Anyways, excuse the rant :). Feel free to comment or just call me crazy.
-Justin
Andrea Aime wrote:
Brent Owens ha scritto:
Your fix sounds good.
A last final change was made to 1.4 before release to fix another issue
that expected the data to be under [data_dir]/data/
I will check if I ported it over to 1.5 (might of forgotten in the haste
to get 1.4.0 out) and if it isn't there I will add it in.What I would also like to see is error messages come up when the person
hits submit for the datastore, instead of waiting all the way until the
feature type editor.
Also a descriptive note in the UI when the person is adding a datastore
that will print out the current datastore location and describe a couple
of relative paths.Yup, all nice ideas, especially not having to wait, one thing that
made me mad with coverages too.
Open the jira issues for theseCheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45ad00e5267398365517736!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
It sounds like you have this issue under control, but while on the topic
I will bring it up.
On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.
Anyways, the way it works is that a resource loader is created in the
container at startup and configured with multiple paths to load data
from. The primary one being the data directory. Similar to how system
paths work when you type commands at the command line.
So when a class needs to load a file:
class MyClass {
GeoServerResourceLoader loader;
public MyClass( GeoServerResourceLoader loader ) {
this.loader = loader;
}
public void foo() {
File file = loader.find( "foo.shp" );
}
}
Which is kind of nice because you only have to worry about paths once.
If my memory servers me correct there are a couple of places in
GeoServer where file paths are played with. I even remember one checking
for the existance of the work "data" in the path!!
Also, I found this to be a nice way to stay backwards compatable with
the old data directory style. Essentially just adding two locations (
WEB-INF, and the set data directory ) for loading resources.
Anyways, excuse the rant . Feel free to comment or just call me crazy.
-Justin
Andrea Aime wrote:
Brent Owens ha scritto:
Your fix sounds good.
A last final change was made to 1.4 before release to fix another issue
that expected the data to be under [data_dir]/data/
I will check if I ported it over to 1.5 (might of forgotten in the haste
to get 1.4.0 out) and if it isn't there I will add it in.What I would also like to see is error messages come up when the person
hits submit for the datastore, instead of waiting all the way until the
feature type editor.
Also a descriptive note in the UI when the person is adding a datastore
that will print out the current datastore location and describe a couple
of relative paths.Yup, all nice ideas, especially not having to wait, one thing that
made me mad with coverages too.
Open the jira issues for theseCheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,45ad00e5267398365517736!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
It sounds like you have this issue under control, but while on the topic
I will bring it up.On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.
Oohh, look, a central place to handle directory issues instead of some
4-5 ones in our existing code base (yeah, there are that many... there
were 2 but WCS replicated them). I told you OWS4 has the effect of
making people stop working on trunk :-p
Anyways, the way it works is that a resource loader is created in the
container at startup and configured with multiple paths to load data
from. The primary one being the data directory. Similar to how system
paths work when you type commands at the command line.
Ok, so one way would be to add the data directory and the "root", that
is, don't prefix data with anything.
So when a class needs to load a file:
class MyClass {
GeoServerResourceLoader loader;
public MyClass( GeoServerResourceLoader loader ) {
this.loader = loader;
}public void foo() {
File file = loader.find( "foo.shp" );
}}
Which is kind of nice because you only have to worry about paths once.
If my memory servers me correct there are a couple of places in
GeoServer where file paths are played with. I even remember one checking
for the existance of the work "data" in the path!!
Indeed you're right :-(, only that now "data" is gone, but there are 4 places doing the path mapping dance.
Cheers
Andrea
Very nice, I like it a lot. Could be cool to make it easy for people to define more paths where to look. So they could just point it at directories where lots of their data is stored.
Someday I do want to bring the concept of the DirectoryDataStore. DavidZ implemented one, but I don't know what happened to it. But we should have a default directory that people don't have to define additional datastores for, they just define featureTypes.
(yes, I'm way behind on my GeoServer email).
Chris
Justin Deoliveira wrote:
It sounds like you have this issue under control, but while on the topic
I will bring it up.On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.Anyways, the way it works is that a resource loader is created in the
container at startup and configured with multiple paths to load data
from. The primary one being the data directory. Similar to how system
paths work when you type commands at the command line.So when a class needs to load a file:
class MyClass {
GeoServerResourceLoader loader;
public MyClass( GeoServerResourceLoader loader ) {
this.loader = loader;
}public void foo() {
File file = loader.find( "foo.shp" );
}}
Which is kind of nice because you only have to worry about paths once.
If my memory servers me correct there are a couple of places in
GeoServer where file paths are played with. I even remember one checking
for the existance of the work "data" in the path!!Also, I found this to be a nice way to stay backwards compatable with
the old data directory style. Essentially just adding two locations (
WEB-INF, and the set data directory ) for loading resources.Anyways, excuse the rant :). Feel free to comment or just call me crazy.
-Justin
Andrea Aime wrote:
Brent Owens ha scritto:
Your fix sounds good.
A last final change was made to 1.4 before release to fix another issue that expected the data to be under [data_dir]/data/
I will check if I ported it over to 1.5 (might of forgotten in the haste to get 1.4.0 out) and if it isn't there I will add it in.What I would also like to see is error messages come up when the person hits submit for the datastore, instead of waiting all the way until the feature type editor.
Also a descriptive note in the UI when the person is adding a datastore that will print out the current datastore location and describe a couple of relative paths.Yup, all nice ideas, especially not having to wait, one thing that
made me mad with coverages too.
Open the jira issues for theseCheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Andrea Aime wrote:
Justin Deoliveira ha scritto:
It sounds like you have this issue under control, but while on the topic
I will bring it up.On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.Oohh, look, a central place to handle directory issues instead of some
4-5 ones in our existing code base (yeah, there are that many... there
were 2 but WCS replicated them). I told you OWS4 has the effect of
making people stop working on trunk :-p
?? How did WCS replicate them? Can we consolidate these back to 2?
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
It sounds like you have this issue under control, but while on the topic
I will bring it up.On the ows4 branch I took a bit of a different approach to loading
resources like file. Instead of assuming a central data directory and
appending paths to it, a class ( GeoServerResourceLoader ) is used. In
the beginning it was an extension of springs "ResourceLoader" interface
but then I realized there was not much benefit to doing so.Oohh, look, a central place to handle directory issues instead of some
4-5 ones in our existing code base (yeah, there are that many... there
were 2 but WCS replicated them). I told you OWS4 has the effect of
making people stop working on trunk :-p?? How did WCS replicate them?
Copy and paste
Can we consolidate these back to 2?
Already did, if I'm not mistaken we're back to 1. GeserverDataDir has now a method to locate a data file. This one could be expanded to
support multiple data directories too, but thinking about how people
used to organize shapefiles on disk (a folder for each physical location) I'd bet my money on the DirectoryDataStore, where the
namaspace could be (mis)used to identify the location as well.
Cheers
Andrea
Chris Holmes ha scritto:
Very nice, I like it a lot. Could be cool to make it easy for people to define more paths where to look. So they could just point it at directories where lots of their data is stored.
Not hard to do, but indeed I think it would be nicer to do whatever
is needed to use the DirectoryDataStore instead.
Someday I do want to bring the concept of the DirectoryDataStore. DavidZ implemented one, but I don't know what happened to it. But we should have a default directory that people don't have to define additional datastores for, they just define featureTypes.
Yep, very much true.
The DirectoryDataStore is still there btw, I think nobody among us tried
it out. I'll give a shot to it and see how it works.
Cheers
Andrea