Hibernate version:
3.0.1

----

I have a set of elements to which I need to add some additional business logic methods. In other words, hibernate gives me back a "set" when it does a <set> mapping and that's not quite enough. I need a "custom" set object back that has some additional methods that allow me to do totalling and filtering.

So I headed down the CustomUserType road and did this:

* subclassed PersistentSet and added my business methods
* wrote a CustomUserType that returned my PersistentSet subclass

The general framework is working fine. The CustomUserType object is called and it returns my PersistentSet subclass.

The problem is in the code for the PersistentSet subclass. In that subclass I need access to the set object that the PersistentSet wraps. That way I can do totalling on the values contained in that set.

But checking the source, it looks like the PersistentSet's internal set object has no visibility declared in which case it gets "package" visibility by default. And with package visibility on PersistentSet's set object, subclasses outside of the PersistentSet package can't access that property.

Which is exactly what I need to do. My PersistentSet subclass needs access to the PersistentSet's "set" object so that I can do totalling and filtering.

What should I do?

Is this CustomUserType/PersistentSetSubclass technique the right thing to do just to get some business-logic methods on my set?

Is there a better way to get access to the PersistentSet's internal set object?

Many thanks!

- gary

I was able to get my aggregation and filtering code working by accessing the PersistentSet's underlying "set" indirectly via the PersistentSet.iterator() method.

So I'm good for now.

But unless I'm misunderstanding something, the UserCollectionType featue isn't all that useful unless one also creates a custom "PersistentCollection" class. And for creating those custom PersistentCollection classes the existing hibernate PersistentCollections seem like a natural place to start subclassing.

Given that it sure would be nice if the visibiilty of PersistentSet's backing "java.util.set" was changed to "private". That would make the set directly available to custom subclasses.

Or am I way off track here?

Thanks!

- Gary

its not private in cvs.

Uh, yah. That's the problem. :-)

There's no visibility modifier on the "set" object. It currently looks like this:



Meaning that it gets "package" visibility by default.

And since "package" visibility yields a property that subclasses can't access we have the problem cited above.

Changing the visibility *to* "private" would fix this. "private" visibility does allow subclasses to have direct access. Like so:



- Gary

P.S. Strictly speaking, subclasses that are located within the same package as the superclass can access objects with "package" visibility. But that's not really much help here since (I assume) most people are going to be creating subclasses that sit within their own package structure, not Hibernate's.[/code]

i think you mean protected.

put a request in jjira for it....a patch for this will make it speedier (and then include what needs to be protected in the other persistent collections)

Oh, duh. Yes, protected, not private.



I've never done a patch before so if there's some kind of procedure/format to follow it'll take a little reading to figure out how the Hibernate project likes things done.

But it's on my list.

Thanks for the response Max!

- Gary

just make a patch with diff or your favorite IDE ;)

/max