You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Leandro Melo <lt...@yahoo.com.br> on 2005/02/13 17:37:38 UTC
RequestProcessor instantiation doubt ( in .NET)
Hi all.
The last days I've been working in a Struts like
framework for .NET. I guess most people that work for
companies that develop both in Java and in .NET whish
they had something like Struts for .NET projects.
The framework is almost ready (when I finish and
publish it, in few days, I'll send an e-mail to the
list).
My framework is a lot simpler than Struts. Although I
got a lot of ideas from Struts, it's not that similar
when we talk about coding. And here's comes my
question.
In Struts, when a http request hits the ActionServlet,
it delegates to a single RequestProcessor instance to
handle the request. There's only one RequestProcessor
instance per module in a Struts application because
this instance keeps a lot of information about
actions, module config, etc...
In my framework, when a http requests hits my Front
controller it delegates, in the same way as Struts, to
the RequestProcessor. However the RequestProcessor is
not responsible for keeping application configuration
information. Basically, I get a singleton class wich
keeps all this data.
So, is it necessary for me to have only one instance
of the RequestProcessor??? Or should I just
instantiante one RequestProcessor for each http
request that hits my front controller???? What would
be the impact on performance for both approaches???
Well, that's it. I'm looking to hear some opinions on
that.
Thanks all and sorry for using Struts list for this,
but I really think it's here i can get the best
information.
Leandro
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RequestProcessor instantiation doubt ( in .NET)
Posted by J Q <ja...@gmail.com>.
Leandro,
You might want to post this on the struts-dev mailing list. You might
get more help there.
JQ.
On Sun, 13 Feb 2005 13:37:38 -0300 (ART), Leandro Melo
<lt...@yahoo.com.br> wrote:
> Hi all.
> The last days I've been working in a Struts like
> framework for .NET. I guess most people that work for
> companies that develop both in Java and in .NET whish
> they had something like Struts for .NET projects.
> The framework is almost ready (when I finish and
> publish it, in few days, I'll send an e-mail to the
> list).
> My framework is a lot simpler than Struts. Although I
> got a lot of ideas from Struts, it's not that similar
> when we talk about coding. And here's comes my
> question.
> In Struts, when a http request hits the ActionServlet,
> it delegates to a single RequestProcessor instance to
> handle the request. There's only one RequestProcessor
> instance per module in a Struts application because
> this instance keeps a lot of information about
> actions, module config, etc...
> In my framework, when a http requests hits my Front
> controller it delegates, in the same way as Struts, to
> the RequestProcessor. However the RequestProcessor is
> not responsible for keeping application configuration
> information. Basically, I get a singleton class wich
> keeps all this data.
> So, is it necessary for me to have only one instance
> of the RequestProcessor??? Or should I just
> instantiante one RequestProcessor for each http
> request that hits my front controller???? What would
> be the impact on performance for both approaches???
> Well, that's it. I'm looking to hear some opinions on
> that.
> Thanks all and sorry for using Struts list for this,
> but I really think it's here i can get the best
> information.
> Leandro
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org