Config files with imports

[p_d_austin]

I have a few comments suggestions on imports.

1. Where is the publically available DTD (not in the jar) fro SF 1.1.1 the old version is at http://www.springframework.org/dtd/spring-beans.dtd

2. The DTD requires you to have at least one bean I would like to be able to have a top level config file that just imports the fragments for the different components of my application.

3. Is it possible to append information to the hbernate config from bean config files that are imported, suppose I had a customer module with 2 beans and two hibernate config files and a products module with 3 beans and hibernate config files. I'd like to have one config file for each module with the bean and hibernate config and a master that I import them, but have a single hibernate session that has the config from both. This would allow me to mix and match my modules to build an application

Thanks,
Paul

[Colin Sampaleanu]

The DTD at

http://www.springframework.org/dtd/spring-beans.dtd

is up to date. Are you caching it somewhere, that you think it's not?

W/regards to mixing and matching the hibernate info in the fashion you describe, you can't do it via import. I presume you're mostly talking about the mappingResource property. You could theoretically use XML entity defs to bring in XML fragments to make up the list, assuming the locations of the XML files are known. It's not really easier, but I guess the other thing you could do is make the list used for the mappingResources be returned by a custom FactoryBean you define. This would take a list of lists, where each list would just be a reference to a list defined in the submodule, and would return one combined list. Not too clean, but it would work...

[cepage]

The DTD at

http://www.springframework.org/dtd/spring-beans.dtd

is up to date. Are you caching it somewhere, that you think it's not?

It seems it would be much nicer if you also had versioned DTD's, like:

http://www.springframework.org/dtd/spring-beans-1.1.dtd
http://www.springframework.org/dtd/s...eans-1.1.1.dtd

This would keep me from having to find and replace all local instances of the schema whenever it is upgraded. You could still keep the old URL up-to-date for people who don't like to know what version of the schema they are working with. :wink:

[Colin Sampaleanu]

I agree, and if you look on the old mailing list archives you'll see that I voted to have versioned DTDs, but Rod and Juergen didn't agree with me :-)