Allow Class-relative resource loading in GenericXmlApplicationContext [SPR-7530]

[spring-projects-issues]

Chris Beams opened SPR-7530 and commented

Add

• GenericXmlApplicationContext(Class<?> relativeTo, String... resources)
• load(Class<?> relativeTo, String... resources)

For convenience and parity with ClassPathXmlApplicationContext, which GenericXmlApplicationContext is designed to supersede.

---

Affects: 3.0 GA

Referenced from: commits 6f69b7b

[spring-projects-issues]

Chris Beams commented

Add Mark and Josh as watchers

[spring-projects-issues]

Chris Beams commented

Allow class-relative resource loading in GenericXmlApplicationContext (SPR-7530)

Before:

    - new GenericXmlApplicationContext("com/acme/path/to/resource.xml");

    - GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
      ctx.load("com/acme/path/to/resource.xml");
      ctx.refresh();

After:

    - The above remain supported, as well as new class-relative variants

    - import com.acme.path.to.Foo;
      new GenericXmlApplicationContext(Foo.class, "resource.xml");

    - import com.acme.path.to.Foo;
      GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
      ctx.load(Foo.class, "resource.xml");
      ctx.refresh();

These changes are generally aligned with signatures long available in
ClassPathXmlApplicationContext. As GenericXmlApplicationContext is
intended to be a more flexible successor to CPXAC (and FSXAC), it's
important that all the same conveniences are available.

[spring-projects-issues]

Mark Fisher commented

Yes, they are "generally aligned" except for order due to those tricky var-args ;)

However, as I'm looking at the signature now, I'm wondering if people might see "Class" as an argument type and assume it's for dealing with @Configuration classes?

[spring-projects-issues]

Chris Beams commented

However, as I'm looking at the signature now, I'm wondering if people might see "Class" as an argument type and assume it's for dealing with @Configuration classes?

Fair question, but I would say that due to the naming (relativeClass) and @param documentation of the variable, it should be fairly clear. If that doesn't do it, then the Xml in GenericXmlApplicationContext ought to.

If someone does specify a @Configuration class, it will "work" as advertised, using the class' package info as a prefix for resource loading, so I guess that could lead to a surprise, but I'm not sure what more we can do for the user at this point. It is properly documented.