A new HsqlEpsgDatabase class has been introduced, which contains for a
significant part a copy of ThreadedHsqlEpsgFactory methods. When such a
derivated class is created, would it be possible to use "svn copy" please?
Also don't forget copyright header, @since 2.4 javadoc tag in class
descripti
Why this class is public?
org.geotools.util.ObjectCacheEntry
(by the way, this class is missing copyright header too, like most new classes
added in the threaded-epsg work).
ObjectCacheEntry seems to be internal to DefaultObjectCache implementation. If
we are not sure, I would prefer keep it p
We see the word "deadlock" used in many place in the javadoc, for example
"DEADLOCK as we wait for the writeLock to be released", "similar to getValue
except it will not DEADLOCK", etc. This is not my understanding of "deadlock".
See:
http://en.wikipedia.org/wiki/Deadlock
A more appropria
ObjectCacheEntry holds a ReadWriteLock. ReadWriteLock are used for example with
HashMap, in order to allows multiple concurrent read operations (on different
keys) while allowing only one write operation at time.
But with ObjectCacheEntry, ReadWriteLock are used on a entry-by-entry level,
which
I would like that Geotools 2.4 branch contains the old EPSG factory
implementation with class renamed, but without the work on the way.
Rational:
* Current work on EPSG-factory seems to consist in a lot of copy
and paste in every directions (referencing Pair inner class
copied in metadata
Martin Desruisseaux ha scritto:
> I would like that Geotools 2.4 branch contains the old EPSG factory
> implementation with class renamed, but without the work on the way.
Wondering... have things been done so that it's not possible
to use the old framework keeping the new one in parallel? Imho
a
Andrea Aime a écrit :
> Wondering... have things been done so that it's not possible
> to use the old framework keeping the new one in parallel?
For now the old classes are kept relatively stable. But with the work hapenning
directly in the referencing module, we will have to choose one or the ot
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> Wondering... have things been done so that it's not possible
>> to use the old framework keeping the new one in parallel?
>
> For now the old classes are kept relatively stable. But with the work
> hapenning directly in the referencing mo
Just commited some changes which are mainly javadoc and code reformating
(adding
the missing copyright headers, adding missing @since javadoc tag), editing some
comments, replaced tabulations by spaces in code). The only significant changes
in the code itself was:
1) NullObjectCache, DefaultOb
Quoting Andrea Aime <[EMAIL PROTECTED]>:
> Wondering... have things been done so that it's not possible
> to use the old framework keeping the new one in parallel?
Andrea it is the same framework. In terms of implementation I have decided not
to patch up Martin's origional superclasses (they were
Quoting Martin Desruisseaux <[EMAIL PROTECTED]>:
> ObjectCacheEntry holds a ReadWriteLock. ReadWriteLock are used for example
> with
> HashMap, in order to allows multiple concurrent read operations (on different
> keys) while allowing only one write operation at time.
>
> But with ObjectCacheEnt
11 matches
Mail list logo
