Announcement Announcement Module
Collapse
No announcement yet.
Lazy setting of properties? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lazy setting of properties?

    Hi all,

    I just wondered if/how it might be possible to lazily set properties.

    Scenario:

    <bean id="A" class="test.A">
    <property name="foo">
    <ref local="B"/>
    </property>
    </bean>

    <bean id="B" class="test.B" lazy-init="true">
    </bean>

    If A is retrieved from the bean factory, B will be instantiated as well.
    Is it somehow possible to assign some kind of lazy proxy for the "foo" property which resolves an actual instance of B on first access?
    I already thought of using TargetSource but didn't find a working solution yet.

    Any help would be appreciated.

    Regards,
    Andreas

  • #2
    I guess <lookup-method name="getFoo" bean="B" /> would do what you ask for.

    Comment


    • #3
      As far as I know, this would require me to define the getFoo method abstract and let it be enhanced by CGLIB. That would not exactly be what I am looking for. I rather look for some kind of dynamic "lazy proxy".

      The idea behind is, that I have a standalone application communicating with a remote EJB. Normally, if the app server isn't running and the configuration fails, that is ok. But now there is a new use case which does not require the server. So I tried to find a simple solution to make the realization of the EJB proxy lazy to allow for that use case even in the absence of the application server (without changing the configuration). Since the EJB is never called, everything would work fine.

      Regards,
      Andreas

      Comment


      • #4
        As of about 1.1, in fact the AbstractSlsbInvokerInterceptor from which the ejb proxy inherits has a lookupHomeOnStartup flag which you can set to false (default is true). Additionally, you can even set the cacheHome property to false, which will make the home be looked up each time. Less efficient, but can handle failure...

        Comment


        • #5
          Thanks Colin
          I didn't realize the introduction of this flag (in fact the initial code used Spring 0.9).
          I think this will solve my problem.

          Andreas

          Comment

          Working...
          X