Announcement Announcement Module
No announcement yet.
create virtual bean property for bean backed by dynamic map Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • create virtual bean property for bean backed by dynamic map

    I have a set of beans I cannot modify. The data in the bean is all implemented by a map and all clients are expected to go through an interface getData("thepropertyyouwant") to obtain data--much like a bean factory.

    However, I need to access this data using getters and setters for a small part of the application where I cannot customize "property/method" access--this part of the application assumes everything is a getter.

    In addition, the bean will be in a spring context so I wanted to use dot notation to access the data via topbean.nextbean.dynamicbean. In this case, the topbean and nextbean has standard getters until you get to the dynamic bean.

    I do not want to write interfaces for all the properties that the application will access, its alot and it would increase maintenance and complexity. However, I would like to write a "when requested data with name X, turn this request into an access method looking like getData(X)" and have this work hierarchically since its in a bean container and the bean is contained within another bean.

    Any thoughts on an approach for this? Not all beans in the context have this issue and I can easily pick out which ones need this support.

  • #2
    Create a wrapper around the "dynamic" target bean, implementing a java.util.Map. In the get(Object) method, delegate to the target bean. In the other methods, that you don't want to implement, throw UnsupportedOperationExceptions.

    Then, in a JSP, "topbean.nextbean.dynamicbeanWrapper.thepropertyyo uwant" should work.


    • #3
      I get what you are saying, but the wrapper needs to have getters and setters as in traditional java beans. The idea is to somehow write a wrapper that intercepts these calls to the getters and setters before a method search is conducted (because obviously it won't find them) and then translate the method call into a real getObject() call. The trick is to intercept the method lookup before it happens because it allows me not to have to write getter/setters at all. In spring I was hoping to write something that could allow me to intercept the method request early enough in the method execution process. Ruby/python has something like this I think.