Announcement Announcement Module
Collapse
No announcement yet.
lazy-init ignored for JNDI-based objects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • lazy-init ignored for JNDI-based objects

    I've read several threads about how lazy-init is ignored in some cases, especially JndiObjectFactoryBean and SimpleRemoteStatelessSessionProxyFactoryBean. And using a lazy lookup of the object using a property solves this issue.

    What I don't understand though is why? Under what circumstances are lazy-init ignored? Given the number of times this has come up, it should at least be documented so people like myself don't have to search all over the place trying to figure out why lazy-init doesn't work in all cases.

    The only documentation I could find, lazy-init is what is suggested to make local session beans lazy initialized, and not lookupHomeOnStartup. This implies to me that it should work in all cases. According to section 17.1.2. Accessing local SLSBs:
    There is one caveat with regards to the JNDI lookup. In a bean container, this class is normally best used as a
    singleton (there simply is no reason to make it a prototype). However, if that bean container pre-instantiates
    singletons (as do the XML ApplicationContext variants) you may have a problem if the bean container is
    loaded before the EJB container loads the target EJB. That is because the JNDI lookup will be performed in the init method of this class and cached, but the EJB will not have been bound at the target location yet. The solution is to not pre-instantiate this factory object, but allow it to be created on first use. In the XML containers, this is controlled via the lazy-init attribute.
    I have no problem with the current solution. I just want to understand why lazy-init doesn't work as advertised. Internal consistency is what I've come to expect from Spring.

  • #2
    Imho lazy initialization does only mean, that lazy-init beans will not be created without reason. As far as I am aware of, the only two reasons are, that the bean is requested from the context or that another bean that gets instantiated depends on that bean.

    For the proxies you mention, the specification of "lookupOnStartup" or "lookupHomeOnStartup" can be applied, so that the factory might get instantiated, but the proxied instance is not accessed yet.

    Anyway, I agree that I seems useful to add a small section about lazy-loading and its implications to the reference manual. Compared to its implication it is not adequately described there, as the number of according questions indicate.

    Regards,
    Andreas

    Comment


    • #3
      Hi

      I have created a JIRA issue to improve the ref docs with regard to the semantics of lazy initialization, and will address said issue before Spring 2.0 final.

      Anything else documentation related while I'm here?

      Cheers
      Rick

      Comment


      • #4
        Originally posted by Andreas Senft
        Imho lazy initialization does only mean, that lazy-init beans will not be created without reason. As far as I am aware of, the only two reasons are, that the bean is requested from the context or that another bean that gets instantiated depends on that bean.
        That's my understanding too. But that doesn't appear to be what happens. But I think I need to test the example I have more to make sure i know what's going on. In my test I have 3 XML files used to create the ApplicationContext. I also use a PropertyPlaceholderConfigurer.

        Comment


        • #5
          The problem I was seeing in my tests was related to the autowiring one of the TestCase subclasses does. For some reason all the classes were instantiated.

          When I tested my context from a main lazy-init seemed to work fine. So the problem I seemed to have in my production code must have been dependency related.

          Comment

          Working...
          X