Re: [sca-j] NEW ISSUE: Catch 22 when trying to prevent property introspection

[Simon Nash <oasis@cjnash.com>]

David Booz wrote:
> Mark, thx for logging it, my apologies for missing it.
> 
> Simon, Did you intentionally leave out the other side of the same 
> problem? A component that does not want to expose a service but does 
> want to expose references and/or properties?
> 
> Both of these are corner cases. Just wondering why you focused on one 
> vs. the other.
> 
Dave,
You have raised a good point that I had overlooked.  The introspection
algorithm applies to any Java class that is used as a component
implementation, and the current algorithm will always produce an
exposed service even if no @Service annotations are present.

In theory it is possible to have a component without any services, so
there is a potential problem here and I am fine with expanding the scope
of the issue to include this.  In practice I think a bogus introspected
service is a somewhat less severe problem than a bogus introspected
property or reference because:
  1. The situation is less likely to occur.
  2. If a required property or reference is introspected when not intended,
     any attempt to invoke the component will fail because there is no
     configured value for the property or reference in the component
     definition.  If an exposed service is introspected when not intended,
     this will not cause a runtime failure.

   Simon

> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> "Mark Combellack" <mcombellack@avaya.com> wrote on 08/27/2009 08:09:23 AM:
> 
>  > [image removed]
>  >
>  > RE: [sca-j] NEW ISSUE: Catch 22 when trying to prevent property 
> introspection
>  >
>  > Mark Combellack
>  >
>  > to:
>  >
>  > Simon Nash, OASIS Java
>  >
>  > 08/27/2009 08:10 AM
>  >
>  > Hi Simon,
>  >
>  > I have raised this new issue as JAVA-181. See:
>  >
>  > http://www.osoa.org/jira/browse/JAVA-181
>  >
>  > Thanks,
>  >
>  > Mark
>  >
>  > > -----Original Message-----
>  > > From: Simon Nash [mailto:oasis@cjnash.com]
>  > > Sent: 26 August 2009 23:39
>  > > To: OASIS Java
>  > > Subject: [sca-j] NEW ISSUE: Catch 22 when trying to prevent property
>  > > introspection
>  > >
>  > > TARGET: POJO Component Implementation
>  > >
>  > > DESCRIPTION: Catch 22 when trying to prevent property introspection
>  > >
>  > > Section 8.2 of JavaCI states that public and protected fields of
>  > > simple types such as "int" are automatically introspected as
>  > > SCA properties if the implementation class does not contain any
>  > > @Reference or @Property annotations.
>  > >
>  > > This rule means that an implementation class without any SCA
>  > properties
>  > > or references will accidentally trigger the default introspection
>  > > algorithm, with the result that any public or protected "int" fields
>  > > will be incorrectly introspected as SCA properties (catch 22).
>  > Because
>  > > there are no intended SCA properties or references, the author of the
>  > > class cannot add any @Property or @Reference annotations to the class
>  > > and is therefore unable to prevent the default introspection algorithm
>  > > from being used.
>  > >
>  > > PROPOSAL:
>  > >
>  > > Change the spec to say that the algorithm in section 8.2 only
>  > > applies if the implementation class has no @Service, @Property, or
>  > > @Reference annotations.  This allows the default introspection
>  > > algorithm to be disabled by adding an explicit @Service annotation.
>  > >
>  > >
>  > > ---------------------------------------------------------------------
>  > > 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
>  >
>  >
>  > ---------------------------------------------------------------------
>  > 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
>  >
>