> > If the tag implementation (not including release()) modifies the values of > > properties, then yes, we're in big trouble. This is the case I've come > > across before. > > > > I thought we had caught all of those, but want to make very sure. > > For example, if the second use of a tag sets the same value for the same > attribute on an instance being reused, the container has the right to > assume that the previous setFoo() call is still in effect.
As far as I've seen the tags are quite clean. The nested tags went AWOL on Resin in a very interesting way because internal logic changes properties for the extended tag. Fixed by caching the values when the tag executes, and setting them back when the tag completes. The fact that these all work on Resin whould have to say something for the extended tag. The pessimistic cache/reset that the nested tags have to do can be taken to the super tags. When the tag completes, set them back and then it wouldn't matter what logic was in the tag, primed from a variation of a constant, internal logic or whatever. From where I sit it's absolute container compliance for the expense of a little object overhead. When the container gets around to the release all together, we can just set to nulls or initial constants. The container has to manage the sate of the tags it's made, this would assure the contract. No? Arron. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
