You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Vijai Kalathur (JIRA)" <de...@tuscany.apache.org> on 2011/08/19 02:32:27 UTC
[jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Inherited fields in service impl classes are treated as Properties
------------------------------------------------------------------
Key: TUSCANY-3924
URL: https://issues.apache.org/jira/browse/TUSCANY-3924
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.x
Reporter: Vijai Kalathur
Fix For: Java-SCA-2.x
In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Greg Dritschler <gr...@gmail.com>.
Mike,
Yes, I think you are right. The introspector shouldn't visit the
superclasses. Instead, it should just visit the implementation class. I
would think though that this should include the inherited members (i.e.
members not hidden by redeclaration in the implementation class). I'd
really have to ponder JSR 250 some more though.
On Fri, Sep 16, 2011 at 6:17 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
>
>> Greg,
>
> Regarding JSR250 and annotations, you are totally correct.
>
> However, the question for SCA and the specifications is not about the
> inheritance of annotations or the inheritance of methods, fields etc. The
> specifications are making statements about what gets introspected - ie the
> algorithm that is used to introspect some class to determine the component
> type.
>
> The decision made by the spec folks was that it is important to enable the
> subclass to be in control - and to do this, it is necessary to limit the
> introspection of the class to the artifacts that it declares itself - and
> not to introspect aspects of the parent class.
>
> The simplest example concerns the @Service annotation. If the superclass
> has an @Service annotation and if that annotation was always scanned by the
> introspection process, then the implication is that the subclass could never
> "turn off" the @Service annotation. If the sublcass is to be in control,
> then the introspection algorithm must not be able to examine the superclass
> annotations. This is then extended to all the aspects of the introspection
> algorithm.
>
> In some ways, this is a case of we're damned if we do and we're damned if
> we don't. Either way we construct the introspection algorithm, there are
> consequences for the developer - more work, more things to do. We've chosen
> one approach - at least its consistent even if for some developers it means
> more effort. I'm open to hearing that we've made the wrong choice, but it
> is fair for me to ask for some convincing examples.
>
>
> Yours, Mike.
>
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Mike Edwards <mi...@gmail.com>.
On 14/09/2011 01:10, Greg Dritschler wrote:
> These questions have come up before, and in the past we've looked at the Common Annotations for the
> Java Platform specification (aka JSR 250) for guidance. The rules being proposed here appear to be
> in opposition to one of those guidelines:
>
> (page 2-6)
> 4. Members inherited from a superclass and which are not hidden or overridden maintain the
> annotations they had in the class that declared them, including member-level annotations implied by
> class-level ones.
>
> This guideline makes a lot of sense to me and in my opinion it would be a mistake to do something
> different.
>
> Can we go back to the original problem? What code is deciding that an unannotated field in a
> superclass is a property? I don't see the code that would do that.
>
> Greg
>
>
Greg,
Regarding JSR250 and annotations, you are totally correct.
However, the question for SCA and the specifications is not about the inheritance of annotations or
the inheritance of methods, fields etc. The specifications are making statements about what gets
introspected - ie the algorithm that is used to introspect some class to determine the component type.
The decision made by the spec folks was that it is important to enable the subclass to be in control
- and to do this, it is necessary to limit the introspection of the class to the artifacts that it
declares itself - and not to introspect aspects of the parent class.
The simplest example concerns the @Service annotation. If the superclass has an @Service annotation
and if that annotation was always scanned by the introspection process, then the implication is that
the subclass could never "turn off" the @Service annotation. If the sublcass is to be in control,
then the introspection algorithm must not be able to examine the superclass annotations. This is
then extended to all the aspects of the introspection algorithm.
In some ways, this is a case of we're damned if we do and we're damned if we don't. Either way we
construct the introspection algorithm, there are consequences for the developer - more work, more
things to do. We've chosen one approach - at least its consistent even if for some developers it
means more effort. I'm open to hearing that we've made the wrong choice, but it is fair for me to
ask for some convincing examples.
Yours, Mike.
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Sep 15, 2011 at 2:52 PM, Greg Dritschler
<gr...@gmail.com> wrote:
> I stumbled upon one case where HeuristicPojoProcessor can cause this. In
> visitEnd(), it tests separately whether an implementation has services,
> references, or properties (as determined by previous introspectors). If an
> implementation has services but no references or properties, it will fall
> into calcPropRefs() which will turn unannotated setters into properties.
> One would think that the first thing HeuristicPojoProcessor.visitEnd()
> should do is
> if (!type.getServices().isEmpty() || !type.getReferenceMembers().isEmpty()
> || !type.getPropertyMembers().isEmpty())
> return;
>
> If all 3 are empty, then it can do its thing.
> But visitEnd() also calls evaluateConstructor() in 2 places, including when
> it knows there are references or properties. I'm not sure why it's trying
> to evaluate constructors in an annotated POJO.
> Greg
Yes, it looks like that method has evolved somewhat and I can't say
precisely what it's trying to do by looking at it. In particular that
spec reference is from OSOA I think. I'll have to crawl through it.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Greg Dritschler <gr...@gmail.com>.
I stumbled upon one case where HeuristicPojoProcessor can cause this. In
visitEnd(), it tests separately whether an implementation has services,
references, or properties (as determined by previous introspectors). If an
implementation has services but no references or properties, it will fall
into calcPropRefs() which will turn unannotated setters into properties.
One would think that the first thing HeuristicPojoProcessor.visitEnd()
should do is
if (!type.getServices().isEmpty() || !type.getReferenceMembers().isEmpty()
|| !type.getPropertyMembers().isEmpty())
return;
If all 3 are empty, then it can do its thing.
But visitEnd() also calls evaluateConstructor() in 2 places, including when
it knows there are references or properties. I'm not sure why it's trying
to evaluate constructors in an annotated POJO.
Greg
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Sep 14, 2011 at 1:10 AM, Greg Dritschler
<gr...@gmail.com> wrote:
> These questions have come up before, and in the past we've looked at the
> Common Annotations for the Java Platform specification (aka JSR 250) for
> guidance. The rules being proposed here appear to be in opposition to one
> of those guidelines:
> (page 2-6)
> 4. Members inherited from a superclass and which are not hidden or
> overridden maintain the annotations they had in the class that declared
> them, including member-level annotations implied by class-level ones.
> This guideline makes a lot of sense to me and in my opinion it would be a
> mistake to do something different.
> Can we go back to the original problem? What code is deciding that an
> unannotated field in a superclass is a property? I don't see the code that
> would do that.
> Greg
>
>
>
Hi Greg
I'll let Mike comment on you proposition w.r.t inheritance of
annotations from a super class.
Vijay's actual problem was that unannotated fields were/are being
included in the calculation that discovers properties. The code I
believe is in the introspection code in implementation-java-runtime.
For example, when processing the methods of a service implementation
the operation getAllUniqueMethods() of JavaIntrospectionHelper
specifically steps up/down the inheritance hierarchy...
// evaluate class hierarchy - this is done last to track inherited
// methods
methods = getAllUniqueMethods(pClass.getSuperclass(), methods,
validating);
return methods;
Haven't debugged through this but I'm assuming that this is collection
methods across the hierarchy.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Greg Dritschler <gr...@gmail.com>.
These questions have come up before, and in the past we've looked at the
Common Annotations for the Java Platform specification (aka JSR 250) for
guidance. The rules being proposed here appear to be in opposition to one
of those guidelines:
(page 2-6)
4. Members inherited from a superclass and which are not hidden or
overridden maintain the annotations they had in the class that declared
them, including member-level annotations implied by class-level ones.
This guideline makes a lot of sense to me and in my opinion it would be a
mistake to do something different.
Can we go back to the original problem? What code is deciding that an
unannotated field in a superclass is a property? I don't see the code that
would do that.
Greg
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Aug 24, 2011 at 10:51 AM, Mike Edwards
<mi...@gmail.com> wrote:
> On 23/08/2011 23:23, Simon Nash wrote:
>>
>> This sounds like the right approach. One small point is that the
>> description
>> talks about redeclaring fields and methods in the subclass. This is
>> possible
>> with methods, but it doesn't work for fields as this results in a separate
>> field
>> with the same name in the subclass which hides the superclass field. To
>> expose
>> a superclass field as a property in the subclass, the subclass would need
>> to
>> declare a subclass setter method that assigns to the superclass field.
>>
>> Simon
>
> Yes, agreed.
>
> This all makes subclassing more work, of course, but I see no alternative if
> the subclass is going to be in control.
>
>
> Yours, Mike.
>
>
>
Thanks for doing this Mike.
Just to be clear I believe the words "If there is no @Service
annotation, then the implementation offers no services. " should be
read in conjunction with the title of Case1. I.e it would be
interpreted as "If there is no @Service annotation, but other other
annotations are present, then the implementation offers no services. "
Shall we put these words here [1]? Not much there at the moment but
seems to be the logical place.
[1] http://tuscany.apache.org/documentation-2x/sca-java-implementationjava.html
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Mike Edwards <mi...@gmail.com>.
On 23/08/2011 23:23, Simon Nash wrote:
> This sounds like the right approach. One small point is that the description
> talks about redeclaring fields and methods in the subclass. This is possible
> with methods, but it doesn't work for fields as this results in a separate field
> with the same name in the subclass which hides the superclass field. To expose
> a superclass field as a property in the subclass, the subclass would need to
> declare a subclass setter method that assigns to the superclass field.
>
> Simon
Yes, agreed.
This all makes subclassing more work, of course, but I see no alternative if the subclass is going
to be in control.
Yours, Mike.
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Simon Nash <na...@apache.org>.
Mike Edwards wrote:
> Folks,
>
> Commenting on this JIRA:
>
> On 19/08/2011 01:32, Vijai Kalathur (JIRA) wrote:
>> Inherited fields in service impl classes are treated as Properties
> <snip>
>>
>> In the scenario where the Service impl class extends a class which has
>> no SCA annotations in it, protected fields in the base class are
>> interpreted like Properties.
>> Ideally, only the fields in the impl class should be introspected for
>> References/Properties. The fields in the base class should not be
>> interpreted as References/Properties if there are no SCA annotations.
>>
>> --
>
> First, I agree that the Java C&I specification is deficient in this area
> - it does not give a clear definition of what is supposed to happen when
> the Java implementation class extends another class.
>
> Simon Nash commented that the principle is that the implementation class
> is in control. In particular, if the implementation class is annotated,
> those annotations are obeyed. This is the correct view, since otherwise
> the subclass is forced to accept whatever is declared in the superclass
> with no option of changing things.
>
> Sections mentioned below are from the SCA Java C&I specification cd034 /
> csd04.
>
>
> a) CASE 1: Implementation class has some SCA Annotations
>
> In the case where the implementation class has one or more SCA
> annotations (@Service, @Reference, @Property), then the rules that apply
> to such annotations are followed, as described in Section 8.
>
> NOTE: It is important to remember that the SCA annotations @Service,
> @Reference, @Property are NOT INHERITED. So that @Service on the
> superclass DOES NOT mean that the sublcass is annotated with @Service
> through inheritance.
>
> If there is an @Service annotation on the class, it is handled as in
> Section 8. If there is no @Service annotation, then the implementation
> offers no services. This applies even if the superclass has an @Service
> annotation.
>
> Each Field and Setter method in the implementation class annotated with
> @Reference or @Property is treated according to Section 8. What about
> Fields and Setter methods declared in the superclass? Clearly any Fields
> and Setters without annotations are simply ignored (as stated by Section
> 8). But what about superclass Fields & Setters with annotations?
>
> For the implementation class to be in control, then it must be the case
> that only annotated fields and setter methods in the implementation
> class are taken into consideration. Any annotated fields and setter
> methods in the superclass are ignored. This puts a burden on the
> implementation class to redeclare the fields / setters and annotate them
> suitably if the implementation class wants those fields / setters
> treated as references or properties.
>
>
>
> b) CASE 2: Implementation class has no SCA Annotations, superclass has
> SCA annotations
>
> @Service annotations are introspected from the implementation class
> itself. Any @Service annotation on the superclass is not inherited.
> Whether *any* services are offered by the implementation class then
> depends on whether there are any @Reference or @Property annotations in
> the class itself (as defined in Section 8.1 of the spec).
>
> Regarding the references and properties of the implementation class,
> following the principle established in CASE 1, annotated fields and
> methods in the superclass are ignored as far as their annotations are
> concerned. ie The presence of a @Reference or @Property annotation in
> the superclass has no impact on whether the implementation class is
> treated as "unannotated".
>
> There is a SEPARATE question as to whether the superclass setter methods
> & public/protected fields are considered for the calculation of the
> references & properties of the unannotated class (ignoring their
> annotations, that is). In my view, all such methods and fields of the
> superclass are also ignored when computing the references & properties
> of the implementation class. If the subclass wants them as references &
> properties, then the implementation class must redeclare them
> appropriately. This provides the subclass with control, as defined for
> CASE 1, at the expense of some work (ie redeclarations etc).
>
>
> c) CASE 3: Implementation class has no SCA Annotations, superclass has
> no SCA annotations
>
> This case follows the principles for CASE 2, except that there are no
> annotations to ignore!
>
>
>
> If we agree this approach, we should write it up and make it available
> permanently.
>
>
> Yours, Mike.
>
>
This sounds like the right approach. One small point is that the description
talks about redeclaring fields and methods in the subclass. This is possible
with methods, but it doesn't work for fields as this results in a separate field
with the same name in the subclass which hides the superclass field. To expose
a superclass field as a property in the subclass, the subclass would need to
declare a subclass setter method that assigns to the superclass field.
Simon
Re: [jira] [Created] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Commenting on this JIRA:
On 19/08/2011 01:32, Vijai Kalathur (JIRA) wrote:
> Inherited fields in service impl classes are treated as Properties
<snip>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
>
> --
First, I agree that the Java C&I specification is deficient in this area - it does not give a clear
definition of what is supposed to happen when the Java implementation class extends another class.
Simon Nash commented that the principle is that the implementation class is in control. In
particular, if the implementation class is annotated, those annotations are obeyed. This is the
correct view, since otherwise the subclass is forced to accept whatever is declared in the
superclass with no option of changing things.
Sections mentioned below are from the SCA Java C&I specification cd034 / csd04.
a) CASE 1: Implementation class has some SCA Annotations
In the case where the implementation class has one or more SCA annotations (@Service, @Reference,
@Property), then the rules that apply to such annotations are followed, as described in Section 8.
NOTE: It is important to remember that the SCA annotations @Service, @Reference, @Property are NOT
INHERITED. So that @Service on the superclass DOES NOT mean that the sublcass is annotated with
@Service through inheritance.
If there is an @Service annotation on the class, it is handled as in Section 8. If there is no
@Service annotation, then the implementation offers no services. This applies even if the
superclass has an @Service annotation.
Each Field and Setter method in the implementation class annotated with @Reference or @Property is
treated according to Section 8. What about Fields and Setter methods declared in the superclass?
Clearly any Fields and Setters without annotations are simply ignored (as stated by Section 8). But
what about superclass Fields & Setters with annotations?
For the implementation class to be in control, then it must be the case that only annotated fields
and setter methods in the implementation class are taken into consideration. Any annotated fields
and setter methods in the superclass are ignored. This puts a burden on the implementation class to
redeclare the fields / setters and annotate them suitably if the implementation class wants those
fields / setters treated as references or properties.
b) CASE 2: Implementation class has no SCA Annotations, superclass has SCA annotations
@Service annotations are introspected from the implementation class itself. Any @Service annotation
on the superclass is not inherited. Whether *any* services are offered by the implementation class
then depends on whether there are any @Reference or @Property annotations in the class itself (as
defined in Section 8.1 of the spec).
Regarding the references and properties of the implementation class, following the principle
established in CASE 1, annotated fields and methods in the superclass are ignored as far as their
annotations are concerned. ie The presence of a @Reference or @Property annotation in the
superclass has no impact on whether the implementation class is treated as "unannotated".
There is a SEPARATE question as to whether the superclass setter methods & public/protected fields
are considered for the calculation of the references & properties of the unannotated class (ignoring
their annotations, that is). In my view, all such methods and fields of the superclass are also
ignored when computing the references & properties of the implementation class. If the subclass
wants them as references & properties, then the implementation class must redeclare them
appropriately. This provides the subclass with control, as defined for CASE 1, at the expense of
some work (ie redeclarations etc).
c) CASE 3: Implementation class has no SCA Annotations, superclass has no SCA annotations
This case follows the principles for CASE 2, except that there are no annotations to ignore!
If we agree this approach, we should write it up and make it available permanently.
Yours, Mike.
[jira] [Closed] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Simon Laws (Closed) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws closed TUSCANY-3924.
-------------------------------
Resolution: Fixed
Fixed
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Simon Nash (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087957#comment-13087957 ]
Simon Nash commented on TUSCANY-3924:
-------------------------------------
I believe the rationale is that the subclass (== component implemention class) can force any of these inherited fields to be a property by having the subclass define a setter method for the field and annotating the setter method with @Property. So by having the default be that these inherited fields are not properties and also providing a mechanism for the subclass to make them into properties, all options are possible.
However, if these inherited fields were properties by default, I don't think there is any way that the subclass (== component implemention class) could prevent any of these fields from being a property.
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087750#comment-13087750 ]
Scott Kurz commented on TUSCANY-3924:
-------------------------------------
Why wouldn't the fields in the base class be treated as Property(s)? Without any specific direction from the spec, I'd have just guessed the base fields would be treated as such?
Can you give some motivation for why it should be different?
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Simon Laws (Assigned) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws reassigned TUSCANY-3924:
-----------------------------------
Assignee: Simon Laws
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Assignee: Simon Laws
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Raymond Feng (Commented) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203979#comment-13203979 ]
Raymond Feng commented on TUSCANY-3924:
---------------------------------------
The changes seem to cause a regression where the base class has SCA annotated fields as references or properties.
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Assignee: Simon Laws
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Simon Laws (Commented) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204341#comment-13204341 ]
Simon Laws commented on TUSCANY-3924:
-------------------------------------
I'm seeing the same Raymond. I don't think my approach is good so am about to revert some of it. I had a chat offline with Mike Edwards and I think we need to rethink the interpretation of the spec (which is not clear in this area) as I'm feeling uncomfortable about the code ignoring base class information.
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Assignee: Simon Laws
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TUSCANY-3924) Inherited fields in service impl
classes are treated as Properties
Posted by "Simon Laws (Reopened) (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws reopened TUSCANY-3924:
---------------------------------
Reopening as I didn't answer the JSR250 question
> Inherited fields in service impl classes are treated as Properties
> ------------------------------------------------------------------
>
> Key: TUSCANY-3924
> URL: https://issues.apache.org/jira/browse/TUSCANY-3924
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-2.x
> Reporter: Vijai Kalathur
> Fix For: Java-SCA-2.x
>
>
> In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties.
> Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira