You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Mark Lewis (JIRA)" <ji...@apache.org> on 2008/02/07 17:24:08 UTC

[jira] Created: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

BeanDiff - encapsulate, apply, and merge bean differences
---------------------------------------------------------

                 Key: BEANUTILS-304
                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
             Project: Commons BeanUtils
          Issue Type: New Feature
          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
    Affects Versions: LATER THAN 1.8.0
            Reporter: Mark Lewis
             Fix For: LATER THAN 1.8.0


It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:

- The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
- A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
- A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
- Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
- If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
- The BeanDiffConflictException contains an array of BeanDiffConflict objects.
- Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.

- All these actions would work on DynaBeans as well.
- +Converters would be able to account for type differences in source and target bean properties.+

An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Issue Comment Edited: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752014#action_12752014 ] 

Java Developer edited comment on BEANUTILS-304 at 9/7/09 10:02 PM:
-------------------------------------------------------------------

Sorry for English!:

In Weblogic application server's classes and jar files you can find the "com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.

You can find some interesting classes inside "weblogic.descriptor" package (e.g. BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor) . And also another interesting class "weblogic.descriptor.internal.BeanDiff" class. Looking at them is useful!! and may brings some ideas.

Implementing this feature would also eases the process of writing ConfigurationMBeans for applications(http://issues.apache.org/jira/browse/CONFIGURATION-394). ConfigurationMBeans and RuntimeMBeans are two mbean hierarchy in weblogic application server.




      was (Author: myapacheaccount):
    Sorry for English!:

In Weblogic application server's classes and jar files you can find the "com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.

You can find some interesting classes inside "weblogic.descriptor" package (e.g. BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor) . And also another interesting class "weblogic.descriptor.internal.BeanDiff" class. Looking at the source of them(using decompilers!) is useful!! and may brings some ideas.

Implementing this feature would also eases the process of writing ConfigurationMBeans for applications(http://issues.apache.org/jira/browse/CONFIGURATION-394).

  
> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.1
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.1
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Issue Comment Edited: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Mark Lewis (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907665#action_12907665 ] 

Mark Lewis edited comment on BEANUTILS-304 at 9/9/10 11:56 AM:
---------------------------------------------------------------

If it did use annotations/interfaces, it would be an anomaly within Commons BeanUtils.  None of the current APIs require changes to your beans, and I'm sure that's by design.  (Also, I think they're still trying to make the library compatible with Java 1.4, so annotations may not be allowed.)

Some level of customization could be handled already with {{org.apache.commons.beanutils.Converter}} and {{java.util.Comparator}}.  As for sub-diff, I think that would best be handled programmatically rather than declaratively.  You'd run a diff on the two parent beans.  Then if the child beans are different, you could run a diff on them too.  This would simplify the API quite a bit, as we wouldn't have to worry about representing nested differences.

These are great use-cases, though, and we should consider all possibilities.

      was (Author: malfunction84):
    If it did use annotations/interfaces, it would be an anomaly within Commons BeanUtils.  None of the current APIs require changes to your beans, and I'm sure that's by design.  (Also, I think they're still trying to make the library compatible with Java 1.4, so annotations may not be allowed.)

Some level of customization could be handled already with {{org.apache.commons.beanutil.Converter}} and {{java.util.Comparator}}.  As for sub-diff, I think that would best be handled programmatically rather than declaratively.  You'd run a diff on the two parent beans.  Then if the child beans are different, you could run a diff on them too.  This would simplify the API quite a bit, as we wouldn't have to worry about representing nested differences.

These are great use-cases, though, and we should consider all possibilities.
  
> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752335#action_12752335 ] 

Java Developer commented on BEANUTILS-304:
------------------------------------------

You are right, I've corrected it. Another suggestion: Xml diff algorithms(e.g. http://tdm.berlios.de/3dm/doc/index.html) might help to implement BeanDiff.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.1
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.1
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Mark Lewis (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907665#action_12907665 ] 

Mark Lewis commented on BEANUTILS-304:
--------------------------------------

If it did use annotations/interfaces, it would be an anomaly within Commons BeanUtils.  None of the current APIs require changes to your beans, and I'm sure that's by design.  (Also, I think they're still trying to make the library compatible with Java 1.4, so annotations may not be allowed.)

Some level of customization could be handled already with {{org.apache.commons.beanutil.Converter}} and {{java.util.Comparator}}.  As for sub-diff, I think that would best be handled programmatically rather than declaratively.  You'd run a diff on the two parent beans.  Then if the child beans are different, you could run a diff on them too.  This would simplify the API quite a bit, as we wouldn't have to worry about representing nested differences.

These are great use-cases, though, and we should consider all possibilities.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893968#action_12893968 ] 

Java Developer commented on BEANUTILS-304:
------------------------------------------

I've attached better and more complete implementation of BeanDiff here:

http://issues.apache.org/jira/browse/CONFIGURATION-394

'FinalConfigClasses.zip' contains implementation.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752039#action_12752039 ] 

Henri Yandell commented on BEANUTILS-304:
-----------------------------------------

Looking at them using a decompiler would seem a bad idea legally. Please do not do this and then contribute code to Apache.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.1
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.1
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Updated: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

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

Mark Lewis updated BEANUTILS-304:
---------------------------------

    Remaining Estimate: 240h  (was: 1008h)
     Original Estimate: 240h  (was: 1008h)

Didn't realize that a "week" was a 168-hour "actual" week and not a 40-hour "work" week.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.0
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.0
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794768#action_12794768 ] 

Java Developer commented on BEANUTILS-304:
------------------------------------------

I've attached a simple implementation of BeanDiff here:

http://issues.apache.org/jira/browse/CONFIGURATION-394

Hope it helps.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.3
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.3
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Mark Lewis (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894063#action_12894063 ] 

Mark Lewis commented on BEANUTILS-304:
--------------------------------------

I've also found an implementation of BeanDiff [here|http://code.google.com/p/beandiff/] (Google Code).

The problem is that one requires the beans to implement an interface, and the other requires them to be annotated.  This introduces unnecessary compile-time dependencies, and it means you can't use existing beans which have already been compiled.  I would've expected it to work more like BeanUtils.copyProperties(dest, src) where it can work on any bean.

I did some experimental work on this a while, but I don't remember where I stashed it.

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752014#action_12752014 ] 

Java Developer commented on BEANUTILS-304:
------------------------------------------

Sorry for English!:

In Weblogic application server's classes and jar files you can find the "com.bea.core.descriptor_1.4.0.0.jar" in "BEA_HOME\modules" folder.

You can find some interesting classes inside "weblogic.descriptor" package (e.g. BeanUpdateListener, BeanUpdateEvent, DescriptorBean, Descriptor) . And also another interesting class "weblogic.descriptor.internal.BeanDiff" class. Looking at the source of them(using decompilers!) is useful!! and may brings some ideas.

Implementing this feature would also eases the process of writing ConfigurationMBeans for applications(http://issues.apache.org/jira/browse/CONFIGURATION-394).


> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.1
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.1
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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


[jira] Commented: (BEANUTILS-304) BeanDiff - encapsulate, apply, and merge bean differences

Posted by "Java Developer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907625#action_12907625 ] 

Java Developer commented on BEANUTILS-304:
------------------------------------------

Sorry for English:

Take advantage of both worlds, I mean we can have a default behavior for beans which doesn't implement the interface nor annotated( like BeanUtils.copyProperties(dest, src) ), and, customized differentiating behavior for beans which implement the interface or are annotated.

This way the programmer can implement his/her customized differentiating behavior as well.

Choice between interface and annotation is a bit challenging because some decisions of differentiating algorithm could be made at run-time. Annotations can not help in run-time case. For an example: the decision about Sub-diff for current property may be annotated with @Subdiff or be implemented with the assist of an interface which is more flexible and dynamic.

Think about both annotation and interface :)

> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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