springframework-developer — Spring Framework developers list

[Springframework-developer] spring build.300 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050708001703Lbuild.300

[Springframework-developer] Akshay K Pandit is out of the office 8th july 05- 11th july 05

[Akshay K P. <aks...@in...>]

I will be out of the office starting  07/08/2005 and will not return until
07/12/2005.

I will be out of office on 8th of july '05 & 11th of july '05. For these
two day's Rajni Klair would be my back up. So please co-ordinate with her,
In case of any urgency

Re: [Springframework-developer] autowiring exclusion attribute

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

I _did_ create the initial Jira entry for this enhancement, so I'm 
biased, but I do think it does add value to be able to exclude some 
beans as autowire candidates. It does add an extra attribute, but at the 
same time, it can help reduce the surprise factor in autowiring, 
allowing autowiring to continue to be used in some cases where it might 
not, and I think that's a good thing generally.

Mark Vickers wrote:

>Hi Juergen, Seth,
>
>(repost - forgive the formatting trainwreck that was the last post)
>
>I'm aware that inner beans are not considered as autowirable candidates,
>but, there are some cases where I find that inner bean definitions cannot be
>used.
>
>For example:
>LazyInitTargetSource, PrototypeTargetSource -
>These are BeanFactoryBasedTargetSources which are supplied with bean names,
>not bean references.
>
>If I want to wrap a proxy around a LazyInitTargetSource, I don't see how I
>can do it without two bean definitions.
>
>There are some other cases where an inner bean definition should not be
>used:
>	ie:) I want an unproxied/unadvised bean for testing
>
>Or imagine this scenario:
>We have an RmiProxyFactoryBean, the target object of which we want to wrap
>additional behaviour around.  In 99/100 cases we want the proxied version of
>the bean (which we happily autowire into other beans), but in one key case
>we need to get at the unproxied version.  But, because its an inner bean
>def, its inaccessible.	
>
>In summary, the ability to tag the corner-case beans as non-candidates for
>autowiring will help where it is difficult, impossible or otherwise
>undesirable to use inner bean defs.
>
>I guess you could call them corner cases, but guess what, we're cornered ;)
>
>Regards,
>Mark
>
>-----Original Message-----
>From: Juergen Hoeller [mailto:ju...@in...]
>Sent: Thursday, July 07, 2005 7:02 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] autowiring exclusion attribute
>
>
>Hi Mark,
>
>I haven't given much thought to this yet. The question is whether there are
>enough good use cases for this.
>
>After all, there's always the option to override autowiring at the level of
>the bean that receives autowiring: You can always explicitly specify
>references for specific properties of constructor arguments there, which
>will override any autowiring that you configured for that bean.
>
>In general, I agree with Seth that inner bean definitions can get you quite
>far as well, in particular regarding proxy vs target. We're illustrating
>that configuration style in JPetStore, for example. Autowiring will always
>only consider the outer bean (the proxy) in such a scenario, never the inner
>bean (the target).
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Mark Vickers
>Sent: Wednesday, July 06, 2005 9:06 PM
>To: 'spr...@li...'
>Subject: [Springframework-developer] autowiring exclusion attribute
>
>Juergen et al,
>
>I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
>http://opensource.atlassian.com/projects/spring/browse/SPR-626
>
>Any chance of this making it into 1.3?
>A quick yea or nay would be appreciated - the presence/absence of this
>feature will greatly impact our development practices.
>
>Regards,
>Mark
>  
>

RE: [Springframework-developer] autowiring exclusion attribute

[Mark V. <MVi...@ev...>]

Hi Juergen, Seth,

(repost - forgive the formatting trainwreck that was the last post)

I'm aware that inner beans are not considered as autowirable candidates,
but, there are some cases where I find that inner bean definitions cannot be
used.

For example:
LazyInitTargetSource, PrototypeTargetSource -
These are BeanFactoryBasedTargetSources which are supplied with bean names,
not bean references.

If I want to wrap a proxy around a LazyInitTargetSource, I don't see how I
can do it without two bean definitions.

There are some other cases where an inner bean definition should not be
used:
	ie:) I want an unproxied/unadvised bean for testing

Or imagine this scenario:
We have an RmiProxyFactoryBean, the target object of which we want to wrap
additional behaviour around.  In 99/100 cases we want the proxied version of
the bean (which we happily autowire into other beans), but in one key case
we need to get at the unproxied version.  But, because its an inner bean
def, its inaccessible.	

In summary, the ability to tag the corner-case beans as non-candidates for
autowiring will help where it is difficult, impossible or otherwise
undesirable to use inner bean defs.

I guess you could call them corner cases, but guess what, we're cornered ;)

Regards,
Mark

-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, July 07, 2005 7:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] autowiring exclusion attribute


Hi Mark,

I haven't given much thought to this yet. The question is whether there are
enough good use cases for this.

After all, there's always the option to override autowiring at the level of
the bean that receives autowiring: You can always explicitly specify
references for specific properties of constructor arguments there, which
will override any autowiring that you configured for that bean.

In general, I agree with Seth that inner bean definitions can get you quite
far as well, in particular regarding proxy vs target. We're illustrating
that configuration style in JPetStore, for example. Autowiring will always
only consider the outer bean (the proxy) in such a scenario, never the inner
bean (the target).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Wednesday, July 06, 2005 9:06 PM
To: 'spr...@li...'
Subject: [Springframework-developer] autowiring exclusion attribute

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - the presence/absence of this
feature will greatly impact our development practices.

Regards,
Mark


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] autowiring exclusion attribute

[Mark V. <MVi...@ev...>]

Hi Juergen, Seth,

I'm aware that inner beans are not considered as autowirable candidates,
but, there 
are some cases where I find that inner bean definitions cannot be used.

	For example:
	LazyInitTargetSource, PrototypeTargetSource -
	These are BeanFactoryBasedTargetSources which are supplied with bean
names, 
	not bean references.

	If I want to wrap a proxy around a LazyInitTargetSource, I don't see
how I 
	can do it without two bean definitions.

There are some other cases where an inner bean definition should not be
used:
	ie:) I want an unproxied/unadvised bean for testing

Or imagine this scenario:
	We have an RmiProxyFactoryBean, the target object of which we want
to 
	wrap additional behaviour around.  In 99/100 cases we want the
proxied 
	version of the bean (which we happily autowire into other beans),
but in one 
	key case we need to get at the unproxied version.  But, because its
an inner bean def, 
	its inaccessible.	

In summary, the ability to tag the corner-case beans as non-candidates for
autowiring will 
help where it is difficult, impossible or otherwise undesirable to use inner
bean defs.

I guess you could call them corner cases, but guess what, we're cornered ;)

Regards,
Mark

-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Thursday, July 07, 2005 7:02 AM
To: spr...@li...
Subject: Re: [Springframework-developer] autowiring exclusion attribute


Hi Mark,

I haven't given much thought to this yet. The question is whether there are
enough good use cases for this.

After all, there's always the option to override autowiring at the level of
the bean that receives autowiring: You can always explicitly specify
references for specific properties of constructor arguments there, which
will override any autowiring that you configured for that bean.

In general, I agree with Seth that inner bean definitions can get you quite
far as well, in particular regarding proxy vs target. We're illustrating
that configuration style in JPetStore, for example. Autowiring will always
only consider the outer bean (the proxy) in such a scenario, never the inner
bean (the target).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Wednesday, July 06, 2005 9:06 PM
To: 'spr...@li...'
Subject: [Springframework-developer] autowiring exclusion attribute

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - the presence/absence of this
feature will greatly impact our development practices.

Regards,
Mark

Re: [Springframework-developer] old dependencies on spring portlet in webflow

[Cris J. H. <hol...@un...>]

Can we PLEASE PLEASE consider changing the two "handleRequest" method=
s=20
to different names?  This is a violation of what is consider good=
=20
practice for overriding.  They are fundamentally different methods.=
=20
This change REALLY should be made before it is moved into the core.

---- Cris J H

Juergen Hoeller wrote:
> Hi Tim.
> =20
> We actually intend to release the core Portlet support earlier now:=
 as=20
> part of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn =
build=20
> on that release then.
> =20
> For the meantime, there might be a Web Flow PR4 as a remedy for the=
=20
> current situation, but that's up to Keith and Erwin to decide. Else=
, I=20
> would recommend to continue using Web Flow PR3 on Spring 1.2.1 for =
the=20
> time being.
> =20
> Juergen
> =20
>=20
> -------------------------------------------------------------------=
-----
> *From:* spr...@li...=20
> [mailto:spr...@li...] *On=
=20
> Behalf Of *Tim Kettering
> *Sent:* Wednesday, July 06, 2005 7:56 PM
> *To:* spr...@li...
> *Subject:* [Springframework-developer] old dependencies on spring=
=20
> portlet in webflow
>=20
> =20
>=20
> This really addresses two issues I=92m having w/ spring portlet=
=20
> development.  I am attempting to use spring webflow /w the portlets=
, and=20
> the PR3 release of webflow apparently includes references to older=
=20
> versions of portlet code (that exist in the spring sandbox) =96 and=
 the=20
> latest version of spring-portlets as released by john lewis include=
s=20
> significantly updated code, and when attempting to include all thos=
e=20
> jars in the portlet environment, theres all sorts of classloader is=
sues=20
> w/ different versions of DispatchPortlet and PortletController lyin=
g=20
> around.  I=92ve been trying to rebuild parts to get them all to tal=
k to=20
> each other, but it=92s been a big time-sink.
>=20
> =20
>=20
> I see the best solution being that John being allowed to merge his=
=20
> portlet code in the cvs =96 so that webflow can be coded against th=
e=20
> proper classes and those classes being dropped from webflow-support=
.  I=20
> know that this has been under discussion lately to start with 1.3=
=20
> development, and I=92m hoping with the release of 1.2.2 complete, t=
hat=20
> things can move in that direction.
>=20

Re: [Springframework-developer] autowiring exclusion attribute

[Juergen H. <ju...@in...>]

Hi Mark,

I haven't given much thought to this yet. The question is whether there are
enough good use cases for this.

After all, there's always the option to override autowiring at the level of
the bean that receives autowiring: You can always explicitly specify
references for specific properties of constructor arguments there, which
will override any autowiring that you configured for that bean.

In general, I agree with Seth that inner bean definitions can get you quite
far as well, in particular regarding proxy vs target. We're illustrating
that configuration style in JPetStore, for example. Autowiring will always
only consider the outer bean (the proxy) in such a scenario, never the inner
bean (the target).

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Mark Vickers
Sent: Wednesday, July 06, 2005 9:06 PM
To: 'spr...@li...'
Subject: [Springframework-developer] autowiring exclusion attribute

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - the presence/absence of this
feature will greatly impact our development practices.

Regards,
Mark


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] old dependencies on spring portlet in webflow

[Juergen H. <ju...@in...>]

Hi Tim.
 
We actually intend to release the core Portlet support earlier now: as part
of Spring 1.2.3 in about two weeks. Web Flow RC1 will in turn build on that
release then.
 
For the meantime, there might be a Web Flow PR4 as a remedy for the current
situation, but that's up to Keith and Erwin to decide. Else, I would
recommend to continue using Web Flow PR3 on Spring 1.2.1 for the time being.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Tim Kettering
Sent: Wednesday, July 06, 2005 7:56 PM
To: spr...@li...
Subject: [Springframework-developer] old dependencies on spring portlet in
webflow



 

This really addresses two issues I'm having w/ spring portlet development.
I am attempting to use spring webflow /w the portlets, and the PR3 release
of webflow apparently includes references to older versions of portlet code
(that exist in the spring sandbox) - and the latest version of
spring-portlets as released by john lewis includes significantly updated
code, and when attempting to include all those jars in the portlet
environment, theres all sorts of classloader issues w/ different versions of
DispatchPortlet and PortletController lying around.  I've been trying to
rebuild parts to get them all to talk to each other, but it's been a big
time-sink.

 

I see the best solution being that John being allowed to merge his portlet
code in the cvs - so that webflow can be coded against the proper classes
and those classes being dropped from webflow-support.  I know that this has
been under discussion lately to start with 1.3 development, and I'm hoping
with the release of 1.2.2 complete, that things can move in that direction.

[Springframework-developer] Christoph Miksovic/Switzerland/IBM is out of the office.

[Christoph M. <chr...@ch...>]

I will be out of the office starting  06.07.2005 and will not return until
13.07.2005.

[Springframework-developer] spring build.299 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050707001618Lbuild.299

[Springframework-developer] autowiring exclusion attribute

[Mark V. <MVi...@ev...>]

Juergen et al,

I've added a patch which addresses SPR-626 (autowiring exclusion attribute)
http://opensource.atlassian.com/projects/spring/browse/SPR-626

Any chance of this making it into 1.3?
A quick yea or nay would be appreciated - 
the presence/absence of this feature will greatly impact our development
practices.

Regards,
Mark

Re: [Springframework-developer] old dependencies on spring portlet in webflow

[Erwin V. <erw...@er...>]

Yes, this is an urgent issue.
There are also other conflicts between SWF PR3 and Spring 1.2.2. Keith =
and I are working on releasing a PR4 release ASAP to address these =
classpath conflicts.

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Tim Kettering=20
  To: spr...@li...=20
  Sent: Wednesday, July 06, 2005 7:56 PM
  Subject: [Springframework-developer] old dependencies on spring =
portlet in webflow


  =20

  This really addresses two issues I'm having w/ spring portlet =
development.  I am attempting to use spring webflow /w the portlets, and =
the PR3 release of webflow apparently includes references to older =
versions of portlet code (that exist in the spring sandbox) - and the =
latest version of spring-portlets as released by john lewis includes =
significantly updated code, and when attempting to include all those =
jars in the portlet environment, theres all sorts of classloader issues =
w/ different versions of DispatchPortlet and PortletController lying =
around.  I've been trying to rebuild parts to get them all to talk to =
each other, but it's been a big time-sink.

  =20

  I see the best solution being that John being allowed to merge his =
portlet code in the cvs - so that webflow can be coded against the =
proper classes and those classes being dropped from webflow-support.  I =
know that this has been under discussion lately to start with 1.3 =
development, and I'm hoping with the release of 1.2.2 complete, that =
things can move in that direction.

[Springframework-developer] old dependencies on spring portlet in webflow

[Tim K. <tim...@vi...>]

 

This really addresses two issues I'm having w/ spring portlet development.
I am attempting to use spring webflow /w the portlets, and the PR3 release
of webflow apparently includes references to older versions of portlet code
(that exist in the spring sandbox) - and the latest version of
spring-portlets as released by john lewis includes significantly updated
code, and when attempting to include all those jars in the portlet
environment, theres all sorts of classloader issues w/ different versions of
DispatchPortlet and PortletController lying around.  I've been trying to
rebuild parts to get them all to talk to each other, but it's been a big
time-sink.

 

I see the best solution being that John being allowed to merge his portlet
code in the cvs - so that webflow can be coded against the proper classes
and those classes being dropped from webflow-support.  I know that this has
been under discussion lately to start with 1.3 development, and I'm hoping
with the release of 1.2.2 complete, that things can move in that direction.

Re: [Springframework-developer] RSS feed for springframework.org

[Thomas V. de V. <tho...@gm...>]

Colin,

It might be usefull to add a more visible link to this news feed. I am not=
=20
even sure if there is one.

Thomas

On 7/2/05, Thomas Van de Velde <tho...@gm...> wrote:
>=20
> Cheers
>=20
> On 7/2/05, Seth Ladd <set...@gm...> wrote:
> >=20
> > > I am looking for an RSS feed with Spring announcements and can't find=
=20
> > it on
> > > springframework.org <http://springframework.org>. Is RSS supported? I=
f=20
> > not, it would be interesting to
> > > add this feature so that I can get these announcements in our=20
> > corporate=20
> > > portal.
> >=20
> > This should help you out:
> >=20
> > http://www.springframework.org/node/feed
> >=20
> > Seth
> >=20
> >=20
> > -------------------------------------------------------=20
> > SF.Net <http://SF.Net> email is sponsored by: Discover Easy Linux=20
> > Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to=20
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick<http:=
//ads.osdn.com/?ad_idt77&alloc_id%16492&opclick>
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer=
=20
> >=20
>=20
>

Re: [Springframework-developer] new Spring Web Flow article

[Steven D. <ste...@gm...>]

Hi Erwin,

I'm glad you like it.

Steven

On 7/6/05, Erwin Vervaet <erw...@er...> wrote:
> Very nice article Steven! "To the bat mobile!" :) Great!!
>=20
> I've added it to the "Articles" on the SWF page.
>=20
> I've been extremely busy the last few weeks, so SWF work kinda lagged and=
 I
> didn't find the time to review the article, sorry about that! (Not that I
> would have had many remarks, the article is pretty slick) Anway, things
> should be kicking into higher gear now since we're starting to prepare fo=
r
> SWF 1.0!
>

Re: [Springframework-developer] new Spring Web Flow article

[Erwin V. <erw...@er...>]

Very nice article Steven! "To the bat mobile!" :) Great!!

I've added it to the "Articles" on the SWF page.

I've been extremely busy the last few weeks, so SWF work kinda lagged and=
 I=20
didn't find the time to review the article, sorry about that! (Not that I=
=20
would have had many remarks, the article is pretty slick) Anway, things=20
should be kicking into higher gear now since we're starting to prepare fo=
r=20
SWF 1.0!


Erwin Vervaet
erw...@er...
----- Original Message -----=20
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Tuesday, July 05, 2005 4:05 PM
Subject: [Springframework-developer] new Spring Web Flow article


There's a new Spring Web Flow article on Javalobby written by myself.
Could you please add it to the article page on
www.springframework.org?

http://www.javalobby.org/articles/spring-webflow/

Also, my previous article was listed on the old site but has
apparently not survived the migration to the new site. Could you also
please add it to the article list?

http://www.javalobby.org/articles/thread-safe/index.jsp

Thanks

Steven

--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.298 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050706001644Lbuild.298

Re: [Springframework-developer] new Spring Web Flow article

[Steven D. <ste...@gm...>]

Thanks Colin.

On 7/5/05, Colin Sampaleanu <col...@ex...> wrote:
> Colin Sampaleanu wrote:
>=20
> > Steven Devijver wrote:
> >
> >> There's a new Spring Web Flow article on Javalobby written by myself.
> >> Could you please add it to the article page on
> >> www.springframework.org?
> >>
> >> http://www.javalobby.org/articles/spring-webflow/
> >>
> >> Also, my previous article was listed on the old site but has
> >> apparently not survived the migration to the new site. Could you also
> >> please add it to the article list?
> >>
> >> http://www.javalobby.org/articles/thread-safe/index.jsp
> >>
> >>
> >>
> > Steven,
> >
> > I've added the two articles as:
> >  http://www.springframework.org/node/122
> >  http://www.springframework.org/node/121
> >
> > The entry for the latter (older) article as created with the original
> > Dec. 21 date, so while it's marked as a front-page entry, it won't
> > appear on the current front page (unless somebody pages all the way
> > back to that date). Both of these articles and any others marked
> > 'Technical Article' will be aggregated together and listed when
> > somebody clicks on the 'Technical Article' link.
> >
> Thomas added a link to the first article at the same time as me, so my
> entry has now been deleted.
>=20
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] new Spring Web Flow article

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

Colin Sampaleanu wrote:

> Steven Devijver wrote:
>
>> There's a new Spring Web Flow article on Javalobby written by myself.
>> Could you please add it to the article page on
>> www.springframework.org?
>>
>> http://www.javalobby.org/articles/spring-webflow/
>>
>> Also, my previous article was listed on the old site but has
>> apparently not survived the migration to the new site. Could you also
>> please add it to the article list?
>>
>> http://www.javalobby.org/articles/thread-safe/index.jsp
>>
>>  
>>
> Steven,
>
> I've added the two articles as:
>  http://www.springframework.org/node/122
>  http://www.springframework.org/node/121
>
> The entry for the latter (older) article as created with the original 
> Dec. 21 date, so while it's marked as a front-page entry, it won't 
> appear on the current front page (unless somebody pages all the way 
> back to that date). Both of these articles and any others marked 
> 'Technical Article' will be aggregated together and listed when 
> somebody clicks on the 'Technical Article' link.
>
Thomas added a link to the first article at the same time as me, so my 
entry has now been deleted.

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] new Spring Web Flow article

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

Steven Devijver wrote:

>There's a new Spring Web Flow article on Javalobby written by myself.
>Could you please add it to the article page on
>www.springframework.org?
>
>http://www.javalobby.org/articles/spring-webflow/
>
>Also, my previous article was listed on the old site but has
>apparently not survived the migration to the new site. Could you also
>please add it to the article list?
>
>http://www.javalobby.org/articles/thread-safe/index.jsp
>
>  
>
Steven,

I've added the two articles as:
  http://www.springframework.org/node/122
  http://www.springframework.org/node/121

The entry for the latter (older) article as created with the original 
Dec. 21 date, so while it's marked as a front-page entry, it won't 
appear on the current front page (unless somebody pages all the way back 
to that date). Both of these articles and any others marked 'Technical 
Article' will be aggregated together and listed when somebody clicks on 
the 'Technical Article' link.

Colin

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

[Springframework-developer] new Spring Web Flow article

[Steven D. <ste...@gm...>]

There's a new Spring Web Flow article on Javalobby written by myself.
Could you please add it to the article page on
www.springframework.org?

http://www.javalobby.org/articles/spring-webflow/

Also, my previous article was listed on the old site but has
apparently not survived the migration to the new site. Could you also
please add it to the article list?

http://www.javalobby.org/articles/thread-safe/index.jsp

Thanks

Steven

--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

[Springframework-developer] New attribute for <bean>

[Nigel S. <nig...@fe...>]

Hi there,

Could someone please have a look at SPR-1078 when you have the time. 
I've suggested that a new attribute be added to the bean entity called 
something like "depends-on-after-created" (I'm not very attached to that 
name) that does the same thing as "depends-on" but after the bean is 
created. I've already made the changes to 1.2.0 and have submitted diffs 
which can be seen at 
http://opensource.atlassian.com/projects/spring/browse/SPR-1078 . I have 
found this to be incredibly useful for calling things like 
MethodInvokingFactoryBeans after a bean is created, to aid in 
facilitating initialisation.

Regards,
Nigel

Re: [Springframework-developer] CVS pruning

[Thomas R. <tho...@tr...>]

"i21" is the original "com.interface21" code base used for 6 months  
of development up to the point where we changed package name between  
the 0.9 release an 1.0M1.  That's when we switched to the "spring"  
module.  It's important to keep this so we can track changes from the  
original code contribution.

Thomas



On Jul 4, 2005, at 11:19 PM, Colin Sampaleanu wrote:

On Jul 4, 2005, at 11:28 PM, Keith Donald wrote:

> Just to close these open questions, as I spoke with Colin:
>
> 1. Yes, the spring-projects module will remain as the place where core
> projects like spring-webflow and spring-binding (data binding) will be
> hosted.
>
> 2. The 'i21' and 'samples' modules will remain to serve a bit of  
> history.
> These modules house the original code from J2EE design and development
> that has grown to become Spring!
>
> Keith
>
>
>> Colin said:
>> ->This should leave the following modules in place
>> -> - 'i21'
>> -> - 'samples'
>> -> - 'spring'
>> -> - 'spring-beandoc'
>>
>> Colin,
>>
>> You meant to include spring-projects as another module to leave in  
>> place,
>> right?
>>
>> What goes in "i21" and "samples"?  I wasn't aware they were being  
>> used.
>>
>> Keith
>>
>>
>>> As per the email below, I am going to submit a support request to  
>>> SF to
>>> remove the following obsolete or wrongly checked in modules from
>>> Spring's CVS on SourceForge:
>>> -  'Spring' (this is an empty module created with the wrong case,  
>>> not to
>>> be confused with the main Spring source, in the 'spring' module)
>>> - 'common-build'
>>> - 'repository'
>>> - 'spring-binding'
>>> - 'spring-modules'
>>> - 'spring-rcp' (this is the old home of Spring-rcp (which is now  
>>> hosted
>>> in it's own sourceforge project, 'spring-rich-c')
>>> - 'spring-webflow'
>>> - 'spring-ide' (this is the old home of Spring-IDE, which is now  
>>> hosted
>>> in it's own Subversion repo elsewhere, managed by Torsten and co.).
>>>
>>> This should leave the following modules in place
>>> - 'i21'
>>> - 'samples'
>>> - 'spring'
>>> - 'spring-beandoc'
>>>
>>> I have no idea if SF will honour such a request from any project
>>> developer, or it needs to be one of the leads (Rod or Juergen in our
>>> case). If I'm told it's the latter, I'll notify Rod and Juergen  
>>> to send
>>> in the request themselves.
>>>
>>> Colin
>>>
>>>
>>> Colin Sampaleanu wrote:
>>>
>>>
>>>> Yes. I'm just getting confirmation from Torsten/Christian that  
>>>> the old
>>>> spring-ide module in CVS can be kileld (all the Spring-IDE)  
>>>> source is
>>>> in their own Subversion repo now, then I'll publish a list of what
>>>> modules are staying and which are being pruned, and submit a  
>>>> service
>>>> request to SF.
>>>>
>>>>
>>>> Erwin Vervaet wrote:
>>>>
>>>>
>>>>> Okay, I've moved my Eclipse over to use the new spring-projects
>>>>> module.
>>>>> So I guess we can have the SF people clean up those bogus modules?
>>>>>
>>>>> Erwin Vervaet
>>>>> erw...@er...
>>>>> ----- Original Message ----- From: "Colin Sampaleanu"
>>>>> <col...@ex...>
>>>>> To: "Keith Donald" <ke...@in...>; "Erwin Vervaet"
>>>>> <erw...@er...>
>>>>> Cc: <spr...@li...>
>>>>> Sent: Friday, June 17, 2005 4:44 AM
>>>>> Subject: Building webflow under spring-projects
>>>>>
>>>>>
>>>>>
>>>>>> Keith/Erwin,
>>>>>>
>>>>>> I moved (copied really) all common-build, spring-binding, and
>>>>>> spring-webflow sources to live under a new spring-projects  
>>>>>> module in
>>>>>> CVS.
>>>>>>
>>>>>> Note that the build relies on the use of a nightly snapshot of  
>>>>>> ivy
>>>>>>   ivy-20050616204129.jar
>>>>>> which may be found in
>>>>>>   spring-projects\repository\jayasoft\ivy\jars
>>>>>> This should be dropped into your ant lib dir to replace the older
>>>>>> ivy 1.1. This If you try to use ivy 1.1 you'll get a failure when
>>>>>> trying to do a publish of the generated artifact.
>>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Colin Sampaleanu
>>> Interface21 Principal Consultant
>>> Spring Training, Consulting and Support - "From the Source"
>>> http://www.springframework.com
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by: Discover Easy Linux Migration  
>>> Strategies
>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>> informative Webcasts and more! Get everything you need to get up to
>>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>>> developer
>>>
>>>
>>
>>
>> --
>> Keith Donald
>> Principal Consultant, Interface21
>> http://www.springframework.com - Spring Services From the Source
>>
>>
>
>
> -- 
> Keith Donald
> Principal Consultant, Interface21
> http://www.springframework.com - Spring Services From the Source
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] CVS pruning

[Keith D. <ke...@in...>]

Just to close these open questions, as I spoke with Colin:

1. Yes, the spring-projects module will remain as the place where core
projects like spring-webflow and spring-binding (data binding) will be
hosted.

2. The 'i21' and 'samples' modules will remain to serve a bit of history. 
These modules house the original code from J2EE design and development
that has grown to become Spring!

Keith

> Colin said:
> ->This should leave the following modules in place
> -> - 'i21'
> -> - 'samples'
> -> - 'spring'
> -> - 'spring-beandoc'
>
> Colin,
>
> You meant to include spring-projects as another module to leave in place,
> right?
>
> What goes in "i21" and "samples"?  I wasn't aware they were being used.
>
> Keith
>
>> As per the email below, I am going to submit a support request to SF to
>> remove the following obsolete or wrongly checked in modules from
>> Spring's CVS on SourceForge:
>> -  'Spring' (this is an empty module created with the wrong case, not to
>> be confused with the main Spring source, in the 'spring' module)
>> - 'common-build'
>> - 'repository'
>> - 'spring-binding'
>> - 'spring-modules'
>> - 'spring-rcp' (this is the old home of Spring-rcp (which is now hosted
>> in it's own sourceforge project, 'spring-rich-c')
>> - 'spring-webflow'
>> - 'spring-ide' (this is the old home of Spring-IDE, which is now hosted
>> in it's own Subversion repo elsewhere, managed by Torsten and co.).
>>
>> This should leave the following modules in place
>> - 'i21'
>> - 'samples'
>> - 'spring'
>> - 'spring-beandoc'
>>
>> I have no idea if SF will honour such a request from any project
>> developer, or it needs to be one of the leads (Rod or Juergen in our
>> case). If I'm told it's the latter, I'll notify Rod and Juergen to send
>> in the request themselves.
>>
>> Colin
>>
>>
>> Colin Sampaleanu wrote:
>>
>>> Yes. I'm just getting confirmation from Torsten/Christian that the old
>>> spring-ide module in CVS can be kileld (all the Spring-IDE) source is
>>> in their own Subversion repo now, then I'll publish a list of what
>>> modules are staying and which are being pruned, and submit a service
>>> request to SF.
>>>
>>>
>>> Erwin Vervaet wrote:
>>>
>>>> Okay, I've moved my Eclipse over to use the new spring-projects
>>>> module.
>>>> So I guess we can have the SF people clean up those bogus modules?
>>>>
>>>> Erwin Vervaet
>>>> erw...@er...
>>>> ----- Original Message ----- From: "Colin Sampaleanu"
>>>> <col...@ex...>
>>>> To: "Keith Donald" <ke...@in...>; "Erwin Vervaet"
>>>> <erw...@er...>
>>>> Cc: <spr...@li...>
>>>> Sent: Friday, June 17, 2005 4:44 AM
>>>> Subject: Building webflow under spring-projects
>>>>
>>>>
>>>>> Keith/Erwin,
>>>>>
>>>>> I moved (copied really) all common-build, spring-binding, and
>>>>> spring-webflow sources to live under a new spring-projects module in
>>>>> CVS.
>>>>>
>>>>> Note that the build relies on the use of a nightly snapshot of ivy
>>>>>   ivy-20050616204129.jar
>>>>> which may be found in
>>>>>   spring-projects\repository\jayasoft\ivy\jars
>>>>> This should be dropped into your ant lib dir to replace the older
>>>>> ivy 1.1. This If you try to use ivy 1.1 you'll get a failure when
>>>>> trying to do a publish of the generated artifact.
>>>>
>>
>> --
>> Colin Sampaleanu
>> Interface21 Principal Consultant
>> Spring Training, Consulting and Support - "From the Source"
>> http://www.springframework.com
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
> --
> Keith Donald
> Principal Consultant, Interface21
> http://www.springframework.com - Spring Services From the Source
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source

Re: [Springframework-developer] CVS pruning

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

Yes, I was still planning to go over the list one more time :-). I 
haven't written anything to SF yet...

Colin

Keith Donald wrote:

>Colin said:
>->This should leave the following modules in place
>-> - 'i21'
>-> - 'samples'
>-> - 'spring'
>-> - 'spring-beandoc'
>
>Colin,
>
>You meant to include spring-projects as another module to leave in place,
>right?
>
>What goes in "i21" and "samples"?  I wasn't aware they were being used.
>
>Keith
>
>  
>
>>As per the email below, I am going to submit a support request to SF to
>>remove the following obsolete or wrongly checked in modules from
>>Spring's CVS on SourceForge:
>>-  'Spring' (this is an empty module created with the wrong case, not to
>>be confused with the main Spring source, in the 'spring' module)
>>- 'common-build'
>>- 'repository'
>>- 'spring-binding'
>>- 'spring-modules'
>>- 'spring-rcp' (this is the old home of Spring-rcp (which is now hosted
>>in it's own sourceforge project, 'spring-rich-c')
>>- 'spring-webflow'
>>- 'spring-ide' (this is the old home of Spring-IDE, which is now hosted
>>in it's own Subversion repo elsewhere, managed by Torsten and co.).
>>
>>This should leave the following modules in place
>>- 'i21'
>>- 'samples'
>>- 'spring'
>>- 'spring-beandoc'
>>
>>I have no idea if SF will honour such a request from any project
>>developer, or it needs to be one of the leads (Rod or Juergen in our
>>case). If I'm told it's the latter, I'll notify Rod and Juergen to send
>>in the request themselves.
>>
>>Colin
>>
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>Yes. I'm just getting confirmation from Torsten/Christian that the old
>>>spring-ide module in CVS can be kileld (all the Spring-IDE) source is
>>>in their own Subversion repo now, then I'll publish a list of what
>>>modules are staying and which are being pruned, and submit a service
>>>request to SF.
>>>
>>>
>>>Erwin Vervaet wrote:
>>>
>>>      
>>>
>>>>Okay, I've moved my Eclipse over to use the new spring-projects module.
>>>>So I guess we can have the SF people clean up those bogus modules?
>>>>
>>>>Erwin Vervaet
>>>>erw...@er...
>>>>----- Original Message ----- From: "Colin Sampaleanu"
>>>><col...@ex...>
>>>>To: "Keith Donald" <ke...@in...>; "Erwin Vervaet"
>>>><erw...@er...>
>>>>Cc: <spr...@li...>
>>>>Sent: Friday, June 17, 2005 4:44 AM
>>>>Subject: Building webflow under spring-projects
>>>>
>>>>
>>>>        
>>>>
>>>>>Keith/Erwin,
>>>>>
>>>>>I moved (copied really) all common-build, spring-binding, and
>>>>>spring-webflow sources to live under a new spring-projects module in
>>>>>CVS.
>>>>>
>>>>>Note that the build relies on the use of a nightly snapshot of ivy
>>>>>  ivy-20050616204129.jar
>>>>>which may be found in
>>>>>  spring-projects\repository\jayasoft\ivy\jars
>>>>>This should be dropped into your ant lib dir to replace the older
>>>>>ivy 1.1. This If you try to use ivy 1.1 you'll get a failure when
>>>>>trying to do a publish of the generated artifact.
>>>>>          
>>>>>
>>--
>>Colin Sampaleanu
>>Interface21 Principal Consultant
>>Spring Training, Consulting and Support - "From the Source"
>>http://www.springframework.com
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>  
>


-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com