Yes, that confuses me too. I'm wondering whether it's anything to do with the system properties or environment set up when geotools is used inside an app server like glassfish - perhaps in your situation Geotools isn't trying to connect to JNDI because it isn't advertised in the environment (I'm afraid that my knowledge of the intimate details of JNDI is very limited so I'm just guessing here). Or - possibly - in your context you actually do want this behaviour - if you are storing your EPSG information in a data source registered in JNDI then geotools is probably doing exactly what you want it to do.
J On 21 Feb 2010, at 20:04, Andrea Aime wrote: > Joshua Portway wrote: >> Hi Andrea, >> I've checked the classpath and I don't have any of the database jars there, >> I don't think that's the problem, I also don't think it's specific to EJB3. >> The class that seems to be causing the trouble is >> org.geotools.referencing.factory.epsg.DefaultFactory which is in the >> standard referencing module jar, and is registered as a service by that jar. >> DefaultFactory inherits from ThreadedEpsgFactory, and what seems to be >> happening is that it attempts to connect to a database when isAvailable is >> called as part of the factory service discovery process - this in turn >> causes a JNDI lookup (in createBackingStore). The JNDI lookup takes a >> considerable amount of time - especially if there's no JNDI registry around >> because then my app sits and waits for a network timeout before continuing. >> The result is that every time my app does a factory lookup there's an >> enormous stall while it goes through all this JNDI stuff and eventually >> spews a load of exception logging before carrying on. >> • *The only solution that seem to work for me is to make a custom version of >> the referencing module with references to the DefaultFactory and the >> LongitudeFirstFactory classes removed from the service declarations >> *(LongitudeFirstFactory also has the same behaviour, and when I remove >> DefaultFactory I just get the same problem with that). This solution seems >> to work - the long stalls and JNDI exceptions go away, and my app still >> runs, so I presume that it's successfully falling back on the WKT module. >> This behaviour seems like a bug to me (it certainly doesn't seem to behave >> as described in the documentation), but I can't understand why nobody else >> seems to be having this problem.... > > What I'm wondering is, why none of the GeoTools or GeoServer show this > issue? We don't have long waits and timeouts... > > 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
