Abe White wrote:
>
> I've committed an equivalent patch to 0.9.7 in SVN revision 522623.
> Can you confirm whether this fixes your problem and, if so, close any
> CR you might have opened on this?
>
I've tested with /branches/0.9.7-incubating:527748 and it seems fine.
>> This works for
I've committed an equivalent patch to 0.9.7 in SVN revision 522623.
Can you confirm whether this fixes your problem and, if so, close any
CR you might have opened on this?
This works for me :) Here's a patch for 0.9.6 source. I've gone for
the
simplest solution, but it might be improved by
Abe White wrote:
>
>>> I see. Here's a proposal: in the MetaDataRepository's implementation
>>> of the RegisterClassListener interface, the repository only registers
>>> the given class if either the user has not specified a persistent
>>> types list (which we allow and in which case we attempt
I see. Here's a proposal: in the MetaDataRepository's implementation
of the RegisterClassListener interface, the repository only registers
the given class if either the user has not specified a persistent
types list (which we allow and in which case we attempt to lazily
discover persistent types)
Abe White wrote:
>
>> In the case above, another webapp has loaded the forums module,
>> causing this
>> webapp to look for the mappings in that module even though they aren't
>> available.
>>
>> I had difficulty trying to figure out how to restrict which
>> subclasses are
>> 'seen'. Ideall
In the case above, another webapp has loaded the forums module,
causing this
webapp to look for the mappings in that module even though they aren't
available.
I had difficulty trying to figure out how to restrict which
subclasses are
'seen'. Ideally I think it'd be done in the
MetaDataRepos
Abe White wrote:
>
>> AFIACT, the problem is that the openjpa.enhance.PCRegistry class
>> uses static
>> fields to store Meta information. When the second instance is
>> loaded, the
>> PCRegistry has been initialized, but doesn't contain that instance's
>> subclasses and an exception is thr
AFIACT, the problem is that the openjpa.enhance.PCRegistry class
uses static
fields to store Meta information. When the second instance is
loaded, the
PCRegistry has been initialized, but doesn't contain that instance's
subclasses and an exception is thrown
The PCRegistry has to use static m
I've been able to patch MetaDataRepository#getPCSubclasses() to work around
this problem (see below), but I'm a bit unsure about whether statics should
be used in PCRegistry or not. The listeners are stored in a static field,
which means they collect information about every application which load
