Christian Müller ha scritto:
> In the meantime a new version of ibm sdk 6 is available. (I am working
> with the new version). If you look at the list of fixes and search for
> introspection, you can get an idea why there have been problems with
> geoserver running on ibm skd.
Wow, lots of them
In the meantime a new version of ibm sdk 6 is available. (I am working with
the new version). If you look at the list of fixes and search for
introspection, you can get an idea why there have been problems with
geoserver running on ibm skd.
I am still in the process of testing
Title: fixes
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> IBM JDK 6 is still not usable, it has bugs related
>> to reflection that prevent GeoServer to work on it
>
> XStream-related?
Possibly, but I'm not sure. Christian knows more.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert
Andrea Aime wrote:
> IBM JDK 6 is still not usable, it has bugs related
> to reflection that prevent GeoServer to work on it
XStream-related?
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Austral
Ben Caradoc-Davies ha scritto:
> Justin Deoliveira wrote:
>> Chiming in late, +1 on the change.
>
> +1 from me as well. I nailed my list of existing toURL grievances to
> GEOT-2568 (I linked it to GEOT-1714 and GEOS-1760). I would be equally
> happy with a utility class that we can publicise.
>
Justin Deoliveira wrote:
> Chiming in late, +1 on the change.
+1 from me as well. I nailed my list of existing toURL grievances to
GEOT-2568 (I linked it to GEOT-1714 and GEOS-1760). I would be equally
happy with a utility class that we can publicise.
> The question is how to ensure that
> dev
Justin Deoliveira ha scritto:
> Chiming in late, +1 on the change. The question is how to ensure that
> developers do not revert to the deprecated behavior, I myself did know
> that toURL() was an issue. I guess diligent review and a big stick :) A
> convenience method probably won't be of much
Chiming in late, +1 on the change. The question is how to ensure that
developers do not revert to the deprecated behavior, I myself did know
that toURL() was an issue. I guess diligent review and a big stick :) A
convenience method probably won't be of much help either since it is
still another
>> Hrm - I do see what you are talking about; the instructions on that page
>> are not the best.
>
> Jody,
> sometimes I wondering if you really read my mails ;-)
Well at least I am good enough to check up on what you said and feel
stupid later :-( Usually if I have not checked your references it
Jody Garnett ha scritto:
> Hrm - I do see what you are talking about; the instructions on that page
> are not the best.
Jody,
sometimes I wondering if you really read my mails ;-)
Please have a look in DataUtilities, there is no fileToURL method at
all, only the method to go the opposite directi
Hrm - I do see what you are talking about; the instructions on that
page are not the best.
Jody
On 29/06/2009, at 6:15 AM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> The file touri tourl work around did not result in 100% success for
>> udig. We did contribute the work around and the in
File to URL is what causes the problems...
File.toURL() is deprecate in Java 6 (because they screwed up the
encoding of spaces and other stuff)
File.toURI().toURL() is the approved workaround
DataUtilities.fileToURL() is our workaround for at least a couple
years now
fileToURL() is similar to
Jody Garnett ha scritto:
> The file touri tourl work around did not result in 100% success for
> udig. We did contribute the work around and the instructions are in the
> developers guide.
Hmmm... search engines gave me nothing. A manual search gave me this:
http://docs.codehaus.org/display/GEOT
The file touri tourl work around did not result in 100% success for
udig. We did contribute the work around and the instructions are in
the developers guide.
Jody
On 29/06/2009, at 1:21 AM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Andrea we have a similar class in uDig called URLU
+1 without comment
Andrea Aime writes:
> Christian Müller ha scritto:
>> Since I am always working with an SDK 6, the usage of File.toUrl() is
>> marked depricated, I think the patch is welcome, especially if I think
>> about the fact that we have no Windows developers.
>> The patch is for 2.
Jody Garnett ha scritto:
> Andrea we have a similar class in uDig called URLUtils that handles a
> lot of these issues; I would love to compare implementations etc... So
> yes the issue is very real; in particular the Java File classes do not
> have any great way of dealing with the "root" items:
>
Christian Müller ha scritto:
> Since I am always working with an SDK 6, the usage of File.toUrl() is
> marked depricated, I think the patch is welcome, especially if I think
> about the fact that we have no Windows developers.
> The patch is for 2.5.x, what about trunk ?
I guess we can just port
Since I am always working with an SDK 6, the usage of File.toUrl() is marked
depricated, I think the patch is welcome, especially if I think about the
fact that we have no Windows developers.
The patch is for 2.5.x, what about trunk ?
Andrea Aime writes:
> Hi all,
> a GT2 user provided thi
Andrea we have a similar class in uDig called URLUtils that handles a
lot of these issues; I would love to compare implementations etc... So
yes the issue is very real; in particular the Java File classes do not
have any great way of dealing with the "root" items:
- C: D: on windows - ie drive lett
Hi all,
a GT2 user provided this patch:
http://jira.codehaus.org/browse/GEOT-2568
that deals with deficiencies of File.toURL to deal
with special characters. I checked on the net and
confirmed the issue is real.
The patch is quite mechanic, but also very extensive
(60kb) so I would like to get so
20 matches
Mail list logo
