One more thing;
-----------------------

Currently in our NormalScopedBeansInterceptorHandler, we use the given
"CreationalContext" to the constructor. Seems that this is not correct. If
we have a save instance of bean in AbstractContext, we have to use the save
CreationalContext instance in the AbstractContext.

Why?
-----------------

In a freshly created instance, we save the dependent objects of the bean in
the CreaitonalContext and save it into our context instance. In later
operations, if we use given CreationalContext instead of using saved
version, we loose the dependent instances of bean. Therefore below logic
does not work as expected.

For example;
-----------------------
We have an @ApplicatioScoped bean and client calls
manager.getReference(bean,type,creational) and we return a proxy. Client
calls method on a proxy object, then we create bean instance and all of its
interceptor instances. We put all of its interceptor instances into
CreationalContextImpl.addDependent and mark them as interceptor. Now, we
have a "bean instance" and "its creational context" in AbstractContext.

Client again calls manager.getReference(bean,type,new creational). If we do
not use saved creational context, whenever we want to get interceptors of
the bean, it returns an empty set because "new creational" does not contain
it. And container creates a new interceptor instance again that we do not
want!

But those are not applied for DependentScoped beans because they are created
an each time client calls manager.getReference() and it creates a new
instance of interceptor.

Thanks;

--Gurkan

2010/3/17 Gurkan Erdogdu <[email protected]>

> Hello;
>
> I was thinking about to update our interceptor logic but not found time.
> Indeed, our interceptor logic is not correct. Currently, we setup
> InterceptorStack for bean but this interceptor stack is shared by all
> instances of this bean, this is not correct. For example, @RequestScoped
> beans may override each of thier interceptor instances, because
> InterceptorData uses interceptor instance and InterceptorData is shared by
> all beans (same InterceptorStack that contains InterceptorData)
>
> We have to separate interceptor instance from InterceptorStack(contains
> InterceptorData). So, mapping should be
> - Bean --> InterceptorStack (also remove "Object interceptorInstance" from
> InterceptorData)
> - Bean Instance --> Interceptor Instance
>
> We can use CreationalContextImpl to save bean interceptor instances. We can
> add another field into DependentCreationalContext to mark dependent instance
> as "interceptor". After that we can get interceptor instance from there
> whenever a intercepted method is called.
>
> We have to do similar things for decorator instances. Currently, we call
> WebBeansDecoratorConfig#getDecoratorStack for every invocation and it
> creates a new instance of decorators.
>
> Thanks;
>
> --Gurkan
>
>
> 2010/3/17 Mark Struberg (JIRA) <[email protected]>
>
> Interceptor instances get created each time the interceptor gets called
>> -----------------------------------------------------------------------
>>
>>                 Key: OWB-329
>>                 URL: https://issues.apache.org/jira/browse/OWB-329
>>             Project: OpenWebBeans
>>          Issue Type: Bug
>>          Components: Interceptor and Decorators
>>    Affects Versions: M4
>>            Reporter: Mark Struberg
>>            Assignee: Mark Struberg
>>            Priority: Critical
>>             Fix For: 1.0.0
>>
>>
>> Interceptors are defined as being @Dependent scoped. Thus, for one
>> @ApplicationScoped contextual instance, only one interceptor instance of a
>> certain type must exist. But we currently create a new instance for each and
>> every method invocation which is intercepted.
>>
>> This is not only terribly slow, but also doesn't work as expected from a
>> portable perspective.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>



-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Reply via email to