IMonitor Changes

[Eric Everman <ev...@precedadesign.com>]

For anyone interested in the IMonitor interface, I posted an RFE at:

http://issues.apache.org/bugzilla/show_bug.cgi?id=18379

The RFE would split the interface up and pass a RequestCycle as an argument 
to each event.

Cheers,

Eric Everman

Preceda Design LLC
www.precedadesign.com

Re: IMonitor Changes

[Eric Everman <ev...@precedadesign.com>]

Simon-

You bring up a good point - the IPageMonitor as I spec'ed it is not 
complete.  I would amend it by adding this event from the IServiceMonitor 
interface:

public void serviceException(IRequestCycle cycle, Throwable exception);

With the rule that serviceException would be called first for the current 
IPageMonitor, then for the IServiceMonitor.

My reasons for suggesting a split interface are for ease of use and 
flexibility.  For instance, I can see people using a page-level persistence 
services for simple transactions and session-level services for resource 
initialization and releasing.  If there is a single interface, there will 
also be a single Monitor instance held by the Engine - does that Monitor 
instance have a session, service, or page lifetime?  To give the session 
events continuity (ie sessionEnd is called on the same Monitor instance as 
sessionBegin), a session lifetime required, but that makes it really 
difficult to manage service and page level transactions.

I *could* see eliminating the session events, since these are somewhat 
duplicated by the idea of a Visit, but a Visit has no defined events to 
automatically clean up resources that might be created for a session.

Please tell me how you would apply an observer pattern here.  The more 
discussion we give this feature the better it will be, and critiques are 
welcome.

Eric Everman


At 3/29/2003, Simon Robins wrote:
>I can't see the benefit to this approach. For example, I have a logging 
>monitor which records accesses to pages for statistical purposes. This 
>would fit in with your suggested approach. On the other hand I have a 
>Hibernate monitor which commits any changes during pageRewindEnd or 
>pageRenderBegin but rolls back any changes and closes the connection 
>during serviceException. This crosses two interfaces and would require 
>extra housekeeping to return the same object for the IServiceMonitor 
>object and the IPageMonitor object.
>
>Personally I'm happy with IMonitor as is apart from needing access to the 
>IRequestContext as you have suggested.
>
>I'd also like to see Tapestry implement the Observer design pattern for 
>IMonitor.
>
>On Wednesday, March 26, 2003, at 08:47  pm, Eric Everman wrote:
>
>>There would be three different monitors, each of which could be specified 
>>in the .application file.
>>
>>Eric Everman
>>
>>At 3/26/2003, you wrote:
>>>Would this mean that there are three different monitors or only one that 
>>>Tapestry would instrospect to determine if the monitor implements a 
>>>particular interface?
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: IMonitor Changes

[Simon Robins <si...@mac.com>]

I can't see the benefit to this approach. For example, I have a logging 
monitor which records accesses to pages for statistical purposes. This 
would fit in with your suggested approach. On the other hand I have a 
Hibernate monitor which commits any changes during pageRewindEnd or 
pageRenderBegin but rolls back any changes and closes the connection 
during serviceException. This crosses two interfaces and would require 
extra housekeeping to return the same object for the IServiceMonitor 
object and the IPageMonitor object.

Personally I'm happy with IMonitor as is apart from needing access to 
the IRequestContext as you have suggested.

I'd also like to see Tapestry implement the Observer design pattern for 
IMonitor.

On Wednesday, March 26, 2003, at 08:47  pm, Eric Everman wrote:

> There would be three different monitors, each of which could be 
> specified in the .application file.
>
> Eric Everman
>
> At 3/26/2003, you wrote:
>> Would this mean that there are three different monitors or only one 
>> that Tapestry would instrospect to determine if the monitor 
>> implements a particular interface?

Re: IMonitor Changes

[Eric Everman <ev...@precedadesign.com>]

There would be three different monitors, each of which could be specified 
in the .application file.

Eric Everman

At 3/26/2003, you wrote:
>Would this mean that there are three different monitors or only one that 
>Tapestry would instrospect to determine if the monitor implements a 
>particular interface?

Re: IMonitor Changes

[Simon Robins <si...@mac.com>]

Would this mean that there are three different monitors or only one 
that Tapestry would instrospect to determine if the monitor implements 
a particular interface?

On Wednesday, March 26, 2003, at 06:42  pm, Eric Everman wrote:

> For anyone interested in the IMonitor interface, I posted an RFE at:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=18379
>
> The RFE would split the interface up and pass a RequestCycle as an 
> argument to each event.
>
> Cheers,
>
> Eric Everman
>
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>