I think the problem is that Bill's view of read-only is that the method 
does not change any state information (more of a pure-functional 
method), and when I am talking about read-only I mean read only fields.

I could notify the container/ interceptor which methods are read-only.

The problem with trying to get the cmp engine run off the jboss.xml tags 
is the jboss.xml tags are method oriented, as opposed to the JBossCMP 
field oriented tags.

-dain

David Jencks wrote:

> There are now 2 sets of functionality around readonly cmp entity behavior,
> and I wonder if they should be integrated a little more.
> 
> As I understand it Dain's cmp2 readonly stuff throws exceptions if you try
> to change a marked readonly value or something in a readonly bean.  The
> tags for this are in jbosscmp-jdbc.xml
> 
> Bill (+ someone?)'s interceptor stack readonly stuff doesn't throw any
> exceptions, but does prevent a readonly entity being locked in a
> transaction.  Previously I added some code that prevented a readonly entity
> ever getting store called on it.  The tags for this are in jboss.xml
> 
> Previous to Bill's update the ejbconf readonly test was doing the
> following:
> creating a readonly bean
> changing its value (which marked it dirty, I think)
> reading its value (which, since it was dirty, reread from the db, which had
> the original value)
> checking the value was unchanged.
> 
> Now, creating a readonly bean is impossible (reasonable enough), but you
> can call a setter on it.  The new value does not get written to the db, but
> does stay in the bean indefinitely.  To see this, uncomment the last line
> of the (updated) ejbconf readonly test case.
> 
> I don't think this is very desirable behavior.  I wonder if it is possible
> to run Dain's exception-throwing behavior off of the jboss.xml tags, so
> that (at least with cmp2, which is pretty much all I care about) something
> marked readonly in jboss.xml will throw exceptions from the cmp2 code if
> you try to change something.
> 
> Is this reasonable? Is there a better way?
> 
> Thanks
> david jencks
> 



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to