You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Mike Edwards (JIRA)" <de...@tuscany.apache.org> on 2010/07/28 17:39:16 UTC

[jira] Created: (TUSCANY-3636) Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements

Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements
----------------------------------------------------------------------------------------------------------------

                 Key: TUSCANY-3636
                 URL: https://issues.apache.org/jira/browse/TUSCANY-3636
             Project: Tuscany
          Issue Type: Bug
          Components: Java SCA Java Implementation Extension
    Affects Versions: Java-SCA-2.0-M5
            Reporter: Mike Edwards
            Assignee: Mike Edwards
             Fix For: Java-SCA-2.0


The OASIS SCA Java POJO specification defines the rules for the introspection of an unannotated Java POJO used as an implementation of a component.  The relevant rules are defined in Section 8.1 of the specification:

http://docs.oasis-open.org/opencsa/sca-j/sca-javaci-1.1-spec-cd02.pdf

The particular problem that is the subject of this JIRA concerns the handling of an unannotated setter method which is a referennce, but where the parameter type of the method is not directly an interface with @Remotable, but is instead an array or a java.util.Collection with such an interface as its base type.

In this case, the reference must have a multiplicity of 1..n - a simple interface type parameter must have multiplicity of 1..1.

Testcases POJO_8025 and POJO_8026 check the introspected mutliplicity and the current code of Tuscany fails both of these tests - and indeed the code fails to create the correct <interface.java/> element in the componentType as well.

This is due to the code in HeuristicPojoProcessor.createReference, which fails to deal with array/collection type parameters - and which gets the interface type and the multiplicity wrong for these cases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (TUSCANY-3636) Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements

Posted by "Mike Edwards (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Edwards resolved TUSCANY-3636.
-----------------------------------

    Resolution: Fixed

Update to HeuristicPojoProcessor committed in 

980115

> Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-3636
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3636
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Java Implementation Extension
>    Affects Versions: Java-SCA-2.0-M5
>            Reporter: Mike Edwards
>            Assignee: Mike Edwards
>             Fix For: Java-SCA-2.0
>
>
> The OASIS SCA Java POJO specification defines the rules for the introspection of an unannotated Java POJO used as an implementation of a component.  The relevant rules are defined in Section 8.1 of the specification:
> http://docs.oasis-open.org/opencsa/sca-j/sca-javaci-1.1-spec-cd02.pdf
> The particular problem that is the subject of this JIRA concerns the handling of an unannotated setter method which is a referennce, but where the parameter type of the method is not directly an interface with @Remotable, but is instead an array or a java.util.Collection with such an interface as its base type.
> In this case, the reference must have a multiplicity of 1..n - a simple interface type parameter must have multiplicity of 1..1.
> Testcases POJO_8025 and POJO_8026 check the introspected mutliplicity and the current code of Tuscany fails both of these tests - and indeed the code fails to create the correct <interface.java/> element in the componentType as well.
> This is due to the code in HeuristicPojoProcessor.createReference, which fails to deal with array/collection type parameters - and which gets the interface type and the multiplicity wrong for these cases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-3636) Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements

Posted by "Mike Edwards (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893216#action_12893216 ] 

Mike Edwards commented on TUSCANY-3636:
---------------------------------------

2 changes are needed in HeuristicPojoProcessor.createReference method:

1) Deal with mutiplicity correctly:

            if( isCollectionType( paramType ) || isArrayType( paramType )) {
            	reference.setMultiplicity(Multiplicity.ONE_N);
            } else {
            	reference.setMultiplicity(Multiplicity.ONE_ONE);
            }

where isCollectionType and isArrayType are new helper methods which examine the parameter type to see if  it is either an array type or a Collection type.  Note that the multiplicity of the other case is also changed from ZERO_ONE to ONE_ONE since the OASIS spec demands this.

2) Deal with the interface type for array or Collection type parameters:

Replace:

        try {
            JavaInterface callInterface = javaInterfaceFactory.createJavaInterface(paramType);

with:

        Class<?> baseType = getBaseType(paramType, genericType);
        if (ServiceReference.class.isAssignableFrom(baseType)) {
            if (Collection.class.isAssignableFrom(paramType)) {
                genericType = JavaIntrospectionHelper.getParameterType(genericType);
            }
            baseType = JavaIntrospectionHelper.getBusinessInterface(baseType, genericType);
        }
        try {
            JavaInterface callInterface = javaInterfaceFactory.createJavaInterface(baseType);


...this new version of the code essentially matches the code in ReferenceProcessor.createReference, which is the code that deals with equivalent setter methods which ARE annotated with @Reference


> Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-3636
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3636
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Java Implementation Extension
>    Affects Versions: Java-SCA-2.0-M5
>            Reporter: Mike Edwards
>            Assignee: Mike Edwards
>             Fix For: Java-SCA-2.0
>
>
> The OASIS SCA Java POJO specification defines the rules for the introspection of an unannotated Java POJO used as an implementation of a component.  The relevant rules are defined in Section 8.1 of the specification:
> http://docs.oasis-open.org/opencsa/sca-j/sca-javaci-1.1-spec-cd02.pdf
> The particular problem that is the subject of this JIRA concerns the handling of an unannotated setter method which is a referennce, but where the parameter type of the method is not directly an interface with @Remotable, but is instead an array or a java.util.Collection with such an interface as its base type.
> In this case, the reference must have a multiplicity of 1..n - a simple interface type parameter must have multiplicity of 1..1.
> Testcases POJO_8025 and POJO_8026 check the introspected mutliplicity and the current code of Tuscany fails both of these tests - and indeed the code fails to create the correct <interface.java/> element in the componentType as well.
> This is due to the code in HeuristicPojoProcessor.createReference, which fails to deal with array/collection type parameters - and which gets the interface type and the multiplicity wrong for these cases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (TUSCANY-3636) Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements

Posted by "Mike Edwards (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Edwards closed TUSCANY-3636.
---------------------------------


Closing resolved issues

> Tuscany does not handle unannotated POJOs with reference setter methods according to the OASIS spec requirements
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-3636
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3636
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Java Implementation Extension
>    Affects Versions: Java-SCA-2.0-M5
>            Reporter: Mike Edwards
>            Assignee: Mike Edwards
>             Fix For: Java-SCA-2.0
>
>
> The OASIS SCA Java POJO specification defines the rules for the introspection of an unannotated Java POJO used as an implementation of a component.  The relevant rules are defined in Section 8.1 of the specification:
> http://docs.oasis-open.org/opencsa/sca-j/sca-javaci-1.1-spec-cd02.pdf
> The particular problem that is the subject of this JIRA concerns the handling of an unannotated setter method which is a referennce, but where the parameter type of the method is not directly an interface with @Remotable, but is instead an array or a java.util.Collection with such an interface as its base type.
> In this case, the reference must have a multiplicity of 1..n - a simple interface type parameter must have multiplicity of 1..1.
> Testcases POJO_8025 and POJO_8026 check the introspected mutliplicity and the current code of Tuscany fails both of these tests - and indeed the code fails to create the correct <interface.java/> element in the componentType as well.
> This is due to the code in HeuristicPojoProcessor.createReference, which fails to deal with array/collection type parameters - and which gets the interface type and the multiplicity wrong for these cases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.