You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rod J. <rod...@in...> - 2004-02-06 07:21:45
|
XXXXOperations is fine by me. I agree, IXXXX isn't ideal. ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, February 05, 2004 4:44 PM Subject: [Springframework-developer] IJdbcTemplate / IHibernateTemplate / ISqlMapTemplate Everybody, Due to a recent request, I've just extracted IHibernateTemplate and ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod introduce= d a while ago. They are intended to ease mocking for unit-testing DAOs, for those who want to mock at this level. For typical DAO implementations, th= e standard template classes are good enough, allowing for mocks of the underlying persistence tool and live tests against a database. However, I wonder about the naming. We don't have the I* pattern anywhere else in the framework; on the other hand, we need to keep the old templat= e names for compatibility (and some templates don't lend themselves for suc= h an interface, like JdoTemplate). IHibernateTemplate etc doesn't worry me, but maybe a different name like HibernateOperations would be better? Essentially, those interfaces specify a set of data access operations for= a particular persistence tool. The naming isn't too important, though, as it will not be the main API th= at people will work with; the template classes will be. We'll just let the templates implement those operation interfaces to allow for mocking them = if desired. BTW, iBATIS SQL Maps is all based on concrete classes rather tha= n interfaces, not allowing to mock the persistence tool itself. Juergen ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Kopylenko, D. <dko...@ac...> - 2004-02-05 20:07:45
|
Well, same story here :-) I emailed Alef a he pointed out to the README = file :-) Dmitriy. -----Original Message----- From: tri...@tr... [mailto:tri...@tr...]=20 Sent: Thursday, February 05, 2004 2:38 PM To: spr...@li... Subject: Re: [Springframework-developer] [PATCH] doc/reference/src/validation.xml Juergen, I did the same thing a few weeks ago, except I started searching the = web and downloading the libraries that the build complained about. After a few attempts I figured there had to be a better way, and I reluctantly = opened up the README file. Thomas Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>: > I should have done my homework, I guess... Argh, laziness is an ugly=20 > trait > ;-) > =20 > Juergen > =20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag = > von Alef Arendsen > Gesendet: Do 05.02.2004 18:46 > An: spr...@li... > Betreff: RE: [Springframework-developer] [PATCH]=20 > doc/reference/src/validation.xml >=20 >=20 >=20 > There's a README file in the docs/reference directory. You need to=20 > download a set of libraries. Due the size of those libraries (about 6 = > or 7 mb) I didn't import it. >=20 > The url: http://www.jteam.nl/spring/reference-libraries.zip >=20 > The lib directory (the readme mentioned a lib directory that has to = be=20 > created, but this is wrong, it's already included in the zipfile). >=20 > Alef >=20 >=20 > > -----Original Message----- > > From: spr...@li... > > [mailto:spr...@li...] On=20 > > Behalf Of j=FCrgen h=F6ller [werk3AT] > > Sent: Thursday, February 05, 2004 6:20 PM > > To: spr...@li... > > Subject: Re: [Springframework-developer] [PATCH]=20 > > doc/reference/src/validation.xml > > > > Can someone enlighten me on how to build the reference doc PDF = file?=20 > > The Ant task complains about "docs/reference/lib" not being = found... > > > > Juergen > > > > > > ________________________________ > > > > Von: spr...@li... im=20 > > Auftrag von Francois Beausoleil > > Gesendet: Do 05.02.2004 15:32 > > An: spr...@li... > > Betreff: [Springframework-developer] [PATCH]=20 > > doc/reference/src/validation.xml > > > > > > > > Hi ! > > > > Another proofread patch. > > > > Log message: > > [[[ > > * doc/reference/src/validation.xml: > > Multiple spelling corrections, and contractions removal. ]]] > > Developer of Java Gui Builder > > http://jgb.sourceforge.net/ > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > = https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > = https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tri...@tr...> - 2004-02-05 19:38:11
|
Juergen, I did the same thing a few weeks ago, except I started searching the web and downloading the libraries that the build complained about. After a few attempts I figured there had to be a better way, and I reluctantly opened up the README file. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > I should have done my homework, I guess... Argh, laziness is an ugly trait > ;-) > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag von > Alef Arendsen > Gesendet: Do 05.02.2004 18:46 > An: spr...@li... > Betreff: RE: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml > > > > There's a README file in the docs/reference directory. You need to download > a set of libraries. Due the size of those libraries (about 6 or 7 mb) I > didn't import it. > > The url: http://www.jteam.nl/spring/reference-libraries.zip > > The lib directory (the readme mentioned a lib directory that has to be > created, but this is wrong, it's already included in the zipfile). > > Alef > > > > -----Original Message----- > > From: spr...@li... > > [mailto:spr...@li...] On Behalf > > Of jürgen höller [werk3AT] > > Sent: Thursday, February 05, 2004 6:20 PM > > To: spr...@li... > > Subject: Re: [Springframework-developer] [PATCH] > > doc/reference/src/validation.xml > > > > Can someone enlighten me on how to build the reference doc PDF file? The > > Ant task complains about "docs/reference/lib" not being found... > > > > Juergen > > > > > > ________________________________ > > > > Von: spr...@li... im Auftrag von > > Francois Beausoleil > > Gesendet: Do 05.02.2004 15:32 > > An: spr...@li... > > Betreff: [Springframework-developer] [PATCH] > > doc/reference/src/validation.xml > > > > > > > > Hi ! > > > > Another proofread patch. > > > > Log message: > > [[[ > > * doc/reference/src/validation.xml: > > Multiple spelling corrections, and contractions removal. > > ]]] > > Developer of Java Gui Builder > > http://jgb.sourceforge.net/ > > > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-02-05 19:06:18
|
Thanks, this has been applied Francois Beausoleil wrote: >Hi ! > >Another proofread patch. > >Log message: >[[[ >* doc/reference/src/validation.xml: > Multiple spelling corrections, and contractions removal. >]]] >Developer of Java Gui Builder >http://jgb.sourceforge.net/ > > |
|
From: Kopylenko, D. <dko...@ac...> - 2004-02-05 18:55:23
|
Juergen, I wouldn't say that with your __crazy__ schedule :-))=20 -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20 Sent: Thursday, February 05, 2004 1:48 PM To: spr...@li... Subject: Re: [Springframework-developer] [PATCH] doc/reference/src/validation.xml I should have done my homework, I guess... Argh, laziness is an ugly = trait ;-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Alef Arendsen Gesendet: Do 05.02.2004 18:46 An: spr...@li... Betreff: RE: [Springframework-developer] [PATCH] doc/reference/src/validation.xml There's a README file in the docs/reference directory. You need to = download a set of libraries. Due the size of those libraries (about 6 or 7 mb) I didn't import it. The url: http://www.jteam.nl/spring/reference-libraries.zip The lib directory (the readme mentioned a lib directory that has to be created, but this is wrong, it's already included in the zipfile). Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On=20 > Behalf Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, February 05, 2004 6:20 PM > To: spr...@li... > Subject: Re: [Springframework-developer] [PATCH]=20 > doc/reference/src/validation.xml > > Can someone enlighten me on how to build the reference doc PDF file?=20 > The Ant task complains about "docs/reference/lib" not being found... > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag = > von Francois Beausoleil > Gesendet: Do 05.02.2004 15:32 > An: spr...@li... > Betreff: [Springframework-developer] [PATCH]=20 > doc/reference/src/validation.xml > > > > Hi ! > > Another proofread patch. > > Log message: > [[[ > * doc/reference/src/validation.xml: > Multiple spelling corrections, and contractions removal. ]]] > Developer of Java Gui Builder > http://jgb.sourceforge.net/ > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > = https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-02-05 18:49:45
|
I should have done my homework, I guess... Argh, laziness is an ugly = trait ;-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Alef Arendsen Gesendet: Do 05.02.2004 18:46 An: spr...@li... Betreff: RE: [Springframework-developer] [PATCH] = doc/reference/src/validation.xml There's a README file in the docs/reference directory. You need to = download a set of libraries. Due the size of those libraries (about 6 or 7 mb) I didn't import it. The url: http://www.jteam.nl/spring/reference-libraries.zip The lib directory (the readme mentioned a lib directory that has to be created, but this is wrong, it's already included in the zipfile). Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, February 05, 2004 6:20 PM > To: spr...@li... > Subject: Re: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml > > Can someone enlighten me on how to build the reference doc PDF file? = The > Ant task complains about "docs/reference/lib" not being found... > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag = von > Francois Beausoleil > Gesendet: Do 05.02.2004 15:32 > An: spr...@li... > Betreff: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml > > > > Hi ! > > Another proofread patch. > > Log message: > [[[ > * doc/reference/src/validation.xml: > Multiple spelling corrections, and contractions removal. > ]]] > Developer of Java Gui Builder > http://jgb.sourceforge.net/ > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rob B. <rob...@ve...> - 2004-02-05 18:41:35
|
As someone points out in this thread http://www.theserverside.com/news/thread.jsp?thread_id=23749 using data binding for web request parameters potentially allows for unintentional "sets" on an object. I recommend Springs request binding code be enhanced to safegaurd this vulnerability. Update DataBinder to have two new sets of methods: public void setAllowedFields(String[]); public String [] getAllowedFields(); public void setDisallowedFields(String []); public String [] getDisallowedFields(); Optionally, modify the bind method to return a boolean. bind(..) returns true if an attempt was made to call a setter which was not allowed. Then implement the following logic. if allowedFields == null && disallowedFields == null Do processing as spring does now. if allowedFields != null && disallowedFields == null Only call setters for allowed fields. Attempts to call setter on a non-allowed field cause bind(...) to return true if allowedFields != null && disallowedFields != null only call setters for allowedFields, and not for disallowedFields attempts to call setter on a non-allowed field cause bind(...) to return true - alternate throw exception as allowedFields & disallowedFields cannot both be used if allowedFields == null && disallowedFields != null call setters for any parameter except those disallowed. attempts to call setter on a disallowed fields cause bind(...) to return true The purpose of having bind(...) return true is that we may want to let the request succeed (thus can't throw exception), but to log information about the request (remote IP, username, all request parameters, etc.) to use in analysis later to determine if someone was attempting to hack the application. Other code (like ServletRequestDataBinder) should be modified to expose these new capabilities. For example, change (or add another) constructor to ServletRequestDataBinder which has a parameter list like (Object target, String name, String[] required, String[] allowed, String[] disallowed) and have its bind method return a boolean too. Later Rob |
|
From: <tri...@tr...> - 2004-02-05 18:07:42
|
From the docs\reference\Readme: To generate documentation, you need to include a lot of libraries, which haven't been added to CVS because they're simply too big. The libraries can be found at: http://www.jteam.nl/spring/reference-libraries.zip. Download them, create a lib directory in the docs/reference directory and unzip the zip there. Then, the targets should work. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > Can someone enlighten me on how to build the reference doc PDF file? The Ant > task complains about "docs/reference/lib" not being found... > > Juergen > > > ________________________________ > > Von: spr...@li... im Auftrag von > Francois Beausoleil > Gesendet: Do 05.02.2004 15:32 > An: spr...@li... > Betreff: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml > > > > Hi ! > > Another proofread patch. > > Log message: > [[[ > * doc/reference/src/validation.xml: > Multiple spelling corrections, and contractions removal. > ]]] > Developer of Java Gui Builder > http://jgb.sourceforge.net/ > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Alef A. <al...@jt...> - 2004-02-05 17:44:03
|
There's a README file in the docs/reference directory. You need to = download a set of libraries. Due the size of those libraries (about 6 or 7 mb) I didn't import it. The url: http://www.jteam.nl/spring/reference-libraries.zip The lib directory (the readme mentioned a lib directory that has to be created, but this is wrong, it's already included in the zipfile). Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Thursday, February 05, 2004 6:20 PM > To: spr...@li... > Subject: Re: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml >=20 > Can someone enlighten me on how to build the reference doc PDF file? = The > Ant task complains about "docs/reference/lib" not being found... >=20 > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag = von > Francois Beausoleil > Gesendet: Do 05.02.2004 15:32 > An: spr...@li... > Betreff: [Springframework-developer] [PATCH] > doc/reference/src/validation.xml >=20 >=20 >=20 > Hi ! >=20 > Another proofread patch. >=20 > Log message: > [[[ > * doc/reference/src/validation.xml: > Multiple spelling corrections, and contractions removal. > ]]] > Developer of Java Gui Builder > http://jgb.sourceforge.net/ >=20 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tri...@tr...> - 2004-02-05 17:37:37
|
I don't like the IXxxxx naming either, and it is inconsistent with other Spring interfaces/implementations. I vote for a name change of the interface classes to either JdbcInterface/HibernateInterface/SqlMapInterface or as you suggested JdbcOperations/HibernateOperations/SqlMapOperations. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > Everybody, > > Due to a recent request, I've just extracted IHibernateTemplate and > ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod introduced a > while ago. They are intended to ease mocking for unit-testing DAOs, for those > who want to mock at this level. For typical DAO implementations, the standard > template classes are good enough, allowing for mocks of the underlying > persistence tool and live tests against a database. > > However, I wonder about the naming. We don't have the I* pattern anywhere > else in the framework; on the other hand, we need to keep the old template > names for compatibility (and some templates don't lend themselves for such an > interface, like JdoTemplate). IHibernateTemplate etc doesn't worry me, but > maybe a different name like HibernateOperations would be better? Essentially, > those interfaces specify a set of data access operations for a particular > persistence tool. > > The naming isn't too important, though, as it will not be the main API that > people will work with; the template classes will be. We'll just let the > templates implement those operation interfaces to allow for mocking them if > desired. BTW, iBATIS SQL Maps is all based on concrete classes rather than > interfaces, not allowing to mock the persistence tool itself. > > Juergen > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-02-05 17:37:17
|
I used to start my interface names with I, but a year or two ago stopped=20 when I realized that in fact I was almost always working against the=20 interfaces anyways, so it was silly to always have the prefix there (now=20 I generally add 'Impl' to the end of the implementation object, if there=20 is only one variant). The I prefix is not going to be pretty here where most of our other=20 interfaces don't have it, but on the other hand, I don't like interface=20 names which seem to have no relation to the impl. objects either... I=20 would probably leave them as Ixxxx and add a note to the javadoc that it=20 is that way for historical reasons, as opposed to having a totally=20 different interface and impl name... Kopylenko, Dmitry wrote: >I'm not a big fan of Ixxx naming pattern for interfaces. +1 for renaming >them to something else. > >Dmitriy. > >-----Original Message----- >From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20 >Sent: Thursday, February 05, 2004 11:45 AM >To: spr...@li... >Subject: [Springframework-developer] IJdbcTemplate / IHibernateTemplate = / >ISqlMapTemplate > > >Everybody, >=20 >Due to a recent request, I've just extracted IHibernateTemplate and >ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod introduc= ed a >while ago. They are intended to ease mocking for unit-testing DAOs, for >those who want to mock at this level. For typical DAO implementations, t= he >standard template classes are good enough, allowing for mocks of the >underlying persistence tool and live tests against a database. >=20 >However, I wonder about the naming. We don't have the I* pattern anywher= e >else in the framework; on the other hand, we need to keep the old templa= te >names for compatibility (and some templates don't lend themselves for su= ch >an interface, like JdoTemplate). IHibernateTemplate etc doesn't worry me= , >but maybe a different name like HibernateOperations would be better? >Essentially, those interfaces specify a set of data access operations fo= r a >particular persistence tool. >=20 >The naming isn't too important, though, as it will not be the main API t= hat >people will work with; the template classes will be. We'll just let the >templates implement those operation interfaces to allow for mocking them= if >desired. BTW, iBATIS SQL Maps is all based on concrete classes rather th= an >interfaces, not allowing to mock the persistence tool itself. >=20 >Juergen >=20 > |
|
From: <jue...@we...> - 2004-02-05 17:21:47
|
Can someone enlighten me on how to build the reference doc PDF file? The = Ant task complains about "docs/reference/lib" not being found... =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Francois Beausoleil Gesendet: Do 05.02.2004 15:32 An: spr...@li... Betreff: [Springframework-developer] [PATCH] = doc/reference/src/validation.xml Hi ! Another proofread patch. Log message: [[[ * doc/reference/src/validation.xml: Multiple spelling corrections, and contractions removal. ]]] Developer of Java Gui Builder http://jgb.sourceforge.net/ |
|
From: Kopylenko, D. <dko...@ac...> - 2004-02-05 16:50:38
|
I'm not a big fan of Ixxx naming pattern for interfaces. +1 for = renaming them to something else. Dmitriy. -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20 Sent: Thursday, February 05, 2004 11:45 AM To: spr...@li... Subject: [Springframework-developer] IJdbcTemplate / IHibernateTemplate = / ISqlMapTemplate Everybody, =20 Due to a recent request, I've just extracted IHibernateTemplate and ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod = introduced a while ago. They are intended to ease mocking for unit-testing DAOs, for those who want to mock at this level. For typical DAO implementations, = the standard template classes are good enough, allowing for mocks of the underlying persistence tool and live tests against a database. =20 However, I wonder about the naming. We don't have the I* pattern = anywhere else in the framework; on the other hand, we need to keep the old = template names for compatibility (and some templates don't lend themselves for = such an interface, like JdoTemplate). IHibernateTemplate etc doesn't worry = me, but maybe a different name like HibernateOperations would be better? Essentially, those interfaces specify a set of data access operations = for a particular persistence tool. =20 The naming isn't too important, though, as it will not be the main API = that people will work with; the template classes will be. We'll just let the templates implement those operation interfaces to allow for mocking = them if desired. BTW, iBATIS SQL Maps is all based on concrete classes rather = than interfaces, not allowing to mock the persistence tool itself. =20 Juergen =20 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-02-05 16:45:20
|
Everybody, =20 Due to a recent request, I've just extracted IHibernateTemplate and = ISqlMapTemplate interfaces, analogous to IJdbcTemplate that Rod = introduced a while ago. They are intended to ease mocking for = unit-testing DAOs, for those who want to mock at this level. For typical = DAO implementations, the standard template classes are good enough, = allowing for mocks of the underlying persistence tool and live tests = against a database. =20 However, I wonder about the naming. We don't have the I* pattern = anywhere else in the framework; on the other hand, we need to keep the = old template names for compatibility (and some templates don't lend = themselves for such an interface, like JdoTemplate). IHibernateTemplate = etc doesn't worry me, but maybe a different name like = HibernateOperations would be better? Essentially, those interfaces = specify a set of data access operations for a particular persistence = tool. =20 The naming isn't too important, though, as it will not be the main API = that people will work with; the template classes will be. We'll just let = the templates implement those operation interfaces to allow for mocking = them if desired. BTW, iBATIS SQL Maps is all based on concrete classes = rather than interfaces, not allowing to mock the persistence tool = itself. =20 Juergen =20 |
|
From: Francois B. <fb...@us...> - 2004-02-05 15:02:40
|
Hi, Another patch, against CVS HEAD, as of 8:30 AM EST. [[[ * doc/reference/src/aop.xml: Multiple textual corrections-duplicated words, wrong or dubious usage of words, spelling mistakes, etc. Replaced decimal entity references 34 and 39 with their corresponding character. This makes it easier to read and edit the text. Created CDATA sections for all examples, as this eases the editing process. ]]] Have a nice day ! Fran=E7ois Developer of Java Gui Builder http://jgb.sourceforge.net/ |
|
From: Francois B. <fb...@us...> - 2004-02-05 14:32:11
|
Hi ! Another proofread patch. Log message: [[[ * doc/reference/src/validation.xml: Multiple spelling corrections, and contractions removal. ]]] Developer of Java Gui Builder http://jgb.sourceforge.net/ |
|
From: Francois B. <fb...@us...> - 2004-02-05 12:49:00
|
On Thu, 5 Feb 2004 08:30:55 -0000 (GMT), "Darren Davison" <da...@da...> said: >=20 > > I will go on with the other chapters as time permits. >=20 > Fran=E7ois, are you creating your patches against the CVS versions of the Yup ! In fact, I just updated my CVS WC, and CVS told me it merged 1.6 and 1.7 of beans.xml :) Bye ! Fran=E7ois Developer of Java Gui Builder http://jgb.sourceforge.net/ |
|
From: Colin S. <col...@ex...> - 2004-02-05 12:38:48
|
There _is_ actually a pretty big use case for this, supporting existing code which wants to use this type of mechanism. For example, we currently use OSWorkflow with the EJB implementation. We want to move to the Hibernate workflow store, but would have to create our own Spring-based transactional workflow to wrap around that. This needs to support a setRollbackOnly mechanism, same as the existing impl. (based on ejb), and the caller doesn't expect an exception at that point, so it's not like the impl. could just throw an exception. Anyways, we can just use the status off the template, so that's fine, but other people might do the same thing as Alef (try to work off the transactionmanager). I got confused myself; when I was looking at the impl. last night I saw for a few of the propogation cases (not supported, and new) that it created a new status and suspended the existing trans., but I figured for the null case with the default definition object being created, and joining in the existing transaction, with no new synchronization, that he was ok. Of course that doesn't make any sense, there is a whole new status object being created... We should probably change the javadocs for PlatformTransactionManager to clarify that getTransaction is not for this use case... jürgen höller [werk3AT] wrote: >Alef, > >What you're doing here is getting a *new* TransactionStatus for a new sub-transaction back: A sub-transaction needs to be committed or rollbacked (via mgr.commit/rollback) to be effective. > >What you intend is to mark the *current* TransactionStatus rollback-only: with TransactionTemplate, you can use the passed-in TransactionStatus; with AOP, TransactionInterceptor.currentTransactionStatus(). > >In general, I see hardly any use cases for rolling back without throwing an exception anyway. If you want to roll back on checked exception, simply specify those in the transaction attributes, e.g. "-MyCheckedException". > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Alef Arendsen >Gesendet: Do 05.02.2004 00:27 >An: spr...@li... >Betreff: RE: [Springframework-developer] Ready for 1.0 RC1 > > > >There's an issue that just came up with the TransactionManager. I >haven't spend enough time on it to fully figure it out, but before I dig >into it further, maybe you guys can give an opinion: > >When using a DataSourceTransactionManager, in a bean I'm asking the >applicationcontext for the transactionmanager. After calling >setRollbackOnly() is doesn't rollback. I've reproduced this using >petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic >and in one of the store*** methods calling: > >PlatformTransactionManager mgr = > (PlatformTransactionManager)appCtx.getBean( > "transactionManager"); >// does this give me the current transaction??? >mgr.getTransaction(null).setRollbackOnly(); > >AFAIK this should result in a rollback, shouldn't it... > >Thanx, > >Alef > >P.s. we're doing this because of some legacy code that needs to rollback >as well. We can't reimplement it right now... > > |
|
From: Colin S. <col...@ex...> - 2004-02-05 12:21:09
|
His patch was against CVS. It applied cleanly... Darren Davison wrote: >>I will go on with the other chapters as time permits. >> >> > >François, are you creating your patches against the CVS versions of the >files? Quite a few updates are in CVS that are not in the docs on the >website. > >Regards, > > > |
|
From: <rod...@in...> - 2004-02-05 09:10:57
|
>In general, I see hardly any use cases for rolling back without throwing an exception anyway. If you want to roll back on checked exception, simply specify those in the transaction attributes, e.g. "-MyCheckedException". +1. This is important for non-invasiveness. You want to try avoid depending on Spring tx api if you can. With Spring rollback rules you can avoid such dependence; with EJB CMT you can't. |
|
From: Darren D. <da...@da...> - 2004-02-05 08:31:05
|
> I will go on with the other chapters as time permits. Fran=E7ois, are you creating your patches against the CVS versions of the files? Quite a few updates are in CVS that are not in the docs on the website. Regards, --=20 Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: <jue...@we...> - 2004-02-05 07:54:52
|
Alef,
=20
What you're doing here is getting a *new* TransactionStatus for a new =
sub-transaction back: A sub-transaction needs to be committed or =
rollbacked (via mgr.commit/rollback) to be effective.
=20
What you intend is to mark the *current* TransactionStatus =
rollback-only: with TransactionTemplate, you can use the passed-in =
TransactionStatus; with AOP, =
TransactionInterceptor.currentTransactionStatus().
=20
In general, I see hardly any use cases for rolling back without throwing =
an exception anyway. If you want to roll back on checked exception, =
simply specify those in the transaction attributes, e.g. =
"-MyCheckedException".
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Alef Arendsen
Gesendet: Do 05.02.2004 00:27
An: spr...@li...
Betreff: RE: [Springframework-developer] Ready for 1.0 RC1
There's an issue that just came up with the TransactionManager. I
haven't spend enough time on it to fully figure it out, but before I dig
into it further, maybe you guys can give an opinion:
When using a DataSourceTransactionManager, in a bean I'm asking the
applicationcontext for the transactionmanager. After calling
setRollbackOnly() is doesn't rollback. I've reproduced this using
petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic
and in one of the store*** methods calling:
PlatformTransactionManager mgr =3D
(PlatformTransactionManager)appCtx.getBean(
"transactionManager");
// does this give me the current transaction???
mgr.getTransaction(null).setRollbackOnly();
AFAIK this should result in a rollback, shouldn't it...
Thanx,
Alef
P.s. we're doing this because of some legacy code that needs to rollback
as well. We can't reimplement it right now...
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-02-05 04:46:36
|
Thanks Francois, this is much appreciated. I have applied the patch. Francois Beausoleil wrote: >Hi ! > >I did a proofread of the first few chapters. I did introduction, >background and beans. > >I have attached a patch with corrections for the beans.xml file. Accept >or reject as you see fit :) There are a few misspellings corrections, >some rewordings, and a correction to the destroy method example. I have >not reviewed the "BeanFactory structure and implementations" >(#beans-factoryimpl) section. The comment says it needs a rewrite, so I >did not spend time on it. > >Log message follows: >[[[ >* docs/reference/src/beans.xml: > Patch by Francois Beausoleil (fb...@us...). > > Corrects spelling mistakes, rewords some sentences, and > corrects the destroy method example. > > The example was copied from the init example, and it > defined the destroy method as init, clearly a cut'n'paste > error. Also changed the destroy method name to something > that didn't look like we implement DisposableBean. >]]] > >I will go on with the other chapters as time permits. > >Sorry for the attachment instead of inlining the patch, but my mailer >*will* wrap long lines, and the beans.xml file has long lines, so the >patch would have been "dead-on-arrival". I preferred to avoid that. > >I used the cvs unified diff format, created on Windows. > >Bye ! >François Beausoleil >Developer of Java Gui Builder >http://jgb.sourceforge.net/ > |
|
From: Colin S. <col...@ex...> - 2004-02-05 00:09:00
|
The current transaction is just attached to the Thread via the DataSource. The lowest-hanging fruit is to first of all step through the getTransaction call in AbstractPlatformTransactionManager and verify that in fact you are getting back the current transaction off the current thread. In the case of feeding it the null TransactionDefinition, the code path is very simple, so I doubt that is where it's failing, but you can verify. If that is ok, step through the commit call and see if it's actually getting the same TransactionStatus object it created before, and it has the rollback flag on like it should... > <pre wrap>There's an issue that just came up with the > TransactionManager. I > haven't spend enough time on it to fully figure it out, but before I dig > into it further, maybe you guys can give an opinion: > > When using a DataSourceTransactionManager, in a bean I'm asking the > applicationcontext for the transactionmanager. After calling > setRollbackOnly() is doesn't rollback. I've reproduced this using > petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic > and in one of the store*** methods calling: > > PlatformTransactionManager mgr = > (PlatformTransactionManager)appCtx.getBean( > "transactionManager"); > // does this give me the current transaction??? > mgr.getTransaction(null).setRollbackOnly(); > > AFAIK this should result in a rollback, shouldn't it... > > Thanx, > > Alef > > P.s. we're doing this because of some legacy code that needs to rollback > as well. We can't reimplement it right now... |
|
From: Alef A. <al...@jt...> - 2004-02-04 23:25:23
|
There's an issue that just came up with the TransactionManager. I haven't spend enough time on it to fully figure it out, but before I dig into it further, maybe you guys can give an opinion: When using a DataSourceTransactionManager, in a bean I'm asking the applicationcontext for the transactionmanager. After calling setRollbackOnly() is doesn't rollback. I've reproduced this using petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic and in one of the store*** methods calling: PlatformTransactionManager mgr = (PlatformTransactionManager)appCtx.getBean( "transactionManager"); // does this give me the current transaction??? mgr.getTransaction(null).setRollbackOnly(); AFAIK this should result in a rollback, shouldn't it... Thanx, Alef P.s. we're doing this because of some legacy code that needs to rollback as well. We can't reimplement it right now... |