Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-05-21 09:14:22
|
I'd like to address our form controller's handling of resubmits and = invalid session state before - avoid hearing this over and over again = after releasing 0.8 ;-) This will definitely be finished at the end of = this week, including testing, so it shouldn't cause any delays. On the occasion, there is a major gap in the web test suite: We don't = have any tests for FrameworkServlet and ControllerServlet currently. I = got aware of this again yesterday when I've discovered that = LocaleResolver initialization was broken (already fixed). Although they = seem to work properly now, we should probably address respective tests = before an official 0.8 release. Otherwise, I agree that we mainly depend on docs and tutorial. But let's = avoid the urge for early perfectness and just release what we have, say, = next week! Juergen -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Tuesday, May 20, 2003 11:06 PM To: spr...@li... Subject: [Springframework-developer] Code changes for 0.8? Guys, Anyone in the middle of any code changes right now? I'm done, besides any bug fixing required. I suggest we go for what I'd call a soft release. That is, we get a drop = out (after agreeing what goes in it...I know Juergen had some ideas), and = each of us tests it, ideally on new machines. This release will also help = some existing users who want the latest code but can't access CVS at work. = (Like me, if I forget my USB pen :-) Once we're happy it all works, the time we actually announce will depend = on the state of the documents. Regards, Rod ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-05-22 15:28:00
|
Besides having reworked the form controller's handling of resubmits, = I've also created an extensive test suite for ControllerServlet and some = web support classes. We're at overall >64% now! Additionally, I've refined some ApplicationContext stuff (moved = OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext = etc), and cleaned the exception handling in the beans package (e.g. = rethrow BeansException directly when catching Exception instead of = wrapping it). Rethrown exceptions don't get logged anymore, as they are logged by the = highest level exception handler anyway (-> no double stack traces in the = console). I've also commented out the println(this) on printing a = rootCause stack trace: As a root stack trace will always get printed = after the exception's message, those lines have only added redundant = information, cluttering the console. I've removed FrameworkServlet's debug support, I don't see any real use = case for it. During development, Log4J's debug log is all you need, IMO = - you exactly see what handlers/mappings/etc get used, no need for = binding them to the request. I'm also gonna move the web.mock classes back to the test sources, as = they are pretty rough, and not really meant for usage within application = development - in constrast to the JNDI mocks, for example. I'll check my stuff in within the next 2 hours. Everybody, please test = the current framework version in your apps! We should really try to = release a 0.8 as stable as possible. BTW, what's the current status in terms of code beautification (Jalopy = etc)? We have mixed headers in our files at the moment, and sometimes = inconsistent formatting. Do we aim to clean this for 0.8? Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Wednesday, May 21, 2003 11:16 AM To: spr...@li... Subject: RE: [Springframework-developer] Code changes for 0.8? I'd like to address our form controller's handling of resubmits and = invalid session state before - avoid hearing this over and over again = after releasing 0.8 ;-) This will definitely be finished at the end of = this week, including testing, so it shouldn't cause any delays. On the occasion, there is a major gap in the web test suite: We don't = have any tests for FrameworkServlet and ControllerServlet currently. I = got aware of this again yesterday when I've discovered that = LocaleResolver initialization was broken (already fixed). Although they = seem to work properly now, we should probably address respective tests = before an official 0.8 release. Otherwise, I agree that we mainly depend on docs and tutorial. But let's = avoid the urge for early perfectness and just release what we have, say, = next week! Juergen -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Tuesday, May 20, 2003 11:06 PM To: spr...@li... Subject: [Springframework-developer] Code changes for 0.8? Guys, Anyone in the middle of any code changes right now? I'm done, besides any bug fixing required. I suggest we go for what I'd call a soft release. That is, we get a drop = out (after agreeing what goes in it...I know Juergen had some ideas), and = each of us tests it, ideally on new machines. This release will also help = some existing users who want the latest code but can't access CVS at work. = (Like me, if I forget my USB pen :-) Once we're happy it all works, the time we actually announce will depend = on the state of the documents. Regards, Rod ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-05-22 16:28:31
|
Excellent. Great news on the test coverage! You've been doing good work here. I'm glad you've cleaned up the stack traces... There were quite a few repeated stack traces a long time ago, and I got many of them (but obviously not all). I think the volume and quality of stack traces is very important. It's about the only thing that really bugs me with Hibernate 2.0 RC1, for example. We may need to consider a consistent approach to logging (levels etc.) for 0.9 or 1.0. I imagine removing debug support in framework servlet removed a lot of code. I actually eyed it myself with my scalpel in mind recently. It did make the code much harder to understand and the fewer lines of code, the fewer potential bugs. Also, I don't think it was documented anywhere, so I doubt anyone will miss it too much. (I did use it myself occasionally but I'm sure I can live without it.) I'm not sure that *any* mock objects should be in the main source tree. Maybe we need a third tree for the mocks and things like EjbContainerDetective that are handy but not part of the core spring runtime. I don't tend to use our mock objects much anymore, since I discovered the wonder that is EasyMock. Code formatting I think is a 0.9 thing. Certainly after we have a tagged stable release. We don't want to delay 0.8 for this. I'm away this weekend (bank holiday in the UK), so won't be doing any work. Anything I do add to Spring until we go to 0.8 will either be an urgent bug fix or simply additional tests. Regards, Rod ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, May 22, 2003 4:29 PM Subject: RE: [Springframework-developer] Code changes for 0.8? Besides having reworked the form controller's handling of resubmits, I've also created an extensive test suite for ControllerServlet and some web support classes. We're at overall >64% now! Additionally, I've refined some ApplicationContext stuff (moved OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext etc), and cleaned the exception handling in the beans package (e.g. rethrow BeansException directly when catching Exception instead of wrapping it). Rethrown exceptions don't get logged anymore, as they are logged by the highest level exception handler anyway (-> no double stack traces in the console). I've also commented out the println(this) on printing a rootCause stack trace: As a root stack trace will always get printed after the exception's message, those lines have only added redundant information, cluttering the console. I've removed FrameworkServlet's debug support, I don't see any real use case for it. During development, Log4J's debug log is all you need, IMO - you exactly see what handlers/mappings/etc get used, no need for binding them to the request. I'm also gonna move the web.mock classes back to the test sources, as they are pretty rough, and not really meant for usage within application development - in constrast to the JNDI mocks, for example. I'll check my stuff in within the next 2 hours. Everybody, please test the current framework version in your apps! We should really try to release a 0.8 as stable as possible. BTW, what's the current status in terms of code beautification (Jalopy etc)? We have mixed headers in our files at the moment, and sometimes inconsistent formatting. Do we aim to clean this for 0.8? Juergen |
|
From: Isabelle M. <isa...@me...> - 2003-05-22 17:02:02
|
Hi everyone, I'll do as much work as I can on the tutorial over the weekend. Hopefully, I can get the equivalent of chapter 12 done, maybe even some of chapter 13. I guess the JNDI and EJB stuff will have to wait until the next release. As always, I'll notify the list and post the new version on my website. Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: <rod...@in...> - 2003-05-22 17:04:39
|
>Regarding mock objects, I think that the JNDI mocks do have value for application developers: They can serve as JNDI replacement for applications test environments and standalone applications, running the same code and config files as in the container environment. I agree. I wasn't suggesting dropping them, just moving them along with some other stuff to a new /support or such tree. So developers could choose to use them, but they'd be clearly intended *not* to be part of most Spring apps in production. Rod |
|
From: <jue...@we...> - 2003-05-22 17:29:55
|
Regarding mock objects, I think that the JNDI mocks do have value for = application developers: They can serve as JNDI replacement for = applications test environments and standalone applications, running the = same code and config files as in the container environment. We are using this to be able to reuse the same Hibernate config file for = both web app and test environments. In the standalone access, we simply = bind a DriverManagerDataSource to the same JNDI location, with Spring's = JNDI mocks as infrastructure. Other development projects can use this strategy too, and EasyMock won't = help here. Thus, I'd like the JNDI mocks to stay, but all other mocks = should not be in our src tree IMO, as they only serve within our test = suites. Regarding FrameworkServlet's debug support, that were exactly the = reasons why I've removed them. It cluttered up the code somewhat, and I = don't consider it necessary. --- I've just added one more refactoring: I've replaced both = JndiDataSourceBean/JndiDataSourceEditor and = JndiSessionFactoryBean/JndiSessionFactoryEditor with generic = implementations, namely JndiObjectFactoryBean and JndiObjectEditor. = Effectively, the FactoryBeans have just returned Objects, so there's no = need for specialized implementations. I've also removed = DataSourceUtils.getDataSourceFromJndi and = SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't = recommended anymore. I don't like too many ways to achieve 1 thing. One more reason is that the former getDataSourceFromJndi always looked = up the given name under "java:comp/env", if not contained in the name. = This is too inflexible: A DataSource might be bound to any JNDI name, in = fact. JndiObjectFactoryBean and JndiObjectEditor need the full JNDI = name: This is clearer and not much effort. So Isabelle and Ken, please use = com.interface21.jndi.JndiObjectFactoryBean for DataSource definitions = instead of com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for = the late change, but I think it's worth it. Gonna check all this stuff in the next hour... Regards, Juergen -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: Thursday, May 22, 2003 6:24 PM To: j=FCrgen h=F6ller [werk3AT] Cc: spr...@li... Subject: Re: [Springframework-developer] Code changes for 0.8? Excellent. Great news on the test coverage! You've been doing good work here. I'm glad you've cleaned up the stack traces... There were quite a few repeated stack traces a long time ago, and I got many of them (but = obviously not all). I think the volume and quality of stack traces is very = important. It's about the only thing that really bugs me with Hibernate 2.0 RC1, = for example. We may need to consider a consistent approach to logging = (levels etc.) for 0.9 or 1.0. I imagine removing debug support in framework servlet removed a lot of = code. I actually eyed it myself with my scalpel in mind recently. It did make = the code much harder to understand and the fewer lines of code, the fewer potential bugs. Also, I don't think it was documented anywhere, so I = doubt anyone will miss it too much. (I did use it myself occasionally but I'm = sure I can live without it.) I'm not sure that *any* mock objects should be in the main source tree. Maybe we need a third tree for the mocks and things like EjbContainerDetective that are handy but not part of the core spring runtime. I don't tend to use our mock objects much anymore, since I discovered the wonder that is EasyMock. Code formatting I think is a 0.9 thing. Certainly after we have a tagged stable release. We don't want to delay 0.8 for this. I'm away this weekend (bank holiday in the UK), so won't be doing any = work. Anything I do add to Spring until we go to 0.8 will either be an urgent = bug fix or simply additional tests. Regards, Rod ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, May 22, 2003 4:29 PM Subject: RE: [Springframework-developer] Code changes for 0.8? Besides having reworked the form controller's handling of resubmits, = I've also created an extensive test suite for ControllerServlet and some web support classes. We're at overall >64% now! Additionally, I've refined some ApplicationContext stuff (moved OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext etc), and cleaned the exception handling in the beans package (e.g. = rethrow BeansException directly when catching Exception instead of wrapping it). Rethrown exceptions don't get logged anymore, as they are logged by the highest level exception handler anyway (-> no double stack traces in the console). I've also commented out the println(this) on printing a = rootCause stack trace: As a root stack trace will always get printed after the exception's message, those lines have only added redundant information, cluttering the console. I've removed FrameworkServlet's debug support, I don't see any real use = case for it. During development, Log4J's debug log is all you need, IMO - you exactly see what handlers/mappings/etc get used, no need for binding = them to the request. I'm also gonna move the web.mock classes back to the test sources, as = they are pretty rough, and not really meant for usage within application development - in constrast to the JNDI mocks, for example. I'll check my stuff in within the next 2 hours. Everybody, please test = the current framework version in your apps! We should really try to release = a 0.8 as stable as possible. BTW, what's the current status in terms of code beautification (Jalopy = etc)? We have mixed headers in our files at the moment, and sometimes = inconsistent formatting. Do we aim to clean this for 0.8? Juergen |
|
From: <tri...@tr...> - 2003-05-23 01:06:12
|
Jürgen, I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications that only use the JDBC framework. Maybe we could change the way it does the lookup to make it similar to the JndiObjectFactoryBean. What do you all think? Thomas > Regarding mock objects, I think that the JNDI mocks do have value for > application developers: They can serve as JNDI replacement for applications > test environments and standalone applications, running the same code and > config files as in the container environment. > > We are using this to be able to reuse the same Hibernate config file for both > web app and test environments. In the standalone access, we simply bind a > DriverManagerDataSource to the same JNDI location, with Spring's JNDI mocks > as infrastructure. > > Other development projects can use this strategy too, and EasyMock won't help > here. Thus, I'd like the JNDI mocks to stay, but all other mocks should not > be in our src tree IMO, as they only serve within our test suites. > > Regarding FrameworkServlet's debug support, that were exactly the reasons why > I've removed them. It cluttered up the code somewhat, and I don't consider it > necessary. > > --- > > I've just added one more refactoring: I've replaced both > JndiDataSourceBean/JndiDataSourceEditor and > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic implementations, > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the > FactoryBeans have just returned Objects, so there's no need for specialized > implementations. I've also removed DataSourceUtils.getDataSourceFromJndi and > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't recommended > anymore. I don't like too many ways to achieve 1 thing. > > One more reason is that the former getDataSourceFromJndi always looked up the > given name under "java:comp/env", if not contained in the name. This is too > inflexible: A DataSource might be bound to any JNDI name, in fact. > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This is > clearer and not much effort. > > So Isabelle and Ken, please use com.interface21.jndi.JndiObjectFactoryBean > for DataSource definitions instead of > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late > change, but I think it's worth it. > > Gonna check all this stuff in the next hour... > > Regards, > Juergen > > > -----Original Message----- > From: Rod Johnson [mailto:rod...@in...] > Sent: Thursday, May 22, 2003 6:24 PM > To: jürgen höller [werk3AT] > Cc: spr...@li... > Subject: Re: [Springframework-developer] Code changes for 0.8? > > > Excellent. Great news on the test coverage! You've been doing good work > here. > > I'm glad you've cleaned up the stack traces... There were quite a few > repeated stack traces a long time ago, and I got many of them (but obviously > not all). I think the volume and quality of stack traces is very important. > It's about the only thing that really bugs me with Hibernate 2.0 RC1, for > example. We may need to consider a consistent approach to logging (levels > etc.) for 0.9 or 1.0. > > I imagine removing debug support in framework servlet removed a lot of code. > I actually eyed it myself with my scalpel in mind recently. It did make the > code much harder to understand and the fewer lines of code, the fewer > potential bugs. Also, I don't think it was documented anywhere, so I doubt > anyone will miss it too much. (I did use it myself occasionally but I'm sure > I can live without it.) > > I'm not sure that *any* mock objects should be in the main source tree. > Maybe we need a third tree for the mocks and things like > EjbContainerDetective that are handy but not part of the core spring > runtime. I don't tend to use our mock objects much anymore, since I > discovered the wonder that is EasyMock. > > Code formatting I think is a 0.9 thing. Certainly after we have a tagged > stable release. We don't want to delay 0.8 for this. > > I'm away this weekend (bank holiday in the UK), so won't be doing any work. > Anything I do add to Spring until we go to 0.8 will either be an urgent bug > fix or simply additional tests. > > Regards, > Rod > > ----- Original Message ----- > From: "jürgen höller [werk3AT]" <jue...@we...> > To: <spr...@li...> > Sent: Thursday, May 22, 2003 4:29 PM > Subject: RE: [Springframework-developer] Code changes for 0.8? > > > Besides having reworked the form controller's handling of resubmits, I've > also created an extensive test suite for ControllerServlet and some web > support classes. We're at overall >64% now! > > Additionally, I've refined some ApplicationContext stuff (moved > OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext > etc), and cleaned the exception handling in the beans package (e.g. rethrow > BeansException directly when catching Exception instead of wrapping it). > > Rethrown exceptions don't get logged anymore, as they are logged by the > highest level exception handler anyway (-> no double stack traces in the > console). I've also commented out the println(this) on printing a rootCause > stack trace: As a root stack trace will always get printed after the > exception's message, those lines have only added redundant information, > cluttering the console. > > I've removed FrameworkServlet's debug support, I don't see any real use case > for it. During development, Log4J's debug log is all you need, IMO - you > exactly see what handlers/mappings/etc get used, no need for binding them to > the request. > > I'm also gonna move the web.mock classes back to the test sources, as they > are pretty rough, and not really meant for usage within application > development - in constrast to the JNDI mocks, for example. > > I'll check my stuff in within the next 2 hours. Everybody, please test the > current framework version in your apps! We should really try to release a > 0.8 as stable as possible. > > BTW, what's the current status in terms of code beautification (Jalopy etc)? > We have mixed headers in our files at the moment, and sometimes inconsistent > formatting. Do we aim to clean this for 0.8? > > Juergen > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Rod J. <rod...@in...> - 2003-05-23 06:47:49
|
I agree with Thomas. Good point. At the moment I know of 2 companies using Spring JDBC only. If they have to do the JNDI stuff themselves it reduces the benefit. Rod ----- Original Message ----- From: <tri...@tr...> To: "jürgen höller [werk3AT]" <jue...@we...> Cc: "Rod Johnson" <rod...@in...>; <spr...@li...> Sent: Friday, May 23, 2003 2:06 AM Subject: RE: [Springframework-developer] Code changes for 0.8? > Jürgen, > > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications that > only use the JDBC framework. Maybe we could change the way it does the lookup > to make it similar to the JndiObjectFactoryBean. What do you all think? > > Thomas > > > Regarding mock objects, I think that the JNDI mocks do have value for > > application developers: They can serve as JNDI replacement for applications > > test environments and standalone applications, running the same code and > > config files as in the container environment. > > > > We are using this to be able to reuse the same Hibernate config file for both > > web app and test environments. In the standalone access, we simply bind a > > DriverManagerDataSource to the same JNDI location, with Spring's JNDI mocks > > as infrastructure. > > > > Other development projects can use this strategy too, and EasyMock won't help > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks should not > > be in our src tree IMO, as they only serve within our test suites. > > > > Regarding FrameworkServlet's debug support, that were exactly the reasons why > > I've removed them. It cluttered up the code somewhat, and I don't consider it > > necessary. > > > > --- > > > > I've just added one more refactoring: I've replaced both > > JndiDataSourceBean/JndiDataSourceEditor and > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic implementations, > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the > > FactoryBeans have just returned Objects, so there's no need for specialized > > implementations. I've also removed DataSourceUtils.getDataSourceFromJndi and > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't recommended > > anymore. I don't like too many ways to achieve 1 thing. > > > > One more reason is that the former getDataSourceFromJndi always looked up the > > given name under "java:comp/env", if not contained in the name. This is too > > inflexible: A DataSource might be bound to any JNDI name, in fact. > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This is > > clearer and not much effort. > > > > So Isabelle and Ken, please use com.interface21.jndi.JndiObjectFactoryBean > > for DataSource definitions instead of > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late > > change, but I think it's worth it. > > > > Gonna check all this stuff in the next hour... > > > > Regards, > > Juergen > > > > > > -----Original Message----- > > From: Rod Johnson [mailto:rod...@in...] > > Sent: Thursday, May 22, 2003 6:24 PM > > To: jürgen höller [werk3AT] > > Cc: spr...@li... > > Subject: Re: [Springframework-developer] Code changes for 0.8? > > > > > > Excellent. Great news on the test coverage! You've been doing good work > > here. > > > > I'm glad you've cleaned up the stack traces... There were quite a few > > repeated stack traces a long time ago, and I got many of them (but obviously > > not all). I think the volume and quality of stack traces is very important. > > It's about the only thing that really bugs me with Hibernate 2.0 RC1, for > > example. We may need to consider a consistent approach to logging (levels > > etc.) for 0.9 or 1.0. > > > > I imagine removing debug support in framework servlet removed a lot of code. > > I actually eyed it myself with my scalpel in mind recently. It did make the > > code much harder to understand and the fewer lines of code, the fewer > > potential bugs. Also, I don't think it was documented anywhere, so I doubt > > anyone will miss it too much. (I did use it myself occasionally but I'm sure > > I can live without it.) > > > > I'm not sure that *any* mock objects should be in the main source tree. > > Maybe we need a third tree for the mocks and things like > > EjbContainerDetective that are handy but not part of the core spring > > runtime. I don't tend to use our mock objects much anymore, since I > > discovered the wonder that is EasyMock. > > > > Code formatting I think is a 0.9 thing. Certainly after we have a tagged > > stable release. We don't want to delay 0.8 for this. > > > > I'm away this weekend (bank holiday in the UK), so won't be doing any work. > > Anything I do add to Spring until we go to 0.8 will either be an urgent bug > > fix or simply additional tests. > > > > Regards, > > Rod > > > > ----- Original Message ----- > > From: "jürgen höller [werk3AT]" <jue...@we...> > > To: <spr...@li...> > > Sent: Thursday, May 22, 2003 4:29 PM > > Subject: RE: [Springframework-developer] Code changes for 0.8? > > > > > > Besides having reworked the form controller's handling of resubmits, I've > > also created an extensive test suite for ControllerServlet and some web > > support classes. We're at overall >64% now! > > > > Additionally, I've refined some ApplicationContext stuff (moved > > OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext > > etc), and cleaned the exception handling in the beans package (e.g. rethrow > > BeansException directly when catching Exception instead of wrapping it). > > > > Rethrown exceptions don't get logged anymore, as they are logged by the > > highest level exception handler anyway (-> no double stack traces in the > > console). I've also commented out the println(this) on printing a rootCause > > stack trace: As a root stack trace will always get printed after the > > exception's message, those lines have only added redundant information, > > cluttering the console. > > > > I've removed FrameworkServlet's debug support, I don't see any real use case > > for it. During development, Log4J's debug log is all you need, IMO - you > > exactly see what handlers/mappings/etc get used, no need for binding them to > > the request. > > > > I'm also gonna move the web.mock classes back to the test sources, as they > > are pretty rough, and not really meant for usage within application > > development - in constrast to the JNDI mocks, for example. > > > > I'll check my stuff in within the next 2 hours. Everybody, please test the > > current framework version in your apps! We should really try to release a > > 0.8 as stable as possible. > > > > BTW, what's the current status in terms of code beautification (Jalopy etc)? > > We have mixed headers in our files at the moment, and sometimes inconsistent > > formatting. Do we aim to clean this for 0.8? > > > > Juergen > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > |
|
From: <jue...@we...> - 2003-05-23 09:02:22
|
Good point indeed, using Spring JDBC without an ApplicationContext. I'll =
reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm a little over-eager in terms of simplification, sorry :-)
I assume that the typical scenario for this is somewhat like the =
following:
DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
JdbcTemplate jt =3D new JdbcTemplate(ds);
jt.<doSomething>;
Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate constructor with a DataSource NAME. The retrieved =
DataSource will typically be kept somewhere anyway.
I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer" property then, to be able to control "java:comp/env" =
prefixing (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means prefix "java:comp/env" if not already =
contained).
Juergen
-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Friday, May 23, 2003 8:36 AM
To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?
I agree with Thomas. Good point. At the moment I know of 2 companies =
using
Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
the benefit.
Rod
----- Original Message -----
From: <tri...@tr...>
To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
Cc: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, May 23, 2003 2:06 AM
Subject: RE: [Springframework-developer] Code changes for 0.8?
> J=FCrgen,
>
> I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
that
> only use the JDBC framework. Maybe we could change the way it does =
the
lookup
> to make it similar to the JndiObjectFactoryBean. What do you all =
think?
>
> Thomas
>
> > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > application developers: They can serve as JNDI replacement for
applications
> > test environments and standalone applications, running the same code =
and
> > config files as in the container environment.
> >
> > We are using this to be able to reuse the same Hibernate config file =
for
both
> > web app and test environments. In the standalone access, we simply =
bind
a
> > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
mocks
> > as infrastructure.
> >
> > Other development projects can use this strategy too, and EasyMock =
won't
help
> > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
not
> > be in our src tree IMO, as they only serve within our test suites.
> >
> > Regarding FrameworkServlet's debug support, that were exactly the
reasons why
> > I've removed them. It cluttered up the code somewhat, and I don't
consider it
> > necessary.
> >
> > ---
> >
> > I've just added one more refactoring: I've replaced both
> > JndiDataSourceBean/JndiDataSourceEditor and
> > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
implementations,
> > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> > FactoryBeans have just returned Objects, so there's no need for
specialized
> > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
and
> > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
recommended
> > anymore. I don't like too many ways to achieve 1 thing.
> >
> > One more reason is that the former getDataSourceFromJndi always =
looked
up the
> > given name under "java:comp/env", if not contained in the name. This =
is
too
> > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: =
This
is
> > clearer and not much effort.
> >
> > So Isabelle and Ken, please use
com.interface21.jndi.JndiObjectFactoryBean
> > for DataSource definitions instead of
> > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > change, but I think it's worth it.
> >
> > Gonna check all this stuff in the next hour...
> >
> > Regards,
> > Juergen
> >
> >
> > -----Original Message-----
> > From: Rod Johnson [mailto:rod...@in...]
> > Sent: Thursday, May 22, 2003 6:24 PM
> > To: j=FCrgen h=F6ller [werk3AT]
> > Cc: spr...@li...
> > Subject: Re: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Excellent. Great news on the test coverage! You've been doing good =
work
> > here.
> >
> > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > repeated stack traces a long time ago, and I got many of them (but
obviously
> > not all). I think the volume and quality of stack traces is very
important.
> > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
for
> > example. We may need to consider a consistent approach to logging
(levels
> > etc.) for 0.9 or 1.0.
> >
> > I imagine removing debug support in framework servlet removed a lot =
of
code.
> > I actually eyed it myself with my scalpel in mind recently. It did =
make
the
> > code much harder to understand and the fewer lines of code, the =
fewer
> > potential bugs. Also, I don't think it was documented anywhere, so I
doubt
> > anyone will miss it too much. (I did use it myself occasionally but =
I'm
sure
> > I can live without it.)
> >
> > I'm not sure that *any* mock objects should be in the main source =
tree.
> > Maybe we need a third tree for the mocks and things like
> > EjbContainerDetective that are handy but not part of the core spring
> > runtime. I don't tend to use our mock objects much anymore, since I
> > discovered the wonder that is EasyMock.
> >
> > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > stable release. We don't want to delay 0.8 for this.
> >
> > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
work.
> > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
bug
> > fix or simply additional tests.
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > To: <spr...@li...>
> > Sent: Thursday, May 22, 2003 4:29 PM
> > Subject: RE: [Springframework-developer] Code changes for 0.8?
> >
> >
> > Besides having reworked the form controller's handling of resubmits,
I've
> > also created an extensive test suite for ControllerServlet and some =
web
> > support classes. We're at overall >64% now!
> >
> > Additionally, I've refined some ApplicationContext stuff (moved
> > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > etc), and cleaned the exception handling in the beans package (e.g.
rethrow
> > BeansException directly when catching Exception instead of wrapping =
it).
> >
> > Rethrown exceptions don't get logged anymore, as they are logged by =
the
> > highest level exception handler anyway (-> no double stack traces in =
the
> > console). I've also commented out the println(this) on printing a
rootCause
> > stack trace: As a root stack trace will always get printed after the
> > exception's message, those lines have only added redundant =
information,
> > cluttering the console.
> >
> > I've removed FrameworkServlet's debug support, I don't see any real =
use
case
> > for it. During development, Log4J's debug log is all you need, IMO - =
you
> > exactly see what handlers/mappings/etc get used, no need for binding
them to
> > the request.
> >
> > I'm also gonna move the web.mock classes back to the test sources, =
as
they
> > are pretty rough, and not really meant for usage within application
> > development - in constrast to the JNDI mocks, for example.
> >
> > I'll check my stuff in within the next 2 hours. Everybody, please =
test
the
> > current framework version in your apps! We should really try to =
release
a
> > 0.8 as stable as possible.
> >
> > BTW, what's the current status in terms of code beautification =
(Jalopy
etc)?
> > We have mixed headers in our files at the moment, and sometimes
inconsistent
> > formatting. Do we aim to clean this for 0.8?
> >
> > Juergen
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
|
|
From: <tri...@tr...> - 2003-05-23 11:26:58
|
Jürgen,
Yes, that is the scenario. Obtain the DataSource based on the JNDI name and
pass it in to the constructor for the JdbcTemplate or a class that extends
Mapping SqlQuery.
While we are on the subject of JDBC. Do we really have to require an explicit
compile for the RdbmsOperation and its subclasses. Currently we throw
InvalidDataAccessApiUsageException when we try to use an operation that has
not been comiled. We could just as easily execute the compile() at that
point, since we know what the problem is.
Thomas
> Good point indeed, using Spring JDBC without an ApplicationContext. I'll
> reintroduce a simple version of it, using a plain JndiTemplate. Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
>
> I assume that the typical scenario for this is somewhat like the following:
>
> DataSource ds = DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> JdbcTemplate jt = new JdbcTemplate(ds);
> jt.<doSomething>;
>
> Would that be enough? I'm not keen on introducing an additional JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will typically
> be kept somewhere anyway.
>
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, for
> maximum code reuse. We'll also have AbstractJndiLocator's "inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=false means plain JNDI name, the default inContainer=true means
> prefix "java:comp/env" if not already contained).
>
> Juergen
>
>
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; jürgen höller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>
>
> I agree with Thomas. Good point. At the moment I know of 2 companies using
> Spring JDBC only. If they have to do the JNDI stuff themselves it reduces
> the benefit.
>
> Rod
>
> ----- Original Message -----
> From: <tri...@tr...>
> To: "jürgen höller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>
>
> > Jürgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications
> that
> > only use the JDBC framework. Maybe we could change the way it does the
> lookup
> > to make it similar to the JndiObjectFactoryBean. What do you all think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config file for
> both
> > > web app and test environments. In the standalone access, we simply bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always looked
> up the
> > > given name under "java:comp/env", if not contained in the name. This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: jürgen höller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did make
> the
> > > code much harder to understand and the fewer lines of code, the fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core spring
> > > runtime. I don't tend to use our mock objects much anymore, since I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "jürgen höller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package (e.g.
> rethrow
> > > BeansException directly when catching Exception instead of wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged by the
> > > highest level exception handler anyway (-> no double stack traces in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after the
> > > exception's message, those lines have only added redundant information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO - you
> > > exactly see what handlers/mappings/etc get used, no need for binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, as
> they
> > > are pretty rough, and not really meant for usage within application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please test
> the
> > > current framework version in your apps! We should really try to release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification (Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in a
> > > relational database is painful, don't do it! Check out ObjectStore.
> > > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
>
>
>
|
|
From: Rod J. <rod...@in...> - 2003-05-23 17:54:04
|
> While we are on the subject of JDBC. Do we really have to require an explicit > compile for the RdbmsOperation and its subclasses. Currently we throw > InvalidDataAccessApiUsageException when we try to use an operation that has > not been comiled. We could just as easily execute the compile() at that > point, since we know what the problem is. Good question. I guess I was concerned about thread safety implications of compiling lazily. What do you think? Certainly there'd be a bonus in making the API slightly easier to use. Regards, Rod |
|
From: <tri...@tr...> - 2003-05-23 17:48:59
|
Rod, A JDO Query supports compile(), but if the Query is not compiled when execute() is called, then the Query is compiled automatically. I think we should provide the same functionality. I have to look closer at the code to determine if there are any threading issues we have to address. --Tomas > > While we are on the subject of JDBC. Do we really have to require an > explicit > > compile for the RdbmsOperation and its subclasses. Currently we throw > > InvalidDataAccessApiUsageException when we try to use an operation that > has > > not been comiled. We could just as easily execute the compile() at that > > point, since we know what the problem is. > > Good question. I guess I was concerned about thread safety implications of > compiling lazily. What do you think? > > Certainly there'd be a bonus in making the API slightly easier to use. > > Regards, > Rod > > > |
|
From: Rod J. <rod...@in...> - 2003-05-23 17:57:44
|
Sounds good. I didn't realise this about JDO. I doubt there are any specific threading issues: a race condition would just initialize (correctly) twice, I guess. Rod ----- Original Message ----- From: <tri...@tr...> To: "Rod Johnson" <rod...@in...> Cc: <spr...@li...> Sent: Friday, May 23, 2003 6:49 PM Subject: Re: [Springframework-developer] Code changes for 0.8? > Rod, > > A JDO Query supports compile(), but if the Query is not compiled when execute() > is called, then the Query is compiled automatically. I think we should provide > the same functionality. I have to look closer at the code to determine if there > are any threading issues we have to address. > > --Tomas > > > > While we are on the subject of JDBC. Do we really have to require an > > explicit > > > compile for the RdbmsOperation and its subclasses. Currently we throw > > > InvalidDataAccessApiUsageException when we try to use an operation that > > has > > > not been comiled. We could just as easily execute the compile() at that > > > point, since we know what the problem is. > > > > Good question. I guess I was concerned about thread safety implications of > > compiling lazily. What do you think? > > > > Certainly there'd be a bonus in making the API slightly easier to use. > > > > Regards, > > Rod > > > > > > > > > > |
|
From: William G. T. Jr. <wg...@ru...> - 2003-05-23 12:14:12
|
Rod, you can add a third org to the list of folks who are using Sprin=
g=20
JDBC without an ApplicationContext. We are using it with in conjucti=
on=20
with the open source uPortal framwork for channel (aka portlet) devel=
opment.
later.
Bill
j=FCrgen h=F6ller [werk3AT] wrote:
> Good point indeed, using Spring JDBC without an ApplicationContext.=
I'll reintroduce a simple version of it, using a plain JndiTemplate.=
Sometimes I'm a little over-eager in terms of simplification, sorry =
:-)
>=20
> I assume that the typical scenario for this is somewhat like the fo=
llowing:
>=20
> =09DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cb=
x");
> =09JdbcTemplate jt =3D new JdbcTemplate(ds);
> =09jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional Jdb=
cTemplate constructor with a DataSource NAME. The retrieved DataSourc=
e will typically be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocato=
r, for maximum code reuse. We'll also have AbstractJndiLocator's "inC=
ontainer" property then, to be able to control "java:comp/env" prefix=
ing (inContainer=3Dfalse means plain JNDI name, the default inContain=
er=3Dtrue means prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companie=
s using
> Spring JDBC only. If they have to do the JNDI stuff themselves it r=
educes
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
>=20
>>J=FCrgen,
>>
>>I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applic=
ations
>=20
> that
>=20
>>only use the JDBC framework. Maybe we could change the way it does=
the
>=20
> lookup
>=20
>>to make it similar to the JndiObjectFactoryBean. What do you all t=
hink?
>>
>>Thomas
>>
>>
>>>Regarding mock objects, I think that the JNDI mocks do have value =
for
>>>application developers: They can serve as JNDI replacement for
>=20
> applications
>=20
>>>test environments and standalone applications, running the same co=
de and
>>>config files as in the container environment.
>>>
>>>We are using this to be able to reuse the same Hibernate config fi=
le for
>=20
> both
>=20
>>>web app and test environments. In the standalone access, we simply=
bind
>=20
> a
>=20
>>>DriverManagerDataSource to the same JNDI location, with Spring's J=
NDI
>=20
> mocks
>=20
>>>as infrastructure.
>>>
>>>Other development projects can use this strategy too, and EasyMock=
won't
>=20
> help
>=20
>>>here. Thus, I'd like the JNDI mocks to stay, but all other mocks s=
hould
>=20
> not
>=20
>>>be in our src tree IMO, as they only serve within our test suites.
>>>
>>>Regarding FrameworkServlet's debug support, that were exactly the
>=20
> reasons why
>=20
>>>I've removed them. It cluttered up the code somewhat, and I don't
>=20
> consider it
>=20
>>>necessary.
>>>
>>>---
>>>
>>>I've just added one more refactoring: I've replaced both
>>>JndiDataSourceBean/JndiDataSourceEditor and
>>>JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
>=20
> implementations,
>=20
>>>namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, th=
e
>>>FactoryBeans have just returned Objects, so there's no need for
>=20
> specialized
>=20
>>>implementations. I've also removed DataSourceUtils.getDataSourceFr=
omJndi
>=20
> and
>=20
>>>SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
>=20
> recommended
>=20
>>>anymore. I don't like too many ways to achieve 1 thing.
>>>
>>>One more reason is that the former getDataSourceFromJndi always lo=
oked
>=20
> up the
>=20
>>>given name under "java:comp/env", if not contained in the name. Th=
is is
>=20
> too
>=20
>>>inflexible: A DataSource might be bound to any JNDI name, in fact.
>>>JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name=
: This
>=20
> is
>=20
>>>clearer and not much effort.
>>>
>>>So Isabelle and Ken, please use
>=20
> com.interface21.jndi.JndiObjectFactoryBean
>=20
>>>for DataSource definitions instead of
>>>com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
>>>change, but I think it's worth it.
>>>
>>>Gonna check all this stuff in the next hour...
>>>
>>>Regards,
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: Rod Johnson [mailto:rod...@in...]
>>>Sent: Thursday, May 22, 2003 6:24 PM
>>>To: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Subject: Re: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Excellent. Great news on the test coverage! You've been doing good=
work
>>>here.
>>>
>>>I'm glad you've cleaned up the stack traces... There were quite a =
few
>>>repeated stack traces a long time ago, and I got many of them (but
>=20
> obviously
>=20
>>>not all). I think the volume and quality of stack traces is very
>=20
> important.
>=20
>>>It's about the only thing that really bugs me with Hibernate 2.0 R=
C1,
>=20
> for
>=20
>>>example. We may need to consider a consistent approach to logging
>=20
> (levels
>=20
>>>etc.) for 0.9 or 1.0.
>>>
>>>I imagine removing debug support in framework servlet removed a lo=
t of
>=20
> code.
>=20
>>>I actually eyed it myself with my scalpel in mind recently. It did=
make
>=20
> the
>=20
>>>code much harder to understand and the fewer lines of code, the fe=
wer
>>>potential bugs. Also, I don't think it was documented anywhere, so=
I
>=20
> doubt
>=20
>>>anyone will miss it too much. (I did use it myself occasionally bu=
t I'm
>=20
> sure
>=20
>>>I can live without it.)
>>>
>>>I'm not sure that *any* mock objects should be in the main source =
tree.
>>>Maybe we need a third tree for the mocks and things like
>>>EjbContainerDetective that are handy but not part of the core spri=
ng
>>>runtime. I don't tend to use our mock objects much anymore, since =
I
>>>discovered the wonder that is EasyMock.
>>>
>>>Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
>>>stable release. We don't want to delay 0.8 for this.
>>>
>>>I'm away this weekend (bank holiday in the UK), so won't be doing =
any
>=20
> work.
>=20
>>>Anything I do add to Spring until we go to 0.8 will either be an u=
rgent
>=20
> bug
>=20
>>>fix or simply additional tests.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>>>To: <spr...@li...>
>>>Sent: Thursday, May 22, 2003 4:29 PM
>>>Subject: RE: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Besides having reworked the form controller's handling of resubmit=
s,
>=20
> I've
>=20
>>>also created an extensive test suite for ControllerServlet and som=
e web
>>>support classes. We're at overall >64% now!
>>>
>>>Additionally, I've refined some ApplicationContext stuff (moved
>>>OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationCo=
ntext
>>>etc), and cleaned the exception handling in the beans package (e.g=
.
>=20
> rethrow
>=20
>>>BeansException directly when catching Exception instead of wrappin=
g it).
>>>
>>>Rethrown exceptions don't get logged anymore, as they are logged b=
y the
>>>highest level exception handler anyway (-> no double stack traces =
in the
>>>console). I've also commented out the println(this) on printing a
>=20
> rootCause
>=20
>>>stack trace: As a root stack trace will always get printed after t=
he
>>>exception's message, those lines have only added redundant informa=
tion,
>>>cluttering the console.
>>>
>>>I've removed FrameworkServlet's debug support, I don't see any rea=
l use
>=20
> case
>=20
>>>for it. During development, Log4J's debug log is all you need, IMO=
- you
>>>exactly see what handlers/mappings/etc get used, no need for bindi=
ng
>=20
> them to
>=20
>>>the request.
>>>
>>>I'm also gonna move the web.mock classes back to the test sources,=
as
>=20
> they
>=20
>>>are pretty rough, and not really meant for usage within applicatio=
n
>>>development - in constrast to the JNDI mocks, for example.
>>>
>>>I'll check my stuff in within the next 2 hours. Everybody, please =
test
>=20
> the
>=20
>>>current framework version in your apps! We should really try to re=
lease
>=20
> a
>=20
>>>0.8 as stable as possible.
>>>
>>>BTW, what's the current status in terms of code beautification (Ja=
lopy
>=20
> etc)?
>=20
>>>We have mixed headers in our files at the moment, and sometimes
>=20
> inconsistent
>=20
>>>formatting. Do we aim to clean this for 0.8?
>>>
>>>Juergen
>>>
>>>
|
|
From: <rod...@in...> - 2003-05-23 11:20:30
|
>I'm not keen on introducing an additional JdbcTemplate constructor with a DataSource NAME. I agree. R |
|
From: <jue...@we...> - 2003-05-23 11:38:54
|
I've just committed the changes.
There's a DataSourceUtils.getDataSourceFromJndi(jndiName) method again, =
assuming running in a container (i.e. adding the prefix "java:comp/env/" =
if not already contained). An overloaded =
getDataSourceFromJndi(jndiName,inContainer) version allows for control =
of the prefixing.
JndiObjectFactoryBean is now a very simple subclass of =
AbstractJndiLocator, supporting the same properties: jndiTemplate, =
jndiName, inContainer. A DataSource definition can thus look as follows:
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">jdbc/myds</property>
</bean>
The following definition is equivalent:
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">java:comp/env/jdbc/myds</property>
</bean>
Or, when not running in a container (no implicit "java:comp/env/" =
prefix):
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">java:/myds</property>
<property name=3D"inContainer">false</property>
</bean>
Notice the "jndiName" property, instead of the former =
JndiDataSourceBean's "name".
Regards,
Juergen
-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Friday, May 23, 2003 1:27 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?
J=FCrgen,
Yes, that is the scenario. Obtain the DataSource based on the JNDI name =
and=20
pass it in to the constructor for the JdbcTemplate or a class that =
extends=20
Mapping SqlQuery.
While we are on the subject of JDBC. Do we really have to require an =
explicit=20
compile for the RdbmsOperation and its subclasses. Currently we throw =20
InvalidDataAccessApiUsageException when we try to use an operation that =
has=20
not been comiled. We could just as easily execute the compile() at that =
point, since we know what the problem is. =20
Thomas
> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
> reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the =
following:
>=20
> DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> JdbcTemplate jt =3D new JdbcTemplate(ds);
> jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will =
typically
> be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
> maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
> prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> > J=FCrgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
> that
> > only use the JDBC framework. Maybe we could change the way it does =
the
> lookup
> > to make it similar to the JndiObjectFactoryBean. What do you all =
think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same =
code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config =
file for
> both
> > > web app and test environments. In the standalone access, we simply =
bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock =
won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, =
the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always =
looked
> up the
> > > given name under "java:comp/env", if not contained in the name. =
This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: j=FCrgen h=F6ller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good =
work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a =
lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did =
make
> the
> > > code much harder to understand and the fewer lines of code, the =
fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so =
I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally =
but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source =
tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core =
spring
> > > runtime. I don't tend to use our mock objects much anymore, since =
I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of =
resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and =
some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package =
(e.g.
> rethrow
> > > BeansException directly when catching Exception instead of =
wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged =
by the
> > > highest level exception handler anyway (-> no double stack traces =
in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after =
the
> > > exception's message, those lines have only added redundant =
information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any =
real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO =
- you
> > > exactly see what handlers/mappings/etc get used, no need for =
binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, =
as
> they
> > > are pretty rough, and not really meant for usage within =
application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please =
test
> the
> > > current framework version in your apps! We should really try to =
release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification =
(Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in =
a
> > > relational database is painful, don't do it! Check out =
ObjectStore.
> > > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
>=20
>=20
>=20
|
|
From: Kopylenko, D. <dko...@ac...> - 2003-05-23 12:30:12
|
Hopefully the list will grow after the official release and good
docs/tutorials
D.
-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@ru...]
Sent: Friday, May 23, 2003 07:56 AM
To: "j=FCrgen h=F6ller [werk3AT]"
Cc: Rod Johnson; tri...@tr...;
spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?
Rod, you can add a third org to the list of folks who are using Spring=20
JDBC without an ApplicationContext. We are using it with in conjuction =
with the open source uPortal framwork for channel (aka portlet) =
development.
later.
Bill
j=FCrgen h=F6ller [werk3AT] wrote:
> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes
I'm a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the
following:
>=20
> DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> JdbcTemplate jt =3D new JdbcTemplate(ds);
> jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional
JdbcTemplate constructor with a DataSource NAME. The retrieved =
DataSource
will typically be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
maximum code reuse. We'll also have AbstractJndiLocator's "inContainer"
property then, to be able to control "java:comp/env" prefixing
(inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
>=20
>>J=FCrgen,
>>
>>I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
>=20
> that
>=20
>>only use the JDBC framework. Maybe we could change the way it does =
the
>=20
> lookup
>=20
>>to make it similar to the JndiObjectFactoryBean. What do you all =
think?
>>
>>Thomas
>>
>>
>>>Regarding mock objects, I think that the JNDI mocks do have value =
for
>>>application developers: They can serve as JNDI replacement for
>=20
> applications
>=20
>>>test environments and standalone applications, running the same code =
and
>>>config files as in the container environment.
>>>
>>>We are using this to be able to reuse the same Hibernate config file =
for
>=20
> both
>=20
>>>web app and test environments. In the standalone access, we simply =
bind
>=20
> a
>=20
>>>DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
>=20
> mocks
>=20
>>>as infrastructure.
>>>
>>>Other development projects can use this strategy too, and EasyMock =
won't
>=20
> help
>=20
>>>here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
>=20
> not
>=20
>>>be in our src tree IMO, as they only serve within our test suites.
>>>
>>>Regarding FrameworkServlet's debug support, that were exactly the
>=20
> reasons why
>=20
>>>I've removed them. It cluttered up the code somewhat, and I don't
>=20
> consider it
>=20
>>>necessary.
>>>
>>>---
>>>
>>>I've just added one more refactoring: I've replaced both
>>>JndiDataSourceBean/JndiDataSourceEditor and
>>>JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
>=20
> implementations,
>=20
>>>namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, the
>>>FactoryBeans have just returned Objects, so there's no need for
>=20
> specialized
>=20
>>>implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
>=20
> and
>=20
>>>SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
>=20
> recommended
>=20
>>>anymore. I don't like too many ways to achieve 1 thing.
>>>
>>>One more reason is that the former getDataSourceFromJndi always =
looked
>=20
> up the
>=20
>>>given name under "java:comp/env", if not contained in the name. This =
is
>=20
> too
>=20
>>>inflexible: A DataSource might be bound to any JNDI name, in fact.
>>>JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name: =
This
>=20
> is
>=20
>>>clearer and not much effort.
>>>
>>>So Isabelle and Ken, please use
>=20
> com.interface21.jndi.JndiObjectFactoryBean
>=20
>>>for DataSource definitions instead of
>>>com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
>>>change, but I think it's worth it.
>>>
>>>Gonna check all this stuff in the next hour...
>>>
>>>Regards,
>>>Juergen
>>>
>>>
>>>-----Original Message-----
>>>From: Rod Johnson [mailto:rod...@in...]
>>>Sent: Thursday, May 22, 2003 6:24 PM
>>>To: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Subject: Re: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Excellent. Great news on the test coverage! You've been doing good =
work
>>>here.
>>>
>>>I'm glad you've cleaned up the stack traces... There were quite a =
few
>>>repeated stack traces a long time ago, and I got many of them (but
>=20
> obviously
>=20
>>>not all). I think the volume and quality of stack traces is very
>=20
> important.
>=20
>>>It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
>=20
> for
>=20
>>>example. We may need to consider a consistent approach to logging
>=20
> (levels
>=20
>>>etc.) for 0.9 or 1.0.
>>>
>>>I imagine removing debug support in framework servlet removed a lot =
of
>=20
> code.
>=20
>>>I actually eyed it myself with my scalpel in mind recently. It did =
make
>=20
> the
>=20
>>>code much harder to understand and the fewer lines of code, the =
fewer
>>>potential bugs. Also, I don't think it was documented anywhere, so I
>=20
> doubt
>=20
>>>anyone will miss it too much. (I did use it myself occasionally but =
I'm
>=20
> sure
>=20
>>>I can live without it.)
>>>
>>>I'm not sure that *any* mock objects should be in the main source =
tree.
>>>Maybe we need a third tree for the mocks and things like
>>>EjbContainerDetective that are handy but not part of the core spring
>>>runtime. I don't tend to use our mock objects much anymore, since I
>>>discovered the wonder that is EasyMock.
>>>
>>>Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
>>>stable release. We don't want to delay 0.8 for this.
>>>
>>>I'm away this weekend (bank holiday in the UK), so won't be doing =
any
>=20
> work.
>=20
>>>Anything I do add to Spring until we go to 0.8 will either be an =
urgent
>=20
> bug
>=20
>>>fix or simply additional tests.
>>>
>>>Regards,
>>>Rod
>>>
>>>----- Original Message -----
>>>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>>>To: <spr...@li...>
>>>Sent: Thursday, May 22, 2003 4:29 PM
>>>Subject: RE: [Springframework-developer] Code changes for 0.8?
>>>
>>>
>>>Besides having reworked the form controller's handling of resubmits,
>=20
> I've
>=20
>>>also created an extensive test suite for ControllerServlet and some =
web
>>>support classes. We're at overall >64% now!
>>>
>>>Additionally, I've refined some ApplicationContext stuff (moved
>>>OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
>>>etc), and cleaned the exception handling in the beans package (e.g.
>=20
> rethrow
>=20
>>>BeansException directly when catching Exception instead of wrapping =
it).
>>>
>>>Rethrown exceptions don't get logged anymore, as they are logged by =
the
>>>highest level exception handler anyway (-> no double stack traces in =
the
>>>console). I've also commented out the println(this) on printing a
>=20
> rootCause
>=20
>>>stack trace: As a root stack trace will always get printed after the
>>>exception's message, those lines have only added redundant =
information,
>>>cluttering the console.
>>>
>>>I've removed FrameworkServlet's debug support, I don't see any real =
use
>=20
> case
>=20
>>>for it. During development, Log4J's debug log is all you need, IMO - =
you
>>>exactly see what handlers/mappings/etc get used, no need for binding
>=20
> them to
>=20
>>>the request.
>>>
>>>I'm also gonna move the web.mock classes back to the test sources, =
as
>=20
> they
>=20
>>>are pretty rough, and not really meant for usage within application
>>>development - in constrast to the JNDI mocks, for example.
>>>
>>>I'll check my stuff in within the next 2 hours. Everybody, please =
test
>=20
> the
>=20
>>>current framework version in your apps! We should really try to =
release
>=20
> a
>=20
>>>0.8 as stable as possible.
>>>
>>>BTW, what's the current status in terms of code beautification =
(Jalopy
>=20
> etc)?
>=20
>>>We have mixed headers in our files at the moment, and sometimes
>=20
> inconsistent
>=20
>>>formatting. Do we aim to clean this for 0.8?
>>>
>>>Juergen
>>>
>>>
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2003-05-23 14:44:57
|
BTW, I've also made AbstractBeanFactory support circular references =
(including proper tests). A bean can now reference another bean that in =
turn references the original one, all via beanRefs. A bean can even =
reference itself now.
Juergen
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, May 23, 2003 1:40 PM
To: tri...@tr...
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?
I've just committed the changes.
There's a DataSourceUtils.getDataSourceFromJndi(jndiName) method again, =
assuming running in a container (i.e. adding the prefix "java:comp/env/" =
if not already contained). An overloaded =
getDataSourceFromJndi(jndiName,inContainer) version allows for control =
of the prefixing.
JndiObjectFactoryBean is now a very simple subclass of =
AbstractJndiLocator, supporting the same properties: jndiTemplate, =
jndiName, inContainer. A DataSource definition can thus look as follows:
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">jdbc/myds</property>
</bean>
The following definition is equivalent:
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">java:comp/env/jdbc/myds</property>
</bean>
Or, when not running in a container (no implicit "java:comp/env/" =
prefix):
<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
<property name=3D"jndiName">java:/myds</property>
<property name=3D"inContainer">false</property>
</bean>
Notice the "jndiName" property, instead of the former =
JndiDataSourceBean's "name".
Regards,
Juergen
-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Friday, May 23, 2003 1:27 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?
J=FCrgen,
Yes, that is the scenario. Obtain the DataSource based on the JNDI name =
and=20
pass it in to the constructor for the JdbcTemplate or a class that =
extends=20
Mapping SqlQuery.
While we are on the subject of JDBC. Do we really have to require an =
explicit=20
compile for the RdbmsOperation and its subclasses. Currently we throw =20
InvalidDataAccessApiUsageException when we try to use an operation that =
has=20
not been comiled. We could just as easily execute the compile() at that =
point, since we know what the problem is. =20
Thomas
> Good point indeed, using Spring JDBC without an ApplicationContext. =
I'll
> reintroduce a simple version of it, using a plain JndiTemplate. =
Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
>=20
> I assume that the typical scenario for this is somewhat like the =
following:
>=20
> DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> JdbcTemplate jt =3D new JdbcTemplate(ds);
> jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional =
JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will =
typically
> be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, =
for
> maximum code reuse. We'll also have AbstractJndiLocator's =
"inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
> prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> I agree with Thomas. Good point. At the moment I know of 2 companies =
using
> Spring JDBC only. If they have to do the JNDI stuff themselves it =
reduces
> the benefit.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> Cc: "Rod Johnson" <rod...@in...>;
> <spr...@li...>
> Sent: Friday, May 23, 2003 2:06 AM
> Subject: RE: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> > J=FCrgen,
> >
> > I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for =
applications
> that
> > only use the JDBC framework. Maybe we could change the way it does =
the
> lookup
> > to make it similar to the JndiObjectFactoryBean. What do you all =
think?
> >
> > Thomas
> >
> > > Regarding mock objects, I think that the JNDI mocks do have value =
for
> > > application developers: They can serve as JNDI replacement for
> applications
> > > test environments and standalone applications, running the same =
code and
> > > config files as in the container environment.
> > >
> > > We are using this to be able to reuse the same Hibernate config =
file for
> both
> > > web app and test environments. In the standalone access, we simply =
bind
> a
> > > DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI
> mocks
> > > as infrastructure.
> > >
> > > Other development projects can use this strategy too, and EasyMock =
won't
> help
> > > here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should
> not
> > > be in our src tree IMO, as they only serve within our test suites.
> > >
> > > Regarding FrameworkServlet's debug support, that were exactly the
> reasons why
> > > I've removed them. It cluttered up the code somewhat, and I don't
> consider it
> > > necessary.
> > >
> > > ---
> > >
> > > I've just added one more refactoring: I've replaced both
> > > JndiDataSourceBean/JndiDataSourceEditor and
> > > JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
> implementations,
> > > namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, =
the
> > > FactoryBeans have just returned Objects, so there's no need for
> specialized
> > > implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi
> and
> > > SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
> recommended
> > > anymore. I don't like too many ways to achieve 1 thing.
> > >
> > > One more reason is that the former getDataSourceFromJndi always =
looked
> up the
> > > given name under "java:comp/env", if not contained in the name. =
This is
> too
> > > inflexible: A DataSource might be bound to any JNDI name, in fact.
> > > JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This
> is
> > > clearer and not much effort.
> > >
> > > So Isabelle and Ken, please use
> com.interface21.jndi.JndiObjectFactoryBean
> > > for DataSource definitions instead of
> > > com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for the =
late
> > > change, but I think it's worth it.
> > >
> > > Gonna check all this stuff in the next hour...
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > > -----Original Message-----
> > > From: Rod Johnson [mailto:rod...@in...]
> > > Sent: Thursday, May 22, 2003 6:24 PM
> > > To: j=FCrgen h=F6ller [werk3AT]
> > > Cc: spr...@li...
> > > Subject: Re: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Excellent. Great news on the test coverage! You've been doing good =
work
> > > here.
> > >
> > > I'm glad you've cleaned up the stack traces... There were quite a =
few
> > > repeated stack traces a long time ago, and I got many of them (but
> obviously
> > > not all). I think the volume and quality of stack traces is very
> important.
> > > It's about the only thing that really bugs me with Hibernate 2.0 =
RC1,
> for
> > > example. We may need to consider a consistent approach to logging
> (levels
> > > etc.) for 0.9 or 1.0.
> > >
> > > I imagine removing debug support in framework servlet removed a =
lot of
> code.
> > > I actually eyed it myself with my scalpel in mind recently. It did =
make
> the
> > > code much harder to understand and the fewer lines of code, the =
fewer
> > > potential bugs. Also, I don't think it was documented anywhere, so =
I
> doubt
> > > anyone will miss it too much. (I did use it myself occasionally =
but I'm
> sure
> > > I can live without it.)
> > >
> > > I'm not sure that *any* mock objects should be in the main source =
tree.
> > > Maybe we need a third tree for the mocks and things like
> > > EjbContainerDetective that are handy but not part of the core =
spring
> > > runtime. I don't tend to use our mock objects much anymore, since =
I
> > > discovered the wonder that is EasyMock.
> > >
> > > Code formatting I think is a 0.9 thing. Certainly after we have a =
tagged
> > > stable release. We don't want to delay 0.8 for this.
> > >
> > > I'm away this weekend (bank holiday in the UK), so won't be doing =
any
> work.
> > > Anything I do add to Spring until we go to 0.8 will either be an =
urgent
> bug
> > > fix or simply additional tests.
> > >
> > > Regards,
> > > Rod
> > >
> > > ----- Original Message -----
> > > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> > > To: <spr...@li...>
> > > Sent: Thursday, May 22, 2003 4:29 PM
> > > Subject: RE: [Springframework-developer] Code changes for 0.8?
> > >
> > >
> > > Besides having reworked the form controller's handling of =
resubmits,
> I've
> > > also created an extensive test suite for ControllerServlet and =
some web
> > > support classes. We're at overall >64% now!
> > >
> > > Additionally, I've refined some ApplicationContext stuff (moved
> > > OPTIONS_BEAN_NAME from ApplicationContext to =
AbstractApplicationContext
> > > etc), and cleaned the exception handling in the beans package =
(e.g.
> rethrow
> > > BeansException directly when catching Exception instead of =
wrapping it).
> > >
> > > Rethrown exceptions don't get logged anymore, as they are logged =
by the
> > > highest level exception handler anyway (-> no double stack traces =
in the
> > > console). I've also commented out the println(this) on printing a
> rootCause
> > > stack trace: As a root stack trace will always get printed after =
the
> > > exception's message, those lines have only added redundant =
information,
> > > cluttering the console.
> > >
> > > I've removed FrameworkServlet's debug support, I don't see any =
real use
> case
> > > for it. During development, Log4J's debug log is all you need, IMO =
- you
> > > exactly see what handlers/mappings/etc get used, no need for =
binding
> them to
> > > the request.
> > >
> > > I'm also gonna move the web.mock classes back to the test sources, =
as
> they
> > > are pretty rough, and not really meant for usage within =
application
> > > development - in constrast to the JNDI mocks, for example.
> > >
> > > I'll check my stuff in within the next 2 hours. Everybody, please =
test
> the
> > > current framework version in your apps! We should really try to =
release
> a
> > > 0.8 as stable as possible.
> > >
> > > BTW, what's the current status in terms of code beautification =
(Jalopy
> etc)?
> > > We have mixed headers in our files at the moment, and sometimes
> inconsistent
> > > formatting. Do we aim to clean this for 0.8?
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in =
a
> > > relational database is painful, don't do it! Check out =
ObjectStore.
> > > Now part of Progress Software. =
http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
>=20
>=20
>=20
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
