Right Dain, I think read-only means read-only. That you cannot change the state of a bean. If people are going to write methods that change the state of a bean that is not supposed to change, then that's their fault. We just document this feature.
Also, Dain, you should be able to throw an exception. The flag David is talking about is marking the WHOLE bean as read-only, not just individual methods, so before you modified a field or something, you could throw an exception if the entire bean is marked read-only. Anyways, I still think that if a user marks a bean as read-only and calls a set method, that they deserve the strange behaviour they get. Although, I do think that creates should be allowed. I'll change this logic. > -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 14, 2002 11:30 AM > To: David Jencks > Cc: Bill Burke; jboss-dev > Subject: Re: Is jboss 3 readonly behavior really what we want now? > > > 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
