Hi;
CreationalContext is a thread safe, you have to provide thread safety when
running multiple threads and the most important object in CreationalContext is
objectInstance and its thread safe.
There is no problem I have seen. Also, your solution eats client provided
CreatinalContext because
Hoi!
The problem is not that CreationalContext is not thread safe, but that
NormalScopedBeanInterceptorHandler is not thread safe if you store the
CreationalContext as member variable :)
And yes, I'm eating the provided CreationalContext for NormalScoped bean
proxies, because in my opinion it
Yes Gurkan, I think I know _why_ you introduced it: because the TCK currently
needs it. But I honestly think the TCK is wrong here. And this has also been
confirmed by Marius and Pete already in the CDITCK-140.
Of course, if we could find a way to resolve those cyclic references _without_
Mark;
Full logic is based on this stuff in OWB. Becuase TCK requires to use them.
Therefore it is not a good idea to remove them completely. Therefore we have to
find a solution to resolve this instead of changing logic.
My point is that, there is a working code and maybe this code is not
Your points are not aligned with specification. You have viewed a different
perspective on using CContexts from how TCK and OWB are implemented .
:)
From: Mark Struberg strub...@yahoo.de
To: dev@openwebbeans.apache.org
Sent: Tue, April 13, 2010 11:38:18 AM
Which point of my argumentation chain?
Which sentence?
Which section in the spec does get injured?
LieGrue,
strub
--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 13.4.2010:
Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
Betreff: Re: svn commit: r933348 - in
Anyway I have reverted to beginning, and create an issue. Because tinkering in
somewhere must not destroy some other places as a side affect.
At evening, we could discuss the current design of the OWB regarding CC and
setup a plan how to handle this weird situation without not effecting other
I know I'm jumping into the conversation a bit late, but Im trying to catch
up and get my head in the game a bit.
I looked over the code, and read over Mark's example scenario earlier, which
I'll paste a snippet of:
And now consider a webserver with 10.000 different users clicking on the
send
That SessionScoped object isn't stored in MailService's creational context is
it?
Indirectly it is!
a) Our CreationalContextImpl form a hierarchy tree which contains all
CreationalContexts of all @Dependent scoped beans
(CreationalContextImpl#dependentObjects). And currently we _also_ store
This makes no difference, really.
The problem is that we store a CreationalContext as a member in
NormalScopedBeanInterceptorHandler. And subsequent function calls rely on it.
But if in the meantime _another_ thread overwrites this
NormalScopedBeanInterceptorHandler.creationalContext (by using
Please attach a small web application code that shows your issue. Without
it, it is very hard to visualize your siutation.
As a side note, serialization issues always a problem in Java Web
Applications. You have to manage this via synchoronization blocks or third
party other libs, for example
11 matches
Mail list logo
