Joshua Portway wrote:
> It seems to me that the problem is that Geotools seems to be
> instantiating DefaultFactory even when the WKT authority is
> available, and DefaultFactory attempts to create a backing store when
> it's instantiated. This attempts to connect to a database in the
> createBackingStore method called by isAvailable() - I'd be very
> surprised if your code was doing anything differently - maybe it's
> just failing silently instead of logging exceptions?
>
> My understanding of the documentation is that the referencing module
> is supposed to look for authority services from one of the epsg jars,
> and use that. What seems to be happening is that *as well* as using
> the provided WKT jar it's also trying to instantiate the
> DefaultFactory service (since this is registered as a service in the
> referencing module itself). I haven't gone into enough detail to find
> out exactly what function DefaultFactory serves, but it looks to me
> as if it's simply providing an epsg service by looking for a JDBC
> database with the information in it. That's probably very useful, but
> it doesn't sound to me as if it should be the default fallback
> (especially since it relies on external resources). I can't see why
> it wouldn't be better if it was factored out into its own jar just
> like the WKT and hsql providers are? Presumably it would be called
> something like "epsg-jdbc" ?
>
> If it is going to be the default, then the behaviour should be
> documented because the current behaviour seems to go against the "add
> a single epsg provider jar" idea. At least - I find it confusing.
So I've looked a bit into it and during GeoServer startup
I see two JNDI lookup attempts occurring when a DefaultFactory
instantiation happens. The code is in ThreadedEPSGFactory
(as you said) and looks like:
protected DataSource createDataSource() throws SQLException {
InitialContext context = null;
DataSource source = null;
try {
context = GeoTools.getInitialContext(new Hints(hints));
source = (DataSource) context.lookup(datasourceName);
} catch (IllegalArgumentException exception) {
// Fall back on 'return null' below.
} catch (NoInitialContextException exception) {
// Fall back on 'return null' below.
} catch (NamingException exception) {
registerInto = context;
// Fall back on 'return null' below.
}
return source;
}
However for me fails fast (instantly) with a NameNotFoundException.
I think we can roll out a epsg-jndi module that contains just
a factory backed by a JNDI data source and remove DefaultFactory,
nothing seems to be using it and it's deprecated anyways.
I cannot make this change that quickly though, it needs
to be discussed with the other developers. However, this should
satisfy your need, right?
I'm still persuaded there should be something wrong in your
setup though... it's like the JNDI lookup is causing a network
lookup that cannot be satisfied and eventually times out (like
trying to to ping an address that is not attached to an existing machine).
Cheers
Andrea
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
