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] JAVA-143: Proposed resolution


Mike,
See comments inline.

   Simon

Mike Edwards wrote:
> 
> Folks,
> 
> I am OK with Simon's proposal to close this issue with no action.
> 
> However, thinking about the scenario, I believe that the whole thing is 
> bogus in that it
> conflates the concepts of "implementation instance" and "reference proxy 
> to a service".
> 
> In reality, the second of these can exist without any of the former for 
> the target service.
> 
> What I am saying is that a reference proxy to a service can be created 
> based on static
> configuration information from the SCA Domain and does not in itself 
> require the existence
> of any implementation instances of the component which implements the 
> service.
> 
> Thus, such a proxy can be created and injected at any time once the 
> Domain configuration
> is known.
> 
> An implementation instance only need be created at the point where an 
> operation of a service
> implemented by that implementation is actually invoked..  
> 
> This means that as long as the SCA Domain configuration is known, a 
> reference proxy can
> *always* be injected when an implementation instance is initialized.
> 
If proxies are used, then we are in the "second bullet" scenario,
not the "first bullet" scenario.

> Now, this does not get us away from the horrible case of a cyclic 
> dependency between
> two implementation classes where each one invokes operations on the 
> other during intialization.
> However, this I think is just the same as two implementation classes 
> that invoke operations on
> each other during regular processing.  If the code in the classes does 
> not prevent it, then
> the two will call each other ad infinitum and the SCA runtime is going 
> to fail.
> 
It isn't quite the same, because during initialization of mutually
dependent instances it is likely that invocations from one to the
other will fail with a "not yet initialized" error rather than
resulting in an infinite loop.  This could happen even there is no
circular invocation loop.  For example, if A and B are mutually
dependent and A's init method invokes operations on B but B's init
method does not invoke operations on A, the problem of A having to
deal with a potentially uninitialized B instance can still occur.

   Simon

> 
> The one other case to discuss is where the SCA Domain configuration is 
> NOT complete at the
> point where a component implementation is initialized.  In this case, it 
> can be literally impossible
> to inject a meaningful reference proxy for the target of the reference 
> since it may not exist in the
> domain.  */null /*is the right thing to inject in this circumstance. 
>  Reinjection comes into play if
> the SCA Domain configuration is later modified so that the target for 
> the reference appears.
> 
> 
> 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
> 
> 
> From: 	Simon Nash <oasis@cjnash.com>
> To: 	OASIS Java <sca-j@lists.oasis-open.org>
> Date: 	15/06/2009 11:21
> Subject: 	[sca-j] JAVA-143: Proposed resolution
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> I would like to revise my proposed resolution to this issue in the
> light of the discusssion and proposed direction for resolving JAVA-131.
> If the currently proposed resolution to JAVA-131 is accepted, it would
> be valid to inject null for an optional reference and then re-inject
> a non-null value later.  In this case, the null value would mean that
> no target for the reference is currently available, and the target
> would become available later as described by the rules for re-injection
> in section 10.17.1 of JavaCAA.
> 
> As an example to illustrate this, consider the case of two components
> A and B that have cyclic references to each other (as fields or setter
> methods), where A's reference to B and B's reference to A are both
> optional.  The first bulleted option of JCI50003 would require the
> SCA runtime to do something like the following:
> 
>  1. create instance of A
>  2. inject null value for A's reference to B
>  3. drive A's @Init method (A can't invoke B because of the null reference)
>  4. create instance of B
>  5. inject null value for B's reference to A
>  6. drive B's @Init method (B can't invoke A because of the null reference)
>  7. inject B instance into A's reference
>  8. inject A instance into B's reference
>  9. make A and B available for service invocations
> 
> I think the above works OK, so I am now proposing to close JAVA-143
> with no action.
> 
>   Simon
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to 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]