-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Hibernate "Class" Type and Primitive Classes
PostPosted: Sat Sep 23, 2006 11:43 am 
Newbie

Joined: Sat Sep 23, 2006 10:47 am
Posts: 2
Location: Halifax Canada
While working on a library to persist the method calls and return values on a proxy object (for auto-generation of mock objects) I ran into an issue with using the Hibernate "class" property type that I'd like to get some feedback on and if possible, implement some new functionality to submit to the project.

While working on persisting the arguments to a method call I established that storing just the arguments themselves was not sufficient, I needed to also store their Class. I believe this was to accomodate the use of primtive data types (i.e. int vs Integer) in calls to the Java reflection API. I discovered that Java uses some class constants to represent primitive classes specifically for use in reflection. (i.e. int.class, float.class, etc)

These class objects return a flat name of "int" or "float", and calling Class.forName("int") is obviously not going to work.

When I attempted to store these primitive class objects as Hibernate's class type, I get a natural no such class exception.

The relevant portion of my hbm.xml looks like this:

Code:
<list name="argumentTypes" access="field" lazy="false">
  <key column="argumentTypeId" />
  <list-index column="sortOrder" />
  <element type="class" />
</list>


The exception originates in org.hibernate.type.ClassType:

Code:
try {
  return ReflectHelper.classForName(str);
}
catch (ClassNotFoundException cnfe) {
  throw new HibernateException("Class not found: " + str);
}


And the ReflectHelper call looks like so:

Code:
      try {
         ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
         if (contextClassLoader!=null) {
            return contextClassLoader.loadClass(name);
         }
         else {
            return Class.forName(name);
         }
      }
      catch (Exception e) {
         return Class.forName(name);
      }


I was wondering what others thought about whether or not this functionality is a good idea, if these classes should be considered impure and not supported, or if there's a glaring alternative I'm missing. If the consensus is for the first option I'll put together a patch and make a submission, if not I'll see if I can track down an alternate route.

Thanks.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.