Support lazy initialization for jee:jndi-lookup [SPR-7477]

[spring-projects-issues]

Oliver Drotbohm opened SPR-7477 and commented

In multi environment scenarios using bean aliases is quite powerful (see attached slide). As handling environments usually involves JNDI lookups. The alias-approach requires beans involved being marked as lazy-init. Thus you will have to use a plain bean definition over the jee namespace. Simply adding a lazy-init attribute would fix that nicely.

---

Affects: 3.0.4

Attachments:

• 7477-git.patch (6.54 kB)
• spring-env-beans.pdf (69.09 kB)

Referenced from: commits c7a350c

[spring-projects-issues]

Chris Beams commented

Ollie - could you flesh this out a bit more? I'm not sure I understand the use case yet. No code required, just give a concrete scenario where this would be helpful, thanks.

Tentatively slated for 3.1 M2 while this is vetted.

[spring-projects-issues]

Oliver Drotbohm commented

Take a look at this slide (taken from Eberhard's Advance Spring workshop). This config snippet sets up selecting beans based on a environment property. To only instantiate the bean suitable for the selected environment, all candidate beans have to be marked as lazy-initialized. As also shown in the example the JNDI related bean has to be set up with plain beans namespace as <jee:jndi-lookup /> does not expose this attribute.

If I don't miss any specialties, it should be straight forward to add the attribute and alter the created bean definition accordingly. So if you like, I could provide a draft for you to review.

[spring-projects-issues]

Chris Beams commented

Makes sense, and this particular use case plays into the conversation around #9935 (Conditional Bean Definitions). You may want to talk to Dave Syer about this, as he's been proposing a similar approach (I added him to the watch list for this issue).

At any rate, the lazy-init attribute seems like a reasonable addition. Working up a patch would be great; it probably won't get addressed soon otherwise (and could easily slip from 3.1 to 3.2).

For consistency, an analysis should also be done across the rest of the core namespaces to see where else lazy-init would make sense. For example, jee:remote-slsb would be an obvious candidate for the same reasons as jndi-lookup.

[spring-projects-issues]

Dave Syer commented

I see no reason why lazy-init shouldn't be added (patch would be great), but note that lazy-init does not prevent autowiring, so your dataSource in the example cannot be injected using @Autowired unfortunately. If we want to fix that it will be more difficult, and it looks like some sort of conditional XML is going to be the answer anyway.

[spring-projects-issues]

Oliver Drotbohm commented

Attached you find a proposed patch to add @lazy-init@ attribute to all elements in @jee@ namespace. It is a Git patch, so applying it to a plain SVN working copy is probably a bit tricky. But as Chris also works with Git SVN integration this should be okay (hopefully :). Any feedback appreciated.

Regards,
Ollie

[spring-projects-issues]

Oliver Drotbohm commented

Reassigned for patch review.

[spring-projects-issues]

Chris Beams commented

Thanks, Ollie. I'll take a look at this next week.

[spring-projects-issues]

Chris Beams commented

This is still a candidate for M2, but the unit test failures in JeeNamespaceHandlerTests need to be addressed.