RE: time to do action

[Mike Whittaker]

>we should enjoy the synergy of using these things
>together instead of hoping for a "mother of all frameworks" solution that
>satisfies every single need in one package.
>
>Craig

"mother of all frameworks"

Sure as hell feels like it from this point on the learning curve!

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Micael]

"Mother of All Frameworks"?  THAT is a hoot!

At 01:02 PM 5/30/03 -0700, Craig R. McClanahan wrote:


On Fri, 30 May 2003, Mike Whittaker wrote:

> Date: Fri, 30 May 2003 19:09:47 +0100
> From: Mike Whittaker <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: time to do action
>
>
> >
> >Maybe I'm wrong, but this is how I understand the way filters work.
>
> You are probably right, my brain hurts, it's Friday.
>
> >
> >> I want the Struts way, I'm learning struts.
> >
> >I didn't realize there was a Struts way.  Filters are filters, aren't 
they?
> >
>
> There must be a struts way to do it surely.

You could certainly create a custom RequestProcessor that includes timing
if you wanted to, but filters are a much more elegant mechanism to
accomplish this particular thing (timing a request).
We shouldn't assume that Struts (or any other framework) is going to meet
100% of your needs.  After all, Struts doesn't try to solve your
persistence-tier problems; it comfortably integrates with anything you
would like to use.  In the same way, you can easily integrate non-Struts
tag libraries, non-Struts XML parsing and processing, non-Struts servlets,
non-Struts filters ... we should enjoy the synergy of using these things
together instead of hoping for a "mother of all frameworks" solution that
satisfies every single need in one package.
Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


LEGAL NOTICE

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank 
you  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Craig R. McClanahan]

On Fri, 30 May 2003, Mike Whittaker wrote:

> Date: Fri, 30 May 2003 19:09:47 +0100
> From: Mike Whittaker <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: time to do action
>
>
> >
> >Maybe I'm wrong, but this is how I understand the way filters work.
>
> You are probably right, my brain hurts, it's Friday.
>
> >
> >> I want the Struts way, I'm learning struts.
> >
> >I didn't realize there was a Struts way.  Filters are filters, aren't they?
> >
>
> There must be a struts way to do it surely.

You could certainly create a custom RequestProcessor that includes timing
if you wanted to, but filters are a much more elegant mechanism to
accomplish this particular thing (timing a request).

We shouldn't assume that Struts (or any other framework) is going to meet
100% of your needs.  After all, Struts doesn't try to solve your
persistence-tier problems; it comfortably integrates with anything you
would like to use.  In the same way, you can easily integrate non-Struts
tag libraries, non-Struts XML parsing and processing, non-Struts servlets,
non-Struts filters ... we should enjoy the synergy of using these things
together instead of hoping for a "mother of all frameworks" solution that
satisfies every single need in one package.

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Whittaker]

>There must be a struts way to do it surely.
>The RequestProcessor is a global controller for all Actions, its
>methods are
>accessed in a sequence, some before the action some launching the action,
>some after.  Surely this can be used to time the Action.
>
>Anyone?

Okay a global way, using the RequestProcessor:

// add the time req'd to process action into request attribute
protected ActionForward processActionPerform(etc) throws etc {

long start = System.currentTimeMillis();
ActionForward fwd =
super.processActionPerform(req,res,action,form,mapping);
long end = System.currentTimeMillis();
String time = Double.toString(((double)(end-start))/1000);
req.setAttribute("time",time);
return fwd;
}

### HOWEVER! ### When you have a simple action mapping like this:



It does not work.
Doesn't the Controller operate in the same way here?

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Whittaker]

>
>Maybe I'm wrong, but this is how I understand the way filters work.

You are probably right, my brain hurts, it's Friday.

>
>> I want the Struts way, I'm learning struts.
>
>I didn't realize there was a Struts way.  Filters are filters, aren't they?
>

There must be a struts way to do it surely.
The RequestProcessor is a global controller for all Actions, its methods are
accessed in a sequence, some before the action some launching the action,
some after.  Surely this can be used to time the Action.

Anyone?

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: time to do action

[Erik Price]

Mike Whittaker wrote:

Eh??

I should be able to do it all in Request scope.  I don't know how to do it
the Struts way, (in fact I don't how to very much at all the Struts way!).
But yes you can do it in a filter, I know how to do that.
chain.doFilter() operates on the same request!  However many you call.
Otherwise you'd have lost the request when it got to the Servlet.
As far as I understand it, the filter performs any code that appears 
before the call to chain.doFilter() first -- before the request is 
passed to the Action/servlet/JSP/whatever.  If you have any code *after* 
the call to chain.doFilter(), then it is too late and the 
Action/servlet/JSP/whatever has already been processed, so you cannot 
output the result using any of those mechanisms.  The only way that I 
can think of would be if you were to directly re-write the contents of 
the response, which would probably be kind of messy.

Maybe I'm wrong, but this is how I understand the way filters work.

I want the Struts way, I'm learning struts.
I didn't realize there was a Struts way.  Filters are filters, aren't they?

And whats with all these duplicate e-mails???
"Don' stick me, that wuz on the roof!"  No idea.



Erik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Jasnowski]

The Struts way?  Well, isn't a request just a request whether it's passing
through the Struts framework or not?  If you're looking to measure at the
granularity within the framework itself then a filter may not give you that
granularity. But if you're looking for just simple HTTP request/response
time then a filter should suffice.

-Original Message-
From: Mike Whittaker [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2003 1:36 PM
To: Struts Users Mailing List
Subject: RE: time to do action


>
>Mike Jasnowski wrote:
>> What about a servlet request/response filter? You might not get
>as granular
>> as you want, but you could get that info relatively easily from
>their, and
>> in the response record the elapsed time.
>
>Filter == very easy way to do it.   In fact there is an already-written
>drop-in filter that times requests and logs them in the excellent
>article at
>
><http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html>
>
>You could easily modify this code to store the results in a
>session-scoped bean and then read this data from a JSP later in the
>user's session.  You wouldn't be able to do it in a lesser scope because
>you record the time *after* the request is processed (after the
>chain.doFilter() method is called).
>

Eh??

I should be able to do it all in Request scope.  I don't know how to do it
the Struts way, (in fact I don't how to very much at all the Struts way!).
But yes you can do it in a filter, I know how to do that.

chain.doFilter() operates on the same request!  However many you call.
Otherwise you'd have lost the request when it got to the Servlet.

I want the Struts way, I'm learning struts.

Thankyou

And whats with all these duplicate e-mails???

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Whittaker]

>
>Mike Jasnowski wrote:
>> What about a servlet request/response filter? You might not get
>as granular
>> as you want, but you could get that info relatively easily from
>their, and
>> in the response record the elapsed time.
>
>Filter == very easy way to do it.   In fact there is an already-written
>drop-in filter that times requests and logs them in the excellent
>article at
>
>
>
>You could easily modify this code to store the results in a
>session-scoped bean and then read this data from a JSP later in the
>user's session.  You wouldn't be able to do it in a lesser scope because
>you record the time *after* the request is processed (after the
>chain.doFilter() method is called).
>

Eh??

I should be able to do it all in Request scope.  I don't know how to do it
the Struts way, (in fact I don't how to very much at all the Struts way!).
But yes you can do it in a filter, I know how to do that.

chain.doFilter() operates on the same request!  However many you call.
Otherwise you'd have lost the request when it got to the Servlet.

I want the Struts way, I'm learning struts.

Thankyou

And whats with all these duplicate e-mails???

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: time to do action

[Erik Price]

Mike Jasnowski wrote:
What about a servlet request/response filter? You might not get as granular
as you want, but you could get that info relatively easily from their, and
in the response record the elapsed time.
Filter == very easy way to do it.   In fact there is an already-written 
drop-in filter that times requests and logs them in the excellent article at



You could easily modify this code to store the results in a 
session-scoped bean and then read this data from a JSP later in the 
user's session.  You wouldn't be able to do it in a lesser scope because 
you record the time *after* the request is processed (after the 
chain.doFilter() method is called).

Erik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Jasnowski]

.. from there

-Original Message-
From: Mike Jasnowski [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2003 12:28 PM
To: Struts Users Mailing List
Subject: RE: time to do action


What about a servlet request/response filter? You might not get as granular
as you want, but you could get that info relatively easily from their, and
in the response record the elapsed time.

-Original Message-
From: Mike Whittaker [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2003 12:30 PM
To: Struts List
Subject: time to do action



In order to aid understanding what would be the simplest way to record the
time taken to carry out a request, and then make this available to a JSP?

To make this global I've been playing with RequestProcessor with little
success.

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: time to do action

[Mike Jasnowski]

What about a servlet request/response filter? You might not get as granular
as you want, but you could get that info relatively easily from their, and
in the response record the elapsed time.

-Original Message-
From: Mike Whittaker [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2003 12:30 PM
To: Struts List
Subject: time to do action



In order to aid understanding what would be the simplest way to record the
time taken to carry out a request, and then make this available to a JSP?

To make this global I've been playing with RequestProcessor with little
success.

--
Mike W


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]