Well, I figured out what's going on. RequestVar and SessionVar depend upon their *class name* for uniqueness. So, you can't just create a RequestVar instance and expect uniqueness, and in fact if you create a RequestVar as a member of a reusable superclass like my JNDIResource, even with a declaration like "object foo extends RequestVar", it will be treated as the same instance in all of the subclasses. If it's created as an anonymous class, it just gets a name like DeclaringClass$$anon$1, the same class name for each instance.
BLEAH. This violated my expectations on a number of levels, and cost me several hours of hunting to figure out. I guess that if one wants to create some abstraction that simplifies the setup of some class of RequestVar instances, the only way to do so is to ensure that this abstraction is itself abstract. Of course, if someone goes to extend your abstraction, they have to know that *their* abstraction also must be abstract and never instantiated directly lest they get name collisions... This all seems far too complicated for what RequestVar is doing - associating a variable with the request handling lifecycle in a typesafe manner, though I now understand why it was done this way. So, would it break things to add some random salt to the variable name that's being mapped into that hash? I can work around the issue, I think, but it would be nice if the behavior wasn't quite so unexpected. Kris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
