All Versions
13
Latest Version
Avg Release Cycle
52 days
Latest Release
1743 days ago

Changelog History
Page 1

  • v3.1.0 Changes

    June 21, 2019

    โž• Added

    • โž• Added value alias for @BeanProperty annotation, so using name = is no longer needed. It is still supported to maintain backwards compatibility
  • v3.0.1 Changes

    July 19, 2018

    ๐Ÿ›  Fixed

    • Issue #118, Nested ParameterizedTypes throws a ClassCastException; when a type is a nested generic (eg, List>) it threw a ClassCastException, even if no mapping took place. Fixed by checking the Type in AbstractBeanPropertyClass and calling for rawType if it concerns a ParameterizedType.
    • Issue #116, Mappable nested classes analyzed for wrong direction; when dealing with a mappable nested class, the applied direction is used as-is. This resulted in errors when the field could only be accessed through a method accessor and that the complementing method accessor was not available (ie, get and no set, or set and no get). The problem has been fixed by inverting the method direction on dealing with a mappable nested class.
  • v3.0.0 Changes

    July 17, 2018

    ๐Ÿ›  Fixed

    • ๐Ÿ’ฅ BREAKING CHANGE: BeanConverter implementations no longer work with BeanField, but with BeanProperty. The name BeanField is no longer correct. A BeanProperty is the combination of BeanField and BeanMethod accessors (get/set).
    • Issue #114, Bean property Class types are determined depending on the accessor that will be used; previously the Class was determined on the basis of the bean field. Now, it will look at the way a property will be accessed (getter/setter/field) and use the proper Class, including generics (ie, Type).
  • v2.4.1 Changes

    June 19, 2018

    ๐Ÿ›  Fixed

    • Issue #109, Specify the return type for AbstractBeanConverter.doConvert; on extending AbstractBeanConverter, it is beneficial for the developer to immediately see the expected return type for the doConvert method.
    • Bug #111, BeanCollection null list overrides the existing list; when a source and target have been assigned to a collection handler, it will now treat a null value for the source as special, subscribing it to the BeanCollectionUsage rules (default: CLEAR). That is, it will REUSE the target, CLEAR it, or CONSTRUCT a new one. This is the most logical behaviour with Hibernate on the other side.
    • ๐Ÿ— Bug #112, Strict mapping messes up the build sequence; The validation took place before all configuration was done, resulting in collection handlers not being available in some cases. The validation of strict classes is done as part of the last step of the BeanMapperBuilder.build() method, after all required steps have been taken.
  • v2.4.0 Changes

    March 28, 2018

    โž• Added

    • โœ… Issue #107, Test for access by running against LogicSecuredCheck instance; ability to add LogicSecuredCheck classes to BeanMapper's configuration. These classes can be called upon using the @BeanLogicSecured annotation. It allows for more complex interaction with the enveloping security system, such as not only checking against roles, but also comparing fields in the source or target against information known about the Principal.
    • Issue #105, Ability to deal with @BeanRoleSecured by delegating to a RoleSecuredCheck; when a field is tagged as @BeanRoleSecured, BeanMapper will query its attached SecuredPropertyHandler. The handler will most likely be associated with a security implementation, such as Spring Security (not handled here). If no handler is present, access is granted by default.
    • ๐Ÿ‘ป Issue #106, When a @BeanRoleSecured is found without a RoleSecuredCheck being set, throw an exception; the absence of a RoleSecuredCheck is by default a reason to throw an exception when @BeanRoleSecured is used anywhere within the application.
  • v2.3.2 Changes

    March 06, 2018

    ๐Ÿ›  Fixed

    • Issue #104, IllegalAccessExceptions that occurred after JMV garbage collection; since all PropertyDescriptor instances are kept in a static cache and PD relies on Java's SoftReference, the reference can be discarded. This means that if the accessible boolean was set to true, it will be discarded. The error can manifest itself after a GC run and if the application relies on package-protected classes. The fix: the setAccessible method should be called very soon prior to calling the invoke method rather than only once at the creation of the PropertyDescriptorPropertyAccessor.
  • v2.3.1 Changes

    November 02, 2017

    ๐Ÿ›  Fixed

    • Issue #99, Collections in superclasses did not get their generic types read; one of the attributes of getDeclaredField(field) is that it only works on the active class. The fix means that the superclasses will be checked for presence of the field. When found, it will call getDeclaredField on that class to get its generic type. Also, collection mapping instructions are not used when no collection element type can be determined; that is the one crucial element required for mapping collections.
    • Issue #100, Collections.EmptySet can not have add() called on; BeanCollectionUsage will check the canonical classname of the collection. If it starts with "java.util.Collections.", it will be tagged as reconstructable.
  • v2.3.0 Changes

    November 02, 2017

    โž• Added

    • Issue #92, BeanCollection no longer required for mapping collections; BeanMapper is now capable of determining the collection element type of the target collection by examining the generic type. It will use this type as input for the mapping process. BeanCollection.elementType is no longer a required value. BeanMapper will merge collection information from target and source, giving preference to target information.
    • Issue #97, StringToEnumConverter replaced with AnyToEnumConverter; this makes it possible to convert enums to enums as well. Functionality is required because lists are no longer copied by reference by default.
  • v2.2.0 Changes

    November 01, 2017

    ๐Ÿ›  Fixed

    • ๐Ÿ’ฅ BREAKING CHANGE Issue #93, config() not threadsafe; it is possible for override configurations to be reused between threads, theoretically allowing fields to be changed before the map is called. This is not threadsafe. Now, nowhere is override configuration reused; it will always create a new override configuration. Both config() and wrapConfig() have been replaced with wrap(), which does the same as wrapConfig(). Internally, some OverrideConfiguration properties have been delegated to an OverrideField which takes care of returning the right value for a property. The clear() method has been removed; calling wrap automatically resets these properties (expect for downsize source/target, which are primarily used internally).
    • ๐Ÿ‘ป Issue #60, Unmatched BeanProperty did not throw an exception; properties annotated with BeanProperty must match. If they do not, an exception must be thrown. Due to a bug, this did not always occur (only with BeanProperty on the target side). The current mechanism keep tabs on matched properties and does a final verification. If unmatched properties remain that should have been matched, an exception is thrown. ### ๐Ÿ”„ Changed
    • ๐Ÿ‘‰ Issue #89, Use sensible implementation for Set; when a set is created an no preferredCollectionClass is passed, the handler will look at the collection element type. If the type is Comparable, it will return a TreeSet. If not, it will return a HashSet. ### โž• Added
    • 0๏ธโƒฃ Issue #90, Introduce a global flushEnabled, BeanCollection.flushAfterClear default true; a global flushEnabled setting has been introduced, which is false by default. The BeanCollection.flushAfterClear has changed from a default false to true. BeanMapper asserts that both settings must be true before flushing. BeanMapper Spring #28 sets flushEnabled=true when Lazy is used, because this offers the best chance of the EntityManager running in a transaction context.
  • v2.1.0 Changes

    October 25, 2017

    ๐Ÿ›  Fixed

    • Issue #83, The name field from an enum is not mapped to target field; in the resolution of issue #78 the definition of getter fields has been tightened, because previously all private fields were tagged as available as well. One project made use of this loophole by reading the name field of an enumeration class to a String field. With the new fix this is no longer possible, since the name field is private. This fix makes an exception for the name field of an enum class. It will be considered available for reading. ### โž• Added
    • Issue #84, BeanMapper executes the list of AfterClearFlusher instances; when a clear method on a collection is called, BeanMapper makes sure to run down the list of registered AfterClearFlusher instances. On every instance, the flush method will be called. By default no AfterClearFlusher instances are added. BeanMapper has no notion of ORMs; this is left to beanmapper-spring and beanmapper-spring-boot-starter. Note that the flusher chain is only called when it has been set to do so in the BeanCollection annotation or the override configuration (flushAfterClear).