Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

Thanks Ben and Rini, I will go ahead and disable the test for now and
continue with my testing.


On Wed, Jan 30, 2013 at 1:41 AM,  wrote:

> Hi,
>
> I managed to dig the original issue for the test:
> http://jira.codehaus.org/browse/GEOT-3493.
> The original behaviour was to swallow the exception and quietly display an
> empty result.
> This is not an acceptable behaviour as it would be frustrating for the
> users to find the configuration fault.
>
> The main change was to add ErrorListener to the transformer in
> GML3OutputFormat.
> I can see the ErrorListener is not affected by Justin's changes, so
> perhaps xerces 2.6 doesn't throw an exception when the namespace URI is
> null.
> If this is the case, I don't think we can do much.. maybe I'll think of
> something later.
> We are a bit short of resources at the moment.
> You can exclude the test in the app-schema-test pom.xml in the mean time.
>
>
> Cheers
> Rini
>
>
> -Original Message-
> From: Caradoc-Davies, Ben (CESRE, Kensington)
> Sent: Wednesday, 30 January 2013 12:54 PM
> To: Justin Deoliveira
> Cc: Geotools-Devel list; Tey, Victor (CESRE, Kensington); Angreani, Rini
> (CESRE, Kensington)
> Subject: Re: [Geotools-devel] removing xerces dependency
>
> Thanks, Justin. My patch was not expected to fix the
> SecondaryNamespaceExceptionTest failure.
>
> I recall that SecondaryNamespaceExceptionTest tests that an exception is
> thrown if secondary namespaces are not defined (null). Once the external
> xerces 2.7 is removed (in favour of the internal xerces 2.6), the null
> namespace prefixes are simply passed through, resulting in an invalid
> response. The test failure alerts us to the change.
>
> I think this test was originally written by Victor. Rini is the app-schema
> component lead and should be able to determine whether this new behaviour
> is aceptable.
>
> Kind regards,
> Ben.
>
> On 30/01/13 12:02, Justin Deoliveira wrote:
> > Hey Ben,
> >
> > So I rebased the xmlnodeps branch against the latest on master and i
> > am still having the same failure with the
> SecondaryNamespaceExceptionTest.
> >
> > I pushed up newly rebased branches to my repos.
> >
> > https://github.com/jdeolive/geoserver/tree/noxmldeps2
> > https://github.com/jdeolive/geotools/tree/noxmldeps2
> >
> > -Justin
> >
> >
> > On Tue, Jan 22, 2013 at 7:12 PM, Ben Caradoc-Davies
> > mailto:ben.caradoc-dav...@csiro.au>>
> wrote:
> >
> > Thanks, Justin.
> >
> > The gt-app-schema-resolver Xerces dependency you found is resolved
> > in the pull request linked below. This patch is against your
> > noxmldeps branch; everything works when it is applied, except that
> > xmlcodegen does not build (I commented it out while testing), and
> > one unit test failure in GeoServer app-schema-test, which you should
> > be able to reproduce when you build GeoServer against your noxmldeps
> > branch. See:
> > https://github.com/jdeolive/__geotools/pull/1
> > <https://github.com/jdeolive/geotools/pull/1>
> >
> > I removed the GeoServer app-schema Xalan dependency late last year:
> > https://jira.codehaus.org/__browse/GEOS-5352
> > <https://jira.codehaus.org/browse/GEOS-5352>
> > https://github.com/geoserver/__geoserver/pull/54
> > <https://github.com/geoserver/geoserver/pull/54>
> >
> > Kind regards,
> > Ben.
> >
> >
> > On 22/01/13 22:57, Justin Deoliveira wrote:
> >
> > Hey Ben,
> >
> > Wasn't waiting explicitly, this sort of just fell off in light
> > of other
> > things to do. I will try this week to resurrect this. As I
> > understand it
> > the app-schema issues have been resolved now?
> >
> > -Justin
> >
> >
> > On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies
> >  > <mailto:Ben.Caradoc-Davies@__csiro.au
> > <mailto:ben.caradoc-dav...@csiro.au>>> wrote:
> >
> >  Justin,
> >
> >  at Monday's meeting we were wondering if you have had time
> to
> >  progress the removal of (external) Xerces dependencies. My
> >  understanding is that you were pretty close. Or are you
> waiting
> >  until after this release cycle?
> >
> >  Kind regards,
> >  Ben.
> >
> >
> >  On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>

Re: [Geotools-devel] removing xerces dependency

[Rini.Angreani]

Hi,

I managed to dig the original issue for the test: 
http://jira.codehaus.org/browse/GEOT-3493.
The original behaviour was to swallow the exception and quietly display an 
empty result. 
This is not an acceptable behaviour as it would be frustrating for the users to 
find the configuration fault.

The main change was to add ErrorListener to the transformer in GML3OutputFormat.
I can see the ErrorListener is not affected by Justin's changes, so perhaps 
xerces 2.6 doesn't throw an exception when the namespace URI is null. 
If this is the case, I don't think we can do much.. maybe I'll think of 
something later.
We are a bit short of resources at the moment. 
You can exclude the test in the app-schema-test pom.xml in the mean time.


Cheers
Rini


-Original Message-
From: Caradoc-Davies, Ben (CESRE, Kensington) 
Sent: Wednesday, 30 January 2013 12:54 PM
To: Justin Deoliveira
Cc: Geotools-Devel list; Tey, Victor (CESRE, Kensington); Angreani, Rini 
(CESRE, Kensington)
Subject: Re: [Geotools-devel] removing xerces dependency

Thanks, Justin. My patch was not expected to fix the 
SecondaryNamespaceExceptionTest failure.

I recall that SecondaryNamespaceExceptionTest tests that an exception is thrown 
if secondary namespaces are not defined (null). Once the external xerces 2.7 is 
removed (in favour of the internal xerces 2.6), the null namespace prefixes are 
simply passed through, resulting in an invalid response. The test failure 
alerts us to the change.

I think this test was originally written by Victor. Rini is the app-schema 
component lead and should be able to determine whether this new behaviour is 
aceptable.

Kind regards,
Ben.

On 30/01/13 12:02, Justin Deoliveira wrote:
> Hey Ben,
>
> So I rebased the xmlnodeps branch against the latest on master and i 
> am still having the same failure with the SecondaryNamespaceExceptionTest.
>
> I pushed up newly rebased branches to my repos.
>
> https://github.com/jdeolive/geoserver/tree/noxmldeps2
> https://github.com/jdeolive/geotools/tree/noxmldeps2
>
> -Justin
>
>
> On Tue, Jan 22, 2013 at 7:12 PM, Ben Caradoc-Davies 
> mailto:ben.caradoc-dav...@csiro.au>> wrote:
>
> Thanks, Justin.
>
> The gt-app-schema-resolver Xerces dependency you found is resolved
> in the pull request linked below. This patch is against your
> noxmldeps branch; everything works when it is applied, except that
> xmlcodegen does not build (I commented it out while testing), and
> one unit test failure in GeoServer app-schema-test, which you should
> be able to reproduce when you build GeoServer against your noxmldeps
> branch. See:
> https://github.com/jdeolive/__geotools/pull/1
> <https://github.com/jdeolive/geotools/pull/1>
>
> I removed the GeoServer app-schema Xalan dependency late last year:
> https://jira.codehaus.org/__browse/GEOS-5352
> <https://jira.codehaus.org/browse/GEOS-5352>
> https://github.com/geoserver/__geoserver/pull/54
> <https://github.com/geoserver/geoserver/pull/54>
>
> Kind regards,
> Ben.
>
>
> On 22/01/13 22:57, Justin Deoliveira wrote:
>
> Hey Ben,
>
> Wasn't waiting explicitly, this sort of just fell off in light
> of other
> things to do. I will try this week to resurrect this. As I
> understand it
> the app-schema issues have been resolved now?
>
> -Justin
>
>
> On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies
>  <mailto:Ben.Caradoc-Davies@__csiro.au
> <mailto:ben.caradoc-dav...@csiro.au>>> wrote:
>
>  Justin,
>
>  at Monday's meeting we were wondering if you have had time to
>  progress the removal of (external) Xerces dependencies. My
>  understanding is that you were pretty close. Or are you waiting
>  until after this release cycle?
>
>  Kind regards,
>  Ben.
>
>
>  On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>
>  Justin,
>
>  I ported AppSchemaValidator to use EntityResolver2,
> required for
>  relative schema locations:
> https://github.com/jdeolive/geotools/pull/1
> <https://github.com/jdeolive/__geotools/pull/1>
>
> <https://github.com/jdeolive/__geotools/pull/1
> <https://github.com/jdeolive/geotools/pull/1>>
>
>  Note that xmlcodegen still fails to build (I commented
> it out
>  for testing).
>
>  With noxmldeps GeoTools, there is a unit test failure
> in GeoServer
>

Re: [Geotools-devel] removing xerces dependency

[Ben Caradoc-Davies]

Thanks, Justin. My patch was not expected to fix the 
SecondaryNamespaceExceptionTest failure.

I recall that SecondaryNamespaceExceptionTest tests that an exception is 
thrown if secondary namespaces are not defined (null). Once the external 
xerces 2.7 is removed (in favour of the internal xerces 2.6), the null 
namespace prefixes are simply passed through, resulting in an invalid 
response. The test failure alerts us to the change.

I think this test was originally written by Victor. Rini is the 
app-schema component lead and should be able to determine whether this 
new behaviour is aceptable.

Kind regards,
Ben.

On 30/01/13 12:02, Justin Deoliveira wrote:
> Hey Ben,
>
> So I rebased the xmlnodeps branch against the latest on master and i am
> still having the same failure with the SecondaryNamespaceExceptionTest.
>
> I pushed up newly rebased branches to my repos.
>
> https://github.com/jdeolive/geoserver/tree/noxmldeps2
> https://github.com/jdeolive/geotools/tree/noxmldeps2
>
> -Justin
>
>
> On Tue, Jan 22, 2013 at 7:12 PM, Ben Caradoc-Davies
> mailto:ben.caradoc-dav...@csiro.au>> wrote:
>
> Thanks, Justin.
>
> The gt-app-schema-resolver Xerces dependency you found is resolved
> in the pull request linked below. This patch is against your
> noxmldeps branch; everything works when it is applied, except that
> xmlcodegen does not build (I commented it out while testing), and
> one unit test failure in GeoServer app-schema-test, which you should
> be able to reproduce when you build GeoServer against your noxmldeps
> branch. See:
> https://github.com/jdeolive/__geotools/pull/1
> 
>
> I removed the GeoServer app-schema Xalan dependency late last year:
> https://jira.codehaus.org/__browse/GEOS-5352
> 
> https://github.com/geoserver/__geoserver/pull/54
> 
>
> Kind regards,
> Ben.
>
>
> On 22/01/13 22:57, Justin Deoliveira wrote:
>
> Hey Ben,
>
> Wasn't waiting explicitly, this sort of just fell off in light
> of other
> things to do. I will try this week to resurrect this. As I
> understand it
> the app-schema issues have been resolved now?
>
> -Justin
>
>
> On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies
>   >> wrote:
>
>  Justin,
>
>  at Monday's meeting we were wondering if you have had time to
>  progress the removal of (external) Xerces dependencies. My
>  understanding is that you were pretty close. Or are you waiting
>  until after this release cycle?
>
>  Kind regards,
>  Ben.
>
>
>  On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>
>  Justin,
>
>  I ported AppSchemaValidator to use EntityResolver2,
> required for
>  relative schema locations:
> https://github.com/jdeolive/geotools/pull/1
> 
>
>  >
>
>  Note that xmlcodegen still fails to build (I commented
> it out
>  for testing).
>
>  With noxmldeps GeoTools, there is a unit test failure
> in GeoServer
>  (app-schema-test SecondaryNamespaceExceptionTest).
> Looks like
>
>  a side
>  effect of your dexercesification is that undefined
> namespace
>  prefixes
>  (null:) are now passed through the GML32OutputFormat
> XSLT rather
>  that
>  causing an ows:ExceptionReport. Not sure why. I also
> needed to
>  remove
>  the xerces dependencies in the release module.
>
>  Nice work! You are pretty close.
>
>  Now just that pesky Xalan (app-schema GeoServer plugin, so
>  off-topic).
>  Any XSLT gurus willing to help backport to Xalan 2.6
> (in the JDK)?
> https://jira.codehaus.org/browse/GEOS-5352
> 
>
>  >
>
>  Kind regards,
>  Ben.
>
>  On 23/10/12 08:29, Justin Deoliveira wrote:
>
>  Hi all,
>
>  So I recently I took a crack at removing the xerces
>  dependency as we
>  discussed in our last skype meeting. For the most
> part this was
>   

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

Hey Ben,

So I rebased the xmlnodeps branch against the latest on master and i am
still having the same failure with the SecondaryNamespaceExceptionTest.

I pushed up newly rebased branches to my repos.

  https://github.com/jdeolive/geoserver/tree/noxmldeps2
  https://github.com/jdeolive/geotools/tree/noxmldeps2

-Justin


On Tue, Jan 22, 2013 at 7:12 PM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> Thanks, Justin.
>
> The gt-app-schema-resolver Xerces dependency you found is resolved in the
> pull request linked below. This patch is against your noxmldeps branch;
> everything works when it is applied, except that xmlcodegen does not build
> (I commented it out while testing), and one unit test failure in GeoServer
> app-schema-test, which you should be able to reproduce when you build
> GeoServer against your noxmldeps branch. See:
> https://github.com/jdeolive/**geotools/pull/1
>
> I removed the GeoServer app-schema Xalan dependency late last year:
> https://jira.codehaus.org/**browse/GEOS-5352
> https://github.com/geoserver/**geoserver/pull/54
>
> Kind regards,
> Ben.
>
>
> On 22/01/13 22:57, Justin Deoliveira wrote:
>
>> Hey Ben,
>>
>> Wasn't waiting explicitly, this sort of just fell off in light of other
>> things to do. I will try this week to resurrect this. As I understand it
>> the app-schema issues have been resolved now?
>>
>> -Justin
>>
>>
>> On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies
>> > >
>> wrote:
>>
>> Justin,
>>
>> at Monday's meeting we were wondering if you have had time to
>> progress the removal of (external) Xerces dependencies. My
>> understanding is that you were pretty close. Or are you waiting
>> until after this release cycle?
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>>
>> Justin,
>>
>> I ported AppSchemaValidator to use EntityResolver2, required for
>> relative schema locations:
>> 
>> https://github.com/jdeolive/__**geotools/pull/1
>>
>> 
>> 
>> >
>>
>> Note that xmlcodegen still fails to build (I commented it out
>> for testing).
>>
>> With noxmldeps GeoTools, there is a unit test failure in GeoServer
>> (app-schema-test SecondaryNamespaceExceptionTes**__t). Looks like
>>
>> a side
>> effect of your dexercesification is that undefined namespace
>> prefixes
>> (null:) are now passed through the GML32OutputFormat XSLT rather
>> that
>> causing an ows:ExceptionReport. Not sure why. I also needed to
>> remove
>> the xerces dependencies in the release module.
>>
>> Nice work! You are pretty close.
>>
>> Now just that pesky Xalan (app-schema GeoServer plugin, so
>> off-topic).
>> Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
>> 
>> https://jira.codehaus.org/__**browse/GEOS-5352
>>
>> 
>> 
>> >
>>
>> Kind regards,
>> Ben.
>>
>> On 23/10/12 08:29, Justin Deoliveira wrote:
>>
>> Hi all,
>>
>> So I recently I took a crack at removing the xerces
>> dependency as we
>> discussed in our last skype meeting. For the most part this
>> was
>> relatively straight forward. Unfortunately one thing i
>> wasn't quite able
>> to figure out was some stuff in app-schema-resolver module.
>> The
>> AppSchemaValidator class uses an implementation of what
>> was XMLEntityResolver directly in xerces. I tried porting
>> this to the
>> jaxp EntityResolver interface which is included in the JDK,
>> but couldn't
>> make it work. So I think i will need some help there. Or we
>> can simply
>> keep xerces as a dependency of just app-schema.
>>
>> Here is the branch I am currently working on.
>>
>> 
>> https://github.com/jdeolive/__**geotools/tree/noxmldeps
>>
>> 
>> 
>> >
>> And the corresponding geoserver branch:
>>
>> 
>> https://github.com/jdeolive/__**geoserver/tree/noxmldeps
>>
>> 
>> 

Re: [Geotools-devel] removing xerces dependency

[Ben Caradoc-Davies]

Thanks, Justin.

The gt-app-schema-resolver Xerces dependency you found is resolved in 
the pull request linked below. This patch is against your noxmldeps 
branch; everything works when it is applied, except that xmlcodegen does 
not build (I commented it out while testing), and one unit test failure 
in GeoServer app-schema-test, which you should be able to reproduce when 
you build GeoServer against your noxmldeps branch. See:
https://github.com/jdeolive/geotools/pull/1

I removed the GeoServer app-schema Xalan dependency late last year:
https://jira.codehaus.org/browse/GEOS-5352
https://github.com/geoserver/geoserver/pull/54

Kind regards,
Ben.

On 22/01/13 22:57, Justin Deoliveira wrote:
> Hey Ben,
>
> Wasn't waiting explicitly, this sort of just fell off in light of other
> things to do. I will try this week to resurrect this. As I understand it
> the app-schema issues have been resolved now?
>
> -Justin
>
>
> On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies
> mailto:ben.caradoc-dav...@csiro.au>> wrote:
>
> Justin,
>
> at Monday's meeting we were wondering if you have had time to
> progress the removal of (external) Xerces dependencies. My
> understanding is that you were pretty close. Or are you waiting
> until after this release cycle?
>
> Kind regards,
> Ben.
>
>
> On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>
> Justin,
>
> I ported AppSchemaValidator to use EntityResolver2, required for
> relative schema locations:
> https://github.com/jdeolive/__geotools/pull/1
> 
>
> Note that xmlcodegen still fails to build (I commented it out
> for testing).
>
> With noxmldeps GeoTools, there is a unit test failure in GeoServer
> (app-schema-test SecondaryNamespaceExceptionTes__t). Looks like
> a side
> effect of your dexercesification is that undefined namespace
> prefixes
> (null:) are now passed through the GML32OutputFormat XSLT rather
> that
> causing an ows:ExceptionReport. Not sure why. I also needed to
> remove
> the xerces dependencies in the release module.
>
> Nice work! You are pretty close.
>
> Now just that pesky Xalan (app-schema GeoServer plugin, so
> off-topic).
> Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
> https://jira.codehaus.org/__browse/GEOS-5352
> 
>
> Kind regards,
> Ben.
>
> On 23/10/12 08:29, Justin Deoliveira wrote:
>
> Hi all,
>
> So I recently I took a crack at removing the xerces
> dependency as we
> discussed in our last skype meeting. For the most part this was
> relatively straight forward. Unfortunately one thing i
> wasn't quite able
> to figure out was some stuff in app-schema-resolver module. The
> AppSchemaValidator class uses an implementation of what
> was XMLEntityResolver directly in xerces. I tried porting
> this to the
> jaxp EntityResolver interface which is included in the JDK,
> but couldn't
> make it work. So I think i will need some help there. Or we
> can simply
> keep xerces as a dependency of just app-schema.
>
> Here is the branch I am currently working on.
>
> https://github.com/jdeolive/__geotools/tree/noxmldeps
> 
> And the corresponding geoserver branch:
>
> https://github.com/jdeolive/__geoserver/tree/noxmldeps
> 
>
> WIth these changes all unit tests pass in both code bases,
> and so do the
> GeoServer cite tests.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
GeoTools-Deve

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

Hey Ben,

Wasn't waiting explicitly, this sort of just fell off in light of other
things to do. I will try this week to resurrect this. As I understand it
the app-schema issues have been resolved now?

-Justin


On Mon, Jan 21, 2013 at 7:03 PM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> Justin,
>
> at Monday's meeting we were wondering if you have had time to progress the
> removal of (external) Xerces dependencies. My understanding is that you
> were pretty close. Or are you waiting until after this release cycle?
>
> Kind regards,
> Ben.
>
>
> On 02/11/12 15:43, Ben Caradoc-Davies wrote:
>
>> Justin,
>>
>> I ported AppSchemaValidator to use EntityResolver2, required for
>> relative schema locations:
>> https://github.com/jdeolive/**geotools/pull/1
>>
>> Note that xmlcodegen still fails to build (I commented it out for
>> testing).
>>
>> With noxmldeps GeoTools, there is a unit test failure in GeoServer
>> (app-schema-test SecondaryNamespaceExceptionTes**t). Looks like a side
>> effect of your dexercesification is that undefined namespace prefixes
>> (null:) are now passed through the GML32OutputFormat XSLT rather that
>> causing an ows:ExceptionReport. Not sure why. I also needed to remove
>> the xerces dependencies in the release module.
>>
>> Nice work! You are pretty close.
>>
>> Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic).
>> Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
>> https://jira.codehaus.org/**browse/GEOS-5352
>>
>> Kind regards,
>> Ben.
>>
>> On 23/10/12 08:29, Justin Deoliveira wrote:
>>
>>> Hi all,
>>>
>>> So I recently I took a crack at removing the xerces dependency as we
>>> discussed in our last skype meeting. For the most part this was
>>> relatively straight forward. Unfortunately one thing i wasn't quite able
>>> to figure out was some stuff in app-schema-resolver module. The
>>> AppSchemaValidator class uses an implementation of what
>>> was XMLEntityResolver directly in xerces. I tried porting this to the
>>> jaxp EntityResolver interface which is included in the JDK, but couldn't
>>> make it work. So I think i will need some help there. Or we can simply
>>> keep xerces as a dependency of just app-schema.
>>>
>>> Here is the branch I am currently working on.
>>>
>>> https://github.com/jdeolive/**geotools/tree/noxmldeps
>>> And the corresponding geoserver branch:
>>>
>>> https://github.com/jdeolive/**geoserver/tree/noxmldeps
>>>
>>> WIth these changes all unit tests pass in both code bases, and so do the
>>> GeoServer cite tests.
>>>
>>> -Justin
>>>
>>> --
>>> Justin Deoliveira
>>> OpenGeo - http://opengeo.org
>>> Enterprise support for open source geospatial.
>>>
>>>
>>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Ben Caradoc-Davies]

Justin,

at Monday's meeting we were wondering if you have had time to progress 
the removal of (external) Xerces dependencies. My understanding is that 
you were pretty close. Or are you waiting until after this release cycle?

Kind regards,
Ben.

On 02/11/12 15:43, Ben Caradoc-Davies wrote:
> Justin,
>
> I ported AppSchemaValidator to use EntityResolver2, required for
> relative schema locations:
> https://github.com/jdeolive/geotools/pull/1
>
> Note that xmlcodegen still fails to build (I commented it out for testing).
>
> With noxmldeps GeoTools, there is a unit test failure in GeoServer
> (app-schema-test SecondaryNamespaceExceptionTest). Looks like a side
> effect of your dexercesification is that undefined namespace prefixes
> (null:) are now passed through the GML32OutputFormat XSLT rather that
> causing an ows:ExceptionReport. Not sure why. I also needed to remove
> the xerces dependencies in the release module.
>
> Nice work! You are pretty close.
>
> Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic).
> Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
> https://jira.codehaus.org/browse/GEOS-5352
>
> Kind regards,
> Ben.
>
> On 23/10/12 08:29, Justin Deoliveira wrote:
>> Hi all,
>>
>> So I recently I took a crack at removing the xerces dependency as we
>> discussed in our last skype meeting. For the most part this was
>> relatively straight forward. Unfortunately one thing i wasn't quite able
>> to figure out was some stuff in app-schema-resolver module. The
>> AppSchemaValidator class uses an implementation of what
>> was XMLEntityResolver directly in xerces. I tried porting this to the
>> jaxp EntityResolver interface which is included in the JDK, but couldn't
>> make it work. So I think i will need some help there. Or we can simply
>> keep xerces as a dependency of just app-schema.
>>
>> Here is the branch I am currently working on.
>>
>> https://github.com/jdeolive/geotools/tree/noxmldeps
>> And the corresponding geoserver branch:
>>
>> https://github.com/jdeolive/geoserver/tree/noxmldeps
>>
>> WIth these changes all unit tests pass in both code bases, and so do the
>> GeoServer cite tests.
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

Nice. Thanks Ben!

On Fri, Nov 2, 2012 at 1:43 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> Justin,
>
> I ported AppSchemaValidator to use EntityResolver2, required for relative
> schema locations:
> https://github.com/jdeolive/**geotools/pull/1
>
> Note that xmlcodegen still fails to build (I commented it out for testing).
>
> With noxmldeps GeoTools, there is a unit test failure in GeoServer
> (app-schema-test SecondaryNamespaceExceptionTes**t). Looks like a side
> effect of your dexercesification is that undefined namespace prefixes
> (null:) are now passed through the GML32OutputFormat XSLT rather that
> causing an ows:ExceptionReport. Not sure why. I also needed to remove the
> xerces dependencies in the release module.
>
> Nice work! You are pretty close.
>
> Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). Any
> XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
> https://jira.codehaus.org/**browse/GEOS-5352
>
> Kind regards,
> Ben.
>
>
> On 23/10/12 08:29, Justin Deoliveira wrote:
>
>> Hi all,
>>
>> So I recently I took a crack at removing the xerces dependency as we
>> discussed in our last skype meeting. For the most part this was
>> relatively straight forward. Unfortunately one thing i wasn't quite able
>> to figure out was some stuff in app-schema-resolver module. The
>> AppSchemaValidator class uses an implementation of what
>> was XMLEntityResolver directly in xerces. I tried porting this to the
>> jaxp EntityResolver interface which is included in the JDK, but couldn't
>> make it work. So I think i will need some help there. Or we can simply
>> keep xerces as a dependency of just app-schema.
>>
>> Here is the branch I am currently working on.
>>
>> https://github.com/jdeolive/**geotools/tree/noxmldeps
>> And the corresponding geoserver branch:
>>
>> https://github.com/jdeolive/**geoserver/tree/noxmldeps
>>
>> WIth these changes all unit tests pass in both code bases, and so do the
>> GeoServer cite tests.
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Ben Caradoc-Davies]

Justin,

I ported AppSchemaValidator to use EntityResolver2, required for 
relative schema locations:
https://github.com/jdeolive/geotools/pull/1

Note that xmlcodegen still fails to build (I commented it out for testing).

With noxmldeps GeoTools, there is a unit test failure in GeoServer 
(app-schema-test SecondaryNamespaceExceptionTest). Looks like a side 
effect of your dexercesification is that undefined namespace prefixes 
(null:) are now passed through the GML32OutputFormat XSLT rather that 
causing an ows:ExceptionReport. Not sure why. I also needed to remove 
the xerces dependencies in the release module.

Nice work! You are pretty close.

Now just that pesky Xalan (app-schema GeoServer plugin, so off-topic). 
Any XSLT gurus willing to help backport to Xalan 2.6 (in the JDK)?
https://jira.codehaus.org/browse/GEOS-5352

Kind regards,
Ben.

On 23/10/12 08:29, Justin Deoliveira wrote:
> Hi all,
>
> So I recently I took a crack at removing the xerces dependency as we
> discussed in our last skype meeting. For the most part this was
> relatively straight forward. Unfortunately one thing i wasn't quite able
> to figure out was some stuff in app-schema-resolver module. The
> AppSchemaValidator class uses an implementation of what
> was XMLEntityResolver directly in xerces. I tried porting this to the
> jaxp EntityResolver interface which is included in the JDK, but couldn't
> make it work. So I think i will need some help there. Or we can simply
> keep xerces as a dependency of just app-schema.
>
> Here is the branch I am currently working on.
>
> https://github.com/jdeolive/geotools/tree/noxmldeps
> And the corresponding geoserver branch:
>
> https://github.com/jdeolive/geoserver/tree/noxmldeps
>
> WIth these changes all unit tests pass in both code bases, and so do the
> GeoServer cite tests.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Andrea Aime]

On Thu, Oct 25, 2012 at 9:24 PM, Gabriel Roldan  wrote:
> re xerces, we'd also need to exclude it from the JTS dependency:
> [INFO] |  +- com.vividsolutions:jts:jar:1.12:compile
> [INFO] |  |  \- xerces:xercesImpl:jar:2.7.1:compile (version managed from 
> 2.4.0)
>
> I'm in favor of reducing the number of embedded databases, but taking
> bdb je off might be good enough for the time being. The effort of
> writing a new epsg factory might not worth the benefit if only looking
> to reducing the permgen stress.
> I _think_ heavy use of dynamic proxies and bytecode instrumentation
> (although it doesn't look like we have cglib in the classpath) makes
> for more classes loaded than a small lib like hsql. Yet a worthy goal
> for general consistency perhaps.
>
> On the other hand, the JVM permgen space is going to be removed[1] in
> upcoming updates of the oracle jvm as they integrate more JRockIt
> code, and it is already removed on OpenJDK[1]
>
> So +1 on removing unnecessary/overlapping dependencies, but not so
> sure permgen is _the_ motivation to do that.
>
> [1] 
> 
> [2] 

Nice, I did not know that they were going to kill the permgen in the 7.x series,
though it was slated for 8.x

That said, the diet is still in order :-)

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Michael Bedward]

Thanks for that explanation Justin.

I know Martin still tries to cater for Java < 1.5 but xerces is not
used in any of the core classes that make up the JTS maven artifacts.

Michael

On 26 October 2012 10:40, Justin Deoliveira  wrote:
>
> Btw, i did this on the branch i pushed up, that is added an exclusion on the
> jts dependency. I can't remember exactly what JTS uses it for but its part
> of the "IO" packages which i don't think are really used anywhere by
> GeoTools. I could be wrong.
>
> To sum up Michael, as of java 1.6 (might even be 1.5) the java runtime ships
> with an internal version of xerces, so its technically not needed. But its
> not exposed directly (or at least in the proprietary package com.sun). So
> using it involves using a new "jaxp" / javax.xml api.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

On Thu, Oct 25, 2012 at 5:48 PM, Michael Bedward
wrote:

> On 26 October 2012 06:24, Gabriel Roldan  wrote:
> > re xerces, we'd also need to exclude it from the JTS dependency:
> > [INFO] |  +- com.vividsolutions:jts:jar:1.12:compile
> > [INFO] |  |  \- xerces:xercesImpl:jar:2.7.1:compile (version managed
> from 2.4.0)
> >
>
> The JTS jars from Maven only include the core stuff. I build and
> deploy them for Martin when he releases new versions. A quick grep of
> the sources shows that although xerces is declared as a dependency it
> is not actually used in any of the core classes. The only reference to
> it at all is a commented-out line in KMLReaderExample.java.  So, when
> Martin releases JTS 1.13 I can remove the redundant xerces dependency
> from the JTS pom (assuming that it still isn't required).
>
> Caveat: I actually have no idea what this thread is about or why
> xerces is a problem - I just saw Gabriel's reference to JTS.
>

Btw, i did this on the branch i pushed up, that is added an exclusion on
the jts dependency. I can't remember exactly what JTS uses it for but its
part of the "IO" packages which i don't think are really used anywhere by
GeoTools. I could be wrong.

To sum up Michael, as of java 1.6 (might even be 1.5) the java runtime
ships with an internal version of xerces, so its technically not needed.
But its not exposed directly (or at least in the proprietary package
com.sun). So using it involves using a new "jaxp" / javax.xml api.

>
> Michael
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Michael Bedward]

On 26 October 2012 06:24, Gabriel Roldan  wrote:
> re xerces, we'd also need to exclude it from the JTS dependency:
> [INFO] |  +- com.vividsolutions:jts:jar:1.12:compile
> [INFO] |  |  \- xerces:xercesImpl:jar:2.7.1:compile (version managed from 
> 2.4.0)
>

The JTS jars from Maven only include the core stuff. I build and
deploy them for Martin when he releases new versions. A quick grep of
the sources shows that although xerces is declared as a dependency it
is not actually used in any of the core classes. The only reference to
it at all is a commented-out line in KMLReaderExample.java.  So, when
Martin releases JTS 1.13 I can remove the redundant xerces dependency
from the JTS pom (assuming that it still isn't required).

Caveat: I actually have no idea what this thread is about or why
xerces is a problem - I just saw Gabriel's reference to JTS.

Michael

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Gabriel Roldan]

re xerces, we'd also need to exclude it from the JTS dependency:
[INFO] |  +- com.vividsolutions:jts:jar:1.12:compile
[INFO] |  |  \- xerces:xercesImpl:jar:2.7.1:compile (version managed from 2.4.0)

I'm in favor of reducing the number of embedded databases, but taking
bdb je off might be good enough for the time being. The effort of
writing a new epsg factory might not worth the benefit if only looking
to reducing the permgen stress.
I _think_ heavy use of dynamic proxies and bytecode instrumentation
(although it doesn't look like we have cglib in the classpath) makes
for more classes loaded than a small lib like hsql. Yet a worthy goal
for general consistency perhaps.

On the other hand, the JVM permgen space is going to be removed[1] in
upcoming updates of the oracle jvm as they integrate more JRockIt
code, and it is already removed on OpenJDK[1]

So +1 on removing unnecessary/overlapping dependencies, but not so
sure permgen is _the_ motivation to do that.

[1] 

[2] 

On Thu, Oct 25, 2012 at 6:58 AM, Andrea Aime
 wrote:
> On Thu, Oct 25, 2012 at 12:39 AM, Jody Garnett  wrote:
>> So what do we have let for embedded database solution? hsql for gt-epsg-hsql
>> ...
>
> Right, at the moment we have hsql in geotools for the EPSG database, and
> Berkely DB + H2 in GeoServer for other purposes
>
> Berkely DB can be removed on trunk using H2 instead, which is also used
> by superoverlays.
> I did try to make a H2 based EPSG factory but that did not go so well,
> and the hsql we are using is way outdated too (version 2.2 is out)
>
> Not sure what to do about it... maybe retry to do a epsg-h2?
> However one thing I'm sure about, I don't have the bandwidth to maintain
> two epsg factories, so I we ever went for epsg-h2 I'd have to drop
> support for epsg-hsql right away
>
> The other issue we have is that we're using a way old version of H2,
> but to upgrade it we'd have to upgrade it everywhere, in geotools,
> geoserver and geowebcache...
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Andrea Aime]

On Thu, Oct 25, 2012 at 12:39 AM, Jody Garnett  wrote:
> So what do we have let for embedded database solution? hsql for gt-epsg-hsql
> ...

Right, at the moment we have hsql in geotools for the EPSG database, and
Berkely DB + H2 in GeoServer for other purposes

Berkely DB can be removed on trunk using H2 instead, which is also used
by superoverlays.
I did try to make a H2 based EPSG factory but that did not go so well,
and the hsql we are using is way outdated too (version 2.2 is out)

Not sure what to do about it... maybe retry to do a epsg-h2?
However one thing I'm sure about, I don't have the bandwidth to maintain
two epsg factories, so I we ever went for epsg-h2 I'd have to drop
support for epsg-hsql right away

The other issue we have is that we're using a way old version of H2,
but to upgrade it we'd have to upgrade it everywhere, in geotools,
geoserver and geowebcache...

Cheers
Andrea


-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Ian Schneider]

>>> However, it does not make sense to duplicate what we already have for
>>> free, either.
>>> If it's not too much trouble, why not remove those as well?
>>>
>>
>> +1 - seems like removing them could help more with like our weird memory
>> bloat more than the actual download size no?

Just so everyone is clear about permgen and jars in the classpath (at
least on the oracle vm):
  if a class is not loaded (it's in a jar but never referenced in
executing code), it will take up no (consequential) memory

The only overhead from a jar being on the classpath (without being
actually used directly) is service (META-INF) and spring context
scanning, but jar info is cached in the standard java classloader and
zip access is fast, so this shouldn't be a primary concern.

Other stuff about permgen:
- permgen growth is not predictable - classes do not appear to end up
there immediately upon load
- permgen size per class may vary over time as code is compiled (code
is only compiled once it has run a certain number of times)

> I actually didn't measure any noticeable difference after removing xerces,
> although I was only trying to measure permgen overhead which unfortunately
> doesn't give you any information about individual class sizes.

At the moment, it doesn't seem to be possible to trace permgen size of
a given class.

The best rules to reduce permgen bloat are:
1) reduce the number of classes and interfaces loaded, whether real or
proxy or otherwise
2) have simpler, smaller methods that result in less byte code and
therefore simple/smaller compiled code
3) make sure classes aren't loaded twice (either via difference
classloaders - probably not an issue here)

With respect to xerces, checking a geoserver heap dump, it is indeed
loaded twice - once from the xerces jar, once from the sun
repackaging. This should result in something, but will be hard to
measure.

Either way, I'm a fan of removing things not needed :)

-- 
Ian Schneider
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Jody Garnett]

So what do we have let for embedded database solution? hsql for gt-epsg-hsql 
... 

-- 
Jody Garnett


On Thursday, 25 October 2012 at 12:02 AM, David Winslow wrote:

> Having poked around with MAT (http://www.eclipse.org/mat/) a few weeks back, 
> I think we'll get a decent win by avoiding the use of two embedded database 
> solutions.  Both H2 and BerkeleyDB had disk caches taking up around 4MB in my 
> minimally configured GeoServer test instance.
> 
> --
> David Winslow
> OpenGeo - http://opengeo.org/
> 
> On Wed, Oct 24, 2012 at 9:13 AM, Justin Deoliveira  (mailto:jdeol...@opengeo.org)> wrote:
> > 
> > 
> > On Tue, Oct 23, 2012 at 1:49 PM, Chris Holmes  > (mailto:chol...@opengeo.org)> wrote:
> > > 
> > > 
> > > On Tue, Oct 23, 2012 at 9:08 AM, Andrea Aime 
> > > mailto:andrea.a...@geo-solutions.it)> 
> > > wrote:
> > > > On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira 
> > > > mailto:jdeol...@opengeo.org)> wrote:
> > > > 
> > > > > Indeed. And also while we are at it i will pose the question. There 
> > > > > is also
> > > > > the opportunity to prune out some other xml dependencies as well. 
> > > > > Namely
> > > > > jdom, xpp and stax from what i can tell. All seem to have equivalents 
> > > > > built
> > > > > into the jdk. Is it worth pruning them out?
> > > > 
> > > > Well, it is not a win as big as with Xerces:
> > > > 
> > > > aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> > > > ls -lh stax-*
> > > > -rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
> > > > -rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
> > > > aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> > > > ls -lh jdom*
> > > > -rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
> > > > aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls 
> > > > -lh xpp*
> > > > -rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
> > > > -rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar
> > > > 
> > > > However, it does not make sense to duplicate what we already have for
> > > > free, either.
> > > > If it's not too much trouble, why not remove those as well?
> > > > 
> > > 
> > > +1 - seems like removing them could help more with like our weird memory 
> > > bloat more than the actual download size no? 
> > >  
> > > 
> > > 
> > 
> > 
> > I actually didn't measure any noticeable difference after removing xerces, 
> > although I was only trying to measure permgen overhead which unfortunately 
> > doesn't give you any information about individual class sizes. 
> > > > Cheers
> > > > Andrea
> > > > 
> > > > --
> > > > ==
> > > > Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> > > > more information.
> > > > ==
> > > > 
> > > > Ing. Andrea Aime
> > > > @geowolf
> > > > Technical Lead
> > > > 
> > > > GeoSolutions S.A.S.
> > > > Via Poggio alle Viti 1187
> > > > 55054  Massarosa (LU)
> > > > Italy
> > > > phone: +39 0584 962313 (tel:%2B39%200584%20962313)
> > > > fax: +39 0584 1660272 (tel:%2B39%200584%201660272)
> > > > mob: +39 339 8844549 (tel:%2B39%20%20339%208844549)
> > > > 
> > > > http://www.geo-solutions.it
> > > > http://twitter.com/geosolutions_it
> > > > 
> > > > ---
> > > > 
> > > > --
> > > > Everyone hates slow websites. So do we.
> > > > Make your web apps faster with AppDynamics
> > > > Download AppDynamics Lite for free today:
> > > > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > > > ___
> > > > GeoTools-Devel mailing list
> > > > GeoTools-Devel@lists.sourceforge.net 
> > > > (mailto:GeoTools-Devel@lists.sourceforge.net)
> > > > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> > > 
> > 
> > 
> > 
> > -- 
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
> > 
> > 
> > --
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > ___
> > GeoTools-Devel mailing list
> > GeoTools-Devel@lists.sourceforge.net 
> > (mailto:GeoTools-Devel@lists.sourceforge.net)
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> > 
> 
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> 
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net 
> (mailto:GeoTools-Devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> 


-

Re: [Geotools-devel] removing xerces dependency

[David Winslow]

Having poked around with MAT (http://www.eclipse.org/mat/) a few weeks
back, I think we'll get a decent win by avoiding the use of two embedded
database solutions.  Both H2 and BerkeleyDB had disk caches taking up
around 4MB in my minimally configured GeoServer test instance.

--
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Oct 24, 2012 at 9:13 AM, Justin Deoliveira wrote:

>
>
> On Tue, Oct 23, 2012 at 1:49 PM, Chris Holmes  wrote:
>
>>
>>
>> On Tue, Oct 23, 2012 at 9:08 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira 
>>> wrote:
>>>
>>> > Indeed. And also while we are at it i will pose the question. There is
>>> also
>>> > the opportunity to prune out some other xml dependencies as well.
>>> Namely
>>> > jdom, xpp and stax from what i can tell. All seem to have equivalents
>>> built
>>> > into the jdk. Is it worth pruning them out?
>>>
>>> Well, it is not a win as big as with Xerces:
>>>
>>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
>>> ls -lh stax-*
>>> -rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
>>> -rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
>>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
>>> ls -lh jdom*
>>> -rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
>>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls
>>> -lh xpp*
>>> -rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
>>> -rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar
>>>
>>> However, it does not make sense to duplicate what we already have for
>>> free, either.
>>> If it's not too much trouble, why not remove those as well?
>>>
>>>
>> +1 - seems like removing them could help more with like our weird memory
>> bloat more than the actual download size no?
>>
>>
> I actually didn't measure any noticeable difference after removing xerces,
> although I was only trying to measure permgen overhead which unfortunately
> doesn't give you any information about individual class sizes.
>
>>  Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>>> more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054  Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39 339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>>
>>> --
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

On Tue, Oct 23, 2012 at 1:49 PM, Chris Holmes  wrote:

>
>
> On Tue, Oct 23, 2012 at 9:08 AM, Andrea Aime  > wrote:
>
>> On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira 
>> wrote:
>>
>> > Indeed. And also while we are at it i will pose the question. There is
>> also
>> > the opportunity to prune out some other xml dependencies as well. Namely
>> > jdom, xpp and stax from what i can tell. All seem to have equivalents
>> built
>> > into the jdk. Is it worth pruning them out?
>>
>> Well, it is not a win as big as with Xerces:
>>
>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
>> ls -lh stax-*
>> -rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
>> -rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
>> ls -lh jdom*
>> -rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
>> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls
>> -lh xpp*
>> -rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
>> -rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar
>>
>> However, it does not make sense to duplicate what we already have for
>> free, either.
>> If it's not too much trouble, why not remove those as well?
>>
>>
> +1 - seems like removing them could help more with like our weird memory
> bloat more than the actual download size no?
>
>
I actually didn't measure any noticeable difference after removing xerces,
although I was only trying to measure permgen overhead which unfortunately
doesn't give you any information about individual class sizes.

>  Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
>> more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> ---
>>
>>
>> --
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Chris Holmes]

On Wed, Oct 24, 2012 at 2:45 AM, Andrea Aime
wrote:

> On Tue, Oct 23, 2012 at 7:49 PM, Chris Holmes  wrote:
>
> >> However, it does not make sense to duplicate what we already have for
> >> free, either.
> >> If it's not too much trouble, why not remove those as well?
> >>
> >
> > +1 - seems like removing them could help more with like our weird memory
> > bloat more than the actual download size no?
>
> Indeed.
> Also, to lower our memory bloat the next big win is to switch to GWC 1.4.x
> and
> have the disk quota mechanism work off H2 instead of Berkely DB (a 2MB
> win, also noticeable in the downloads)
>
>
Any reason not to do that soon? I'd love to see those improvements on
GeoServer master, I've psyched to read about the advances on the GWC list,
sounds like great work Andrea. And it seems like it'd be good to get in
sooner rather than later so we can start ironing out any bugs.


> Cheers
> Andrea
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Andrea Aime]

On Tue, Oct 23, 2012 at 7:49 PM, Chris Holmes  wrote:

>> However, it does not make sense to duplicate what we already have for
>> free, either.
>> If it's not too much trouble, why not remove those as well?
>>
>
> +1 - seems like removing them could help more with like our weird memory
> bloat more than the actual download size no?

Indeed.
Also, to lower our memory bloat the next big win is to switch to GWC 1.4.x and
have the disk quota mechanism work off H2 instead of Berkely DB (a 2MB
win, also noticeable in the downloads)

Cheers
Andrea



-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Chris Holmes]

On Tue, Oct 23, 2012 at 9:08 AM, Andrea Aime
wrote:

> On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira 
> wrote:
>
> > Indeed. And also while we are at it i will pose the question. There is
> also
> > the opportunity to prune out some other xml dependencies as well. Namely
> > jdom, xpp and stax from what i can tell. All seem to have equivalents
> built
> > into the jdk. Is it worth pruning them out?
>
> Well, it is not a win as big as with Xerces:
>
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> ls -lh stax-*
> -rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
> -rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
> ls -lh jdom*
> -rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
> aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls
> -lh xpp*
> -rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
> -rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar
>
> However, it does not make sense to duplicate what we already have for
> free, either.
> If it's not too much trouble, why not remove those as well?
>
>
+1 - seems like removing them could help more with like our weird memory
bloat more than the actual download size no?


> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for
> more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Andrea Aime]

On Tue, Oct 23, 2012 at 2:59 PM, Justin Deoliveira  wrote:

> Indeed. And also while we are at it i will pose the question. There is also
> the opportunity to prune out some other xml dependencies as well. Namely
> jdom, xpp and stax from what i can tell. All seem to have equivalents built
> into the jdk. Is it worth pruning them out?

Well, it is not a win as big as with Xerces:

aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
ls -lh stax-*
-rw-r--r-- 1 aaime aaime 176K 2010-03-03 20:05 stax-1.2.0.jar
-rw-r--r-- 1 aaime aaime  26K 2010-01-25 10:01 stax-api-1.0.1.jar
aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$
ls -lh jdom*
-rw-r--r-- 1 aaime aaime 150K 2010-01-25 08:47 jdom-1.0.jar
aaime@hydra:~/devel/git-gs/src/web/app/target/geoserver/WEB-INF/lib$ ls -lh xpp*
-rw-r--r-- 1 aaime aaime 118K 2010-01-25 09:18 xpp3-1.1.3.4.O.jar
-rw-r--r-- 1 aaime aaime  25K 2010-01-25 09:58 xpp3_min-1.1.4c.jar

However, it does not make sense to duplicate what we already have for
free, either.
If it's not too much trouble, why not remove those as well?

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Justin Deoliveira]

On Tue, Oct 23, 2012 at 3:02 AM, Andrea Aime
wrote:

> On Tue, Oct 23, 2012 at 2:29 AM, Justin Deoliveira 
> wrote:
>
>> Hi all,
>>
>> So I recently I took a crack at removing the xerces dependency as we
>> discussed in our last skype meeting. For the most part this was relatively
>> straight forward. Unfortunately one thing i wasn't quite able to figure out
>> was some stuff in app-schema-resolver module. The AppSchemaValidator class
>> uses an implementation of what was XMLEntityResolver directly in xerces. I
>> tried porting this to the jaxp EntityResolver interface which is included
>> in the JDK, but couldn't make it work. So I think i will need some help
>> there. Or we can simply keep xerces as a dependency of just app-schema.
>>
>> Here is the branch I am currently working on.
>>
>>   https://github.com/jdeolive/geotools/tree/noxmldeps
>>
>> And the corresponding geoserver branch:
>>
>>   https://github.com/jdeolive/geoserver/tree/noxmldeps
>>
>> WIth these changes all unit tests pass in both code bases, and so do the
>> GeoServer cite tests.
>>
>
> Well done! Hopefully Ben & co will chime in for the last push on app-schema
>

Indeed. And also while we are at it i will pose the question. There is also
the opportunity to prune out some other xml dependencies as well. Namely
jdom, xpp and stax from what i can tell. All seem to have equivalents built
into the jdk. Is it worth pruning them out?

>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] removing xerces dependency

[Andrea Aime]

On Tue, Oct 23, 2012 at 2:29 AM, Justin Deoliveira wrote:

> Hi all,
>
> So I recently I took a crack at removing the xerces dependency as we
> discussed in our last skype meeting. For the most part this was relatively
> straight forward. Unfortunately one thing i wasn't quite able to figure out
> was some stuff in app-schema-resolver module. The AppSchemaValidator class
> uses an implementation of what was XMLEntityResolver directly in xerces. I
> tried porting this to the jaxp EntityResolver interface which is included
> in the JDK, but couldn't make it work. So I think i will need some help
> there. Or we can simply keep xerces as a dependency of just app-schema.
>
> Here is the branch I am currently working on.
>
>   https://github.com/jdeolive/geotools/tree/noxmldeps
>
> And the corresponding geoserver branch:
>
>   https://github.com/jdeolive/geoserver/tree/noxmldeps
>
> WIth these changes all unit tests pass in both code bases, and so do the
> GeoServer cite tests.
>

Well done! Hopefully Ben & co will chime in for the last push on app-schema

Cheers
Andrea

-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] removing xerces dependency

[Justin Deoliveira]

Hi all,

So I recently I took a crack at removing the xerces dependency as we
discussed in our last skype meeting. For the most part this was relatively
straight forward. Unfortunately one thing i wasn't quite able to figure out
was some stuff in app-schema-resolver module. The AppSchemaValidator class
uses an implementation of what was XMLEntityResolver directly in xerces. I
tried porting this to the jaxp EntityResolver interface which is included
in the JDK, but couldn't make it work. So I think i will need some help
there. Or we can simply keep xerces as a dependency of just app-schema.

Here is the branch I am currently working on.

  https://github.com/jdeolive/geotools/tree/noxmldeps

And the corresponding geoserver branch:

  https://github.com/jdeolive/geoserver/tree/noxmldeps

WIth these changes all unit tests pass in both code bases, and so do the
GeoServer cite tests.

-Justin

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel