You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/12/20 17:51:29 UTC
MetadataException when using Sets in 1:n relationships
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)
...
2. I use the XDoclet module and the documentation of it claims that:
http://db.apache.org/ojb/docu/guides/xdoclet-module.html#ojb.collection:
"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
necessary."
So at least XDoclet module documentation is wrong or the module itself is broken.
3. This error was reported repeatedly:
http://www.mail-archive.com/ojb-user@db.apache.org/msg03124.html
(without reaction)
http://www.mail-archive.com/ojb-user@db.apache.org/msg03153.html
(same person again with useless reaction)
http://www.mail-archive.com/ojb-user@db.apache.org/msg04047.html
(don't know what the reaction shall mean)
http://www.mail-archive.com/ojb-user@db.apache.org/msg03299.html
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.
5. Would just setting the collection-class help? Or do I need to implement
ManageableCollection?
I have not tested all and everything like setting collection-class I have
somewhat longer release cycles at the moment (no direct access to a running
machine). I would be fine if you can answer the questions though.
Thanks for your help.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: MetadataException when using Sets in 1:n relationships
Posted by Thomas Dudziak <to...@first.fhg.de>.
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:
>http://db.apache.org/ojb/docu/guides/xdoclet-module.html#ojb.collection:
>"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
>necessary."
>
>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:
>http://www.mail-archive.com/ojb-user@db.apache.org/msg03124.html
>(without reaction)
>http://www.mail-archive.com/ojb-user@db.apache.org/msg03153.html
>(same person again with useless reaction)
>http://www.mail-archive.com/ojb-user@db.apache.org/msg04047.html
>(don't know what the reaction shall mean)
>http://www.mail-archive.com/ojb-user@db.apache.org/msg03299.html
>
>
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
>ManageableCollection?
>
>
Both (see above).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org