[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA componentcode - Another update
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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]