sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Java" <sca-j@lists.oasis-open.org>
- Date: Mon, 5 Nov 2007 10:06:03 +0000
Folks,
I believe that option #3 below is the
right one.
I think that for components of composite
scope, it is best to ban the use of injected callbacks.
Then force the programmer of such a
component to retrieve the callback reference via API for
each invocation. This must be
done in the thread used for the invocation. Once retrieved, the
reference can be handed around and used
in any later context, eg on another thread.
This removes any "magic" and
gives a straightforward meaning to the retrieved callback
reference.
It is a necessary but acceptable price
for doing something that is more complex - ie writing a
composite scoped component, which can
clearly be handling many invocations over its lifetime
and so requires some special handling
of this special behaviour.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Simon Nash/UK/IBM@IBMGB
01/11/2007 17:13
|
To
| sca-j@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [sca-j] ISSUE 4 - Dependency reinjection |
|
On last week's SCA-J call, I took an action to consider
what the callback
target would be if multiple forward calls are made to callback interfaces
of a composite-scoped component.
I can think of 3 options:
1. Use the value from the last forward call that was made. This could
lead to a need for reinjection. It is not safe if the component can
receive multithreaded forward invocations.
2. Store the callback address on the thread when a forward call is
received, and use this address for the callback. This works with
multithreaded forward invocations but does not work if a forward request
spins off a new thread to make the callback.
3. When the callback request is made, take the callback address from the
current RequestContext. This is a small variation on 2, but it is
more
robust because it uses official APIs.
I think 3 is the best approach.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Peshev, Peter" <peter.peshev@sap.com>
05/10/2007 08:12
To
<sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Hi,
The issue in the JIRA has an amendment :
AMENDMENT:
This issue covers not only @Reference, but also (reinjection of)
@Callback and @Property.
Can someone clarify what scenario would lead to reinjection of callback
? Unlike references, callbacks can not start unwired, an attempt to call
such component with unwired callback would result to -
"NoRegisteredCallbackException"
Best Regards
Peter
________________________________
From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Thursday, 4. October 2007 16:31
To: Barack, Ron; sca-j@lists.oasis-open.org
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
Subject line shortened.
________________________________
From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Thursday, October 04, 2007 5:27 AM
To: sca-j@lists.oasis-open.org
Subject: [sca-j] ISSUE LOGGED: JAVA-4: Dependency reinjection
http://www.osoa.org/jira/browse/JAVA-4
________________________________
Von: Michael Rowley [mailto:mrowley@bea.com]
Gesendet: Mittwoch, 26. September 2007 00:31
An: sca-j@lists.oasis-open.org
Betreff: [sca-j] NEW ISSUE: Dependency reinjection
TARGET: Java Common Annotations and APIs specification
section "@Reference"
DESCRIPTION:
The description of the @Reference annotation does not specify what
happens if the wire changes after the component has been instantiated.
One example of a place where this could occur is for a composite-scoped
component that exists at the domain level. The target of its reference
could start off unwired (and thus would be null). A later deployment
could deploy a <wire source="" target=""> element
which provides a
target for this component.
PROPOSAL:
In the above scenario, when constructor-based injection is not being
used, the target MAY be reinjected.
This would be marked as "MAY" behavior, since it would not be
required
of all runtimes. However, the developer who is creating portable
code
needs to know that this reinjection may occur.
Other scenarios where such reinjection may occur is TBD. Note that
reinjection should never occur for a conversational-scoped component
that is in middle of its conversation.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]