[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-761) Modify the default interception practices

Tue Jul 10 10:09:31 EDT 2007

    [ http://jira.jboss.com/jira/browse/JBSEAM-761?page=comments#action_12368377 ] 

Mischa Koelliker commented on JBSEAM-761:
-----------------------------------------

I run into a similiar situation where I was logging the current conversation stack and all its contained objects.
My specific situation was, that I did a conversationContext.flush(), then a Conversation.pop() and sometime afterwards logged the conversation stack and its objects.
While logging, I called someMethod() on all these objects which touched them and made them dirty. This caused them to misteriously appear in the 'additions' collection again (from where they have been flushed before), what caused them to be put into the wrong conversation context (the now active one, one level too high) at the end of the request.

It took me 2 days to figure all this out and therefore I would really appreciate having more sophisticated ways to control when and on which methods intercetion is applied!

The 'disinjection' feature is another one which made me bang my head against the wall. Because I set() a member of a class which normally is injected (@RequestParameter) by Seam, but in my case was sometimes not available. But despite the set(), this member was always null... I found the disinjection 'feature' only by digging into the Seam code. Please, at least document such things! And also in this case, it would be helpful to be able to switch off certain interceptions.

> Modify the default interception practices
> -----------------------------------------
>
>                 Key: JBSEAM-761
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-761
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.1.0.GA
>         Environment: Any.
>            Reporter: Mike Quilleash
>         Assigned To: Gavin King
>             Fix For: 2.0.0.BETA1
>
>
> Currently all methods on a Seam component will be intercepted.  In some circumstances this can make debugging difficult as a lot of debuggers call toString() on objects visible from the breakpoint which executes all the Bijection incl the DisInjection which can damage the state of the object depending where the breakpoint is in the process.
> Perhaps the interception logic could ignore calls to any method on the Object class so the default toString() doesn't cause problems.
> Another complementary change would be to expand the @Intercept to be allowed on methods (and fields?) to allow the interception logic to be configured on individual methods (like a custom toString()) method.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira