You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Lei Gao <ga...@tek-tools.com> on 2003/05/28 18:56:39 UTC
How do you orgnize your project directory?
Hello guys,
I want to know when you start a Structs project, generally how do you
orgnize your project directory?
Which way you think is the most comfortable way for both developing and
deploying?
Thanks for share your idea with me.
Lei
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Struts and the infamous IE multiple browser/same session problem
Posted by Michael Ruppin <mr...@yahoo.com>.
I guess you could say, "An application where those
footing the bill (Client) demand it". But, it's not
application specific, and it's not multiple sessions
we're talking about here, it's multiple browsers on
the same session. Multiple sessions are a non-issue.
Regardless of what your application is, one of the
following should be true:
1) You do nothing about multiple browsers on the
same session, and
a) You use no session data
b) You take your chances that session data may
become corrupt
2) You prevent multiple browsers on the same session
through
a) JavaScript (Risky, since it could be turned
off)
b) Synchronized Tokens?
3) You do something to segregate the session data
between browsers.
1b is not acceptable to most Clients since their data
is at risk, and when it is acceptable, you still take
the chance that you may have corrupted data to fix. 2
is acceptable for most Clients, data integrity tends
to be a higher priority than keeping the end user
happy. When, however, the Client insists on data
integrity and optimal ease of use, you're left to
implement 1a or 3.
[OT] If your real question was what "Under what
circumstances would a user want more than one browser
accessing a given application, regardless of whether
or not they have the same session�, the answers are
many. How about a warehouse application where the
Customer Service Representatives need to see Orders,
Inventory, and Customer data, at the same time? It�s
not always acceptable to anticipate what combinations
of data they need to see at the same time, and can it
into a screen. Nor is it acceptable to tell them they
have to keep navigating from one to another
constantly. The answer is, they want multiple
browsers viewing whatever datum is of interest to them
at the moment.
m
--- Doug <um...@myrealbox.com> wrote:
> Michael Ruppin wrote:
> > I'm reconsidering my approach to this problem, in
> > favor of something more elegant/more compatible
> with
> > out-of-the-box Struts. Anyone tackled this yet?
> >
> > For those not aware, MS IE allows users to launch
> a
> > browser against the same session via
> File/New/Window
> > (Ctrl-N). The issue is, if you have need to keep
> data
> > in the session (which I do), a submission from one
> > browser could grab and/or overwrite session data
> meant
> > for the other browser. This can lead to data
> > integrity problems and other weirdness. Telling
> my
> > user community not to use MS IE or it's Ctrl-N
> feature
> > is not an option.
> >
> > My current approach is to put a hidden random
> "key"
> > into the HTML, and name the session attribute with
> > that. When one of the two browsers submits a
> request
> > (Assuming, at this point, they've opened another)
> the
> > session data is pulled by key, assigned a new key,
> a
> > new copy is placed in the session named with the
> new
> > key, and the new key is rendered in the HTML
> > response. The old session data may or may not be
> > removed, depending on whether or not it is
> acceptable
> > for the browser with the old key to [gracefully]
> fail,
> > how we choose to expire session data, and whether
> or
> > not a means of dealing with stale data is
> supported by
> > the model.
> >
> > This works fine, but in doing so I've had to write
> my
> > own methods for populating collections of forms
> which
> > would have otherwise been taken care of for me by
> > specifying session scope in struts-config. Am I
> > missing a better way?
> >
> > m
>
> Out of curiosity, what kind of application do you
> have where you really
> *need* to support someone having multiple different
> sessions active at
> the same time? I'm not necessarily saying that you
> don't need this -
> I'm just wondering. You may be bending over
> backwards to solve a
> problem that real users (as opposed to testers)
> won't have.
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Struts and the infamous IE multiple browser/same session problem
Posted by Doug <um...@myrealbox.com>.
Michael Ruppin wrote:
> I'm reconsidering my approach to this problem, in
> favor of something more elegant/more compatible with
> out-of-the-box Struts. Anyone tackled this yet?
>
> For those not aware, MS IE allows users to launch a
> browser against the same session via File/New/Window
> (Ctrl-N). The issue is, if you have need to keep data
> in the session (which I do), a submission from one
> browser could grab and/or overwrite session data meant
> for the other browser. This can lead to data
> integrity problems and other weirdness. Telling my
> user community not to use MS IE or it's Ctrl-N feature
> is not an option.
>
> My current approach is to put a hidden random "key"
> into the HTML, and name the session attribute with
> that. When one of the two browsers submits a request
> (Assuming, at this point, they've opened another) the
> session data is pulled by key, assigned a new key, a
> new copy is placed in the session named with the new
> key, and the new key is rendered in the HTML
> response. The old session data may or may not be
> removed, depending on whether or not it is acceptable
> for the browser with the old key to [gracefully] fail,
> how we choose to expire session data, and whether or
> not a means of dealing with stale data is supported by
> the model.
>
> This works fine, but in doing so I've had to write my
> own methods for populating collections of forms which
> would have otherwise been taken care of for me by
> specifying session scope in struts-config. Am I
> missing a better way?
>
> m
Out of curiosity, what kind of application do you have where you really
*need* to support someone having multiple different sessions active at
the same time? I'm not necessarily saying that you don't need this -
I'm just wondering. You may be bending over backwards to solve a
problem that real users (as opposed to testers) won't have.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Struts and the infamous IE multiple browser/same session problem
Posted by Michael Ruppin <mr...@yahoo.com>.
Well, I'm not sure exactly how to implement your
solutions 1 and 3. Perhaps 1 is what I am doing? 2
might be nice, but it's not considered good to hit the
model on every submission, and there�s more to persist
than just the model. For 4, when you say "Check it
for each update request and reject the update if the
session numbers don't match", I assume you mean reject
the update if the *version* numbers don't match. The
problems with this are scenarios like the following:
Browsers 1 & 2 are on the same session, with version 1
of a form object with property Checkbox=false.
Checkbox is not part of the model. Let's assume the
form is session scoped. Browser 1 checks the checkbox
and submits a �Delete checked� request. This
navigates them to a confirmation screen. Meanwhile,
browser 2 submits something like �Refresh�. Struts
calls the reset method on this form, where, of course,
I default Checked=false. Browser 1 now submits �OK�,
to confirm the delete. The delete method finds the
form�s checkbox unchecked, and does nothing.
This situation is not so bad, but there are many
others which may be. I do a lot of nested indexed
forms. It may actually be good, if one form refreshes
the session data from the model for another, but is it
appropriate for one browser to entirely alter the list
of another, or it�s non-model components? This will
cause a lot of confusion, at minimum. My solution is
to name the session data based a number unique to each
browser. The version is still implemented, to cover
the DB issues. The problem with this solution is, I
have to do a lot of the work Struts would normally do
for me, myself.
Based on posts I�ve read concerning disabling a
browser�s Back button, it sounds like I might be able
to make use of Action token methods to prevent
�duplicate� submissions. However, as you say,
enforcing that each browser has it�s own session is
not �convenient for the user�, and some clients insist
that we support the multiple browser / same session
scenario. Other ideas, anyone?
m
m
--- Steve Raeburn <st...@ninsky.com> wrote:
> Forgive me if I'm misunderstanding something here
> because I am unaware of
> the background and previous discussions on this
> topic.
>
> This doesn't seem to just be a issue with IE.
> Mozilla and Opera both keep
> the same session if you have multiple browser
> windows open. It doesn't
> matter whether you open a new window in a separate
> tab or browser, it still
> maintains the same session.
>
> Why would you even want a browser that enforced
> separate sessions if you
> open a new window. I may want to accomplish several
> tasks or refer to
> information while I'm updating something else. There
> are any number of
> reasons why I would want multiple windows. If you
> enforced separate sessions
> then I would have to login each time I opened a
> window. Not exactly
> convenient for the user!
>
> Why is this considered a problem? The session
> represents the state for the
> user, not for a particular browser window. Each
> window is just a view of the
> model so it should not matter how many different
> views are active at any
> time. If you need to guard against inconsistent data
> then you need to be
> aware that the session is not thread safe and ensure
> that you do your own
> synchronization on any objects that you place in it.
>
> Surely, this is no more a bug than the database bug
> where data gets out of
> sync when you don't use transactions? ;-)
>
> Anyway, to avoid any problems here's a few options:
> 1. Synchronize objects that you use in the session
> 2. Don't use the session at all. Store your
> 'session' information in a
> database. Some distributed session managers do this
> for you.
> 3. Synchronize on some other session 'locking'
> object if you need to update
> multiple session objects in a transaction.
> 4. Consider using an optimistic locking system for
> your session objects. Add
> a version number property to the objects you're
> going to place in the
> session. Check it for each update request and reject
> the update if the
> session numbers don't match. (You'll still need to
> synchronize for updates
> but not for reads).
>
> Don't shoot me if the last option doesn't work. It
> just occurred to me while
> I was thing about database transactions :-)
>
> Like I said, if I've misunderstood then please
> (gently) point out of the
> error of my ways.
>
> Steve
>
>
> > -----Original Message-----
> > From: Michael Ruppin [mailto:mruppin@yahoo.com]
> > Sent: May 28, 2003 1:47 PM
> > To: Struts Users Mailing List
> > Subject: Struts and the infamous IE multiple
> browser/same session
> > problem
> >
> >
> > I'm reconsidering my approach to this problem, in
> > favor of something more elegant/more compatible
> with
> > out-of-the-box Struts. Anyone tackled this yet?
> >
> > For those not aware, MS IE allows users to launch
> a
> > browser against the same session via
> File/New/Window
> > (Ctrl-N). The issue is, if you have need to keep
> data
> > in the session (which I do), a submission from one
> > browser could grab and/or overwrite session data
> meant
> > for the other browser. This can lead to data
> > integrity problems and other weirdness. Telling
> my
> > user community not to use MS IE or it's Ctrl-N
> feature
> > is not an option.
> >
> > My current approach is to put a hidden random
> "key"
> > into the HTML, and name the session attribute with
> > that. When one of the two browsers submits a
> request
> > (Assuming, at this point, they've opened another)
> the
> > session data is pulled by key, assigned a new key,
> a
> > new copy is placed in the session named with the
> new
> > key, and the new key is rendered in the HTML
> > response. The old session data may or may not be
> > removed, depending on whether or not it is
> acceptable
> > for the browser with the old key to [gracefully]
> fail,
> > how we choose to expire session data, and whether
> or
> > not a means of dealing with stale data is
> supported by
> > the model.
> >
> > This works fine, but in doing so I've had to write
> my
> > own methods for populating collections of forms
> which
> > would have otherwise been taken care of for me by
> > specifying session scope in struts-config. Am I
> > missing a better way?
> >
> > m
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Calendar - Free online calendar with sync
> to Outlook(TM).
> > http://calendar.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Struts and the infamous IE multiple browser/same session problem
Posted by Andrew Hill <an...@gridnode.com>.
Another fun thing to consider with multiple browser windows is the problems
you get if multiple windows are showing the same edit page (ie: same action)
, but editing different records, and you are using a session scoped
actionForm...
-----Original Message-----
From: Steve Raeburn [mailto:steve@ninsky.com]
Sent: Thursday, 29 May 2003 06:52
To: Struts Users Mailing List
Subject: RE: Struts and the infamous IE multiple browser/same session
problem
Forgive me if I'm misunderstanding something here because I am unaware of
the background and previous discussions on this topic.
This doesn't seem to just be a issue with IE. Mozilla and Opera both keep
the same session if you have multiple browser windows open. It doesn't
matter whether you open a new window in a separate tab or browser, it still
maintains the same session.
Why would you even want a browser that enforced separate sessions if you
open a new window. I may want to accomplish several tasks or refer to
information while I'm updating something else. There are any number of
reasons why I would want multiple windows. If you enforced separate sessions
then I would have to login each time I opened a window. Not exactly
convenient for the user!
Why is this considered a problem? The session represents the state for the
user, not for a particular browser window. Each window is just a view of the
model so it should not matter how many different views are active at any
time. If you need to guard against inconsistent data then you need to be
aware that the session is not thread safe and ensure that you do your own
synchronization on any objects that you place in it.
Surely, this is no more a bug than the database bug where data gets out of
sync when you don't use transactions? ;-)
Anyway, to avoid any problems here's a few options:
1. Synchronize objects that you use in the session
2. Don't use the session at all. Store your 'session' information in a
database. Some distributed session managers do this for you.
3. Synchronize on some other session 'locking' object if you need to update
multiple session objects in a transaction.
4. Consider using an optimistic locking system for your session objects. Add
a version number property to the objects you're going to place in the
session. Check it for each update request and reject the update if the
session numbers don't match. (You'll still need to synchronize for updates
but not for reads).
Don't shoot me if the last option doesn't work. It just occurred to me while
I was thing about database transactions :-)
Like I said, if I've misunderstood then please (gently) point out of the
error of my ways.
Steve
> -----Original Message-----
> From: Michael Ruppin [mailto:mruppin@yahoo.com]
> Sent: May 28, 2003 1:47 PM
> To: Struts Users Mailing List
> Subject: Struts and the infamous IE multiple browser/same session
> problem
>
>
> I'm reconsidering my approach to this problem, in
> favor of something more elegant/more compatible with
> out-of-the-box Struts. Anyone tackled this yet?
>
> For those not aware, MS IE allows users to launch a
> browser against the same session via File/New/Window
> (Ctrl-N). The issue is, if you have need to keep data
> in the session (which I do), a submission from one
> browser could grab and/or overwrite session data meant
> for the other browser. This can lead to data
> integrity problems and other weirdness. Telling my
> user community not to use MS IE or it's Ctrl-N feature
> is not an option.
>
> My current approach is to put a hidden random "key"
> into the HTML, and name the session attribute with
> that. When one of the two browsers submits a request
> (Assuming, at this point, they've opened another) the
> session data is pulled by key, assigned a new key, a
> new copy is placed in the session named with the new
> key, and the new key is rendered in the HTML
> response. The old session data may or may not be
> removed, depending on whether or not it is acceptable
> for the browser with the old key to [gracefully] fail,
> how we choose to expire session data, and whether or
> not a means of dealing with stale data is supported by
> the model.
>
> This works fine, but in doing so I've had to write my
> own methods for populating collections of forms which
> would have otherwise been taken care of for me by
> specifying session scope in struts-config. Am I
> missing a better way?
>
> m
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Struts and the infamous IE multiple browser/same session problem
Posted by Steve Raeburn <st...@ninsky.com>.
Forgive me if I'm misunderstanding something here because I am unaware of
the background and previous discussions on this topic.
This doesn't seem to just be a issue with IE. Mozilla and Opera both keep
the same session if you have multiple browser windows open. It doesn't
matter whether you open a new window in a separate tab or browser, it still
maintains the same session.
Why would you even want a browser that enforced separate sessions if you
open a new window. I may want to accomplish several tasks or refer to
information while I'm updating something else. There are any number of
reasons why I would want multiple windows. If you enforced separate sessions
then I would have to login each time I opened a window. Not exactly
convenient for the user!
Why is this considered a problem? The session represents the state for the
user, not for a particular browser window. Each window is just a view of the
model so it should not matter how many different views are active at any
time. If you need to guard against inconsistent data then you need to be
aware that the session is not thread safe and ensure that you do your own
synchronization on any objects that you place in it.
Surely, this is no more a bug than the database bug where data gets out of
sync when you don't use transactions? ;-)
Anyway, to avoid any problems here's a few options:
1. Synchronize objects that you use in the session
2. Don't use the session at all. Store your 'session' information in a
database. Some distributed session managers do this for you.
3. Synchronize on some other session 'locking' object if you need to update
multiple session objects in a transaction.
4. Consider using an optimistic locking system for your session objects. Add
a version number property to the objects you're going to place in the
session. Check it for each update request and reject the update if the
session numbers don't match. (You'll still need to synchronize for updates
but not for reads).
Don't shoot me if the last option doesn't work. It just occurred to me while
I was thing about database transactions :-)
Like I said, if I've misunderstood then please (gently) point out of the
error of my ways.
Steve
> -----Original Message-----
> From: Michael Ruppin [mailto:mruppin@yahoo.com]
> Sent: May 28, 2003 1:47 PM
> To: Struts Users Mailing List
> Subject: Struts and the infamous IE multiple browser/same session
> problem
>
>
> I'm reconsidering my approach to this problem, in
> favor of something more elegant/more compatible with
> out-of-the-box Struts. Anyone tackled this yet?
>
> For those not aware, MS IE allows users to launch a
> browser against the same session via File/New/Window
> (Ctrl-N). The issue is, if you have need to keep data
> in the session (which I do), a submission from one
> browser could grab and/or overwrite session data meant
> for the other browser. This can lead to data
> integrity problems and other weirdness. Telling my
> user community not to use MS IE or it's Ctrl-N feature
> is not an option.
>
> My current approach is to put a hidden random "key"
> into the HTML, and name the session attribute with
> that. When one of the two browsers submits a request
> (Assuming, at this point, they've opened another) the
> session data is pulled by key, assigned a new key, a
> new copy is placed in the session named with the new
> key, and the new key is rendered in the HTML
> response. The old session data may or may not be
> removed, depending on whether or not it is acceptable
> for the browser with the old key to [gracefully] fail,
> how we choose to expire session data, and whether or
> not a means of dealing with stale data is supported by
> the model.
>
> This works fine, but in doing so I've had to write my
> own methods for populating collections of forms which
> would have otherwise been taken care of for me by
> specifying session scope in struts-config. Am I
> missing a better way?
>
> m
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Struts and the infamous IE multiple browser/same session problem
Posted by Michael Ruppin <mr...@yahoo.com>.
I'm reconsidering my approach to this problem, in
favor of something more elegant/more compatible with
out-of-the-box Struts. Anyone tackled this yet?
For those not aware, MS IE allows users to launch a
browser against the same session via File/New/Window
(Ctrl-N). The issue is, if you have need to keep data
in the session (which I do), a submission from one
browser could grab and/or overwrite session data meant
for the other browser. This can lead to data
integrity problems and other weirdness. Telling my
user community not to use MS IE or it's Ctrl-N feature
is not an option.
My current approach is to put a hidden random "key"
into the HTML, and name the session attribute with
that. When one of the two browsers submits a request
(Assuming, at this point, they've opened another) the
session data is pulled by key, assigned a new key, a
new copy is placed in the session named with the new
key, and the new key is rendered in the HTML
response. The old session data may or may not be
removed, depending on whether or not it is acceptable
for the browser with the old key to [gracefully] fail,
how we choose to expire session data, and whether or
not a means of dealing with stale data is supported by
the model.
This works fine, but in doing so I've had to write my
own methods for populating collections of forms which
would have otherwise been taken care of for me by
specifying session scope in struts-config. Am I
missing a better way?
m
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: How do you orgnize your project directory?
Posted by Erik Price <ep...@ptc.com>.
Lei Gao wrote:
> Thanks Erik,
>
> Very clear specified, then where generally you put your servlet/bean source
> code?
> Is that a good way for creating a sub directory called 'javasrc' or
> something?
I have re-attached this to the list in case it be helpful to others.
I have my current (real world) project directory structured like this:
myProjectName/
bin/
build.properties
build.xml
docs/
lib/
misc/
resources/
src/
com/
domain/
myProject/
...etc...
test/
com/
domain/
myProject/
...etc...
web/
some.jsp
other.jsp
more.jsp
some.css
WEB-INF/
web.xml
tld/
myProject-tld.xml
...etc...
- The "bin" directory is only used by my IDE, eclipse. If I were not
using Eclipse, I wouldn't have a "bin" directory.
- The build.properties and build.xml are my Ant files.
- If I write any documentation I will put it in the "doc" directory, but
- I probably won't write any. Still, the Ant script will automatically
put anything in the "doc" directory into the documentation directory in
the final distributable.
- The "lib" directory contains any JAR dependencies used by my
application that I need to compile. These JARs will be put in the
WEB-INF/lib directory by my Ant file when I build the application.
- The "misc" directory contains temporary files that I'm using, such as
files with SQL code or other scratchwork. My Ant build file does not
use this directory when building the project at all.
- The "resources" directory contains any miscellaneous files that I do
need for my project, and these are handled on a per-case basis by the
Ant build script.
- The "src" directory is where all of my Java code is. The meat of the
project. All of my servlets, beans, and plain old java objects go in
here, in the package hierarchy.
- The "test" directory contains unit test code, and mirrors the regular
package hierarchy so that my unit tests have default access to various
class members in the actual codebase.
- The "web" directory contains JSP files and static files, as well as a
WEB-INF directory which is copied to the actual WEB-INF of the webapp
during deployment by the Ant build file.
As you can see, it's not very original. I gathered the layout from the
Tomcat deployment guide, the XPetstore application, and "Java
Development With Ant" by Erik Hatcher and Steve Loughran. I think it's
pretty close to the recommended layout. But it works for me.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: How do you orgnize your project directory?
Posted by Erik Price <ep...@ptc.com>.
Lei Gao wrote:
> Hello guys,
>
> I want to know when you start a Structs project, generally how do you
> orgnize your project directory?
> Which way you think is the most comfortable way for both developing and
> deploying?
<http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/deployment.html>
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org