On 05/16/2011 12:25 PM, Jody Garnett wrote:
Why does the existing code scan classloaders?
I cannot remember; would need to check the email archives. I would
expect it is to account for environments with restrictions on class
loaders (such as OSGi or spring?).
In principle the context classloader should fix just that.
We do have the situation where a child class loader wants to advertise
a datastore implementation to the parent geotools classloader.
I would say that can be a problem in itself.
Say in your application server you have two applications A and B which
both use Geotools. Say also that the deployers chose to put the Geotools
jars in the application server's lib directory to save resources.
Geotools would then be in a system classloader (SCL) while each of the
applications could have their own classloader (ACL and BCL). SCL would
be a parent for both ACL and BCL.
If configuration changes are made visible to the parent classloader
(SCL), then application A's specific configuation will be visible to
application B (and vice versa). Worse, it may be that one of the
configurations overwrites the other (making debugging "interesting" ).
(It must be a parent because geotools defines the Factory interfaces;
so the child classloader needs a way to feed an implementation of that
factory back into GeoTools).
I don't think it should be in the parent. This assumes the factories
should JVM-wide singletons . I don't think that is correct (see above).
I would say that only the context classloader should be used (unless
that is null, then you can fallback to this.getClass().GetClassLoader()).
I don't know what you mean by context classloader?
Thread.currentThread().getContextClassLoader()
This is normally set up by the execution environment. In some cases it
is not set, but you can then safely assume there is only one classloader
the this.getClass().getClassloader() is a good fallback.
Kind regards,
Joachim
In would expect that not using the context classloader would make the
scanning fail in EE environments (like JBoss). As application servers
can mess around with the classloader quite a bit, I would assume that
any attempt to make sure it works in all environments is tricky to say
the least.
Joachim
On 05/16/2011 11:41 AM, Jan De Moerloose wrote:
Hi,
as reported in http://jira.codehaus.org/browse/GEOT-2817, there is an
issue with the FactoryRegistry combined with GWT. I noticed that there
is an effort going on to replace the SPI mechanism with something more
extensible that would work on all environments. I will try to get
involved in that, but in the mean time i would like to know if there are
any objections against a patch that would force the context class loader
to be used in all circumstances where it is present ?
--
Joachim Van der Auwera
Geosparc, supporting the Geomajas GIS community
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Joachim Van der Auwera
Geosparc, supporting the Geomajas GIS community
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
