Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-08-20 07:21:44
|
The following suggestion sounds plausible: =20 http://opensource.atlassian.com/projects/spring/browse/SPR-269 =20 Currently, singleton parent bean definitions that are not meant to be = instantiated directly have to be marked "lazy-init" to avoid eager = instantiation on application context startup. I guess it would be = cleaner do introduce an abstract=3D"true"/"false" attribute at the = "bean" level, clearly indicating that this bean should never be created = but just serves as template for child bean definitions. =20 Any objections to adding this for 1.1 final? =20 Juergen |
|
From: Rod J. <ro...@in...> - 2004-08-20 12:31:50
|
I think this would be valuable functionality. In fact, the Interface21 framework did have the notion of "abstract" bean definitions. It's important of course that such abstract definitions are not returned = by the enumeration methods on ListableBeanFactory.=20 I would be very keen to see this in 1.1 final. -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: 20 August 2004 08:25 To: spr...@li... Subject: [Springframework-developer] Introduce explicit "abstract" bean definition attribute The following suggestion sounds plausible: =20 http://opensource.atlassian.com/projects/spring/browse/SPR-269 =20 Currently, singleton parent bean definitions that are not meant to be instantiated directly have to be marked "lazy-init" to avoid eager instantiation on application context startup. I guess it would be = cleaner do introduce an abstract=3D"true"/"false" attribute at the "bean" level, = clearly indicating that this bean should never be created but just serves as template for child bean definitions. =20 Any objections to adding this for 1.1 final? =20 Juergen ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media = 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-08-20 18:42:46
|
+1 Rod Johnson wrote: >I think this would be valuable functionality. In fact, the Interface21 >framework did have the notion of "abstract" bean definitions. > >It's important of course that such abstract definitions are not returned by >the enumeration methods on ListableBeanFactory. > >I would be very keen to see this in 1.1 final. > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...] On Behalf Of >jürgen höller [werk3AT] >Sent: 20 August 2004 08:25 >To: spr...@li... >Subject: [Springframework-developer] Introduce explicit "abstract" bean >definition attribute > >The following suggestion sounds plausible: > >http://opensource.atlassian.com/projects/spring/browse/SPR-269 > >Currently, singleton parent bean definitions that are not meant to be >instantiated directly have to be marked "lazy-init" to avoid eager >instantiation on application context startup. I guess it would be cleaner do >introduce an abstract="true"/"false" attribute at the "bean" level, clearly >indicating that this bean should never be created but just serves as >template for child bean definitions. > >Any objections to adding this for 1.1 final? > >Juergen > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk >Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off >Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Guillaume P. <gpo...@gl...> - 2004-08-20 19:30:35
|
+1 Colin Sampaleanu wrote: > +1 > > Rod Johnson wrote: > >> I think this would be valuable functionality. In fact, the Interface21 >> framework did have the notion of "abstract" bean definitions. >> >> It's important of course that such abstract definitions are not=20 >> returned by >> the enumeration methods on ListableBeanFactory. >> I would be very keen to see this in 1.1 final. >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On=20 >> Behalf Of >> j=FCrgen h=F6ller [werk3AT] >> Sent: 20 August 2004 08:25 >> To: spr...@li... >> Subject: [Springframework-developer] Introduce explicit "abstract" bea= n >> definition attribute >> >> The following suggestion sounds plausible: >> >> http://opensource.atlassian.com/projects/spring/browse/SPR-269 >> >> Currently, singleton parent bean definitions that are not meant to be >> instantiated directly have to be marked "lazy-init" to avoid eager >> instantiation on application context startup. I guess it would be=20 >> cleaner do >> introduce an abstract=3D"true"/"false" attribute at the "bean" level,=20 >> clearly >> indicating that this bean should never be created but just serves as >> template for child bean definitions. >> >> Any objections to adding this for 1.1 final? >> >> Juergen >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank=20 >> Media 100pk >> Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% o= ff >> Retail on Ink & Toner - Free Shipping and Free Gift. >> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> =20 >> > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Martin K. <Mar...@St...> - 2004-08-20 19:52:20
|
+1 > +1 > > Rod Johnson wrote: > > >I think this would be valuable functionality. In fact, the Interface21 > >framework did have the notion of "abstract" bean definitions. > > > >It's important of course that such abstract definitions are not returned by > >the enumeration methods on ListableBeanFactory. > > > >I would be very keen to see this in 1.1 final. > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...] On Behalf Of > >jürgen höller [werk3AT] > >Sent: 20 August 2004 08:25 > >To: spr...@li... > >Subject: [Springframework-developer] Introduce explicit "abstract" bean > >definition attribute > > > >The following suggestion sounds plausible: > > > >http://opensource.atlassian.com/projects/spring/browse/SPR-269 > > > >Currently, singleton parent bean definitions that are not meant to be > >instantiated directly have to be marked "lazy-init" to avoid eager > >instantiation on application context startup. I guess it would be cleaner do > >introduce an abstract="true"/"false" attribute at the "bean" level, clearly > >indicating that this bean should never be created but just serves as > >template for child bean definitions. > > > >Any objections to adding this for 1.1 final? > > > >Juergen > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk > >Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off > >Retail on Ink & Toner - Free Shipping and Free Gift. > >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > >_______________________________________________ > >Springframework-developer mailing list > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > >_______________________________________________ > >Springframework-developer mailing list > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Martin K. <Mar...@St...> - 2004-08-20 19:58:19
|
Hi folks,
Checking the Spring 1.1 RC2 remote code, I have noticed,
that the RemoteInvocationResult class is referring to Exception
rather than Throwable.
Visiting the InvocationTargetException the code reads:
/**
* Get the thrown target exception.
*
* <p>This method predates the general-purpose exception chaining
facility.
* The {@link Throwable#getCause()} method is now the preferred means of
* obtaining this information.
*
* @return the thrown target exception (cause of this exception).
*/
public Throwable getTargetException() {
return target;
}
So I guess it would be more consistent to use Throwable instead
of Exception since the Throwable would be more abstract (thus
more flexibile).
Summary:
public class RemoteInvocationResult implements Serializable {
private Object value;
private Exception exception;
should be changed into:
public class RemoteInvocationResult implements Serializable {
private Object value;
private Throwable exception;
Cheers,
Martin (Kersten)
|
