Ah that's the problem then. You're expecting them to be assigned based on
the name of the variable, but @SessionState assigns them based on their
type.
You could have in page1:
@SessionState
private String username;
In page 2:
@SessionState
private String email;
And they would be assigned to the same thing, because it's done based on the
type rather than the variable name.
I see how this would be confusing though - it does seem intuitive that they
would be assigned based on the variable name.
On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry <mgen...@masslight.net>wrote:
> Hi Donny,
>
> Thanks for the explanation, but the types might be a red herring. I'm
> less concerned about that than the fact that Tapestry seems to be
> assigning one of my variables to a different variable. It doesn't
> matter if the types are the same or different. I could've had:
>
> @SessionState(create=false)
> private List<String> list1;
> @SessionState(create=false)
> private List<String> list2;
>
> And I'd still expect to have two separate/distinct variables and
> lists, not two variables pointing to the same list (unless I
> specifically assigned them to the same list myself).
>
> Thanks,
>
> mrg
>
>
> On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny <donny.nado...@gmail.com>
> wrote:
> > Your two lists are the same - they're both of type List so they both get
> > assigned to the same thing. See below for why.
> >
> > The solution is to make two classes, one that holds the booleans, and one
> > that holds the strings. Technically you would only need to do that for
> one,
> > but it's probably a good idea to do it for both anyway.
> >
> > The reason why they're both considered the same: this has to do with how
> > generics work in Java. It's called type erasure - after the class is
> > compiled, the generic type is erased, so at runtime it doesn't care what
> the
> > type is. Generics are a compile time check.
> >
> > For example, you could do:
> > List<String> strings = new ArrayList<String>();
> > List strings2 = strings;
> > strings2.add(new Object()); //this line is fine
> > String string = strings.get(0); //throws ClassCastException
> >
> > You might think that the strings2.add(new Object()) would have a problem
> > because strings2 is pointing to strings which is an ArrayList<String>,
> but
> > it doesn't because at runtime it doesn't do any checks, or even know that
> > you put <String> there (well, there's certain ways of figuring it out,
> but
> > generally just accept that it doesn't know). All it can do is give a
> warning
> > at "List strings2 = strings" because you're doing some potentially type
> > unsafe things.
> >
> >
> > On Thu, Jan 6, 2011 at 9:38 AM, Michael Gentry <mgen...@masslight.net
> >wrote:
> >
> >> Hi everyone,
> >>
> >> Given the following page class:
> >>
> >>
> >> public class Bug
> >> {
> >> @Inject
> >> private Logger log;
> >>
> >> @SessionState(create=false)
> >> private List<Boolean> booleans;
> >>
> >> @SessionState(create=false)
> >> private List<String> strings;
> >>
> >> void onActivate()
> >> {
> >> log.debug("booleans = " + booleans);
> >> log.debug("strings = " + strings);
> >>
> >> if (booleans == null)
> >> booleans = new ArrayList<Boolean>();
> >>
> >> booleans.add(Boolean.TRUE);
> >>
> >> log.debug("booleans: " + booleans);
> >> log.debug("strings: " + strings);
> >> log.debug("equal? " + booleans.equals(strings));
> >> }
> >> }
> >>
> >> I get this output:
> >>
> >> DEBUG 2011-01-06 09:35:24,014 booleans = null
> >> DEBUG 2011-01-06 09:35:24,014 strings = null
> >> DEBUG 2011-01-06 09:35:24,014 booleans: [true]
> >> DEBUG 2011-01-06 09:35:24,014 strings: [true]
> >> DEBUG 2011-01-06 09:35:24,015 equal? true
> >>
> >>
> >> Even though I don't add anything to the strings list or even allocate
> >> the strings list, it seems to be pointing to the booleans list, which
> >> is, of course, incorrect. This seems to be happening on both 5.1 and
> >> 5.2. Am I missing something?
> >>
> >> Thanks,
> >>
> >> mrg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
