TaintedString is my own custom class that just wrapps String and deprecates toString(). I've told Hibernate to treat each varchar or text column as a TaintedString in the .hbm.xml files, but I haven't told Hibernate HOW to actually turn a varchar into a TaintedString. How do I do that? Implement org.hibernate.persister.entity.Loadable? Do I need to provide an org.hibernate.persister.entity.EntityPersister?

Here's some of UserSession.hbm.xml:


Here's some of my persistent UserSession.java class:


Here's some of TaintedString.java - the wrapper for String:


And when I try to run, I get this exception:


Hibernate has been working great for me in production for 6 years now. Since it worked before this change, looks to me like Hibernate expect to my custom string wrapper class in serialized form in the database. But the data is just stored in varchar and/or text fields as raw strings, not serialized java.lang.String objects, and certainly not as myApp.util.TaintedString objects. When Hibernate tries to deserialize it, java.io.ObjectInputStream wants the first two shorts to be some special secret Java serialization code that regular strings in the database don't start with. They are just raw strings.

So I think that I need Hibernate to know how to construct my class from a plain JDBC String. How do I let Hibernate know 1. that it needs to do that and 2. how to do that?

I thought the ensuing conversation on FreeNode#hibernate belonged here as the answer. Edited for brevity/clarity.

<sebersole> That is meant to name a "Hibernate Type" aka, an impl of org.hibernate.type.Type, which is the answer to your question. You'd use an impl of org.hibernate.type.Type to perform the mapping.

Do you *always* want to use your TaintedString in place of String? or just in certain cases?

<gpeterso> I want a TaintedString instead of String in 99% of cases and the other 1% of the time is not so important, so I went and changed them all.

<sebersole> If you wanted all replaced you could have simply asked Hibernate to use your TaintedStringType (after you implement it:) anytime it *implicitly* would have used its StringType. If you've already changed all the mappings, it's somewhat a moot point.

<gpeterso> I can change them back. How would I tell it to treat all Strings as TaintedStrings?

<sebersole> http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#types-registry

cfg.registerTypeOverride( new TaintedStringType() );

where TaintedStringType names the exposed java type of the attribute in getRegistrationKeys()

You didn't say (that i saw) how you represent this in your java model. Are the attribute values exposed as this TainedString class? What type is UserSession#sessionIdStr defined as?

<gpeterso> A TaintedString

<sebersole> OK, in your TaintedStringType#getRegistrationKeys() you'd return: new String[] { TaintedString.class.getName() }

As the docs I pointed to discuss, those keys are how Hibernate decides which mapping-type (Type) to use for attributes which do not explicitly indicate one

<gpeterso> Glad you said so. My first thought was public String[] getRegistrationKeys() { return new String[] {"org.hibernate.type.StringType"}; }

<sebersole> No, its the attribute types

<gpeterso> So TaintedStringType is a separate class from TaintedString. I pass TaintedStringType to the Configuration with cfg.registerTypeOverride()? That's better than just making TaintedString extend org.hibernate.type.StringType.

<sebersole> They are different concepts. TaintedString is your domain concept. TaintedStringType is a Hibernate concept, telling Hibernate how to handle TaintedString, how to read it, write it, what its internal mutability policy is, how to cache it, etc.

I'm planning a series of topical docs, one of which is going to be "type mapping"

<gpeterso> So I understand that to map a Basic Value Type I implement org.hibernate.type.BasicType (not in 3.2.6) OR org.hibernate.type.Type (or one of its derivatives) OR org.hibernate.usertype.UserType. Of those three org.hibernate.usertype.UserType seems the friendliest. I think I want a separate class, TaintedStringType to implement UserType.
<sebersole> UserType is a stand-in for Type
<gpeterso> Do I also need to register: cfg.registerTypeOverride( new TaintedStringType() );
<sebersole> not understanding
<sebersole> 3.2.6?!?
<sebersole> yikes
<gpeterso> If I don't register my TaintedStringType, how will Hibernate know how to deal with all the things I mapped as TaintedStrings and stored in varchar or text fields?
<sebersole> well as we already said you have 2 options
<sebersole> 1) specify type="TaintedStringType" for all attributes
<sebersole> 2) cfg.registerTypeOverride( new TaintedStringType() );
<sebersole> actually
<sebersole> not sure cfg.registerTypeOverride is even available in 3.2
<gpeterso> So in the database reverse engineering, it will know that TaintedStringType (or myApp.util.TaintedStringType) in the .hbm.xml files needs to be just TaintedString in the .java files?
<sebersole> no
<sebersole> reverse engineering wont understand that
<gpeterso> So I should register.
<sebersole> reverse engineering has a different way to hook in specific Type mappings
<sebersole> but you'd need to ask max (the hibernate-tools dude)
<sebersole> #jbosstools
<gpeterso> the reverse enginnering tools are working with myApp.util.TaintedString for varchar and text. If I registerTypeOverride, then the Hibernate runtime will do the right thing with those mappings?
<sebersole> "reverse enginnering tools are working with myApp.util.TaintedString" would mean (most likely) that it is doing (1)
<sebersole> or does it not add type=""?
<sebersole> again, you have 2 options
<sebersole> for runtime
<gpeterso> Would this be easier if I was using annotations instead of .hbm.xml files?
<sebersole> 1) specify type="TaintedStringType" for all attributes in the mappings <- this is something reverse engineering should be able to do
<sebersole> 2) cfg.registerTypeOverride( new TaintedStringType() ); <- again, not sure that is actually available in 3.2
<sebersole> you need to realize just how old 3.2 is ;)
<sebersole> its gotta be 6 years old now
<sebersole> at least
<gpeterso> I built a lot of tools around the reverse engineering component and as a result, I became afraid of upgrading it.
<sebersole> upgradng the reverse eng tool and upgrading the runtime are not necessarily linked
<gpeterso> I didn't know that. This is good news!
<sebersole> like i said, i think reveng has a way to let you specify Type (type="") as well
<gpeterso> I really appreciate your help. Thank you very much. It's very cool that Hibernate has built-in capabilities to do this - had these abilities 6 years ago!
<gpeterso> Yeah, 3.2 doesn't have registerTypeOverride.
<gpeterso> I'll upgrade. Should have done this anyway.
<sebersole> well you could also look into reveng adding those type="" attributes

Time passes...

<gpeterso> Sorry, I was thinking about reverse engineering and the Hibernate run-time as a unit. When you said type="" I thought hibernate.reveng.xml instead of SomeEntity.hbm.xml. I think I'm on the same page now.
<gpeterso> You asked about type="" attributes. Right now it says <property name="sessionIdStr" type="myApp.util.TaintedString">.
<gpeterso> If I just change that to myApp.util.TaintedStringType, you are saying that I should be good.
<sebersole> type="myApp.util.TaintedString" would work too (bit redundant), but only if you did cfg.registerTypeOverride( new TaintedStringType() ); as we already discussed
<sebersole> in fact, type="myApp.util.TaintedString" would be the same as having no type="" at all

<gpeterso> But type="myApp.util.TaintedStringType" should work without registerTypeOverride()?
<gpeterso> It's probably safer to upgrade and use registerTypeOverride() too.
<sebersole> gpeterso: right, type="myApp.util.TaintedStringType" will work without registerTypeOverride()
<sebersole> if you do both its redundant
<gpeterso> Cool. I can do that. Thanks!
<sebersole> the purpose is that registerTypeOverride needs to be done once
<sebersole> type="" would need to be done for each attribute
<sebersole> for a unique domain type (TaintedString), registerTypeOverride() makes much more sense imo
<gpeterso> Yes. Good idea. I have to implement UserType either way, so I'll do that first to see a proof of concept. Once I have things working again, I can upgrade and use registerTypeOverride(). Thanks!

P.S. (Outside of the above conversation - just for Karma)
I've upgraded to 3.6.10. I would have upgraded to Hibernate 4, but it contains/requires jboss-logging which is pure LGPL (no Classpath Exception) and I can't use LGPL for this project without a classpath exception. So I'm at the latest possible version now. Thanks for encouraging me to upgrade!