springframework-developer

[Springframework-developer] Import tag for XML bean definitions

[<jue...@we...>]

We've got an enhancements request in JIRA, currently for the 1.0.3 =
timeframe:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-137
=20
Essentially, it's about an <import> tag that allows to specify imports =
within an application context XML file rather than in an external =
"contextConfigLocation" setting - imports driven by the XML file itself =
rather than from the outside.
=20
<import file=3D'imported.xml'/>
=20
<beans>
=20
  ...
=20
</beans>

Something similar can already be achieved with XML entity includes, but =
those are arguably not very convenient to use. XWork has such an =
<import> tag, BTW; Mike Cannon-Brookes has already suggested this for =
Spring a couple of months ago too.
=20
I wouldn't mind adding such an option, although I still prefer external =
contextConfigLocations. It does have some effects on our =
XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader =
is needed by the parser now for resolving those import locations. This =
indicates that it might be better to introduce this for 1.1 rather than =
for 1.0.3, I guess.=20
=20
Thoughts?
=20
Juergen

[Springframework-developer] Import tag for XML bean definitions

[<jue...@we...>]

Hi everybody,

During an extra evening I had to spend at an airport hotel in Rome, I've =
implemented an "import" tag for XML bean definitions:

http://opensource.atlassian.com/projects/spring/browse/SPR-137

Basically, you can put any number of "import" tags at the beginning of =
bean definition files:

<beans>

  <import resource=3D"myImport1.xml"/>
  <import resource=3D"myImport2.xml"/>

  <bean ... />

</beans>

The resource locations are interpreted as relative to the file that =
contains the import tags. Effectively, this is delegated to the =
"createRelative" method on the Resource interface, invoked on the =
Resource object for the containing file. ("createRelative" has already =
been introduced in 1.1 final.)

I'll commit this tonight, provided that there aren't any objections. =
While I'm not gonna recommend this feature too much, as I personally =
prefer a "contextConfigLocation" that refers to multiple files, I still =
believe that an import tag is a useful addition. In particular, some =
people are used to such a feature from Ant and XWork...

Juergen

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

[Keith <kd...@cs...>]

This sounds great!  Just curious, why wouldn't you recommend it too =
much? =20

I know I've had mention before people wanting to see logically how the =
files
are related - when they're looking at the files (rather than going to
bootstrap configuration, generally separate.)  Kind of a "less magic" =
thing.
I think the import tag, like the recent abstract attribute for abstract =
bean
definitions, can help make things more explicit.

<beans description=3D"Business layer services definitions">

	<import resource=3D"data-access.xml"
         	  description=3D"Import dependent DAO definitions"/>

	<bean> ... </bean>

	...

</beans>

Just curious: if I was to do like above, and still bootstrap a single
application context with "business-layer.xml" and "data-access.xml" as
opposed to just "business-layer" - what happens?

Let's say I had a "utilities-context.xml" with utility beans used by my
other contexts (like PropertyPlaceholderConfigurer), used by business =
and
dao.  If I imported that guy into those files, but in the end everything
resulted in a flat "big" context -- what would happen?

Getting code churned out at the airport is the best! :-) Keith=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, September 16, 2004 4:22 AM
To: spr...@li...
Subject: [Springframework-developer] Import tag for XML bean definitions

Hi everybody,

During an extra evening I had to spend at an airport hotel in Rome, I've
implemented an "import" tag for XML bean definitions:

http://opensource.atlassian.com/projects/spring/browse/SPR-137

Basically, you can put any number of "import" tags at the beginning of =
bean
definition files:

<beans>

  <import resource=3D"myImport1.xml"/>
  <import resource=3D"myImport2.xml"/>

  <bean ... />

</beans>

The resource locations are interpreted as relative to the file that =
contains
the import tags. Effectively, this is delegated to the "createRelative"
method on the Resource interface, invoked on the Resource object for the
containing file. ("createRelative" has already been introduced in 1.1
final.)

I'll commit this tonight, provided that there aren't any objections. =
While
I'm not gonna recommend this feature too much, as I personally prefer a
"contextConfigLocation" that refers to multiple files, I still believe =
that
an import tag is a useful addition. In particular, some people are used =
to
such a feature from Ant and XWork...

Juergen


-------------------------------------------------------
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

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

[Andy D. <an...@ma...>]

I like having this option.  One thought this triggered in my head is the=20
possibility of having application oriented XML config files.  In other word=
s,=20
config files that are oriented around your app so that they become easier t=
o=20
work with for the masses.  ActiveMQ and Mule are two systems that allow you=
=20
to either configure via Spring or configure via a native XML that is=20
typically easier to work with.  ActiveMQ actually uses XSL internally to=20
translate from the ActiveMQ oriented XML config to a Spring config.  So,=20
having said all this, would it make sense to add an xsl (or transform-with)=
=20
attribute to the import tag?  I could then do something like this:
  <beans>
    <import resource=3D"app-config.xml" transform-with=3D"app-to-spring.xsl=
"/>
    ...
  </beans>

  Thoughts?

    - Andy

On Thursday 16 September 2004 01:22 am, j=FCrgen h=F6ller [werk3AT] wrote:
> Hi everybody,
>
> During an extra evening I had to spend at an airport hotel in Rome, I've
> implemented an "import" tag for XML bean definitions:
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>
> Basically, you can put any number of "import" tags at the beginning of be=
an
> definition files:
>
> <beans>
>
>   <import resource=3D"myImport1.xml"/>
>   <import resource=3D"myImport2.xml"/>
>
>   <bean ... />
>
> </beans>
>
> The resource locations are interpreted as relative to the file that
> contains the import tags. Effectively, this is delegated to the
> "createRelative" method on the Resource interface, invoked on the Resource
> object for the containing file. ("createRelative" has already been
> introduced in 1.1 final.)
>
> I'll commit this tonight, provided that there aren't any objections. While
> I'm not gonna recommend this feature too much, as I personally prefer a
> "contextConfigLocation" that refers to multiple files, I still believe th=
at
> an import tag is a useful addition. In particular, some people are used to
> such a feature from Ant and XWork...
>
> Juergen
>
>
> -------------------------------------------------------
> 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

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

[bryan <nih...@gm...>]

juergen .... you are a legend !!!!=20

Hey one thing though ..

Would it be possible to allow the user to specify a list like=20
so  .......=20

 <import resource=3D"myImport1.xml,myImport2.xml,myImport3.xml"/>

The reason that this would be *super* *super* usefull is because then=20
users could store these values in a properties file or in the registry
using the Preferences API and then use the property placeholder=20
configurer to fill in the blanks at runtime.=20

On other thing ..... if you wanted to be super smart and really show off=20
heres a cool feature ....=20

<beans>
<if value=3D"test" equals=3D"test">
 <import resource=3D"myImport1.xml"/>
</if>

 <bean ... />


</beans>

--b




On Thu, 16 Sep 2004 10:22:12 +0200, j=FCrgen h=F6ller [ werk3AT ]
<jue...@we...> wrote:
> Hi everybody,
>=20
> During an extra evening I had to spend at an airport hotel in Rome, I've =
implemented an "import" tag for XML bean definitions:
>=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>=20
> Basically, you can put any number of "import" tags at the beginning of be=
an definition files:
>=20
> <beans>
>=20
>   <import resource=3D"myImport1.xml"/>
>   <import resource=3D"myImport2.xml"/>
>=20
>   <bean ... />
>=20
> </beans>
>=20
> The resource locations are interpreted as relative to the file that conta=
ins the import tags. Effectively, this is delegated to the "createRelative"=
 method on the Resource interface, invoked on the Resource object for the c=
ontaining file. ("createRelative" has already been introduced in 1.1 final.=
)
>=20
> I'll commit this tonight, provided that there aren't any objections. Whil=
e I'm not gonna recommend this feature too much, as I personally prefer a "=
contextConfigLocation" that refers to multiple files, I still believe that =
an import tag is a useful addition. In particular, some people are used to =
such a feature from Ant and XWork...
>=20
> Juergen
>=20
> -------------------------------------------------------
> 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
>

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

[Chris E. <chr...@co...>]

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.

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

[bryan <nih...@gm...>]

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
>

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

[Chris E. <chr...@co...>]

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

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

[bryan <nih...@gm...>]

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
>

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

[bryan <nih...@gm...>]

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
> >
>

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

[bryan <nih...@gm...>]

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
> > >
> >
>

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

[Chris E. <chr...@co...>]

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

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

[Drew D. <dr...@og...>]

bryan wrote:

>juergen .... you are a legend !!!! 
>
>Hey one thing though ..
>
>Would it be possible to allow the user to specify a list like 
>so  ....... 
>
> <import resource="myImport1.xml,myImport2.xml,myImport3.xml"/>
>
>The reason that this would be *super* *super* usefull is because then 
>users could store these values in a properties file or in the registry
>using the Preferences API and then use the property placeholder 
>configurer to fill in the blanks at runtime. 
>
>On other thing ..... if you wanted to be super smart and really show off 
>heres a cool feature .... 
>
><beans>
><if value="test" equals="test">
> <import resource="myImport1.xml"/>
></if>
>
> <bean ... />
>
>
></beans>
>  
>

Better yet is for me to get myself in gear and start putting OGNL 
support into Spring for 1.3.  Then it would be:

<beans>
    <if condition="somevalue == 1">
       <import resource="myImport1.xml"/>
    </if>
</beans>

- Drew

-- 
+---------------------------------+
< Drew Davidson | OGNL Technology >
+---------------------------------+
|  Email: dr...@og...          /
|    Web: http://www.ognl.org   /
|    Vox: (520) 531-1966       <
|    Fax: (520) 531-1965        \
| Mobile: (520) 405-2967         \
+---------------------------------+

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

[bryan <nih...@gm...>]

If you were to do it that way would you still be able to use the 
properties/preferencesPlaceHolderConfigurer ? 

Do those properties need to be applied to a complete field ?

Would it be possible to set those values at the top of the file like 
in ant where you can set properties ?

How would you load the variables ? A custom PropertyAccessor ? 

--b

On Thu, 16 Sep 2004 21:28:51 -0700, Drew Davidson <dr...@og...> wrote:
> bryan wrote:
> 
> >juergen .... you are a legend !!!!
> >
> >Hey one thing though ..
> >
> >Would it be possible to allow the user to specify a list like
> >so  .......
> >
> > <import resource="myImport1.xml,myImport2.xml,myImport3.xml"/>
> >
> >The reason that this would be *super* *super* usefull is because then
> >users could store these values in a properties file or in the registry
> >using the Preferences API and then use the property placeholder
> >configurer to fill in the blanks at runtime.
> >
> >On other thing ..... if you wanted to be super smart and really show off
> >heres a cool feature ....
> >
> ><beans>
> ><if value="test" equals="test">
> > <import resource="myImport1.xml"/>
> ></if>
> >
> > <bean ... />
> >
> >
> ></beans>
> >
> >
> 
> Better yet is for me to get myself in gear and start putting OGNL
> support into Spring for 1.3.  Then it would be:
> 
> <beans>
>     <if condition="somevalue == 1">
>        <import resource="myImport1.xml"/>
>     </if>
> </beans>
> 
> - Drew
> 
> --
> +---------------------------------+
> < Drew Davidson | OGNL Technology >
> +---------------------------------+
> |  Email: dr...@og...          /
> |    Web: http://www.ognl.org   /
> |    Vox: (520) 531-1966       <
> |    Fax: (520) 531-1965        \
> | Mobile: (520) 405-2967         \
> +---------------------------------+
> 
> 
> 
> 
> -------------------------------------------------------
> 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
>

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

[Timo V. <sic...@gm...>]

Hi!

Maybe the XInclude Candidate Recommendation from W3C should be=20
considered for the syntax (http://www.w3.org/TR/xinclude/). Future XML=20
Editors might provide support for it.

Regards,

Timo


Am Freitag, 4. Juni 2004 10:29 schrieb j=FCrgen h=F6ller [werk3AT]:
> We've got an enhancements request in JIRA, currently for the 1.0.3
> timeframe:
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>
> Essentially, it's about an <import> tag that allows to specify
> imports within an application context XML file rather than in an
> external "contextConfigLocation" setting - imports driven by the XML
> file itself rather than from the outside.
>
> <import file=3D'imported.xml'/>
>
> <beans>
>
>   ...
>
> </beans>
>
> Something similar can already be achieved with XML entity includes,
> but those are arguably not very convenient to use. XWork has such an
> <import> tag, BTW; Mike Cannon-Brookes has already suggested this for
> Spring a couple of months ago too.
>
> I wouldn't mind adding such an option, although I still prefer
> external contextConfigLocations. It does have some effects on our
> XmlBeanDefinitionReader/Parser signatures, though, as a
> ResourceLoader is needed by the parser now for resolving those import
> locations. This indicates that it might be better to introduce this
> for 1.1 rather than for 1.0.3, I guess.
>
> Thoughts?
>
> Juergen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>r

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

[Tom T. <tom...@pr...>]

This would be useful for "composed bean definition files" packaged in an
api jar file. We usually split up larger bean definition files by
functional domain, but this separation does not always make sense for the
application that uses the jar file.

It would be nice if the application using the jar file could just specify
a single contextConfigLocation, without knowing whether this file is
actually "composed" or not. In the "composed" case, the actual file would
probably consist of only import tags.

Maybe an <import resource=3D"classpath:/mypackage/imported.xml"/> syntax
would be more obvious? Or maybe "file" is always relative against the
current location?

Kind regards,
Tom.

On Fri, 4 Jun 2004 10:29:38 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> We've got an enhancements request in JIRA, currently for the 1.0.3
> timeframe:
>=20=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-137
>=20=20
> Essentially, it's about an <import> tag that allows to specify imports
> within an application context XML file rather than in an external
> "contextConfigLocation" setting - imports driven by the XML file itself
> rather than from the outside.
>=20=20
> <import file=3D'imported.xml'/>
>=20=20
> <beans>
>=20=20
>   ...
>=20=20
> </beans>
>=20
> Something similar can already be achieved with XML entity includes, but
> those are arguably not very convenient to use. XWork has such an <import>
> tag, BTW; Mike Cannon-Brookes has already suggested this for Spring a
> couple of months ago too.
>=20=20
> I wouldn't mind adding such an option, although I still prefer external
> contextConfigLocations. It does have some effects on our
> XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader is
> needed by the parser now for resolving those import locations. This
> indicates that it might be better to introduce this for 1.1 rather than
> for 1.0.3, I guess.=20
>=20=20
> Thoughts?
>=20=20
> Juergen
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

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

[Kirill M. <ki...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jürgen höller [werk3AT] wrote:

| We've got an enhancements request in JIRA, currently for the 1.0.3 timeframe:
|
| http://opensource.atlassian.com/projects/spring/browse/SPR-137
|
| Essentially, it's about an <import> tag that allows to specify imports within an application context XML file rather than in an external
"contextConfigLocation" setting - imports driven by the XML file itself rather than from the outside.
|
| <import file='imported.xml'/>
|
| <beans>
|
|   ...
|
| </beans>
|
| Something similar can already be achieved with XML entity includes, but those are arguably not very convenient to use. XWork has such an
<import> tag, BTW; Mike Cannon-Brookes has already suggested this for Spring a couple of months ago too.
|
| I wouldn't mind adding such an option, although I still prefer external contextConfigLocations. It does have some effects on our
XmlBeanDefinitionReader/Parser signatures, though, as a ResourceLoader is needed by the parser now for resolving those import locations.
This indicates that it might be better to introduce this for 1.1 rather than for 1.0.3, I guess.

~  I've attached a CVS-based patch to the request which implements this
~  feature without changing the interface of Reader/Parser. Only
~  Resource interface is affected.


|
| Thoughts?
|
| Juergen
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by the new InstallShield X.
|>From Windows to Linux, servers to mobile, InstallShield X is the one
| installation-authoring solution that does it all. Learn more and
| evaluate today! http://www.installshield.com/Dev2Dev/0504
| _______________________________________________
| Springframework-developer mailing list
| Spr...@li...
| https://lists.sourceforge.net/lists/listinfo/springframework-developer
|


- --
Kirill Maximov (aka KIR) | http://www.maxkir.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAyB64E0YZ3264U5QRAvWoAJwOiMHopFMMLec0Y97oO6T9pUAz1ACfYprN
+0xzl/R6J3i4nSgEfSs0XdQ=
=xLS4
-----END PGP SIGNATURE-----