OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Mike,
The getService() method is defined as follows:
   getService(Class<B> businessInterface, String referenceName) ? Returns 
a proxy for the reference defined by the current component.
This could be afftected by rewiring without redeployment.

The comments from various folks including Reza, Henning, Dave and  Mike 
are making me think that the only consistent way to handle API calls is to 
make them always use the most current wiring (except for cast, which 
operates on an existing proxy).  This would change the top right box of 
Reza's table.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Mike Edwards/UK/IBM@IBMGB 
09/01/2008 10:45

To
"OASIS Java" <sca-j@lists.oasis-open.org>
cc

Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection







Dave, 

Some of these literally can't occur, in my opinion - details follow. 

Basically, my view is that if a component gets redeployed (ie original 
configuration is undeployed 
and a new configuration is deployed), then this is something completely 
new - there is no question 
of "updating" any instances of components of the old configuration. 

I suppose there is a question of whether the pre-existing component 
instances are allowed to remain 
in existence when a redeployment of this kind takes place.  I'm prepared 
to punt on this for now and 
leave it up to the runtime. 

For me, redeployment of a component never creates reinjection of the 
component instances belonging 
to the old configuration. 

Note that this is different from the case of references - as I pointed out 
previously, the wiring and the 
target service(s) of a reference can change WITHOUT redeployment of the 
component itself.  In this 
case, redeployment can occur either on separately deployed wire elements 
and/or on target components 
that are separately deployed.  So there are special measures required in 
these cases, which is what we 
have been debating. 

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 


David Booz <booz@us.ibm.com> 
08/01/2008 20:46 


To
sca-j@lists.oasis-open.org 
cc

Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection








This thread is wandering around on various topics.  I explicitly picked
this part of the thread to make an additional point.

The proposal needs to consider all the APIs:
(a) getURI() - A deployment change could affect what is returned 

<mje> This can only happen with a redeployment, I think. </mje>

(b) getService() - Wiring could affect what is returned here 

<mje> I'm not sure what changes you're implying here.  Typically, IF 
wiring is deployed 
separately from the component, then it CAN'T affect the service.  It CAN 
affect reference 
targets.</mje>

(c) createSelfReference() - A deployment change to the component itself
could affect what's returned here 

<mje> Clearly, this is a redeployment of the component itself </mje>

(d) getProperty() - I don't know why we're limiting the re-injection issue
to references 

<mje> Properties can only get changed if the component, or its containing 
composite, is 
itself redeployed.   
</mje>

It is not wise to have some of the CC API's expose wiring or deployment
changes, but not others.



Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


 
            Simon Nash 
            <NASH@uk.ibm.com> 
                                                                       To 
            01/07/2008 01:48          "OASIS Java" 
            PM                        <sca-j@lists.oasis-open.org> 
                                                                       cc 
 
                                                                  Subject 
                                      RE: [sca-j] ISSUE 4 - Dependency 
                                      reinjection 
 
 
 
 
 
 




Reza,
My first thought was to propose what you have said.  My second thought was
that if an existing instance has not had the new target reinjected, it
could produce confusing results if calls to the reference using
ComponentContext.getServiceReference() use a target that's different from
any target currently known to the instance or available by other means.
I'll be interested to hear whether others think my first thought or second
thought was better.

   Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



"Reza Shafii" <rshafii@bea.com>
07/01/2008 17:23

To
Simon Nash/UK/IBM@IBMGB, "OASIS Java" <sca-j@lists.oasis-open.org>
cc

Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection






Thanks Simon,

Along the same line of thought, shouldn't the effect of a "change to the
target reference" on "subsequent invocations of getServiceReference()"
be a reference to the new target no matter whether reinjection has
occurred or not?

Cheers...

Reza

-----Original Message-----
From: Simon Nash [mailto:NASH@uk.ibm.com]
Sent: Monday, January 07, 2008 4:59 AM
To: OASIS Java
Subject: Re: [sca-j] ISSUE 4 - Dependency reinjection

Reza,
This table is very helpful.  I have one comment.  In the third column,
you
have equated getServiceReference() and cast().  I don't think these are
equivalent.  getServiceReference() is obtaining a new reference, in
which
case I think the current wiring and target service should be used.
cast()
is converting an existing proxy to a ServiceReference, and I think the
semantics for this should match the semantics of using the proxy.
Here's
my attempt to capture this in tabular form.



Effect on


Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.cast()
Subsequent Invocations of ComponentContext.
getServiceReference()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.


Mike,
I don't agree that re-injection should be supported for all scopes.  (I
presume you are proposing that if a runtime supports it at all, then it
must be supported for all scopes.)  Locating and updating existing
short-lived instances when rewiring occurs would impose runtime
overheads
without providing useful value.  The annotation is an interesting idea,
but I think it should be additive to the scope restrictions already
agreed.

   Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Mike Edwards/UK/IBM@IBMGB
07/01/2008 09:27

To
"OASIS Java" <sca-j@lists.oasis-open.org>
cc

Subject
Re: [sca-j] ISSUE 4 - Dependency reinjection







Reza,

This is a good contribution to settling this item of work.

I suggest one addition to the table - "Target Service Undeployed" is OK
for services within the SCA Domain - to deal with services elsewhere,
"Target Service becomes Unavailable" is a better description (we don't
know anything about HOW it became unavailable), but the effects are the
same.



Effect on

Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.
getServiceReference() or
cast()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed service. Business methods

SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.



Now, I'd like to propose the following, which I realize changes some of
the decisions we made previously, but I am getting concerned about
complexity:

1. No reinjection of references occurs by default for any component of
any
scope

2. Any component of any scope can declare that it requires reinjection.
My
suggestion is to provide a parameter to the @Reference
annotation reinject="true", which only has meaning for References which
are a) Fields b) accessible via a setter method (ie it cannot apply to a

reference injected via the constructor).

This I believe is much simpler and it gives the component writer a
chance
to decide for themselves whether they want to be concerned about
wiring changes occurring dynamically during the lifetime of a component.

It will also make it simpler for us to give a good description of the
kinds of circumstance in which it might be good to react to wiring
changes.


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


"Reza Shafii" <rshafii@bea.com>
04/01/2008 22:19


To
<sca-j@lists.oasis-open.org>
cc

Subject
[sca-j] ISSUE 4 - Dependency reinjection








Hi All,

In an effort to try to put more structure around a potential solution to

issue 4, Michael and I put together the attached table. Most of the
content is derived from conlusions reached by the TC's past discussions.
A
matrix such as this might help us better focus future discussions.

Looking forward to your feedback,

Reza

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual

or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by
email and then delete it.[attachment "Dynamic Modification Behavior.xls"

deleted by Mike Edwards/UK/IBM]
---------------------------------------------------------------------
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












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


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this by
email and then delete it.







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




---------------------------------------------------------------------
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 












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]