Another Lesson for Today

whew.

So the above cookie stuff was not 100% of my problem, although a good
piece of info. Today I learned more in depth facts on how and what the
struts action "redirect" attribute is used for. If you want to chain
actions (despite it being something that is not advised) and you want
to have the client get a response and create a new request with your
desired action, you should add ' redirect="true" ' to your actions.
The default value of false, makes your desired action complete in the
same request/response cycle as the original action instead of two
separate ones.

The pros about having the same request/response cycle for the two
actions is that your request data is preserved across them. The con is
that things (like cookie deletion) require that the client be told to
remove the cookie via a response from the server, which would never
get there until after BOTH actions have ran. In my case, that was not
what I needed. By the time the client was told to delete the cookie,
it was too late. We had already tried to process other needless code
based on that cookie still being in existence. Therefore, forcing each
chained action to have its own request/response cycle fixed this
problem, because the client was being told to delete its cookie before
the server ran that second bit of code. However, that caused other
problems. Now I see why the struts spec does not encourage action
chaining :D. This same problem held for updating the cookies' value to
something useless as well, because again, the client must be told from
a response to change/delete its cookies.

Solution:

In addition to checking to see if the cookie exists, I am going to
check to see what the cookie's age is. The way things work out, we
only have 2 possibilities for the age, so that will work just fine.
Again, not the prettiest solution probably, but it gets the job done.