[Springframework-developer] Re: Import tag for XML bean definitions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Speaking abstractly I feel that a been configuration file should be 
finalized before deployment.  Before something is installed into an 
end-user environment, the dependencies should generally be well defined.

You could make an argument for plugins... but again, generally, a 
solutions provider will probably configure that sort of thing prior to 
delivering an integrated product.

However, there are much more subjective configuration issues, like which 
database driver is being used, what the connection URL is, etc.  These 
things do need to be configured by end users or their support staff (sys 
admins).  This is what the PropertyPlaceHolder stuff is good for.

I think of bean configurations as a place where dependencies are 
defined.  A property, such as a URL, is not in and of itself a 
dependency... it's more a configuration parameter.

Keeping those two separate enables end users to configure an app for 
their specific environment without requiring them to mess with xml files.

The only way to xml-validate dependencies would be to keep one big file 
or use entity descriptors.  Either supplying multiple xml files to an 
App Context or using an import tag defeats simple validation.  But 
perhaps this is moot because many FactoryBeans allow dependencies to be 
specified by bean name, not by id, to enable prototype behavior.  So you 
need a smart validator either way.

I haven't given much thought to how to make is easier for the end user 
to edit a properties file, but at least keep in mind it doesn't 
necessarily have to be a classpath resource.  It might be anywhere in 
the filesystem, intranet, or any other resource.

My $0.02.

bryan wrote:
> So is my point valid or not ? Has anyone gone so far as to consider the 
> deployment part of the spring lifecycle ?
> 
> --b
> 
> 
> On Tue, 21 Sep 2004 13:40:19 +0200, bryan <nih...@gm...> wrote:
> 
>>Chris did you read my reply ?
>>
>>--b
>>
>>
>>
>>
>>On Mon, 20 Sep 2004 18:32:00 +0200, bryan <nih...@gm...> wrote:
>>
>>>If you use a non xml based import facility i think it will be harder to use
>>>xml editors like xmlbuddy with them as there will be problems with entities
>>>referencing entities that are not in the document, this will make it harder to
>>>validate at development time.
>>>
>>>Why not instead take the approach of a single big file like a registry
>>>depending on a single properties file or set of preferences ( registry )
>>>values.
>>>
>>>The problem is that with some things like
>>>org.springframework.web.context.ContextLoaderListener get the list of
>>>properties files using a context-param.
>>>
>>>How can the user change this unless she unzips the application, manually
>>>edits the value and then redeploys it ?
>>>
>>>Wouldn't it be far simpler from an end user ( at the end of the day they
>>>drive requirements ) point of view if they could just run a simple program
>>>which would edit the registry keys and then restart the application with the
>>>changes happening automatically ?
>>>
>>>Very few web applications are well designed from an installation/administration
>>>point of view, but there are a couple that really stand such as the php based
>>>squirrelmail.
>>>
>>>It offers an easy to use perl config program that chooses sensible defaults for
>>>the administrator but allows them to change them as they see fit.
>>>
>>>If there is no chance of making the changes to the xml format perhaps it
>>>would be good to at least allow some mechanism for changing the files that
>>>ContextLoaderListener uses at runtime without unzip, edit xml, re-zip
>>>cycle.
>>>
>>>Not everyone is a programmer or technically literate, this is fine for some
>>>but not fine for your average point and click windows "administrator".
>>>
>>>--b
>>>
>>>On Mon, 20 Sep 2004 08:15:41 -0400, Chris Eldredge
>>><chr...@co...> wrote:
>>>
>>>>As my message stated, I think the import tag is a good feature and look
>>>
>>>
>>>>forward to using it.  It should solve your 3 * 300 problem.
>>>>
>>>>The part I take issue with is putting conditionals and other
>>>>meta-programming into an xml file.  Keep in mind, xml and IoC are
>>>>intended to divorce configuration from the program.  Turning a bean
>>>>configuration file into a bean "script" entirely defeats that purpose
>>>>because essentially you are putting the program into the configuration.
>>>>
>>>>What is the perceived advantage of using
>>>>
>>>><condition test="foo"> <import name="sometimes.xml"> </condition>
>>>>
>>>>instead of the java equivalent:
>>>>
>>>>if (foo) {
>>>>        context = new ClassPathXmlApplicationContext(new String[] {"main.xml",
>>>>"sometimes.xml"});
>>>>} else {
>>>>        context = new ClassPathXmlApplicationContext(new String[] {"main.xml"});
>>>>}
>>>>
>>>>All you would be doing is mixing your configuration with your program.
>>>>
>>>>
>>>>
>>>>bryan wrote:
>>>>
>>>>>Chris,
>>>>>
>>>>>You must really like keeping 3 *  300 line files in sync with each
>>>>>other when just
>>>>>60/70 lines are different in each one .....
>>>>>
>>>>>I'm not talking about adding #ifdef and #define to the top of your java source
>>>>>files here !
>>>>>
>>>>>--b
>>>>>
>>>>>
>>>>>
>>>>>On Thu, 16 Sep 2004 14:46:45 -0400, Chris Eldredge
>>>>><chr...@co...> wrote:
>>>>>
>>>>>
>>>>>>bryan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>><beans>
>>>>>>><if value="test" equals="test">
>>>>>>><import resource="myImport1.xml"/>
>>>>>>></if>
>>>>>>
>>>>>>This looks an awful lot like meta-programming to me.  This becomes a
>>>>>>slippery slope.  IMO, xml bean files should be for configuration, not
>>>>>>for scripting.
>>>>>>
>>>>>>The <import>, however, is something that I am looking forward to using
>>>>>>on my current project.
>>>>>>
>>>>>>Chris.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>>>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>>>>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>>>>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>>>>>_______________________________________________
>>>>>>Springframework-developer mailing list
>>>>>>Spr...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>>>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>>>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>>>_______________________________________________
>>>>Springframework-developer mailing list
>>>>Spr...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php