#176 Add support for custom proxy resolver

Dozer v5.1
closed
5
2009-07-30
2009-02-21
No

Allow dozer to be injected with a custom proxy resolver. Default behavior would be used if a custom proxy resolver is not used. Possible methods in the interface would be...

isProxy(Class<?> clazz)
Class<?> getRealClass(Class<?> clazz)
Class<?> getRealSuperclass(Class<?> clazz)

Discussion

  • ed

    ed - 2009-02-21

    Hi Matt,

    I am glat you understand the proxy problem.
    I don't seem to react on https://sourceforge.net/tracker2/?func=detail&atid=727368&aid=2560608&group_id=133517 as it's deleted. It says that comments are closed for this bug.

    Anyway: it's funny to read how you start with the above code as those where exactly my thoughts when I started to make the current proxy resolver as found in the MapperHelper.
    But I chose to use one simple method in the proxy resolver:
    Object unProxy(Object object);

    Why?
    1) You need the wrapped proxied object anyway, so why not extract it straight at the start.
    2) It hardly touch any of the other Dozer core code. I started like you propose above, but found out it has quite some code impact, that also results in quite some possible bugs....
    Like explained in the above bug: simple unproxy in the entrance map methods and that's it... Dozer simple continue working on the encapsulated object.
    3) It's much more future safe. That is, if you make any changes in the future and forget to use the proxy resolver, you easily introduce bugs. Or if you introduce some code that asks for an extra method in the proxy resolver, you need to change the interface of this proxy resolver, which many people won't like of course, such that you might not be able to implement this new feature..

    Simple keep proxies outside the Dozer core.. and you never have to worry about proxies...

    Just my thoughts...

    -- Ed

     
  • Matt Tierney

    Matt Tierney - 2009-03-05

    I implemented this no problem in my local dev environment and all regression tests ran green. Because proxies can be tricky, I decided to wait until 5.1 to release to production if all the testing goes ok. There were a lot of client migration changes in 5.0, so I didnt want clients go through the work of upgrading and possibly run into a functionality problem because of this change. The approach would unproxy to determine which classmapping xml to use, but all data mapping logic would operate on the proxy.

    It seems that if an object is proxied, dozer should interact with that data object via the proxy, so I didnt go down the path of having unProxy() in the interface. The following is the proposed custom proxy resolver interface that could be injected into dozer:

    public interface ProxyResolver {

    public boolean isProxy(Class<?> objectClass);
    public Class<?> getRealClass(Object object);
    public Class<?> getRealSuperclass(Object object);

    }

    Attached is the patch code. There are some unrelated changes in the diff file, but I know which ones are for this. My plan is to provide Ed with a 5.1 beta jar and have him test to be sure it resolves the issue.

    I am not totally convinced this solution is going to resolve the hibernate/polymorphism/proxy issue, but I am hoping for the best and we will find out soon enough. My concern is what will happen when the polymorphic super class attributes are attempted to be mapped on the proxy. There may only be so much dozer can do to get around this issue.

     
  • Matt Tierney

    Matt Tierney - 2009-03-05

    File Added: proxyResolverPatch.txt

     
  • ed

    ed - 2009-03-05

    He Matt,

    Did you put it on a branch? as I don't see it on the trunk..

    Currious: why did you choose this methods in the proxy resolver that handle the class. Why not the unproxy method like I suggested that keep dozer from any strange proxy objects ?

    Be aware that your solution is not without risk. Example: "is-accessible="true"" can't be used anymore as you must access properties through their read/write methods as those are the ones that are proxied. There a more of these issues. Some of them I listed below, but I can easily think of more. This can lead to strange bugs and ofcourse and questions in the forum.

    If you simple unproxy the object you can still use all all functionality of dozer without any problem.

    Just my thoughts.

    -- Ed

     
  • ed

    ed - 2009-03-05

    Ahhhh... now I read your forlast comment ;)... I only saw your last comment about the file added... :(

     
  • ed

    ed - 2009-03-05

    Yep, you have a good point there. It's not called proxy for nothing so you should access it through the proxy... ..

     
  • dmitry (lv)

    dmitry (lv) - 2009-07-30

    Implemented in trunk with minimal code changes.
    It is possible to provide custom implementation of org.dozer.util.DozerProxyResolver in properties file.
    Documentation part will be added as a part of 5.1 release.

     
  • dmitry (lv)

    dmitry (lv) - 2009-07-30
    • labels: --> Mapping Process Improvement
    • milestone: 891576 --> Dozer v5.1
    • assigned_to: mhtierney --> buzdin
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks