Thanks for sharing your insights on this issue! "ALRubinger" wrote : Sure, but you've set up a maintenance "gotcha" that is pretty easy to violate and will be difficult to debug. Also, you'll be less likely to see the inconsistencies exhibited in development, meaning it's likely that Peter's "weird stuff" will happen in Production. So as a general rule, I'd avoid this paradigm
Agreed. I don't like it either. That's why I brought it up ) anonymous wrote : | unless you can say: | 1) There's no cleaner way | Before asking this question I thought of two, you introduced the third, and now I don't like any of them ) anonymous wrote : | 2) Document the hell out of it to make sure the instance var is cleansed upon each invocation | Good point. anonymous wrote : | No, cluttered APIs are not pretty, though this approach *is* pretty foolproof. | Ugly or fragile? That is the question. anonymous wrote : | You can also look into: | 1) Store that parameter in a ThreadLocal | 2) Each method looks to the ThreadLocal for the value | 3) Apply an interceptor to, after invocation, clear the value of the ThreadLocal (as the Thread will also be returned to a pool). | Looks kinda the same as our discussed approach, only you have to clean a single variable. To make sure that variables are "clean" I can devote a special init() method for that, and call it each time inside my business methods. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171114#4171114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171114 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
