While we are at it, I should note that date, timestamp, timestamp with TZ
handling inside the existing implementation is pretty weak. I have been able
to create overriding extensions that behave well enough to support filters
and encoding, but a systematic set of test cases in the encoding cases, and
per datastore test cases for the weird types that each datastore might
provide is required IMHO.
There are also potentially things like forcing the Oracle jdbc driver to
behave in a J2EE compliant mode (and return java.sql.Timestamp instead of
oracle.sql.Timestamp).
Rob
On Sat, May 24, 2008 at 4:24 AM, Jody Garnett <[EMAIL PROTECTED]>
wrote:
> Wow that is great news; did you want to CC the geotools list ;-)
>
> Alessio Fabiani wrote:
> > We started from a first implementation made by Alexander Petkov and
> > continued by adding more features and replacing Date and Time lower
> > level implemented functionalities with Joda-Time library stuff. We
> > would like to adopt those APIs for some projects, like the new
> > ImageIO-ND plugin we are writing, which already supports NetCDF-CF,
> > HDF and GRIB1 file types and also for the GeoServer W?S temporal
> > metadata handling.
> >
> > So ... basically what we should do now, is the best way of
> > marshalling/unmarshalling temporal schema objects. The GeoServer
> > net.opengis.ows package, and related ones, uses ECore while GeoTools
> > coverageio stuff uses JAXB. We have not looked deep into ECore yet,
> > but we used JAXB more than once in the past.
> > Having the desire to use this stuff with GeoServer as well, what do
> > you guys think would be the best choice?
> You are kind of stuck with both; dependencies ... each has a different
> value add.
>
> Are you refering to org.eclipse.emf.ecore.xml.type.internal.XMLCalendar?
> It is marked as "internal" to be repalced with JAXP 1.3
> javax.xml.datatype.XMLGregorianCalendar (ie there should not be a
> conflict between these two).
>
> I am not sure what ECore time representation you are thinking of...
> Jody
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
