Re: [Geotools-devel] Adding a GeoTools.shutdown() method

christian.muel...@nvoe.at ha scritto: > +1 for the concept. > +1 for the name GeoTools.undeploy() > > -1 onWebApplicationUnload(), geotools itself has nothing to do with > webapps, > why should UDIG call onWebApplicationUnload() ?? It should not. That method is specifically designed for J2EE cle

Re: [Geotools-devel] Adding a GeoTools.shutdown() method

+1 for the concept. +1 for the name GeoTools.undeploy() -1 onWebApplicationUnload(), geotools itself has nothing to do with webapps, why should UDIG call onWebApplicationUnload() ?? IMHO it would make sense to have a GeoTools.redploy(). To give an example: The imagemosaic-jdbc module could reread

Re: [Geotools-devel] Adding a GeoTools.shutdown() method

Jody Garnett ha scritto: > Thinking about that; I don't see a problem but kind of wish the > shutdown was a bit more fine grained then that (ie datastore dispose > cleaning up everything it is responsible for). > > I do like the idea of having the shutdown hook and us using it to > catch leaks. H

Re: [Geotools-devel] [ExternalEmail] Re: App schema busted?

And thanks Rini for thanking Jody. I never realised that Jody was the one who fixed it! I thought he'd just screwed up his local workspace. I did a test build without realising that by then Jody had already fixed the build. Doh. On 14/05/10 14:06, Rini Angreani wrote: > Sorry, that was my fault

Re: [Geotools-devel] App schema busted?

Sorry, that was my fault. I only ran maven on trunk, and forgot to do the same on 2.6.x before committing. Thank's for fixing it, Jody. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/App-schema-busted-tp5048859p5049695.html Sent from the geotools-devel mailing list arch

Re: [Geotools-devel] Encode using XSD with element

Hi Ben & Justin, I think I might be wrong of saying the EMF model not handling element, as when I step thru the code at org.geotools.xml.Schemas (breakpoint at line 831), I can see the particle has an xs:any element (org.eclipse.xsd.impl.xsdparticlei...@f16568 (element: [xs:any: null]) (minOc

Re: [Geotools-devel] [ExternalEmail] Re: App schema busted?

Oh, I saw in your later email that this is fixed. On 14/05/10 11:25, Ben Caradoc-Davies wrote: > Jody, > > I can confirm that it compiles just fine for me in a clean up-to-date 2.6.x. > > Did you locally apply part of your patch for GEOT-3055 (promote Query to > class) to 2.6.x? I think that patch

Re: [Geotools-devel] App schema busted?

Jody, I can confirm that it compiles just fine for me in a clean up-to-date 2.6.x. Did you locally apply part of your patch for GEOT-3055 (promote Query to class) to 2.6.x? I think that patch has only been accepted and committed (by Michael Bedward) to trunk. On 2.6.x, Query is still an interfa

Re: [Geotools-devel] Encode using XSD with element

Justin, do you know if the version of EMF we are using (ecore-2.2.2 and xsd-2.2.2) even support the element as a content model? If so, how should it appear in the XSDTypeDefinition? Florence reports seeing no elements in the EMF model of the parsed schema. Kind regards, Ben. On 12/05/10 22:

Re: [Geotools-devel] Tagging 2.6.4

So Victor: You should be able to build geoserver against the following tag: - http://svn.osgeo.org/geotools/tags/2.6.4 I always / always have a little trouble getting the build of a branch going; as it trips up over a geotools javadoc maven thing that is not built yet. Still not sure how to get a

[Geotools-devel] Hudson build is back to normal: geotools-2.6.x #347

See -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lis

[Geotools-devel] Tagging 2.6.4

Fixed. Tagging 2.6.4 and will deploy shortly. I am going to "hold this tag" until GeoServer CITE tests are passed. Jody On 14/05/2010, at 9:40 AM, Jody Garnett wrote: > Hi Ben; my checkout is busted due to failure in app-schema - based on the > failure I suspect it due to applying patches bet

[Geotools-devel] App schema busted?

Hi Ben; my checkout is busted due to failure in app-schema - based on the failure I suspect it due to applying patches between trunk and 2.6.x and not building? /Users/jody/java/geotools/2.6.x/modules/unsupported/app-schema/app-schema/src/main/java/org/geotools/data/complex/DataAccessMappingFeat

Re: [Geotools-devel] Adding a GeoTools.shutdown() method

Thinking about that; I don't see a problem but kind of wish the shutdown was a bit more fine grained then that (ie datastore dispose cleaning up everything it is responsible for). I do like the idea of having the shutdown hook and us using it to catch leaks. Jody On 14/05/2010, at 2:07 AM, An

[Geotools-devel] Build failed in Hudson: geotools-2.6.x #346

See Changes: [aaime] GEOT-3081, LabelPainter treats halo radius as an integer -- [...truncated 10301 lines...] at org.geotools.renderer.shape.ShapefileRenderer.computeScale(Shapefil

[Geotools-devel] [jira] Created: (GEOT-3081) LabelPainter treats halo radius as an integer

LabelPainter treats halo radius as an integer - Key: GEOT-3081 URL: http://jira.codehaus.org/browse/GEOT-3081 Project: GeoTools Issue Type: Bug Components: core render Affects Version

Re: [Geotools-devel] Adding a GeoTools.shutdown() method

Sounds like a great idea to me. On 10-05-13 10:07 AM, Andrea Aime wrote: > Hi, > looking into why GeoServer leaks permgen memory on application > redeploy in web containers I've found a number of problems in > Geotools, mostly related to referencing and coverages: referencing > keeps threads open

Re: [Geotools-devel] Proposed Mosaicing GeoRaster Module

Christian, As per your statements below, it seems that at this time the functionality Baskar is working on for this purpose is not yet justified for inclusion in the GeoTools libraries themselves but we intend to keep working on this functionality and appreciate your guidance thus far. We need

[Geotools-devel] Adding a GeoTools.shutdown() method

Hi, looking into why GeoServer leaks permgen memory on application redeploy in web containers I've found a number of problems in Geotools, mostly related to referencing and coverages: referencing keeps threads open and uses thread locals, the coverages subsystem registers operations and similar obj

[Geotools-devel] Build failed in Hudson: geotools-2.6.x #345

See Changes: [ang05a] Matthew Birk's patch for GEOS-3807: maxFeature parameter in app-schema doesn't work for denormalised views -- [...truncated 10354 lines...] at org.geotools.re

[Geotools-devel] Build failed in Hudson: geotools-2.6.x #344

See Changes: [ang05a] Make toXlinkHref function works with feature chaining. [ang05a] Make toXlinkHref function works with feature chaining. -- [...truncated 10299 lines...] at sun.

Re: [Geotools-devel] FEST GUI unit testing library

Thanks Andrea. I've only played with it briefly so far but it looks very useful. Michael On 13 May 2010 17:18, Andrea Aime wrote: > > Well, it would be a test dependency in a single module (or a limited > number of modules) > > I don't see a problem with that. Happy FEaSTing :-) > > Cheers > And

Re: [Geotools-devel] FEST GUI unit testing library

Michael Bedward ha scritto: > Hi folks, > > For the current work on the swing module I'd like to make use of the > FEST library to test Swing components with JUnit 4.5... > > http://code.google.com/p/fest/ > > It's available from maven central, the jars are relatively small and I > think it only

[Geotools-devel] FEST GUI unit testing library

Hi folks, For the current work on the swing module I'd like to make use of the FEST library to test Swing components with JUnit 4.5... http://code.google.com/p/fest/ It's available from maven central, the jars are relatively small and I think it only pulls in one transitive dependency: commons-c