This content has been marked as final.
Show 5 replies
-
1. Re: PojoCache physical POJO field mapping and region
brian.stansberry Oct 5, 2006 10:10 AM (in response to ben.wang)It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.
-
2. Re: PojoCache physical POJO field mapping and region
genman Oct 5, 2006 2:47 PM (in response to ben.wang)
Why couldn't you create a node wrapper and hang your meta data from it?class DelegatingNode implements Node { Node delegate; ... } class PojoNode extends DelegatingNode { Object secretData; }
Or...
There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user.
Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data. -
3. Re: PojoCache physical POJO field mapping and region
ben.wang Oct 5, 2006 10:45 PM (in response to ben.wang)"bstansberry@jboss.com" wrote:
It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.
I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API? -
4. Re: PojoCache physical POJO field mapping and region
ben.wang Oct 5, 2006 11:04 PM (in response to ben.wang)"genman" wrote:
Why couldn't you create a node wrapper and hang your meta data from it?class DelegatingNode implements Node { Node delegate; ... } class PojoNode extends DelegatingNode { Object secretData; }
Or...
There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user.
Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data.
This is certainly interesting to hide the internal fields from the users. But this will involve the underlying Cache design change either with a new API. Or if we access it directly, how do we go through the cache interceptor chain?
I have created a Jira to diiscuss it:
http://jira.jboss.com/jira/browse/JBCACHE-797
Thanks,
-Ben -
5. Re: PojoCache physical POJO field mapping and region
brian.stansberry Oct 6, 2006 12:31 PM (in response to ben.wang)"ben.wang@jboss.com" wrote:
"bstansberry@jboss.com" wrote:
It would be good if when I call getChildrenNames() the resulting set doesn't include _JBossInternal_. Having that exposed to user code as a child is the only downside I see to what you propose.
I know you have told me before but what exactly is the usage for getChildrenNames() again? I mean can PojoCache provide that kind of functionality such that you don't need to use the underlying cache API?
The specific use case it the root of the region is the root of the webapp; the children are the sessions. A call to getChildrenNames() provides the ids of all the sessions in the cache.
That's the specific case, but I think it's a general problem. Node higher in the tree defines some category; children represent specific instances. I think a general solution of some sort (e.g. like Elias mentions) is appropriate.
As a sophisticated user I can of course get around this by removing _JBossInternal_ from the set. But that's a hack.
You could provide some kind of PojoCache function to replace the getChildrenNames() call, but the usage here is really a plain cache usage.