Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@in...> - 2006-07-12 09:35:55
|
All, I would like your input on this JIRA issue. Do you think this is valid breakage of backward-compatibility or would you like to see the change backed out? http://opensource.atlassian.com/projects/spring/browse/SPR-2277 Rob |
|
From: Matt S. <mat...@sp...> - 2006-07-12 14:16:59
|
My 2 cents is that an IDE will point this out to you and the change will take all of 2 minutes to code. It would be a bigger deal IMO if you had to change your context definitions, because in that case the error might not be found for a while (for example, if the bean was lazily initialized). However, Spring's use of PropertyEditors means the change should be transparent in terms of XML application context definitions. Matt Rob Harrop wrote: > All, > > I would like your input on this JIRA issue. Do you think this is valid > breakage of backward-compatibility or would you like to see the change > backed out? > > http://opensource.atlassian.com/projects/spring/browse/SPR-2277 > > Rob > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Matt S. <mat...@sp...> - 2006-07-12 14:26:47
|
Also, changes such as the new behavior of beanFactory.getBeansOfType are much more subtle and will cause problems that aren't easily pointed out by an IDE. So, I really wouldn't worry about this considering there are bigger compatibility differences between 1.x and 2.x Matt Matt Sgarlata wrote: > My 2 cents is that an IDE will point this out to you and the change will > take all of 2 minutes to code. > > It would be a bigger deal IMO if you had to change your context > definitions, because in that case the error might not be found for a > while (for example, if the bean was lazily initialized). However, > Spring's use of PropertyEditors means the change should be transparent > in terms of XML application context definitions. > > Matt > > Rob Harrop wrote: >> All, >> >> I would like your input on this JIRA issue. Do you think this is valid >> breakage of backward-compatibility or would you like to see the change >> backed out? >> >> http://opensource.atlassian.com/projects/spring/browse/SPR-2277 >> >> Rob >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 |
|
From: Keith D. <ke...@in...> - 2006-07-12 14:31:14
|
Hmm... Would it be good to note these issues in a "from 1.x to 2.0 migration guide" -- perhaps initially flushed out on the Wiki? Matt, it sounds like you've already got a good start there with some useful input for those moving to 2.0. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Matt Sgarlata Sent: Wednesday, July 12, 2006 10:26 AM To: spr...@li... Subject: Re: [Springframework-developer] Input on JIRA issue Also, changes such as the new behavior of beanFactory.getBeansOfType are much more subtle and will cause problems that aren't easily pointed out by an IDE. So, I really wouldn't worry about this considering there are bigger compatibility differences between 1.x and 2.x Matt Matt Sgarlata wrote: > My 2 cents is that an IDE will point this out to you and the change > will take all of 2 minutes to code. > > It would be a bigger deal IMO if you had to change your context > definitions, because in that case the error might not be found for a > while (for example, if the bean was lazily initialized). However, > Spring's use of PropertyEditors means the change should be transparent > in terms of XML application context definitions. > > Matt > > Rob Harrop wrote: >> All, >> >> I would like your input on this JIRA issue. Do you think this is >> valid breakage of backward-compatibility or would you like to see the >> change backed out? >> >> http://opensource.atlassian.com/projects/spring/browse/SPR-2277 >> >> Rob >> >> >> --------------------------------------------------------------------- >> --- >> >> >> --------------------------------------------------------------------- >> ---- Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier Download IBM WebSphere Application Server v.1.0.1 based on >> Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121 >> 642 >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-develope >> r > > > > ---------------------------------------------------------------------- > --- Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=1216 > 42 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2006-07-12 14:45:35
|
I don't think this will affect many people at all, as it's quite rare for people to use TransactionProxyFactoryBean programmatically. You could almost break things down into backwards compatibility for the declarative use (very very common) vs. programmatic use. I definitely like the use of Class[] more, it's cleaner. However if we are really concerned about even programmatic backwards compatibility, then one consideration is that in 2.0 people won't even be using TransactionProxyFactoryBean very much (preferring the new XML dialect), so it's not like the "benefit" of the Class[] signature is getting to many people. Of course, the 2.0 class could support both signatures, but the in that case for the declarative use the String[] will always be picked for the declarative case as it's a one-to-one mapping. Colin On 7/12/2006 10:15 AM, Matt Sgarlata wrote: > My 2 cents is that an IDE will point this out to you and the change will > take all of 2 minutes to code. > > It would be a bigger deal IMO if you had to change your context > definitions, because in that case the error might not be found for a > while (for example, if the bean was lazily initialized). However, > Spring's use of PropertyEditors means the change should be transparent > in terms of XML application context definitions. > > Matt > > Rob Harrop wrote: > >> All, >> >> I would like your input on this JIRA issue. Do you think this is valid >> breakage of backward-compatibility or would you like to see the change >> backed out? >> >> http://opensource.atlassian.com/projects/spring/browse/SPR-2277 >> >> Rob >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Rob H. <ro...@in...> - 2006-07-13 14:41:24
|
You can't have two setters with the name but different types if you want JavaBeans introspection to work. So we could have something like setProxyInterfaces(String[]) setProxyInterfaceTypes(Class[]) but that doesn't really help.... Juergen is back from a well earned holiday next Monday - lets see what he thinks and then make a final choice. On 12 Jul 2006, at 15:45, Colin Sampaleanu wrote: > I don't think this will affect many people at all, as it's quite rare > for people to use TransactionProxyFactoryBean programmatically. You > could almost break things down into backwards compatibility for the > declarative use (very very common) vs. programmatic use. > > I definitely like the use of Class[] more, it's cleaner. However if we > are really concerned about even programmatic backwards compatibility, > then one consideration is that in 2.0 people won't even be using > TransactionProxyFactoryBean very much (preferring the new XML > dialect), > so it's not like the "benefit" of the Class[] signature is getting to > many people. > > Of course, the 2.0 class could support both signatures, but the in > that > case for the declarative use the String[] will always be picked for > the > declarative case as it's a one-to-one mapping. > > Colin > > On 7/12/2006 10:15 AM, Matt Sgarlata wrote: >> My 2 cents is that an IDE will point this out to you and the >> change will >> take all of 2 minutes to code. >> >> It would be a bigger deal IMO if you had to change your context >> definitions, because in that case the error might not be found for a >> while (for example, if the bean was lazily initialized). However, >> Spring's use of PropertyEditors means the change should be >> transparent >> in terms of XML application context definitions. >> >> Matt >> >> Rob Harrop wrote: >> >>> All, >>> >>> I would like your input on this JIRA issue. Do you think this is >>> valid >>> breakage of backward-compatibility or would you like to see the >>> change >>> backed out? >>> >>> http://opensource.atlassian.com/projects/spring/browse/SPR-2277 >>> >>> Rob >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> >>> -------------------------------------------------------------------- >>> ----- >>> Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to make >>> your job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> http://sel.as-us.falkag.net/sel? >>> cmd=lnk&kid=120709&bid=263057&dat=121642 >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework- >>> developer >>> >> >> >> >> --------------------------------------------------------------------- >> ---- >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework- >> developer >> >> > > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Rob Harrop VP, Technology Strategy Interface21 - Spring Services from the Source http://www.springframework.com |
|
From: Glen M. <gr...@ve...> - 2006-07-12 16:57:45
|
I would advise against *complete* backwards compatibility, especially if it means burdening future releases of Spring with seldom-used cobwebs from previous ones, of things that originally sounded like good ideas but turned out not to work so well after all. I think it is important that Spring have some "nimbleness", i.e. occasionally be allowed to clear itself out of past baggage, so it can compete effectively against future competitor frameworks, that, by virtue of being new, don't need to be burdened with older API's from past releases. Glen Colin Sampaleanu write: > I don't think this will affect many people at all, as it's quite rare > for people to use TransactionProxyFactoryBean programmatically. You > could almost break things down into backwards compatibility for the > declarative use (very very common) vs. programmatic use. > > I definitely like the use of Class[] more, it's cleaner. However if we > are really concerned about even programmatic backwards compatibility, > then one consideration is that in 2.0 people won't even be using > TransactionProxyFactoryBean very much (preferring the new XML dialect), > so it's not like the "benefit" of the Class[] signature is getting to > many people. > > Of course, the 2.0 class could support both signatures, but the in that > case for the declarative use the String[] will always be picked for the > declarative case as it's a one-to-one mapping. > > Colin > > On 7/12/2006 10:15 AM, Matt Sgarlata wrote: > >>My 2 cents is that an IDE will point this out to you and the change will >>take all of 2 minutes to code. >> >>It would be a bigger deal IMO if you had to change your context >>definitions, because in that case the error might not be found for a >>while (for example, if the bean was lazily initialized). However, >>Spring's use of PropertyEditors means the change should be transparent >>in terms of XML application context definitions. >> >>Matt >> >>Rob Harrop wrote: >> >> >>>All, >>> >>>I would like your input on this JIRA issue. Do you think this is valid >>>breakage of backward-compatibility or would you like to see the change >>>backed out? >>> >>>http://opensource.atlassian.com/projects/spring/browse/SPR-2277 >>> >>>Rob >>> |
