Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA componentcode - Another update

[Simon Nash <oasis@cjnash.com>]

It seems that we may be getting close to reopening the discussion of
this issue.  As there has been quite a lot of email discussion on
this thread, I'd like to summarize my remaining concerns with the
current draft proposal.  See comments inline below.

   Simon

Mike Edwards wrote:
> 
> Folks,
> 
> Following the discussion and Simon's points, here is an updated proposal.
> 
> This simply restores all the code in the abstract SCAClientFactory class 
> and makes it normative, including the injection point.
 >
In the latest draft, the description of the class in section 8.9 is fine.
In Appendix B, it's still described as a reference implementation which
is not correct.

> I have not proposed to follow Simon's alternative approach.
> 
There has been further email discussion of this and the use case that
motivates it.  The mechanism in the current proposal has the following
disadvantages:

1) Injecting into defaultFactory currently short-circuits the factory
    finding process and causes all arguments passed to the newInstance()
    method to be ignored.  This means that if vendor A uses this
    injection point, there is no capability for vendor B's factory
    to be located or used, even if suitable Properties and/or ClassLoader
    objects were passed to newInstance().

2) As a consequence of 1), code written for a standalone client
    environment to access services in a vendor B domain won't work in a
    vendor A managed SCA environment that has used the defaultFactory
    injection point.

> http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31871/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%204.pdf 
> 
> http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31870/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%204.doc 
> 
> 
> I have left in the code in both the mainline text and in the appendix. 
>  It is my opinion that this should be the practice for all of
> the code described by this specification, following the practice for 
> XSD, where the appendix contains a full copy of the code
> and the mainline contains a reduced version.
> 
If we duplicated all the code currently in chapters 8 and 9 by adding
it to Appendix B, it would significantly increase the size of the
specification document.  It would also create opportunities for
potential inconsistencies between the versions of the code in
chapters 8 and 9 and the versions in Appendix B.  I can see no reason
to list all the code twice in the same specification document.

The analogy with schemas isn't valid, because the inline pseudo-schemas
are very brief informal summaries of what is in the real normative
schemas.  This isn't the case for the Java code in chapters 8 and 9,
which is fully compilable and normative.

   Simon

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