Hi all,
I'm trying to import the other configurations into svn, making them
proper data dirs, and have them usable both inside the geoserver war
and as external data dirs at the same time.
The document at
http://docs.codehaus.org/display/GEOSDOC/GeoServer+Data+Directory
wants a flat directory layout:
data_dir:
- catalog.xml
- services.xml
- coverages\
- data\
- demo\
- featureTypes\
- plugins\
- styles\
- validation\
and then instructs people to prefix file:/data/ to have relative
paths... well, this is not how is it working at the moment...
Every path (no matter if it starts with the data dir or not)
will be concatenated against the data dir and if it
exists, it'll be considered as part of the data directory,
otherwise it will be used as absolute.
Shall we restore the documented behaviour?
If we do so, the default geoserver data dir will be back to being
<webapp>/data, not simply <webapp> (where <webapp> is the absolute
path to the deployed web application). We can then protect it
so that people cannot see its contents using a masking servlet
(I already have one).
Well, let me know, I have most of the work done, I just need to
make sure I'm not screwing up.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:1023,45c716eb114636309890654!
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I moved it up one level to avoid the confusion of describing the "data directory" (data_dir/data/) in the "data_directory" (data_dir/). So there would be one root data_dir, and under that the person can put their files wherever they want. But if that means we can't mask the contents of the directory, then maybe we should switch back to /data.
As for the UI specifying "file:data/", we can just update that again to reflect what it should be when we decide.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Hi all,
I'm trying to import the other configurations into svn, making them
proper data dirs, and have them usable both inside the geoserver war
and as external data dirs at the same time.
The document at
http://docs.codehaus.org/display/GEOSDOC/GeoServer+Data+Directory
wants a flat directory layout:
data_dir:
- catalog.xml
- services.xml
- coverages\
- data\
- demo\
- featureTypes\
- plugins\
- styles\
- validation\
and then instructs people to prefix file:/data/ to have relative
paths... well, this is not how is it working at the moment...
Every path (no matter if it starts with the data dir or not)
will be concatenated against the data dir and if it
exists, it'll be considered as part of the data directory,
otherwise it will be used as absolute.
Shall we restore the documented behaviour?
If we do so, the default geoserver data dir will be back to being
<webapp>/data, not simply <webapp> (where <webapp> is the absolute
path to the deployed web application). We can then protect it
so that people cannot see its contents using a masking servlet
(I already have one).
Well, let me know, I have most of the work done, I just need to
make sure I'm not screwing up.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:1023,45c716eb114636309890654!
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
I moved it up one level to avoid the confusion of describing the "data directory" (data_dir/data/) in the "data_directory" (data_dir/). So there would be one root data_dir, and under that the person can put their files wherever they want. But if that means we can't mask the contents of the directory, then maybe we should switch back to /data.
I have a servlet ready on my disk that can be configured to mask whatever we want.
But, in the geoserver embedded data dir
we're using in the war releases, I'd like to have everything under
the data folder, and have the data dir be that folder, instead of
being all the webapp. It seems clearer to me.
Cheers
Andrea
The old versions use data_dir/data for the default shapefiles (states, tazmania...). I still have the release build it out to be that way. As long as the catalog.xml file is the same, so that the datastores are located under the same path whether it is under [install]/data_dir or [webapps]/data it all works fine.
What I was seeing before is "file:data/data/" and it looked a little odd.
I think we can configure each release (binary, war..) to be the way that suits each best. So the war will have it under 'data/'.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
I moved it up one level to avoid the confusion of describing the "data directory" (data_dir/data/) in the "data_directory" (data_dir/). So there would be one root data_dir, and under that the person can put their files wherever they want. But if that means we can't mask the contents of the directory, then maybe we should switch back to /data.
I have a servlet ready on my disk that can be configured to mask whatever we want.
But, in the geoserver embedded data dir
we're using in the war releases, I'd like to have everything under
the data folder, and have the data dir be that folder, instead of
being all the webapp. It seems clearer to me.
Cheers
Andrea
I feel like for a release or two we renamed 'data_dir' to 'conf'? But looking at 1.4.0 that's not how it is. That to me seems the most sensible, since it's really the whole config, and then the data/ sub-directory of that is where the data goes. I concede that we've already got a bit of a mess, so renaming the data_directory to conf/ won't solve everything nicely at this point.
I do think that we should have all releases have their configuration look the same though, for consistency. And so if I configure my GeoServer on the .exe release I can drop that in to the war.
I like doing the masking, and putting the data_dir in an obvious place in the war. My idea was to just stick the whole thing in web-inf, but if we can do a masking in the servlet that works even better. But it should look the same as how we do it in the .exe release.
Chris
Brent Owens wrote:
The old versions use data_dir/data for the default shapefiles (states, tazmania...). I still have the release build it out to be that way. As long as the catalog.xml file is the same, so that the datastores are located under the same path whether it is under [install]/data_dir or [webapps]/data it all works fine.
What I was seeing before is "file:data/data/" and it looked a little odd.
I think we can configure each release (binary, war..) to be the way that suits each best. So the war will have it under 'data/'.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
I moved it up one level to avoid the confusion of describing the "data directory" (data_dir/data/) in the "data_directory" (data_dir/). So there would be one root data_dir, and under that the person can put their files wherever they want. But if that means we can't mask the contents of the directory, then maybe we should switch back to /data.
I have a servlet ready on my disk that can be configured to mask whatever we want.
But, in the geoserver embedded data dir
we're using in the war releases, I'd like to have everything under
the data folder, and have the data dir be that folder, instead of
being all the webapp. It seems clearer to me.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,45c75ac9154621362196140!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Andrea Aime wrote:
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
This is another topic that makes me think that doing resource lookups in GeoServer should be path based, and not tied to a single directory. Perhaps that should be made somewhat of a priority?
I moved it up one level to avoid the confusion of describing the "data directory" (data_dir/data/) in the "data_directory" (data_dir/). So there would be one root data_dir, and under that the person can put their files wherever they want. But if that means we can't mask the contents of the directory, then maybe we should switch back to /data.
I have a servlet ready on my disk that can be configured to mask whatever we want.
But, in the geoserver embedded data dir
we're using in the war releases, I'd like to have everything under
the data folder, and have the data dir be that folder, instead of
being all the webapp. It seems clearer to me.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,45c75747150476309890654!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
This is another topic that makes me think that doing resource lookups in GeoServer should be path based, and not tied to a single directory. Perhaps that should be made somewhat of a priority?
I guess we can open an issue for geoserver 1.6.x about this.
Yet, I do believe whilst nice on the programmer's side, it may
bring confusion to the user. Think about it, having absolute paths,
and multiple relative ones as well...
It could work if each relative path had a name that one could refer
in the data url, something like:
excavations -> c:\data\excavations
research -> c:\research\gisdata
and then be able to use:
file://{excavations}/myshape.shp
file://{research}/airpollution.tiff
And then we would need something like the continuum fs browser to
allow people to choose from their fs without this much copy and paste...
just my 2 cents
In the meantime, I'll try to have a data dir that conforms to our
documentation for the next release.
Cheers
Andrea
On 2/5/07, Brent Owens <brentowens@anonymised.com> wrote:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
Why? The current setup with the catalog.xml and services.xml residing
in data_dir works fine...
Alex
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Brent Owens ha scritto:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
I'd prefer the flat version me too.
Let's see if some other developer has any opinion on this one....
Btw, how does the data dir we're shipping geoserver for windows look
like? I would also hate to change the data dir layout for the n-th time.
Well, for sure I don't want a web-inf around.
This is another topic that makes me think that doing resource lookups in GeoServer should be path based, and not tied to a single directory. Perhaps that should be made somewhat of a priority?
I guess we can open an issue for geoserver 1.6.x about this.
Yet, I do believe whilst nice on the programmer's side, it may
bring confusion to the user. Think about it, having absolute paths,
and multiple relative ones as well...
It could work if each relative path had a name that one could refer
in the data url, something like:
excavations -> c:\data\excavations
research -> c:\research\gisdata
and then be able to use:
file://{excavations}/myshape.shp
file://{research}/airpollution.tiff
Not sure I follow where you are going here. I would like eliminate the need to have to use absolute paths. Of course if the user wants to they can since at the end of the day everything gets converted to an absolute path anyways.
The user enters in "myshape.shp" in the text field and completely underneath the covers it gets converted into "file://C:\excavations\myshap.shp" because "C:\excavations" is on the "data path".
I admit there are some other issues with this approach. For one it would involve exposing the notion of "repositories" to the user -> places where you store your data. Which is not a bad idea imho. There could also be conflicts that arise when a user enters in a file name and it exists in multiple locations on the path.
And then we would need something like the continuum fs browser to
allow people to choose from their fs without this much copy and paste...
just my 2 cents
Again, not sure I understand.
In the meantime, I'll try to have a data dir that conforms to our
documentation for the next release.
Perhaps a path based data setup might be something that more naturally fits into a new user interface, if it comes.
Cheers
Andrea
!DSPAM:1004,45c7683a166141362196140!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
The releases are going to contain the same data directories (format/layout) as they have previously, we won't be messing with that. It is just the layout under the configuration directory in SVN.
Brent Owens
(The Open Planning Project)
Alexander Petkov wrote:
On 2/5/07, Brent Owens <brentowens@anonymised.com> wrote:
To confirm, you want the data directory to look like this?:
data_dir/
- data/
- catalog.xml
- services.xml
- ....
Why? The current setup with the catalog.xml and services.xml residing
in data_dir works fine...
Alex
Justin Deoliveira ha scritto:
Andrea Aime wrote:
It could work if each relative path had a name that one could refer
in the data url, something like:
excavations -> c:\data\excavations
research -> c:\research\gisdata
and then be able to use:
file://{excavations}/myshape.shp
file://{research}/airpollution.tiff
Not sure I follow where you are going here. I would like eliminate the need to have to use absolute paths. Of course if the user wants to they can since at the end of the day everything gets converted to an absolute path anyways.
The user enters in "myshape.shp" in the text field and completely underneath the covers it gets converted into "file://C:\excavations\myshap.shp" because "C:\excavations" is on the "data path".
You're assuming a normal user gets the idea of a PATH better than
the one of variables, not sure this works in practice neither.
What happens when the same file name is available in multiple places?
How does a normal person tell which file gets taken?
In fact, for the layman these relative paths things are, imho, obscure 
And then we would need something like the continuum fs browser to
allow people to choose from their fs without this much copy and paste...
just my 2 cents
Again, not sure I understand.
As I user I would really prefer to have the ability to pick the file
on the file system just like with a normal app, with a file chooser.
But I may not be on the server, so a server file system navigator would
be needed.
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
It could work if each relative path had a name that one could refer
in the data url, something like:
excavations -> c:\data\excavations
research -> c:\research\gisdata
and then be able to use:
file://{excavations}/myshape.shp
file://{research}/airpollution.tiff
Not sure I follow where you are going here. I would like eliminate the need to have to use absolute paths. Of course if the user wants to they can since at the end of the day everything gets converted to an absolute path anyways.
The user enters in "myshape.shp" in the text field and completely underneath the covers it gets converted into "file://C:\excavations\myshap.shp" because "C:\excavations" is on the "data path".
You're assuming a normal user gets the idea of a PATH better than
the one of variables, not sure this works in practice neither.
What happens when the same file name is available in multiple places?
How does a normal person tell which file gets taken?
In fact, for the layman these relative paths things are, imho, obscure
Sure, as equally obscure as making your user prefix there file names with the word "data" :). I don't think you have to expose it to the user. We could leave it the exact same way it is today, and the idea still works. Its just under the scenes we add multiple locations to the path so we don't have to write conditional code based on wether we are running standalone, or via a war file.
Or if we want to allow the user the ability to specify multiples places on their file system where data is stored, we can do that too.
And then we would need something like the continuum fs browser to
allow people to choose from their fs without this much copy and paste...
just my 2 cents
Again, not sure I understand.
As I user I would really prefer to have the ability to pick the file
on the file system just like with a normal app, with a file chooser.
But I may not be on the server, so a server file system navigator would
be needed.
Of course, absolute paths would always be supported.
Cheers
Andrea
!DSPAM:1004,45c77f08197351665516417!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
It could work if each relative path had a name that one could refer
in the data url, something like:
excavations -> c:\data\excavations
research -> c:\research\gisdata
and then be able to use:
file://{excavations}/myshape.shp
file://{research}/airpollution.tiff
Not sure I follow where you are going here. I would like eliminate the need to have to use absolute paths. Of course if the user wants to they can since at the end of the day everything gets converted to an absolute path anyways.
The user enters in "myshape.shp" in the text field and completely underneath the covers it gets converted into "file://C:\excavations\myshap.shp" because "C:\excavations" is on the "data path".
You're assuming a normal user gets the idea of a PATH better than
the one of variables, not sure this works in practice neither.
What happens when the same file name is available in multiple places?
How does a normal person tell which file gets taken?
In fact, for the layman these relative paths things are, imho, obscure
Sure, as equally obscure as making your user prefix there file names with the word "data" :).
Indeed I removed that. A path is checked against the data dir
and if the file is not found, it's assumed to be an absolute one.
I don't think you have to expose it to the user. We could leave it the exact same way it is today, and the idea still works. Its just under the scenes we add multiple locations to the path so we don't have to write conditional code based on wether we are running standalone, or via a war file.
There is no conditional code anymore, I've removed it all (commented
out in fact) with the last commit. The data dir now works the same, with the same structure, both in the war and outside it.
Try it out and tell me how it works
Cheers
Andrea
Justin Deoliveira a écrit :
Andrea Aime wrote:
As I user I would really prefer to have the ability to pick the file
on the file system just like with a normal app, with a file chooser.
But I may not be on the server, so a server file system navigator would
be needed.
Of course, absolute paths would always be supported.
If I can explain my "Geoserver user" point of view : when I create a coverage store, which requires a file, if I make a mistake in the path for the file, I am not warned that I specified a wrong way. It is only when I create a coverage using this coverage store that a /|java.io.FileNotFoundException |/appears.
With a file system chooser, I will be sure that I will not specify a wrong path, and that my coverage or data store will be well defined.
Cheers,
Cédric B.
||
Cédric Briançon ha scritto:
Justin Deoliveira a écrit :
Andrea Aime wrote:
As I user I would really prefer to have the ability to pick the file
on the file system just like with a normal app, with a file chooser.
But I may not be on the server, so a server file system navigator would
be needed.
Of course, absolute paths would always be supported.
If I can explain my "Geoserver user" point of view : when I create a coverage store, which requires a file, if I make a mistake in the path for the file, I am not warned that I specified a wrong way. It is only when I create a coverage using this coverage store that a /|java.io.FileNotFoundException |/appears.
Yup, very ugly. I've already opened an issue about this (GEOS-851), though I don't know when we'll be able to fix it.
With a file system chooser, I will be sure that I will not specify a wrong path, and that my coverage or data store will be well defined.
Indeed. The only trick here is that we need a "server side" file system chooser, since the browser may not be on the same box as Geoserver...
Something like this: http://geo.openplans.org:9090/continuum/servlet/continuum/target/WorkingCopy.vm/view/WorkingCopy/id/291
but maybe ajax based, so that the page does not need to be reloaded
each time you walk into a directory...
Cheers
Andrea
Hi Andrea
Can I get a quick update on where your fixes are at. I tried to run with an "old style" data directory yesterday from 1.5.x and the result was failure, services.xml and catalog.xml would not be loaded from under WEB-INF. Is this intended?
-Justin
Andrea Aime wrote:
Cédric Briançon ha scritto:
Justin Deoliveira a écrit :
Andrea Aime wrote:
As I user I would really prefer to have the ability to pick the file
on the file system just like with a normal app, with a file chooser.
But I may not be on the server, so a server file system navigator would
be needed.
Of course, absolute paths would always be supported.
If I can explain my "Geoserver user" point of view : when I create a coverage store, which requires a file, if I make a mistake in the path for the file, I am not warned that I specified a wrong way. It is only when I create a coverage using this coverage store that a /|java.io.FileNotFoundException |/appears.
Yup, very ugly. I've already opened an issue about this (GEOS-851), though I don't know when we'll be able to fix it.
With a file system chooser, I will be sure that I will not specify a wrong path, and that my coverage or data store will be well defined.
Indeed. The only trick here is that we need a "server side" file system chooser, since the browser may not be on the same box as Geoserver...
Something like this: http://geo.openplans.org:9090/continuum/servlet/continuum/target/WorkingCopy.vm/view/WorkingCopy/id/291
but maybe ajax based, so that the page does not need to be reloaded
each time you walk into a directory...
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,45c8630819351429667743!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Hi Andrea
Can I get a quick update on where your fixes are at. I tried to run with an "old style" data directory yesterday from 1.5.x and the result was failure, services.xml and catalog.xml would not be loaded from under WEB-INF. Is this intended?
Yes, it is... there is no such a thing as a data directory like the "old one", I thought these were intended only for "in webapp" deployement.
Brent did rehash them to have the documented layout for releases anyways.
I can restore the code that allows lookups in WEB-INF thougth
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea
Can I get a quick update on where your fixes are at. I tried to run with an "old style" data directory yesterday from 1.5.x and the result was failure, services.xml and catalog.xml would not be loaded from under WEB-INF. Is this intended?
Yes, it is... there is no such a thing as a data directory like the "old one", I thought these were intended only for "in webapp" deployement.
Brent did rehash them to have the documented layout for releases anyways.
I can restore the code that allows lookups in WEB-INF thougth
Ok, just trying to be clear. Dowever this kind of surprises me. Does this not make us non-backwards compatible with previous versions?
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,45c8aff167916309890654!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea
Can I get a quick update on where your fixes are at. I tried to run with an "old style" data directory yesterday from 1.5.x and the result was failure, services.xml and catalog.xml would not be loaded from under WEB-INF. Is this intended?
Yes, it is... there is no such a thing as a data directory like the "old one", I thought these were intended only for "in webapp" deployement.
Brent did rehash them to have the documented layout for releases anyways.
I can restore the code that allows lookups in WEB-INF thougth
Ok, just trying to be clear. Dowever this kind of surprises me. Does this not make us non-backwards compatible with previous versions?
Only for developers that were using the broken data dir format
with a WEB-INF section inside, not for users that did set up an
external data dir following the documented format.
Afaik the WEB-INF section were used only if you deploy a data dir
in the old format inside geoserver... you should not need to,
version control has release, cite and minimal configs.
Anyways, just uncommented the extra lookup paths at GeoserverDataDir,
to look like:
// these are left here to allow loading from the 1.4.x developer data
// dir style the one that contained a data and a web-inf subfolder
loader.addSearchLocation(new File(servContext.getRealPath("WEB-INF")));
loader.addSearchLocation(new File(servContext.getRealPath("data")));
this should solve your issue.
Cheers
Andrea