db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: MetadataException when using Sets in 1:n relationships
Date Thu, 23 Dec 2004 11:15:15 GMT
Joerg Heinicke wrote:

>Hello everybody,
>do you remember me, the probably only person using OTM ;-)
>When fixing an sorting bug in my application I switched an 1:n relationship from
>List to Set. Unfortunately this does not work though the documentation says it
>should as it is a Collection too. But step by step ...
>1. The exception: org.apache.ojb.broker.metadata.MetadataException: Error
>setting field:installmentRates in object:com.ewerk.erak.model.Settings
>  at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl.
>         doSet(PersistentFieldDirectAccessImpl.java:88)
>  at org.apache.ojb.broker.metadata.fieldaccess.AbstractPersistentField.
>         set(AbstractPersistentField.java:99)
>Caused by: java.lang.IllegalArgumentException
>  at sun.reflect.UnsafeObjectFieldAccessorImpl.
>         set(UnsafeObjectFieldAccessorImpl.java:63)
>  at java.lang.reflect.Field.set(Field.java:519)

Hmm, you snipped away the interesting part (where in OJB the 
IllegalArgumentException) happens. But this usually means that the 
actual type of the value which is tried to be set in the field, is not 
assignable to the declared type of that field.

>2. I use the XDoclet module and the documentation of it claims that:
>"collection-class: Specifies the class that implements the collection. This
>attribute is usually only required if the actual type of the collection object
>shall be different from the variable type. Collection classes that implement
>java.util.Collection can be handled by OJB as-is so specifying them is not
>So at least XDoclet module documentation is wrong or the module itself is broken.
Well, it could be a bit clearer (and I will update it accordingly): You 
can declare your java field (which implements the collection) with a 
java-collection type that OJB can handle, i.e. using one of the base 
interfaces Collection, List, Set, or you use a concrete collection class 
that implements ManageableCollection, either one of OJB's collection 
classes or your own. In the former case, you need to specify which 
concrete collection class OJB shall use (XDoclet tag) or OJB will use 
the default one specified in OJB.properties. In the latter case, the 
XDoclet module automatically checks that the collection class is a 
ManageableCollection and creates the descriptor accordingly.

>3. This error was reported repeatedly:
>(without reaction)
>(same person again with useless reaction)
>(don't know what the reaction shall mean)
The problem (as visible from the stacktrace) is that the field is 
declared as a HashSet (which should be Set btw.), but a 
RemovalAwareCollection was configured (probably the default setting in 
OJB.properties) which is not a subclass of HashSet (nor Set for that 
matter). So he probably forgot to specify collection-class as 
ManageableHashSet or similar.

>4. I know OJB always instantiated a RemovalAwareCollection/List. So can it
>handle my Set at all? It is not just a common Set, but my own class extending
>java.util.TreeSet, providing a default constructor that instantiates a TreeSet
>with a Comparator and providing all delegate methods that delegate to this
>TreeSet. This means if OJB would use the constructors and methods of the
>Collection interface everything should work.
As mentioned above: the default setting from OJB.properties is taken if 
no collection-class is specified for the collection. So if you want to 
use your own collection class (which has to implement 
ManageableCollection), then simply declare the field in Java with the 
java.util.Set type, and specify your class as the collection-class of 
this collection.

>5. Would just setting the collection-class help? Or do I need to implement
Both (see above).


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message