You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "P.A (JIRA)" <ji...@apache.org> on 2010/09/20 15:11:32 UTC

[jira] Created: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

wrong behavior of InstanceManager.onSet(..) method
--------------------------------------------------

                 Key: FELIX-2603
                 URL: https://issues.apache.org/jira/browse/FELIX-2603
             Project: Felix
          Issue Type: Bug
          Components: iPOJO
    Affects Versions: iPOJO-1.4.0
         Environment: all
            Reporter: P.A


Hello,

Clement and I has talked about this issue, and some different point of views are welcome.

Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".

Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.

I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.


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


[jira] Commented: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FELIX-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912882#action_12912882 ] 

Clement Escoffier commented on FELIX-2603:
------------------------------------------

Fixed in trunk, I've also deployed a SNAPSHOT versions.

Thanks !

> wrong behavior of InstanceManager.onSet(..) method
> --------------------------------------------------
>
>                 Key: FELIX-2603
>                 URL: https://issues.apache.org/jira/browse/FELIX-2603
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.4.0
>         Environment: all
>            Reporter: P.A
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.8.0
>
>
> Hello,
> Clement and I has talked about this issue, and some different point of views are welcome.
> Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
> See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
> Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".
> Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.
> I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
> If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.

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


[jira] Commented: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FELIX-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928156#action_12928156 ] 

Clement Escoffier commented on FELIX-2603:
------------------------------------------

Released in iPOJO Core 1.6.6

> wrong behavior of InstanceManager.onSet(..) method
> --------------------------------------------------
>
>                 Key: FELIX-2603
>                 URL: https://issues.apache.org/jira/browse/FELIX-2603
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.4.0
>         Environment: all
>            Reporter: P.A
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.8.0
>
>
> Hello,
> Clement and I has talked about this issue, and some different point of views are welcome.
> Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
> See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
> Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".
> Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.
> I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
> If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.

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


[jira] Closed: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clement Escoffier closed FELIX-2603.
------------------------------------


> wrong behavior of InstanceManager.onSet(..) method
> --------------------------------------------------
>
>                 Key: FELIX-2603
>                 URL: https://issues.apache.org/jira/browse/FELIX-2603
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.4.0
>         Environment: all
>            Reporter: P.A
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.8.0
>
>
> Hello,
> Clement and I has talked about this issue, and some different point of views are welcome.
> Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
> See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
> Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".
> Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.
> I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
> If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.

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


[jira] Updated: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clement Escoffier updated FELIX-2603:
-------------------------------------

         Assignee: Clement Escoffier
    Fix Version/s: iPOJO-1.8.0

> wrong behavior of InstanceManager.onSet(..) method
> --------------------------------------------------
>
>                 Key: FELIX-2603
>                 URL: https://issues.apache.org/jira/browse/FELIX-2603
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.4.0
>         Environment: all
>            Reporter: P.A
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.8.0
>
>
> Hello,
> Clement and I has talked about this issue, and some different point of views are welcome.
> Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
> See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
> Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".
> Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.
> I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
> If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.

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


[jira] Resolved: (FELIX-2603) wrong behavior of InstanceManager.onSet(..) method

Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clement Escoffier resolved FELIX-2603.
--------------------------------------

    Resolution: Fixed

> wrong behavior of InstanceManager.onSet(..) method
> --------------------------------------------------
>
>                 Key: FELIX-2603
>                 URL: https://issues.apache.org/jira/browse/FELIX-2603
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: iPOJO-1.4.0
>         Environment: all
>            Reporter: P.A
>            Assignee: Clement Escoffier
>             Fix For: iPOJO-1.8.0
>
>
> Hello,
> Clement and I has talked about this issue, and some different point of views are welcome.
> Currently, in the InstanceManager.onSet(..) method, the calls to the FieldInterceptor.onSet(..) is conditioned by '!value.equals(objectValue)', the 'value' is the current reference to the intercepted field, 'objectValue' is the reference that is going to be assigned to the intercepted field.
> See line 1096 of InstanceManager.java in iPOJO core 1.6.4.
> Thus, in my opinion, the semantic of 'onSet' is not really what is described in the iPOJO documentation "This method is called each time a field of the POJO is assigned" (see http://felix.apache.org/site/how-to-write-your-own-handler.html#Howtowriteyourownhandler-InteractingwiththePOJO). Its semantic is rather "this method is called each time a field of the POJO is assigned and the new assigned value is different (in the 'equals(..)' method way) from the current value".
> Moreover, the call to 'equals' method can result in some expensive computations, thus this optimization can be counter productive.
> I suggest to remove the condition '!value.equals(objectValue))' in 'InstanceManager.onSet(..)'.
> If some external codes rely on the current behavior of onSet(..), rename the 'InstanceManager.onSet(..)' to 'InstanceManager.onModification(..)', add the method onModification(..) in FieldInterceptor interface, and adapt the external codes to use this new 'onModification(..)' method.

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