springframework-developer

[Springframework-developer] Another BeanFactory feature

[Rod J. <rod...@in...>]

All,

I've just prototyped another potential BeanFactory feature that tackles the
PicoContainer head on.

I call it "autowire". Another new optional attribute on <bean>, although it
could be supported in non-XML factories as well.

Again it's backward compatible. It doesn't complicate the API, although it
obviously adds a bit more code to the implementation.

I see it working in 3 modes:

- autowire="none": the traditional and default behaviour. Dependency
checking might be used here if desired.

- autowire="byType": if a bean exposes a property of type Foo and there's
exactly one bean of type Foo defined in the same factory, the property of
type Foo is set to the other bean automatically. My prototype does nothing
if there are 0 or >1 beans of type Foo; not sure if this should result in an
exception. This is basically PicoContainer behaviour: good for small
factories with one object of each type but inadequate for more complex
scenarios, which Spring already supports well.

- autowire="byName": if a bean exposes a property with name "spouse" it's
automatically set to the value of the "spouse" bean in the same factory if
one is present. If this results in a type mismatch that's a fatal error.
This behaviour has no parallel in PicoContainer but might be useful in some
cases. It would work even if there were multiple beans of the type of
Spouse.

Implementation wasn't very complex.

Is this worthwhile behaviour? Should I commit it (probably tomorrow)?

Again I think the marketing value is the most important thing. This would
enable us to say that we can do anything PicoContainer does, and more.

Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
didn't choose to use it.

Regards,
Rod

Re: [Springframework-developer] Another BeanFactory feature

[Ivan R. <iv...@we...>]

> I've just prototyped another potential BeanFactory feature that tackles the
> PicoContainer head on.
> 
> I call it "autowire". Another new optional attribute on <bean>, although it
> could be supported in non-XML factories as well.
 >
 > ...
 >
> Is this worthwhile behaviour? Should I commit it (probably tomorrow)?
> 
> Again I think the marketing value is the most important thing. This would
> enable us to say that we can do anything PicoContainer does, and more.
> 
> Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
> didn't choose to use it.

   I am giving my comments from a position of someone who has only
   observed Spring from a (sometimes short) distance but hasn't used
   in a project yet. Please feel free to disregard my comments if you
   wish.

   When I was trying out the Web MVC part of Spring I got confused
   with the behavior of the SpringServlet (hope I got the name right),
   where I didn't have to give it anything - it simply went to
   the application context and got stuff out of it itself.
   Things were happening somehow and it wasn't clear how. It took
   me some time to figure out what was happening. Honestly, that
   part of the framework is still a bit blurry to me.

   On a similar note, I would prefer to have only one way to
   configure beans. I understand how it may look interesting to
   have beans wired automatically but I suspect people will then have
   to put comments to explain to other people what's really going on.

   In a way, wiring the beans manually is a form of documentation
   how system works. So, if it were up to me I would cancel all
   automagical processes. Besides, we will probably soon have GUI
   tools to configure our beans with and that will be more fun
   anyway.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Another BeanFactory feature

[Colin S. <col...@ex...>]

Ivan Ristic wrote:

>
>> I've just prototyped another potential BeanFactory feature that 
>> tackles the
>> PicoContainer head on.
>>
>> I call it "autowire". Another new optional attribute on <bean>, 
>> although it
>> could be supported in non-XML factories as well.
>
> >
> > ...
> >
>
>> Is this worthwhile behaviour? Should I commit it (probably tomorrow)?
>>
>> Again I think the marketing value is the most important thing. This 
>> would
>> enable us to say that we can do anything PicoContainer does, and more.
>>
>> Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
>> didn't choose to use it.
>
>
>   I am giving my comments from a position of someone who has only
>   observed Spring from a (sometimes short) distance but hasn't used
>   in a project yet. Please feel free to disregard my comments if you
>   wish.
>
>   When I was trying out the Web MVC part of Spring I got confused
>   with the behavior of the SpringServlet (hope I got the name right),
>   where I didn't have to give it anything - it simply went to
>   the application context and got stuff out of it itself.
>   Things were happening somehow and it wasn't clear how. It took
>   me some time to figure out what was happening. Honestly, that
>   part of the framework is still a bit blurry to me.
>
>   On a similar note, I would prefer to have only one way to
>   configure beans. I understand how it may look interesting to
>   have beans wired automatically but I suspect people will then have
>   to put comments to explain to other people what's really going on.
>
>   In a way, wiring the beans manually is a form of documentation
>   how system works. So, if it were up to me I would cancel all
>   automagical processes. Besides, we will probably soon have GUI
>   tools to configure our beans with and that will be more fun
>   anyway.
>
I think automagic behaviour is actually quite good when it covers almost all
cases actually. Typing a lot of the same stuff over and over is no good when
a framework can do it for you in 99% of the cases. I would really hate to
have to on a regular basis do work that a framework can do for me, just to
make things clearer on initial use.

On the basis of the above though, I certainly don't think the new stuff 
Rod is
describing qualifies for being on by default, since it wouldn't apply 
much of
the time. But I do think it's maybe worth being in there are an option, 
if even
for the marketing aspect. Like it or not, people have a number of choices in
what frameworks/containers they use; we think Spring is the best choice, but
sometimes people will not get past a pure feature comparison, so sometimes
you have to add some things just on this basis.

Regards,
Colin

Re: [Springframework-developer] Another BeanFactory feature

[Rod J. <rod...@in...>]

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we don't
use it, and don't really recommend it, this neutralizes that claim.

RE : [Springframework-developer] Another BeanFactory feature

[Jean-Pierre <jp...@jp...>]

+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoy=E9=A0: jeudi 4 septembre 2003 23:42
=C0=A0: Ivan Ristic
Cc=A0: spr...@li...
Objet=A0: Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: RE : [Springframework-developer] Another BeanFactory feature

[Alef A. \(JTeam\) <al...@jt...>]

Well, I think this feature could be pretty useful... The only thing I
was thinking of is: how about multiply properties wiring
automatically... As I understand it right now, there's only one property
per bean that can be autowired...

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Jean-Pierre
Verzonden: Friday, September 05, 2003 12:17 AM
Aan: 'Rod Johnson'; 'Ivan Ristic'
CC: spr...@li...
Onderwerp: RE : [Springframework-developer] Another BeanFactory feature


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson Envoy=E9=A0: jeudi 4 septembre 2003 23:42 =C0=A0: =
Ivan
Ristic Cc=A0: spr...@li...
Objet=A0: Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the "objects cannot be in an inconsistent state" argument is the only
thing PicoContainer can really claim as an advantage over Spring. Even
if we don't use it, and don't really recommend it, this neutralizes that
claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Sad but true, was Another BeanFactory feature

[Rob B. <rob...@ve...>]

Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend"
for "marketing" value.  I know it's true that open source projects need to
be concerned as much with marketing these days as commercial software.  It's
just sad to have it be so true, since many open source projects are attempts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagical"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuff
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Also
"autowiring", etc would be disabled.  This (I think) would make both crowds
happy because those who want automagical stuff can use it, they would just
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave it
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoyé : jeudi 4 septembre 2003 23:42
À : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Colin S. <col...@ex...>]

To reverse the old adage, 'one man's poison is another man's meat'. I 
honestly don't think that what you're describing is possible, since 
different things are of different value to different people. On top of 
that, Spring is made up of various components, so it's hard to do 
something such as cut out a swath of functionality across the whole thing.

At the end of the day, I think as the project (any project really) 
devleops, you have to constantly look at the value of the new features 
you are adding (and there is more than one way to define value), decide 
whether they are worth having at all, and try to come up with some 
sensible defaults and usage and configuration mechanisms that achieve 
the right balance in all these aspects such as ease of use, power, 
reliability, marketing, etc. I know this is vague, but I really think it 
has to be done on a case by case basis, and handled in that fashion it 
is manageable and possible.

Regards,
Colin


Rob Butler wrote:

>Sad but true (Metallica)
>
>It's pretty sad when an open source, well architected project has to add
>features that are of little use or ones that they "don't really recommend"
>for "marketing" value.  I know it's true that open source projects need to
>be concerned as much with marketing these days as commercial software.  It's
>just sad to have it be so true, since many open source projects are attempts
>to get away from the marketing and hype and deliver a quality (free)
>technically superior piece software.
>
>Back to the matter at hand, I can see the value in having the "automagical"
>wiring, and I can also see the value in not having the automagical stuff.
>How about adding a feature to the framework that ALL the automagical stuff
>can be declaritively turned on/off(disabled) with just one setting, by
>default it is off(disabled).  In that way, any attempt to use the
>automagical features in the config files throws an error on startup.  Also
>"autowiring", etc would be disabled.  This (I think) would make both crowds
>happy because those who want automagical stuff can use it, they would just
>specifically have to turn it ON for the framework before using the
>automagical features in code / config files.  Those who don't can leave it
>turned off.
>
>Later
>Rob
>
>
>+1
>
>I agree it's not really to recommend. But marketing has to be taken in
>account.
>
>Jean-Pierre
>
>-----Message d'origine-----
>De : spr...@li...
>[mailto:spr...@li...] De la
>part de Rod Johnson
>Envoyé : jeudi 4 septembre 2003 23:42
>À : Ivan Ristic
>Cc : spr...@li...
>Objet : Re: [Springframework-developer] Another BeanFactory feature
>
>  
>
>>   In a way, wiring the beans manually is a form of documentation
>>   how system works. So, if it were up to me I would cancel all
>>   automagical processes. Besides, we will probably soon have GUI
>>   tools to configure our beans with and that will be more fun
>>   anyway.
>>    
>>
>
>I'm inclined to agree. But I think the marketing advantage is real, as
>the
>"objects cannot be in an inconsistent state" argument is the only thing
>PicoContainer can really claim as an advantage over Spring. Even if we
>don't
>use it, and don't really recommend it, this neutralizes that claim.
>
>  
>

RE: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Trevor C. <pr...@se...>]

I think it's a great idea, partly for marketing but more for an easier
"entry-level" use.  While I'm sure most of us are very talented developer=
s,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.  Making Spring easier for those
who don't have the time or expertise to figure out the details of the
framework are more likely to adopt if most of the little stuff is taken c=
are
of (like the "automagical wiring").  I also see broad acceptance of Sprin=
g
being of big value, since that provides more use/testing in the real worl=
d,
and because a larger market of users will naturally draw more developers,
thus improving Spring even more.

With that in mind, I personally wouldn't mind seeing auto-wiring ON by
default.  I would not use it, and (I'm assuming) most of the developers I=
've
talked to from the Spring project wouldn't use it.  However, if those wit=
h
the time/experience to fully understand how to use/configure Spring are i=
n
the minority (which I expect they will be if we have a large user base),
wouldn't it make more sense to have the defaults at a "beginner" level to
handle the 80% of users, rather than "advanced" to support the 20% (which
then forces the 80% to do more digging/searching, and often going
elsewhere).

I also wouldn't say I wouldn't recommend using the autowiring.  If I'm do=
ind
an important, enterprise level system, I definately want to control exact=
ly
what's going on, and I will probably have a more complex context.  Howeve=
r,
for all the "one-off" standalone apps, internal web sites, and prototypes=
,
you simply don't need to manually code stuff, and even the "advanced"
developer might use the auto-wiring.

+1 to adding it with either default setting (but I'd lean to "beginner"
defaults)

T


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Butler
Sent: September 5, 2003 12:30 PM
To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
Cc: spr...@li...
Subject: [Springframework-developer] Sad but true, was Another
BeanFactory feature


Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend=
"
for "marketing" value.  I know it's true that open source projects need t=
o
be concerned as much with marketing these days as commercial software.  I=
t's
just sad to have it be so true, since many open source projects are attem=
pts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagica=
l"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuf=
f
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Als=
o
"autowiring", etc would be disabled.  This (I think) would make both crow=
ds
happy because those who want automagical stuff can use it, they would jus=
t
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave i=
t
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoy=E9 : jeudi 4 septembre 2003 23:42
=C0 : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Rod J. <rod...@in...>]

I understand some concerns about this feature.

Rob, I don't think it needs to have a global switch to turn it off. It's off
by default. It's off if you don't know it's there or don't want to. The only
way to turn it on involves adding an optional attribute to each bean that
uses it. It's backward compatible. It doesn't complicate the API (no more
public methods on classes application developers will use).

Secondly, if no one uses it and it ends up being only for marketing, I'll
happily get rid of it. I believe we should be ruthless with features no one
uses. Hibernate get this right.

Marketing: I agree it's sad. But there are a lot of good open source
projects that don't go anywhere, meaning it doesn't matter how good they
are. I don't want Spring to be like that. I think our architecture is
particularly good, we have an advantage in my public profile and the fact
that many of us regularly contribute to TSS etc, but we need to consider
marketing.

Nevertheless, I would never want to do anything that compromises our
architecture. I don't think this feature does.

>While I'm sure most of us are very talented developers,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.

I used to think that. But I'm starting to wonder if we aren't all being a
bit naive here. Maybe it's just the market, but I've found that I can hire
good developers in London who are capable of working things out for
themselves. Of course I have to interview 2-3 others before I employ one,
but there are a lot of good Java developers out there.

Regards,
Rod


----- Original Message -----
From: "Trevor Cook" <pr...@se...>
To: <spr...@li...>
Sent: Friday, September 05, 2003 9:20 PM
Subject: RE: [Springframework-developer] Sad but true, was Another
BeanFactory feature


I think it's a great idea, partly for marketing but more for an easier
"entry-level" use.  While I'm sure most of us are very talented developers,
almost everyone I talk to always comments on the programmers who can't
figure out how to turn on a light switch.  Making Spring easier for those
who don't have the time or expertise to figure out the details of the
framework are more likely to adopt if most of the little stuff is taken care
of (like the "automagical wiring").  I also see broad acceptance of Spring
being of big value, since that provides more use/testing in the real world,
and because a larger market of users will naturally draw more developers,
thus improving Spring even more.

With that in mind, I personally wouldn't mind seeing auto-wiring ON by
default.  I would not use it, and (I'm assuming) most of the developers I've
talked to from the Spring project wouldn't use it.  However, if those with
the time/experience to fully understand how to use/configure Spring are in
the minority (which I expect they will be if we have a large user base),
wouldn't it make more sense to have the defaults at a "beginner" level to
handle the 80% of users, rather than "advanced" to support the 20% (which
then forces the 80% to do more digging/searching, and often going
elsewhere).

I also wouldn't say I wouldn't recommend using the autowiring.  If I'm doind
an important, enterprise level system, I definately want to control exactly
what's going on, and I will probably have a more complex context.  However,
for all the "one-off" standalone apps, internal web sites, and prototypes,
you simply don't need to manually code stuff, and even the "advanced"
developer might use the auto-wiring.

+1 to adding it with either default setting (but I'd lean to "beginner"
defaults)

T


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Butler
Sent: September 5, 2003 12:30 PM
To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
Cc: spr...@li...
Subject: [Springframework-developer] Sad but true, was Another
BeanFactory feature


Sad but true (Metallica)

It's pretty sad when an open source, well architected project has to add
features that are of little use or ones that they "don't really recommend"
for "marketing" value.  I know it's true that open source projects need to
be concerned as much with marketing these days as commercial software.  It's
just sad to have it be so true, since many open source projects are attempts
to get away from the marketing and hype and deliver a quality (free)
technically superior piece software.

Back to the matter at hand, I can see the value in having the "automagical"
wiring, and I can also see the value in not having the automagical stuff.
How about adding a feature to the framework that ALL the automagical stuff
can be declaritively turned on/off(disabled) with just one setting, by
default it is off(disabled).  In that way, any attempt to use the
automagical features in the config files throws an error on startup.  Also
"autowiring", etc would be disabled.  This (I think) would make both crowds
happy because those who want automagical stuff can use it, they would just
specifically have to turn it ON for the framework before using the
automagical features in code / config files.  Those who don't can leave it
turned off.

Later
Rob


+1

I agree it's not really to recommend. But marketing has to be taken in
account.

Jean-Pierre

-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Rod Johnson
Envoyé : jeudi 4 septembre 2003 23:42
À : Ivan Ristic
Cc : spr...@li...
Objet : Re: [Springframework-developer] Another BeanFactory feature

>    In a way, wiring the beans manually is a form of documentation
>    how system works. So, if it were up to me I would cancel all
>    automagical processes. Besides, we will probably soon have GUI
>    tools to configure our beans with and that will be more fun
>    anyway.

I'm inclined to agree. But I think the marketing advantage is real, as
the
"objects cannot be in an inconsistent state" argument is the only thing
PicoContainer can really claim as an advantage over Spring. Even if we
don't
use it, and don't really recommend it, this neutralizes that claim.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Autowire

[Rod J. <rod...@in...>]

I've now committed autowire. It's off by default, and can only be switched
on at individual bean level. So you won't notice any change unless you
choose to use it.

I've made a big effort to make the error messages helpful, so that people
will have some idea what happens if autowiring is going wrong.

Thomas, the DTD needs to be uploaded again. I've added an explanation of the
feature in the DTD.

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <pr...@se...>;
<spr...@li...>
Sent: Saturday, September 06, 2003 8:27 AM
Subject: Re: [Springframework-developer] Sad but true, was Another
BeanFactory feature


> I understand some concerns about this feature.
>
> Rob, I don't think it needs to have a global switch to turn it off. It's
off
> by default. It's off if you don't know it's there or don't want to. The
only
> way to turn it on involves adding an optional attribute to each bean that
> uses it. It's backward compatible. It doesn't complicate the API (no more
> public methods on classes application developers will use).
>
> Secondly, if no one uses it and it ends up being only for marketing, I'll
> happily get rid of it. I believe we should be ruthless with features no
one
> uses. Hibernate get this right.
>
> Marketing: I agree it's sad. But there are a lot of good open source
> projects that don't go anywhere, meaning it doesn't matter how good they
> are. I don't want Spring to be like that. I think our architecture is
> particularly good, we have an advantage in my public profile and the fact
> that many of us regularly contribute to TSS etc, but we need to consider
> marketing.
>
> Nevertheless, I would never want to do anything that compromises our
> architecture. I don't think this feature does.
>
> >While I'm sure most of us are very talented developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.
>
> I used to think that. But I'm starting to wonder if we aren't all being a
> bit naive here. Maybe it's just the market, but I've found that I can hire
> good developers in London who are capable of working things out for
> themselves. Of course I have to interview 2-3 others before I employ one,
> but there are a lot of good Java developers out there.
>
> Regards,
> Rod
>
>
> ----- Original Message -----
> From: "Trevor Cook" <pr...@se...>
> To: <spr...@li...>
> Sent: Friday, September 05, 2003 9:20 PM
> Subject: RE: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> I think it's a great idea, partly for marketing but more for an easier
> "entry-level" use.  While I'm sure most of us are very talented
developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.  Making Spring easier for those
> who don't have the time or expertise to figure out the details of the
> framework are more likely to adopt if most of the little stuff is taken
care
> of (like the "automagical wiring").  I also see broad acceptance of Spring
> being of big value, since that provides more use/testing in the real
world,
> and because a larger market of users will naturally draw more developers,
> thus improving Spring even more.
>
> With that in mind, I personally wouldn't mind seeing auto-wiring ON by
> default.  I would not use it, and (I'm assuming) most of the developers
I've
> talked to from the Spring project wouldn't use it.  However, if those with
> the time/experience to fully understand how to use/configure Spring are in
> the minority (which I expect they will be if we have a large user base),
> wouldn't it make more sense to have the defaults at a "beginner" level to
> handle the 80% of users, rather than "advanced" to support the 20% (which
> then forces the 80% to do more digging/searching, and often going
> elsewhere).
>
> I also wouldn't say I wouldn't recommend using the autowiring.  If I'm
doind
> an important, enterprise level system, I definately want to control
exactly
> what's going on, and I will probably have a more complex context.
However,
> for all the "one-off" standalone apps, internal web sites, and prototypes,
> you simply don't need to manually code stuff, and even the "advanced"
> developer might use the auto-wiring.
>
> +1 to adding it with either default setting (but I'd lean to "beginner"
> defaults)
>
> T
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rob Butler
> Sent: September 5, 2003 12:30 PM
> To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
> Cc: spr...@li...
> Subject: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> Sad but true (Metallica)
>
> It's pretty sad when an open source, well architected project has to add
> features that are of little use or ones that they "don't really recommend"
> for "marketing" value.  I know it's true that open source projects need to
> be concerned as much with marketing these days as commercial software.
It's
> just sad to have it be so true, since many open source projects are
attempts
> to get away from the marketing and hype and deliver a quality (free)
> technically superior piece software.
>
> Back to the matter at hand, I can see the value in having the
"automagical"
> wiring, and I can also see the value in not having the automagical stuff.
> How about adding a feature to the framework that ALL the automagical stuff
> can be declaritively turned on/off(disabled) with just one setting, by
> default it is off(disabled).  In that way, any attempt to use the
> automagical features in the config files throws an error on startup.  Also
> "autowiring", etc would be disabled.  This (I think) would make both
crowds
> happy because those who want automagical stuff can use it, they would just
> specifically have to turn it ON for the framework before using the
> automagical features in code / config files.  Those who don't can leave it
> turned off.
>
> Later
> Rob
>
>
> +1
>
> I agree it's not really to recommend. But marketing has to be taken in
> account.
>
> Jean-Pierre
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Rod Johnson
> Envoyé : jeudi 4 septembre 2003 23:42
> À : Ivan Ristic
> Cc : spr...@li...
> Objet : Re: [Springframework-developer] Another BeanFactory feature
>
> >    In a way, wiring the beans manually is a form of documentation
> >    how system works. So, if it were up to me I would cancel all
> >    automagical processes. Besides, we will probably soon have GUI
> >    tools to configure our beans with and that will be more fun
> >    anyway.
>
> I'm inclined to agree. But I think the marketing advantage is real, as
> the
> "objects cannot be in an inconsistent state" argument is the only thing
> PicoContainer can really claim as an advantage over Spring. Even if we
> don't
> use it, and don't really recommend it, this neutralizes that claim.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Autowire

[<tri...@tr...>]

Rod,

> Thomas, the DTD needs to be uploaded again. I've added an explanation of the
> feature in the DTD.
> 

It's there now!

Thomas

Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Rob B. <rob...@ve...>]

Last comment:

A wise man once said:

"A framework should be easy to use.  Unduly complex frameworks will be
ignored by developers, and create problems of their own.  Irrelevant, or
seldom-used, capabilities are a key danger.  The Pareto Principle is
particularly relevant to framework design.  Often it's best to settle for a
simple solution to most problems than a comprehensive, but complex solution
that makes many tasks harder than they should be (J2EE arguably falls into
the latter category)."

Rod Johnson - Expert one-on-one J2EE Design and Development pg396 paragraph
5

I agree that many open source projects die because of "marketing" problems.
I don't want that to happen to spring either,  because I hope to use it in
future projects of my own and want it to be a well supported framework with
a thriving community.  I'm perfectly fine with this feature being added to
spring.  I also don't want to seem the black sheep / black cloud, and I
think that it appears I may have come off that way..  Please excuse me if
that is the case.  I only ask that the Pareto Principle be kept in mind when
adding any "feature" only for the purposes of "marketing".  It can also be
considered a "feature" to not include capabilities that are "Irrelevent, or
seldom-used" or that the project developers "don't really recommend".

There are a few way to compete on the "marketing" front.  We can all jump
off the bridge because the PicoContainer does.  We can all forget spring
completely and use entity beans and struts because "everyone else does".  Or
we can say, no, we don't do xxx or yyy because doing things that way is bad.
We do it this way instead because it's better.  Let us show you how and why
it's better.

Again, I'm fine with this particular "feature".  I just concerned it will be
one of the first "features" to sneak in for marketing and then set a
precendence.  It's always harder to close the door once it's open.  It's
also harder to "remove" a feature because "no one" uses it.  Someone,
somewhere will use it, and then when it's removed complain like crazy.

AS for the "global switch".  My thoughts behind that were to offer some sort
of "strict" capability, where any of the features that are not recommended
can be shut off as a group.  This would prevent a developer from
inadvertantly using any feature (not just this one) that is not recommended.
Kind of along the lines of the XHTML strict / transitional option.  The same
thing could probably be implemented by having two DTD's for Spring.  One
that has all the "added for marketing" stuff, and one that has only the
recommended stuff.  Doing things in this manner would require no code
changes to Spring itself, and still have the advantage of preventing the use
of "marketing" features accidentally by developers - as long as the
developer verifies their XML against the DTD. If you feel it's not needed
though, I'm cool with it.

Later
Rob

> I understand some concerns about this feature.
>
> Rob, I don't think it needs to have a global switch to turn it off. It's
off
> by default. It's off if you don't know it's there or don't want to. The
only
> way to turn it on involves adding an optional attribute to each bean that
> uses it. It's backward compatible. It doesn't complicate the API (no more
> public methods on classes application developers will use).
>
> Secondly, if no one uses it and it ends up being only for marketing, I'll
> happily get rid of it. I believe we should be ruthless with features no
one
> uses. Hibernate get this right.
>
> Marketing: I agree it's sad. But there are a lot of good open source
> projects that don't go anywhere, meaning it doesn't matter how good they
> are. I don't want Spring to be like that. I think our architecture is
> particularly good, we have an advantage in my public profile and the fact
> that many of us regularly contribute to TSS etc, but we need to consider
> marketing.
>
> Nevertheless, I would never want to do anything that compromises our
> architecture. I don't think this feature does.
>
> >While I'm sure most of us are very talented developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.
>
> I used to think that. But I'm starting to wonder if we aren't all being a
> bit naive here. Maybe it's just the market, but I've found that I can hire
> good developers in London who are capable of working things out for
> themselves. Of course I have to interview 2-3 others before I employ one,
> but there are a lot of good Java developers out there.
>
> Regards,
> Rod
>
>
> ----- Original Message -----
> From: "Trevor Cook" <pr...@se...>
> To: <spr...@li...>
> Sent: Friday, September 05, 2003 9:20 PM
> Subject: RE: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> I think it's a great idea, partly for marketing but more for an easier
> "entry-level" use.  While I'm sure most of us are very talented
developers,
> almost everyone I talk to always comments on the programmers who can't
> figure out how to turn on a light switch.  Making Spring easier for those
> who don't have the time or expertise to figure out the details of the
> framework are more likely to adopt if most of the little stuff is taken
care
> of (like the "automagical wiring").  I also see broad acceptance of Spring
> being of big value, since that provides more use/testing in the real
world,
> and because a larger market of users will naturally draw more developers,
> thus improving Spring even more.
>
> With that in mind, I personally wouldn't mind seeing auto-wiring ON by
> default.  I would not use it, and (I'm assuming) most of the developers
I've
> talked to from the Spring project wouldn't use it.  However, if those with
> the time/experience to fully understand how to use/configure Spring are in
> the minority (which I expect they will be if we have a large user base),
> wouldn't it make more sense to have the defaults at a "beginner" level to
> handle the 80% of users, rather than "advanced" to support the 20% (which
> then forces the 80% to do more digging/searching, and often going
> elsewhere).
>
> I also wouldn't say I wouldn't recommend using the autowiring.  If I'm
doind
> an important, enterprise level system, I definately want to control
exactly
> what's going on, and I will probably have a more complex context.
However,
> for all the "one-off" standalone apps, internal web sites, and prototypes,
> you simply don't need to manually code stuff, and even the "advanced"
> developer might use the auto-wiring.
>
> +1 to adding it with either default setting (but I'd lean to "beginner"
> defaults)
>
> T
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Rob Butler
> Sent: September 5, 2003 12:30 PM
> To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic'
> Cc: spr...@li...
> Subject: [Springframework-developer] Sad but true, was Another
> BeanFactory feature
>
>
> Sad but true (Metallica)
>
> It's pretty sad when an open source, well architected project has to add
> features that are of little use or ones that they "don't really recommend"
> for "marketing" value.  I know it's true that open source projects need to
> be concerned as much with marketing these days as commercial software.
It's
> just sad to have it be so true, since many open source projects are
attempts
> to get away from the marketing and hype and deliver a quality (free)
> technically superior piece software.
>
> Back to the matter at hand, I can see the value in having the
"automagical"
> wiring, and I can also see the value in not having the automagical stuff.
> How about adding a feature to the framework that ALL the automagical stuff
> can be declaritively turned on/off(disabled) with just one setting, by
> default it is off(disabled).  In that way, any attempt to use the
> automagical features in the config files throws an error on startup.  Also
> "autowiring", etc would be disabled.  This (I think) would make both
crowds
> happy because those who want automagical stuff can use it, they would just
> specifically have to turn it ON for the framework before using the
> automagical features in code / config files.  Those who don't can leave it
> turned off.
>
> Later
> Rob
>
>
> +1
>
> I agree it's not really to recommend. But marketing has to be taken in
> account.
>
> Jean-Pierre
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Rod Johnson
> Envoyé : jeudi 4 septembre 2003 23:42
> À : Ivan Ristic
> Cc : spr...@li...
> Objet : Re: [Springframework-developer] Another BeanFactory feature
>
> >    In a way, wiring the beans manually is a form of documentation
> >    how system works. So, if it were up to me I would cancel all
> >    automagical processes. Besides, we will probably soon have GUI
> >    tools to configure our beans with and that will be more fun
> >    anyway.
>
> I'm inclined to agree. But I think the marketing advantage is real, as
> the
> "objects cannot be in an inconsistent state" argument is the only thing
> PicoContainer can really claim as an advantage over Spring. Even if we
> don't
> use it, and don't really recommend it, this neutralizes that claim.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer