[geotk] Can I prevent Geotoolkit from spawning new threads?

[Jon Blower]

Hi Martin,

> Yes, an application could instantiate directly the PropertyEpsgFactory class
> without using any Factory at all. He would have to cache the result himself
> if he wish to, which also avoid the WeakValueHashMap issue.

I just tried this and instantiating PropertyEpsgFactory does seem to
create background threads so I get the same problem as before.  Is
there any way to separate this from the Factory architecture?

Thanks for the clarification on WeakValueHashMaps etc!

> The javax.vecmath package could also be used as a substitute of
> AffineTransform, but that would be change that I would prefer to isolate on
> a mercurial clone and would require significant work. But after that point,
> WMS/WCS implementors would still be faced to the exclusion of the whole
> java.awt.image and javax.imageio packages as well.

Well, I've just successfully run a load of classes from javax.imageio
on my local dev server, which is supposed to replicate Google's setup.
 So maybe the published whitelist is not complete, but I haven't tried
to run anything on Google's servers yet.  I'll investigate further and
publish back to the list...

Cheers, Jon

On Wed, Oct 14, 2009 at 11:02 AM, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr> wrote:
> Jon Blower a écrit :
>
>> In Google App Engine applications cannot write to the local disk
>> anyway - they must use Google's I/O abstractions to write to their
>> distributed file store.  Files can only be read from the local
>> filesystem from inside the application's WAR file.  So I was thinking
>> of packaging epsg.properties in the application's WAR and reading CRSs
>> from there.  Presumably somewhere in the GeoTk code there is a method
>> for parsing WKT that is not dependent on factories (even if it's
>> buried somewhere in a private method)?
>
> Yes, an application could instantiate directly the PropertyEpsgFactory class
> without using any Factory at all. He would have to cache the result himself
> if he wish to, which also avoid the WeakValueHashMap issue.
>
>
>> I'm not sure why Geotk needs a WeakHashMap implementation, since there
>> is one in the JDK.  I'm also not sure why weak collections need
>> background cleanup threads; entries will automatically disappear from
>> WeakHashMaps when the keys are garbage-collected.  (The JDK doesn't
>> have a WeakHashSet or Cache implementation AFAIK.)  I guess there must
>> be a reason though?
>
> Just realized that I misnamed the class in my email: Geotk provides
> Weak*Value*HashMap. The JDK WeakHashMap applies to keys, while Geotk
> WeakValueHashMap applies to values.
>
> A search for WeakValueHashMap in Google shows an amazing amount of projects
> which developped this functionality on their own (JScience, JBoss, Apache,
> ...).
>
> The garbage collector sets the referent to null in WeakReference, the
> background thread is for removing immediatly the corresponding entry from
> the Map. This is a bit different from JDK WeakHashMap, which removes the
> corresponding entry only when a method is invoked on that WeakHashMap
> instance (so Geotk has a more aggressive cleaning policy).
>
> But anyway it should not be an issue if PropertyEpsgFactory is used
> directly.
>
>
>>> The whole java.awt.geom package is excluded from this white list.
>>
>> Oh dear.  :-(  This looks like the biggest problem.  I wonder if it's
>> possible to provide awt.geom as a separate JAR in user space?  I shall
>> investigate on the GAE forums and see if I can find a reason why it's
>> omitted.
>
> The javax.vecmath package could also be used as a substitute of
> AffineTransform, but that would be change that I would prefer to isolate on
> a mercurial clone and would require significant work. But after that point,
> WMS/WCS implementors would still be faced to the exclusion of the whole
> java.awt.image and javax.imageio packages as well.
>
>        Martin
>



-- 
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm