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


HI Mike,
 
That's very interesting question. I think for that use case injecting a dead reference (or invalidating somehow the old working reference) is more consistent with the resolution that was made as ASSEMBLY-6 :
 
...
A reference with multiplicity  1..1 or 1..n MUST have at least one target service defined.

Where it is detected that the above rules have been violated, either at deployment
or at execution time, an SCA Runtime MUST generate an error no later than
when the reference is invoked by the component implementation.
 
So that would lead to having "dead references" and saying that the "null representation" rule is not applied for domain level wires.
 
 
Btw, another way of thinking would be to require from the deployment tooling to detect such invalid deployment operations that lead to unwired references with multiplicity 1 and reject them.
I.e. a good implementation could show a dialog - " You are trying to undeploy a wire from A to B, however component A is using the wire with multiplicity 1 and the operation can not be performed, do you want to
 
- undeploy A as well 
- abort undeployment.
- redeploy A with changed multiplicity to 0
 
Just thinking aloud.
 
Best Regards
Peter


From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, 8. January 2008 12:22
To: OASIS Java
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection


Peter,

I'd be happy keeping the use of null for unwired references for 0..x multiplicity cases.  This gives the implementation
code a very simple way of checking whether the reference is wired or not.  Note in your table below, reinjection
may give a null reference, an empty collection or simply a reduced size collection (for 0..n cases with multiple
targets present).

The more interesting question is what to do in the case of 1..x multiplicity cases where the wiring is supplied "externally"
- ie not in the direct configuration of the reference itself, at domain level.  So, I'm thinking of

a) reference is marked with autowire & targets arrive from other contributions
b) reference is wired with explicit <wire/> elements supplied in a separate contribution

If the multiplicity constraints are not honoured at some time, what is supposed to happen?  Is it valid to inject a null
reference object in this case?  If not, what DOES the runtime inject when the wiring changes so that there is no wire
present any longer.....

I don't have a clear view of this at the moment.  The consistent thing to do is to inject a null reference.  However, for
a component declaring the reference 1..x, this should not happen.  An alternative is to inject a "dead" reference -
one which can only ever generate an exception if any of its business methods are invoked.


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



"Peshev, Peter" <peter.peshev@sap.com>

07/01/2008 18:18

To
"Blohm, Henning" <henning.blohm@sap.com>, Mike Edwards/UK/IBM@IBMGB, "OASIS Java" <sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection





HI,

Just to comment on  " Targeted Service Undeployed " usecase. According to the OSOA errata submitted in OASIS, unwired references should have the following representation :

"An unwired reference with a multiplicity of 0..1 must be null. An unwired reference with a multiplicity of 0..N must be an empty array or collection"

So perhaps the following representation looks more consistent to that decision :

Effect on
Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.
getServiceReference()
Targeted Service Undeployed Reinjection with null /empty collection MAY occur Business methods SHOULD throw ServiceUnavialbleException. Returns null or empty collection


I would personally would be happy to revisit that decision and say that the "null representation" is not valid for domain level wiring that is subject to change and keep the exception throwing as defined by Reza.

Best Regards

Peter

________________________________

From: Blohm, Henning [
mailto:henning.blohm@sap.com]
Sent: Monday, 7. January 2008 19:43
To: Mike Edwards; OASIS Java
Subject: AW: [sca-j] ISSUE 4 - Dependency reinjection


Hi Reza, Mike,

 I am sure that table helps a lot. I believe the component context should always reflect the most current wiring situation (independent of whether re-injection occured or not). That is easiest to understand and implement and otherwise there would be no way of getting to the current wiring (while hoilding on to a service reference is always possible).

 It seems that less re-injection is probably safer than more re-injection, so designating an annotation attribute looks like a smart move.

Thanks,
 Henning

________________________________

Von: Mike Edwards [
mailto:mike_edwards@uk.ibm.com]
Gesendet: Montag, 7. Januar 2008 10:27
An: OASIS Java
Betreff: 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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]