You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/07/10 19:43:28 UTC
Re: Struts architecture performance
On Wed, 10 Jul 2002, pierre jauffret wrote:
> Date: Wed, 10 Jul 2002 19:23:15 GMT+1
> From: pierre jauffret <pi...@caramail.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts architecture performance
>
> We are looking for a proved web architecture that can
> support a billion pages call per month.
>
> We heard about Struts, and we would like to know if the
> struts architecture based on 1 Servlet Controler(MVC) is
> better than a classical architecture based on several
> Servlets(MVC also): and for what reasons.
>
I will leave it to others to talk about their own scalability experiences
(which have a lot more to do with the hardware you are running on, and the
quality of the code generated by your app server's JSP compiler than it
does with Struts), and address the one-controller issue plus a couple of
other things you might want to think about.
Basically, my view is that one of the key benefits of MVC as a design
pattern is the opportunity to guarantee that *all* requests flow through a
single point of control, so that you can centralize functionality that you
want applied to every single request. In the Struts implementation of
MVC, that central point is the ActionServlet controller servlet, and the
request processing lifecycle that it implements for every single request.
This approach has actually benefitted apps based on Struts already,
because we can transparently support additional functionality in the
controller in many cases, without making anyone update their Action
implementations that link to the business logic.
Regarding performance impacts of one servlet versus several, it is
actually *more* efficient to use a single instance (which is already
dealing with multiple simultaneous requests), because it occupies less
memory. But this is a really minor impact in the big picture scheme of
things.
A scalability issue that does matter for large applications, though, is
the central configuration file (struts-config.xml). For a very large
application, with pieces built by different teams, it can be difficult to
manage integrating all of the information into a single file because it
will be continuously updated by the various teams.
One of the key features of the upcoming Struts 1.1 release is that you can
now divide a monolithic Struts based application into "sub-applications"
(they are going to end up being called application modules), each with its
own struts-config.xml file. You still configure this all to run within a
single web application, with a single instance of the controller servlet,
but it allows each development team to completely manage the development
of their particular module without interference from others. Any given
application module can be run by itself in a webapp, or along with others,
with a very simple change to the webapp configuration file -- this
facilitates independent development of the modules with the ability to
combine them later quite easily.
> Could you give us some examples, and testimonies.
> Is struts reliable?
>
> Thanks.
>
> Pierre
> _________________________________________________________
> Envoyez des messages musicaux sur le portable de vos amis
> http://mobile.lycos.fr/mobile/local/sms_musicaux/
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts architecture performance
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Aug 2002, Benjamin Schupp wrote:
> Date: Wed, 14 Aug 2002 14:24:35 +0200
> From: Benjamin Schupp <be...@sesa.de>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Struts architecture performance
>
> Hi Thinh,
>
> as I understand, with struts 1.1 one is not allowed to name
> struts-config.xml differently for each module (e.g.
> struts-config-xyz.xml) now, but has to call it struts-config.xml.
> Did I get it right?
>
No -- the name of each configuration resource file can be whatever you
want. The actual name is not relevant, because the important issue is
the name of the initialization parameter. For example, the following is
perfectly legal for a Struts app with three modules:
<servlet>
...
<!-- The default application module -->
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/default-struts-config.xml</param-value>
</init-param>
<!-- The "/foo" application module -->
<init-param>
<param-name>config/foo</param-name>
<param-value>/WEB-INF/struts-config-bar.xml</param-value>
</init-param>
</servlet>
Although common sense suggests that the name of the config file should
bear some relationship to the module prefix to reduce confusion.
> Greetings,
> Ben
>
Craig
>
> Craig R. McClanahan wrote:
> >
> > On Tue, 13 Aug 2002, Thinh Doan wrote:
> >
> >
> >>Date: Tue, 13 Aug 2002 22:19:24 -0500
> >>From: Thinh Doan <td...@twjconsulting.com>
> >>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> >> tdoan@twjconsulting.com
> >>To: Struts Users Mailing List <st...@jakarta.apache.org>
> >>Subject: RE: Struts architecture performance
> >>
> >>Craig,
> >>
> >>
> >>>>you can now divide a monolithic Struts based application into
> >>>
> >>"sub-applications"
> >>
> >>>>(they are going to end up being called application modules), each with its
> >>>>own struts-config.xml file.
> >>>
> >>Do you have additional info. on how to setup sub-apps with multiple
> >>struts-configs in 1.1b2? Thank you,
> >>
> >
> >
> > This definitely needs to be documented better, but it is actually
> > amazingly simple:
> >
> > * You must be using extension mapping for the controller servlet
> > (i.e. "*.do" style instead of "/do/*" style).
> >
> > * All requests must go through the controller servlet. No linking
> > directly to JSP pages (this restriction will be lifted once
> > Struts mandates Servlet 2.3 as the base platform so we can use
> > filters).
> >
> > * The resource path to the struts-config.xml file in Struts 1.0.x
> > is specified in the "config" parameter to the controller servlet.
> > In 1.1, this continues to be true, but it now refers to the "root"
> > application module that is used if no other application modules are
> > installed. Thus, existing apps continue to work.
> >
> > * Several things that used to be configured with other servlet init
> > parameters are now configured in the new <controller> element in
> > the struts-config.xml file for a module. The old parameters continue
> > to work, but they are deprecated and only apply to the default module.
> >
> > * To add an additional application module, simply configure an additional
> > servlet init parameter for the controller servlet. To have a module
> > whose context-relative prefix is "/foo", then the init parameter name
> > would be "config/foo".
> >
> > * If you do this, all paths that (in Struts 1.0.2 config files) were
> > context-relative now become module relative. Say you have a forward
> > declaration like this:
> >
> > <forward name="Main Menu" path="/mainmenu.jsp"/>
> >
> > In the default module, Struts will prefix this with the context path
> > for your web application, so the path would be something like
> > "/myapp/mainmenu.jsp". However, if this struts-config.xml file were
> > pointed at by the "config/foo" init parameter (so that the module
> > prefix is "/foo"), then the path will automatically be converted to
> > "/myapp/foo/mainmenu.jsp" instead.
> >
> > * The net result is that any given struts-config.xml file should be able
> > to be used -- unchanged -- as either the default module (equivalent
> > to the only module in a 1.0.x environment) or as an app module. The
> > only thing you have to do is put all the JSP pages (or other resources
> > used for the view layer) into a subdirectory that corresponds to the
> > module prefix.
> >
> > In the past, it was often necessary, on very large scale applications, for
> > different development teams to fight over the one-and-only copy of
> > struts-config.xml. Now, each module can be developed independently -- and
> > you can choose whether or not to combine them into a single webapp based
> > on whether or not you need to share session information between modules.
> > It's a very powerful paradigm.
> >
> > Try it, you'll like it :-).
> >
> >
> >>Thinh
> >>
> >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts architecture performance
Posted by Benjamin Schupp <be...@sesa.de>.
Hi Thinh,
as I understand, with struts 1.1 one is not allowed to name
struts-config.xml differently for each module (e.g.
struts-config-xyz.xml) now, but has to call it struts-config.xml.
Did I get it right?
Greetings,
Ben
Craig R. McClanahan wrote:
>
> On Tue, 13 Aug 2002, Thinh Doan wrote:
>
>
>>Date: Tue, 13 Aug 2002 22:19:24 -0500
>>From: Thinh Doan <td...@twjconsulting.com>
>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
>> tdoan@twjconsulting.com
>>To: Struts Users Mailing List <st...@jakarta.apache.org>
>>Subject: RE: Struts architecture performance
>>
>>Craig,
>>
>>
>>>>you can now divide a monolithic Struts based application into
>>>
>>"sub-applications"
>>
>>>>(they are going to end up being called application modules), each with its
>>>>own struts-config.xml file.
>>>
>>Do you have additional info. on how to setup sub-apps with multiple
>>struts-configs in 1.1b2? Thank you,
>>
>
>
> This definitely needs to be documented better, but it is actually
> amazingly simple:
>
> * You must be using extension mapping for the controller servlet
> (i.e. "*.do" style instead of "/do/*" style).
>
> * All requests must go through the controller servlet. No linking
> directly to JSP pages (this restriction will be lifted once
> Struts mandates Servlet 2.3 as the base platform so we can use
> filters).
>
> * The resource path to the struts-config.xml file in Struts 1.0.x
> is specified in the "config" parameter to the controller servlet.
> In 1.1, this continues to be true, but it now refers to the "root"
> application module that is used if no other application modules are
> installed. Thus, existing apps continue to work.
>
> * Several things that used to be configured with other servlet init
> parameters are now configured in the new <controller> element in
> the struts-config.xml file for a module. The old parameters continue
> to work, but they are deprecated and only apply to the default module.
>
> * To add an additional application module, simply configure an additional
> servlet init parameter for the controller servlet. To have a module
> whose context-relative prefix is "/foo", then the init parameter name
> would be "config/foo".
>
> * If you do this, all paths that (in Struts 1.0.2 config files) were
> context-relative now become module relative. Say you have a forward
> declaration like this:
>
> <forward name="Main Menu" path="/mainmenu.jsp"/>
>
> In the default module, Struts will prefix this with the context path
> for your web application, so the path would be something like
> "/myapp/mainmenu.jsp". However, if this struts-config.xml file were
> pointed at by the "config/foo" init parameter (so that the module
> prefix is "/foo"), then the path will automatically be converted to
> "/myapp/foo/mainmenu.jsp" instead.
>
> * The net result is that any given struts-config.xml file should be able
> to be used -- unchanged -- as either the default module (equivalent
> to the only module in a 1.0.x environment) or as an app module. The
> only thing you have to do is put all the JSP pages (or other resources
> used for the view layer) into a subdirectory that corresponds to the
> module prefix.
>
> In the past, it was often necessary, on very large scale applications, for
> different development teams to fight over the one-and-only copy of
> struts-config.xml. Now, each module can be developed independently -- and
> you can choose whether or not to combine them into a single webapp based
> on whether or not you need to share session information between modules.
> It's a very powerful paradigm.
>
> Try it, you'll like it :-).
>
>
>>Thinh
>>
>
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RES: sub-app switch
Posted by julio <ju...@softsite.com.br>.
I don´t know if its the best way, but you could create an entry in the
struts-config.xml, with the action SwitchAction and redirect in your
page to that path to do the work.
________________________________
Julio Cesar
SOFTSITE Tecnologia
Fortaleza, CE, Brasil
http://www.softsite.com.br
________________________________
-----Mensagem original-----
De: Thinh Doan [mailto:tdoan@twjconsulting.com]
Enviada em: sexta-feira, 6 de setembro de 2002 14:50
Para: Struts-User
Assunto: sub-app switch
is it possible to switch to a sub-app with <html:link forward="Name in
subapp struts-config"> from outside the current sub-app or the default
app?
TIA,
Thinh
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Tuesday, August 13, 2002 10:59 PM
To: Struts Users Mailing List; tdoan@twjconsulting.com
Subject: RE: Struts architecture performance
On Tue, 13 Aug 2002, Thinh Doan wrote:
> Date: Tue, 13 Aug 2002 22:19:24 -0500
> From: Thinh Doan <td...@twjconsulting.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> tdoan@twjconsulting.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts architecture performance
>
> Craig,
>
> >>you can now divide a monolithic Struts based application into
> "sub-applications"
> >>(they are going to end up being called application modules), each
with
its
> >>own struts-config.xml file.
>
> Do you have additional info. on how to setup sub-apps with multiple
> struts-configs in 1.1b2? Thank you,
>
This definitely needs to be documented better, but it is actually
amazingly simple:
* You must be using extension mapping for the controller servlet
(i.e. "*.do" style instead of "/do/*" style).
* All requests must go through the controller servlet. No linking
directly to JSP pages (this restriction will be lifted once
Struts mandates Servlet 2.3 as the base platform so we can use
filters).
* The resource path to the struts-config.xml file in Struts 1.0.x
is specified in the "config" parameter to the controller servlet.
In 1.1, this continues to be true, but it now refers to the "root"
application module that is used if no other application modules are
installed. Thus, existing apps continue to work.
* Several things that used to be configured with other servlet init
parameters are now configured in the new <controller> element in
the struts-config.xml file for a module. The old parameters continue
to work, but they are deprecated and only apply to the default module.
* To add an additional application module, simply configure an
additional
servlet init parameter for the controller servlet. To have a module
whose context-relative prefix is "/foo", then the init parameter name
would be "config/foo".
* If you do this, all paths that (in Struts 1.0.2 config files) were
context-relative now become module relative. Say you have a forward
declaration like this:
<forward name="Main Menu" path="/mainmenu.jsp"/>
In the default module, Struts will prefix this with the context path
for your web application, so the path would be something like
"/myapp/mainmenu.jsp". However, if this struts-config.xml file were
pointed at by the "config/foo" init parameter (so that the module
prefix is "/foo"), then the path will automatically be converted to
"/myapp/foo/mainmenu.jsp" instead.
* The net result is that any given struts-config.xml file should be able
to be used -- unchanged -- as either the default module (equivalent
to the only module in a 1.0.x environment) or as an app module. The
only thing you have to do is put all the JSP pages (or other resources
used for the view layer) into a subdirectory that corresponds to the
module prefix.
In the past, it was often necessary, on very large scale applications,
for
different development teams to fight over the one-and-only copy of
struts-config.xml. Now, each module can be developed independently --
and
you can choose whether or not to combine them into a single webapp based
on whether or not you need to share session information between modules.
It's a very powerful paradigm.
Try it, you'll like it :-).
> Thinh
>
Craig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
sub-app switch
Posted by Thinh Doan <td...@twjconsulting.com>.
is it possible to switch to a sub-app with <html:link forward="Name in
subapp struts-config"> from outside the current sub-app or the default app?
TIA,
Thinh
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Tuesday, August 13, 2002 10:59 PM
To: Struts Users Mailing List; tdoan@twjconsulting.com
Subject: RE: Struts architecture performance
On Tue, 13 Aug 2002, Thinh Doan wrote:
> Date: Tue, 13 Aug 2002 22:19:24 -0500
> From: Thinh Doan <td...@twjconsulting.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> tdoan@twjconsulting.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts architecture performance
>
> Craig,
>
> >>you can now divide a monolithic Struts based application into
> "sub-applications"
> >>(they are going to end up being called application modules), each with
its
> >>own struts-config.xml file.
>
> Do you have additional info. on how to setup sub-apps with multiple
> struts-configs in 1.1b2? Thank you,
>
This definitely needs to be documented better, but it is actually
amazingly simple:
* You must be using extension mapping for the controller servlet
(i.e. "*.do" style instead of "/do/*" style).
* All requests must go through the controller servlet. No linking
directly to JSP pages (this restriction will be lifted once
Struts mandates Servlet 2.3 as the base platform so we can use
filters).
* The resource path to the struts-config.xml file in Struts 1.0.x
is specified in the "config" parameter to the controller servlet.
In 1.1, this continues to be true, but it now refers to the "root"
application module that is used if no other application modules are
installed. Thus, existing apps continue to work.
* Several things that used to be configured with other servlet init
parameters are now configured in the new <controller> element in
the struts-config.xml file for a module. The old parameters continue
to work, but they are deprecated and only apply to the default module.
* To add an additional application module, simply configure an additional
servlet init parameter for the controller servlet. To have a module
whose context-relative prefix is "/foo", then the init parameter name
would be "config/foo".
* If you do this, all paths that (in Struts 1.0.2 config files) were
context-relative now become module relative. Say you have a forward
declaration like this:
<forward name="Main Menu" path="/mainmenu.jsp"/>
In the default module, Struts will prefix this with the context path
for your web application, so the path would be something like
"/myapp/mainmenu.jsp". However, if this struts-config.xml file were
pointed at by the "config/foo" init parameter (so that the module
prefix is "/foo"), then the path will automatically be converted to
"/myapp/foo/mainmenu.jsp" instead.
* The net result is that any given struts-config.xml file should be able
to be used -- unchanged -- as either the default module (equivalent
to the only module in a 1.0.x environment) or as an app module. The
only thing you have to do is put all the JSP pages (or other resources
used for the view layer) into a subdirectory that corresponds to the
module prefix.
In the past, it was often necessary, on very large scale applications, for
different development teams to fight over the one-and-only copy of
struts-config.xml. Now, each module can be developed independently -- and
you can choose whether or not to combine them into a single webapp based
on whether or not you need to share session information between modules.
It's a very powerful paradigm.
Try it, you'll like it :-).
> Thinh
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts architecture performance
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 13 Aug 2002, Thinh Doan wrote:
> Date: Tue, 13 Aug 2002 22:19:24 -0500
> From: Thinh Doan <td...@twjconsulting.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>,
> tdoan@twjconsulting.com
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: RE: Struts architecture performance
>
> Craig,
>
> >>you can now divide a monolithic Struts based application into
> "sub-applications"
> >>(they are going to end up being called application modules), each with its
> >>own struts-config.xml file.
>
> Do you have additional info. on how to setup sub-apps with multiple
> struts-configs in 1.1b2? Thank you,
>
This definitely needs to be documented better, but it is actually
amazingly simple:
* You must be using extension mapping for the controller servlet
(i.e. "*.do" style instead of "/do/*" style).
* All requests must go through the controller servlet. No linking
directly to JSP pages (this restriction will be lifted once
Struts mandates Servlet 2.3 as the base platform so we can use
filters).
* The resource path to the struts-config.xml file in Struts 1.0.x
is specified in the "config" parameter to the controller servlet.
In 1.1, this continues to be true, but it now refers to the "root"
application module that is used if no other application modules are
installed. Thus, existing apps continue to work.
* Several things that used to be configured with other servlet init
parameters are now configured in the new <controller> element in
the struts-config.xml file for a module. The old parameters continue
to work, but they are deprecated and only apply to the default module.
* To add an additional application module, simply configure an additional
servlet init parameter for the controller servlet. To have a module
whose context-relative prefix is "/foo", then the init parameter name
would be "config/foo".
* If you do this, all paths that (in Struts 1.0.2 config files) were
context-relative now become module relative. Say you have a forward
declaration like this:
<forward name="Main Menu" path="/mainmenu.jsp"/>
In the default module, Struts will prefix this with the context path
for your web application, so the path would be something like
"/myapp/mainmenu.jsp". However, if this struts-config.xml file were
pointed at by the "config/foo" init parameter (so that the module
prefix is "/foo"), then the path will automatically be converted to
"/myapp/foo/mainmenu.jsp" instead.
* The net result is that any given struts-config.xml file should be able
to be used -- unchanged -- as either the default module (equivalent
to the only module in a 1.0.x environment) or as an app module. The
only thing you have to do is put all the JSP pages (or other resources
used for the view layer) into a subdirectory that corresponds to the
module prefix.
In the past, it was often necessary, on very large scale applications, for
different development teams to fight over the one-and-only copy of
struts-config.xml. Now, each module can be developed independently -- and
you can choose whether or not to combine them into a single webapp based
on whether or not you need to share session information between modules.
It's a very powerful paradigm.
Try it, you'll like it :-).
> Thinh
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts architecture performance
Posted by Thinh Doan <td...@twjconsulting.com>.
Craig,
>>you can now divide a monolithic Struts based application into
"sub-applications"
>>(they are going to end up being called application modules), each with its
>>own struts-config.xml file.
Do you have additional info. on how to setup sub-apps with multiple
struts-configs in 1.1b2? Thank you,
Thinh
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Wednesday, July 10, 2002 12:43 PM
To: Struts Users Mailing List
Subject: Re: Struts architecture performance
On Wed, 10 Jul 2002, pierre jauffret wrote:
> Date: Wed, 10 Jul 2002 19:23:15 GMT+1
> From: pierre jauffret <pi...@caramail.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> Subject: Struts architecture performance
>
> We are looking for a proved web architecture that can
> support a billion pages call per month.
>
> We heard about Struts, and we would like to know if the
> struts architecture based on 1 Servlet Controler(MVC) is
> better than a classical architecture based on several
> Servlets(MVC also): and for what reasons.
>
I will leave it to others to talk about their own scalability experiences
(which have a lot more to do with the hardware you are running on, and the
quality of the code generated by your app server's JSP compiler than it
does with Struts), and address the one-controller issue plus a couple of
other things you might want to think about.
Basically, my view is that one of the key benefits of MVC as a design
pattern is the opportunity to guarantee that *all* requests flow through a
single point of control, so that you can centralize functionality that you
want applied to every single request. In the Struts implementation of
MVC, that central point is the ActionServlet controller servlet, and the
request processing lifecycle that it implements for every single request.
This approach has actually benefitted apps based on Struts already,
because we can transparently support additional functionality in the
controller in many cases, without making anyone update their Action
implementations that link to the business logic.
Regarding performance impacts of one servlet versus several, it is
actually *more* efficient to use a single instance (which is already
dealing with multiple simultaneous requests), because it occupies less
memory. But this is a really minor impact in the big picture scheme of
things.
A scalability issue that does matter for large applications, though, is
the central configuration file (struts-config.xml). For a very large
application, with pieces built by different teams, it can be difficult to
manage integrating all of the information into a single file because it
will be continuously updated by the various teams.
One of the key features of the upcoming Struts 1.1 release is that you can
now divide a monolithic Struts based application into "sub-applications"
(they are going to end up being called application modules), each with its
own struts-config.xml file. You still configure this all to run within a
single web application, with a single instance of the controller servlet,
but it allows each development team to completely manage the development
of their particular module without interference from others. Any given
application module can be run by itself in a webapp, or along with others,
with a very simple change to the webapp configuration file -- this
facilitates independent development of the modules with the ability to
combine them later quite easily.
> Could you give us some examples, and testimonies.
> Is struts reliable?
>
> Thanks.
>
> Pierre
> _________________________________________________________
> Envoyez des messages musicaux sur le portable de vos amis
> http://mobile.lycos.fr/mobile/local/sms_musicaux/
>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>