Menu
▾
▴
springframework-developer — Spring Framework developers list
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: <jue...@we...> - 2004-07-19 09:03:36
|
OK - I think it makes sense to stick to such a uniform approach here. =
I'll give the finished version a try as soon as I can, against MySQL.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Mo 19.07.2004 00:20
An: spr...@li...
Betreff: Re: [Springframework-developer] Generated keys support
I'd like to wrap this up -
For SqlUpdate - I'm removing update(Object[], List) and leaving
update(Object[], KeyHolder)
For JdbcTemplate - I'm changing update(PreparedStatementCreator, List)
to update(PreparedStatementCreator, KeyHolder)
I'm also moving KeyHolder/GeneratedKeyHolder to jdbc.support package.
I'm comitting these changes tonight.
Thomas
Thomas Risberg wrote:
> We could add an update(PreparedStatementCreator, KeyHolder) method to
> JdbcTemplate - should we get rid of the
> update(PreparedStatementCreator, List) at the same time to keep things
> simpler? This would force the use of the KeyHolder.
>
> Thomas
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Oh, I didn't notice this. I was just wondering because JdbcTemplate's
>> update(PreparedStatementCreator, List) method still takes a List for
>> generated keys... Shouldn't it use a KeyHolder too? KeyHolder and co
>> would have to reside in the core package then, I guess, because
>> jdbc.core.support is intended to refer to jdbc.core but not the other
>> way round. jdbc.support would be OK too, provided that KeyHolder does
>> not depend on jdbc.core.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von Thomas Risberg
>> Gesendet: Sa 17.07.2004 19:31
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Generated keys support
>>
>>
>>
>> I added a KeyHolder interface and a GeneratedKeyHolder class (in
>> jdbc.support). They are used by the SqlUpdate.update(Object[],
>> KeyHolder) method.
>>
>> Here is an example:
>>
>> SqlUpdate su =3D new SqlUpdate(dataSource, "insert into Show2
>> (name) values(?)");
>> su.declareParameter(new SqlParameter("name", Types.VARCHAR));
>> su.setReturnGeneratedKeys(true);
>> su.setGeneratedKeysColumnNames(new String[] {"id"}); //this =
has
>> no effect for MySQL only DB2
>> su.compile();
>> Object[] val =3D {"Sven"};
>> KeyHolder kh =3D new GeneratedKeyHolder();
>> int updateCnt =3D su.update(val, kh);
>> int myKey =3D kh.getKey().intValue();
>> System.out.println("Key: " + myKey);
>> List myKeys =3D kh.getKeyList();
>> System.out.println(myKeys);
>>
>> Direct JdbcTemplate use would look like:
>>
>> KeyHolder kh =3D new GeneratedKeyHolder();
>> int rowsAffected =3D
>> getJdbcTemplate().update(newPreparedStatementCreator(args),
>> kh.getKeyList());
>>
>>
>> Thomas
>>
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>=20
>>
>>> Thomas,
>>>
>>> We discussed changing the List argument for generated keys into a
>>> GeneratedKeysHolder class or the like, for easier access to a single
>>> generated key (the typical use case). If we change that, we should
>>> do so before 1.1 RC1, even if this means having 1.1 RC1 mid or late
>>> next week rather than on Monday.
>>>
>>> Juergen
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>> FREE Java Enterprise J2EE developer tools!
>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>> http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dclick
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>
>>> =20
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dclick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>=20
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dmitriy K. <dko...@ru...> - 2004-07-19 04:25:50
|
I was browsing context.event package and I had two questions: 1) There is a class called ConsoleListener which is pretty useless. Can we remove it or at least put it in the sandbox? 2) What was the reason for removing the initialization check for "applicationEventClass" (via InitializingBean) in EventPublicationInterceptor (looking at the CVS history it was done on 10/23/03 by user *uid112313*)? Regards, Dmitriy. |
|
From: Mark P. <Mar...@Co...> - 2004-07-19 02:04:08
|
Hi, I removed the use of static initializtion of the jndi initial context that may have caused some side effects with the tests, it was better coding anyway. However, running all the tests with and without the JMS tests I still get some failures, two in ClassPathXmlApplicationContextTestSuite and many in the jdo package. Running the appctx suite in isolation still results in failures, but not in the case of jdo. There is still some side effect occuring. I'll look into it some more, just wanted to give an update. Cheers, Mark > Looking into it, sorry everyone! > > Mark > > >> I think the JMS stuff causes static sideffects that causes the other >> failures. It's not that the JMS tests themselves fail. >> >> R >> >> ----- Original Message ----- >> From: "Mark Pollack" <Mar...@Co...> >> To: <spr...@li...> >> Sent: Saturday, July 17, 2004 8:03 PM >> Subject: Re: [Springframework-developer] Ant 1.6.2 >> >> >>> Hi, >>> >>> I ran all the tests inside eclipse, there were some failures, but not >>> JMS >>> stuff. >>> >>> Cheers, >>> Mark >>> >>> > I believe it's the JMS stuff. I've raised it with Mark. >>> > >>> > ----- Original Message ----- >>> > From: "Colin Sampaleanu" <col...@ex...> >>> > To: <spr...@li...> >>> > Sent: Saturday, July 17, 2004 3:23 AM >>> > Subject: Re: [Springframework-developer] Ant 1.6.2 >>> > >>> > >>> >> It would still be nice to get all or most of the tests working in >>> >> Eclipse again, but it'll have to wait a while. In the meantime, it's >>> >> reasonable to run tests individually in Eclispe while writing code, >>> and >>> >> then run everything from ant right before checking in to make sure >>> >> nothing's broken. >>> >> >>> >> Colin >>> >> >>> >> >>> >> Thomas Risberg wrote: >>> >> >>> >> > Colin, >>> >> > >>> >> > This is excellent. It seems like I can run the tests faster than >>> I >>> >> > can type this email :-) The failing JUnit tests within Eclipse >>> were >>> >> > starting to bother me and testing with Ant was too slow. Now the >>> Ant >>> >> > tests take only 10% extra compared to running within Eclipse. >>> >> > Definitely worth the upgrade!!!! Thanks for figuring this out. >>> >> > >>> >> > Thomas >>> >> > >>> >> > Colin Sampaleanu wrote: >>> >> > >>> >> >> I spent a bit more time and got this going. Running the "tests" >>> >> >> target from command-line went down for me from about 6:40 to >>> 1:37. >>> >> >> Note bad! >>> >> >> >>> >> >> To get things going, I set the <junit> element forkmode to >>> >> >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> >>> >> >> element, and added them as 3 separate single test <batchtests> >> (still >>> >> >> kept as <batchtest> instead of <test> so the default excludes >>> would >>> >> >> still work. It's not that great to have to name tests >>> individually >>> >> >> like this, but it's just a few. If this has to be done for a few >>> >> >> more, it will actually get less verbose to just use a separate >>> junit >>> >> >> task instance, then one instance would have forkMode="perBatch", >>> and >>> >> >> one forkMode="perTest" (the default). >>> >> >> >>> >> >> Regards, >>> >> >> Colin >>> >> >> >>> >> >> Colin Sampaleanu wrote: >>> >> >> >>> >> >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on >>> the >>> >> >>> junit task, which allows ant to still fork for junit tests, but >> only >>> >> >>> once for the entire task (instead of for each testcase). >>> >> >>> Alternately, forkmode="perBatch" allows forking once per batch >>> > element. >>> >> >>> >>> >> >>> This is pretty promising, since it could bring the time to run >>> the >>> >> >>> test suite from ant down to a similar value to when running in >>> an >>> >> >>> IDE, which is currently much faster. >>> >> >>> >>> >> >>> I've tried to give it a go (making sure to remove the ant 1.6.1 >>> in >>> >> >>> the lib dir, otherwise that will interfere), by adding >>> >> >>> forkmode="once" to the junit element in the tests target. It is >>> >> >>> currently breaking on SqlStateExceptionTranslatorTests, due to >>> the >>> >> >>> initial context factory builder already being set. This should >>> be >>> >> >>> resolvable by using a separate batch for that test, or some >>> other >>> >> >>> strategy. I am curious however why this doesn't break in the IDE >>> >> >>> though. >>> >> >>> >>> >> >>> I don't have time to play with this any longer, but will give it >>> a >>> >> >>> go at some later date. If anybody feels like playing around with >>> >> >>> this themselves, please go ahead by all means. >>> >> >>> >>> >> >>> Regards, >>> >> >>> Colin >>> >> >>> >>> >> >>> ----- >>> >> >>> >>> >> >>> [junit] Testsuite: >>> >> >>> org.springframework.jdbc.support.SQLStateExceptionTransla >>> >> >>> torTests >>> >> >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 >> sec >>> >> >>> >>> >> >>> [junit] Testcase: testBadSqlGrammar took 0 sec >>> >> >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec >>> >> >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec >>> >> >>> [junit] java.lang.ExceptionInInitializerError >>> >> >>> [junit] at java.lang.Class.forName0(Native Method) >>> >> >>> [junit] at java.lang.Class.forName(Class.java:141) >>> >> >>> [junit] at >>> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> >> >>> <init>(JUnitTestRunner.java:204) >>> >> >>> [junit] at >>> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> >> >>> <init>(JUnitTestRunner.java:177) >>> >> >>> [junit] at >>> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> >> >>> launch(JUnitTestRunner.java:651) >>> >> >>> [junit] at >>> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> >> >>> main(JUnitTestRunner.java:537) >>> >> >>> [junit] Caused by: java.lang.IllegalStateException: >>> >> >>> InitialContextFactoryBui >>> >> >>> lder already set >>> >> >>> [junit] at >>> >> >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde >>> >> >>> r(NamingManager.java:687) >>> >> >>> [junit] at >>> >> >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java >>> >> >>> :93) >>> >> >> >>> >> >>> >> >>> >> >>> >> >>> >> ------------------------------------------------------- >>> >> This SF.Net email is sponsored by BEA Weblogic Workshop >>> >> FREE Java Enterprise J2EE developer tools! >>> >> Get your free copy of BEA WebLogic Workshop 8.1 today. >>> >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>> >> _______________________________________________ >>> >> Springframework-developer mailing list >>> >> Spr...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >> >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------- >>> > This SF.Net email is sponsored by BEA Weblogic Workshop >>> > FREE Java Enterprise J2EE developer tools! >>> > Get your free copy of BEA WebLogic Workshop 8.1 today. >>> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>> > _______________________________________________ >>> > Springframework-developer mailing list >>> > Spr...@li... >>> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> > >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by BEA Weblogic Workshop >>> FREE Java Enterprise J2EE developer tools! >>> Get your free copy of BEA WebLogic Workshop 8.1 today. >>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <al...@jt...> - 2004-07-18 23:20:11
|
<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE - =
build.56</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>07/19/2004 00:16:13</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 17 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>07/17/2004 22:10:40</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>renamed reference data (aka enum) support package in sandb=
ox to "enums" from "enum" to run under jdk 1.5/ various polishing of those =
packages.</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader"> Errors/Warnings: (=
6) </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Tests: (1470) </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data"> failure =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2"> </td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader"> =
Unit Test Error Details: (1) </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2"> Test: test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2"> =
Class: org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2"> Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2"> Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
"> </td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader"> =
Modifications since last build: =
(22) </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
kdonald</td><td class=3D"modifications-data">sandbox/src/org/springframewor=
k/rules/Operator.java</td><td class=3D"modifications-data">renamed referenc=
e data (aka enum) support package in sandbox to "enums" from "enum" to run =
under jdk 1.5/ various polishing of those packages.</td></tr><tr class=3D"m=
odifications-oddrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sandb=
ox/src/org/springframework/rules/reporting/Severity.java</td><td class=3D"m=
odifications-data">renamed reference data (aka enum) support package in san=
dbox to "enums" from "enum" to run under jdk 1.5/ various polishing of thos=
e packages.</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modif=
ications-data">deleted</td><td class=3D"modifications-data">kdonald</td><td=
class=3D"modifications-data">sandbox/test/org/springframework/enum/CodedEn=
umTestSuite.java</td><td class=3D"modifications-data">renamed reference dat=
a (aka enum) support package in sandbox to "enums" from "enum" to run under=
jdk 1.5/ various polishing of those packages.</td></tr><tr class=3D"modifi=
cations-oddrow"><td class=3D"modifications-data">deleted</td><td class=3D"m=
odifications-data">kdonald</td><td class=3D"modifications-data">sandbox/tes=
t/org/springframework/enum/Gender.java</td><td class=3D"modifications-data"=
>renamed reference data (aka enum) support package in sandbox to "enums" fr=
om "enum" to run under jdk 1.5/ various polishing of those packages.</td></=
tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">del=
eted</td><td class=3D"modifications-data">kdonald</td><td class=3D"modifica=
tions-data">sandbox/test/org/springframework/enum/enum-context.xml</td><td =
class=3D"modifications-data">renamed reference data (aka enum) support pack=
age in sandbox to "enums" from "enum" to run under jdk 1.5/ various polishi=
ng of those packages.</td></tr><tr class=3D"modifications-oddrow"><td class=
=3D"modifications-data">deleted</td><td class=3D"modifications-data">kdonal=
d</td><td class=3D"modifications-data">sandbox/src/org/springframework/enum=
/AbstractCodedEnum.java</td><td class=3D"modifications-data">renamed refere=
nce data (aka enum) support package in sandbox to "enums" from "enum" to ru=
n under jdk 1.5/ various polishing of those packages.</td></tr><tr class=3D=
"modifications-evenrow"><td class=3D"modifications-data">deleted</td><td cl=
ass=3D"modifications-data">kdonald</td><td class=3D"modifications-data">san=
dbox/src/org/springframework/enum/CodedEnum.java</td><td class=3D"modificat=
ions-data">renamed reference data (aka enum) support package in sandbox to =
"enums" from "enum" to run under jdk 1.5/ various polishing of those packag=
es.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-=
data">deleted</td><td class=3D"modifications-data">kdonald</td><td class=3D=
"modifications-data">sandbox/src/org/springframework/enum/CodedEnumEditor.j=
ava</td><td class=3D"modifications-data">renamed reference data (aka enum) =
support package in sandbox to "enums" from "enum" to run under jdk 1.5/ var=
ious polishing of those packages.</td></tr><tr class=3D"modifications-evenr=
ow"><td class=3D"modifications-data">deleted</td><td class=3D"modifications=
-data">kdonald</td><td class=3D"modifications-data">sandbox/src/org/springf=
ramework/enum/CodedEnumResolver.java</td><td class=3D"modifications-data">r=
enamed reference data (aka enum) support package in sandbox to "enums" from=
"enum" to run under jdk 1.5/ various polishing of those packages.</td></tr=
><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">delete=
d</td><td class=3D"modifications-data">kdonald</td><td class=3D"modificatio=
ns-data">sandbox/src/org/springframework/enum/LetterCodedEnum.java</td><td =
class=3D"modifications-data">renamed reference data (aka enum) support pack=
age in sandbox to "enums" from "enum" to run under jdk 1.5/ various polishi=
ng of those packages.</td></tr><tr class=3D"modifications-evenrow"><td clas=
s=3D"modifications-data">deleted</td><td class=3D"modifications-data">kdona=
ld</td><td class=3D"modifications-data">sandbox/src/org/springframework/enu=
m/ShortCodedEnum.java</td><td class=3D"modifications-data">renamed referenc=
e data (aka enum) support package in sandbox to "enums" from "enum" to run =
under jdk 1.5/ various polishing of those packages.</td></tr><tr class=3D"m=
odifications-oddrow"><td class=3D"modifications-data">deleted</td><td class=
=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sandbo=
x/src/org/springframework/enum/StringCodedEnum.java</td><td class=3D"modifi=
cations-data">renamed reference data (aka enum) support package in sandbox =
to "enums" from "enum" to run under jdk 1.5/ various polishing of those pac=
kages.</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modificati=
ons-data">deleted</td><td class=3D"modifications-data">kdonald</td><td clas=
s=3D"modifications-data">sandbox/src/org/springframework/enum/support/Abstr=
actCodedEnumResolver.java</td><td class=3D"modifications-data">renamed refe=
rence data (aka enum) support package in sandbox to "enums" from "enum" to =
run under jdk 1.5/ various polishing of those packages.</td></tr><tr class=
=3D"modifications-oddrow"><td class=3D"modifications-data">deleted</td><td =
class=3D"modifications-data">kdonald</td><td class=3D"modifications-data">s=
andbox/src/org/springframework/enum/support/CachingJdbcCodedEnumResolver.ja=
va</td><td class=3D"modifications-data">renamed reference data (aka enum) s=
upport package in sandbox to "enums" from "enum" to run under jdk 1.5/ vari=
ous polishing of those packages.</td></tr><tr class=3D"modifications-evenro=
w"><td class=3D"modifications-data">deleted</td><td class=3D"modifications-=
data">kdonald</td><td class=3D"modifications-data">sandbox/src/org/springfr=
amework/enum/support/CodedEnumUserType.java</td><td class=3D"modifications-=
data">renamed reference data (aka enum) support package in sandbox to "enum=
s" from "enum" to run under jdk 1.5/ various polishing of those packages.</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>deleted</td><td class=3D"modifications-data">kdonald</td><td class=3D"modi=
fications-data">sandbox/src/org/springframework/enum/support/GenericLabeled=
CodedEnum.java</td><td class=3D"modifications-data">renamed reference data =
(aka enum) support package in sandbox to "enums" from "enum" to run under j=
dk 1.5/ various polishing of those packages.</td></tr><tr class=3D"modifica=
tions-evenrow"><td class=3D"modifications-data">deleted</td><td class=3D"mo=
difications-data">kdonald</td><td class=3D"modifications-data">sandbox/src/=
org/springframework/enum/support/StaticCodedEnumResolver.java</td><td class=
=3D"modifications-data">renamed reference data (aka enum) support package i=
n sandbox to "enums" from "enum" to run under jdk 1.5/ various polishing of=
those packages.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"m=
odifications-data">deleted</td><td class=3D"modifications-data">kdonald</td=
><td class=3D"modifications-data">sandbox/src/org/springframework/enum/supp=
ort/TypeMapping.java</td><td class=3D"modifications-data">renamed reference=
data (aka enum) support package in sandbox to "enums" from "enum" to run u=
nder jdk 1.5/ various polishing of those packages.</td></tr><tr class=3D"mo=
difications-evenrow"><td class=3D"modifications-data">modified</td><td clas=
s=3D"modifications-data">kdonald</td><td class=3D"modifications-data">sandb=
ox/src/org/springframework/rules/values/BeanPropertyAccessStrategy.java</td=
><td class=3D"modifications-data">renamed reference data (aka enum) support=
package in sandbox to "enums" from "enum" to run under jdk 1.5/ various po=
lishing of those packages.</td></tr><tr class=3D"modifications-oddrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
trisberg</td><td class=3D"modifications-data">src/org/springframework/jdbc/=
core/support/GeneratedKeyHolder.java</td><td class=3D"modifications-data">c=
hanged return type of getKey to Number</td></tr><tr class=3D"modifications-=
evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modific=
ations-data">trisberg</td><td class=3D"modifications-data">src/org/springfr=
amework/jdbc/core/support/KeyHolder.java</td><td class=3D"modifications-dat=
a">changed return type of getKey to Number</td></tr><tr class=3D"modificati=
ons-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">trisberg</td><td class=3D"modifications-data">src/org/sprin=
gframework/jdbc/core/support/GeneratedKeyHolder.java</td><td class=3D"modif=
ications-data">fixed java doc reference</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader"> =
Deployments by this build: (8) </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html> |
|
From: Thomas R. <tho...@tr...> - 2004-07-18 22:20:29
|
I'd like to wrap this up -
For SqlUpdate - I'm removing update(Object[], List) and leaving
update(Object[], KeyHolder)
For JdbcTemplate - I'm changing update(PreparedStatementCreator, List)
to update(PreparedStatementCreator, KeyHolder)
I'm also moving KeyHolder/GeneratedKeyHolder to jdbc.support package.
I'm comitting these changes tonight.
Thomas
Thomas Risberg wrote:
> We could add an update(PreparedStatementCreator, KeyHolder) method to
> JdbcTemplate - should we get rid of the
> update(PreparedStatementCreator, List) at the same time to keep things
> simpler? This would force the use of the KeyHolder.
>
> Thomas
>
> jürgen höller [werk3AT] wrote:
>
>> Oh, I didn't notice this. I was just wondering because JdbcTemplate's
>> update(PreparedStatementCreator, List) method still takes a List for
>> generated keys... Shouldn't it use a KeyHolder too? KeyHolder and co
>> would have to reside in the core package then, I guess, because
>> jdbc.core.support is intended to refer to jdbc.core but not the other
>> way round. jdbc.support would be OK too, provided that KeyHolder does
>> not depend on jdbc.core.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von Thomas Risberg
>> Gesendet: Sa 17.07.2004 19:31
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Generated keys support
>>
>>
>>
>> I added a KeyHolder interface and a GeneratedKeyHolder class (in
>> jdbc.support). They are used by the SqlUpdate.update(Object[],
>> KeyHolder) method.
>>
>> Here is an example:
>>
>> SqlUpdate su = new SqlUpdate(dataSource, "insert into Show2
>> (name) values(?)");
>> su.declareParameter(new SqlParameter("name", Types.VARCHAR));
>> su.setReturnGeneratedKeys(true);
>> su.setGeneratedKeysColumnNames(new String[] {"id"}); //this has
>> no effect for MySQL only DB2
>> su.compile();
>> Object[] val = {"Sven"};
>> KeyHolder kh = new GeneratedKeyHolder();
>> int updateCnt = su.update(val, kh);
>> int myKey = kh.getKey().intValue();
>> System.out.println("Key: " + myKey);
>> List myKeys = kh.getKeyList();
>> System.out.println(myKeys);
>>
>> Direct JdbcTemplate use would look like:
>>
>> KeyHolder kh = new GeneratedKeyHolder();
>> int rowsAffected =
>> getJdbcTemplate().update(newPreparedStatementCreator(args),
>> kh.getKeyList());
>>
>>
>> Thomas
>>
>> jürgen höller [werk3AT] wrote:
>>
>>
>>
>>> Thomas,
>>>
>>> We discussed changing the List argument for generated keys into a
>>> GeneratedKeysHolder class or the like, for easier access to a single
>>> generated key (the typical use case). If we change that, we should
>>> do so before 1.1 RC1, even if this means having 1.1 RC1 mid or late
>>> next week rather than on Monday.
>>>
>>> Juergen
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>> FREE Java Enterprise J2EE developer tools!
>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>> http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
|
|
From: Seth L. <set...@gm...> - 2004-07-18 18:52:58
|
On Sun, 18 Jul 2004 14:19:56 +0200, j=FCrgen h=F6ller [werk3AT] <jue...@we...> wrote: > Those are implementations of the javax.servlet.jsp.tagext.TryCatchFinally= interface, to be called by the JSP container. The only reason why we imple= ment them is to reset the requestContext member variable in doFinally. (Thi= s was requested by a user for proper cleanup in any case.) >=20 Ahh... thanks! I think I'll add the JSP classes to my project classpath to help me notice these things in the future. :) Seth |
|
From: Alef A. <al...@jt...> - 2004-07-18 18:27:03
|
That'd be absolutely great! =20 I've started with writing some of the docs ages ago and did it all in a = rush, only focusing on getting things done, not making it an example of = how a reference manual should look like. =20 alef ________________________________ Van: spr...@li... namens Colin = Sampaleanu Verzonden: zo 18-7-2004 16:30 Aan: spr...@li... Onderwerp: Re: [Springframework-developer] Documentation Editing Rob, I think that'd be great! It's been my intent to do that myself for all the text, but the only chapter I've actually managed to go through that deeply so far as the beans one. Colin Rob Harrop wrote: > All, > > My girlfriend is a professional proof reader who has checked quite a > few technical books of mine in the past, and she has volunteered to > proof read the Spring documentation and makes amendments as necessary. > I'm not sure how everyone feels about this but if you think it would > be beneficial then I will get her started on a snapshot ASAP. > > robh ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-18 17:03:46
|
>BTW, TransactionProxyFactoryBean's "preInterceptors" and "postInterceptors" also accept Advisors, so "preAdvices" and "postAdvices" wouldn't be entirely correct either and would still have to accept an Object array. Is there a common term that covers both direct advices and advisors with conditional advices? > > > One common term in case of both "advices" and "advisors" that comes to my mind is "aspect". That is - an "advice" is unconditional aspect and an "advisor" is conditional aspect containing advice that should be applied to a given pointcut. Dmitriy. |
|
From: Mark P. <Mar...@Co...> - 2004-07-18 16:37:39
|
Looking into it, sorry everyone! Mark > I think the JMS stuff causes static sideffects that causes the other > failures. It's not that the JMS tests themselves fail. > > R > > ----- Original Message ----- > From: "Mark Pollack" <Mar...@Co...> > To: <spr...@li...> > Sent: Saturday, July 17, 2004 8:03 PM > Subject: Re: [Springframework-developer] Ant 1.6.2 > > >> Hi, >> >> I ran all the tests inside eclipse, there were some failures, but not >> JMS >> stuff. >> >> Cheers, >> Mark >> >> > I believe it's the JMS stuff. I've raised it with Mark. >> > >> > ----- Original Message ----- >> > From: "Colin Sampaleanu" <col...@ex...> >> > To: <spr...@li...> >> > Sent: Saturday, July 17, 2004 3:23 AM >> > Subject: Re: [Springframework-developer] Ant 1.6.2 >> > >> > >> >> It would still be nice to get all or most of the tests working in >> >> Eclipse again, but it'll have to wait a while. In the meantime, it's >> >> reasonable to run tests individually in Eclispe while writing code, >> and >> >> then run everything from ant right before checking in to make sure >> >> nothing's broken. >> >> >> >> Colin >> >> >> >> >> >> Thomas Risberg wrote: >> >> >> >> > Colin, >> >> > >> >> > This is excellent. It seems like I can run the tests faster than I >> >> > can type this email :-) The failing JUnit tests within Eclipse >> were >> >> > starting to bother me and testing with Ant was too slow. Now the >> Ant >> >> > tests take only 10% extra compared to running within Eclipse. >> >> > Definitely worth the upgrade!!!! Thanks for figuring this out. >> >> > >> >> > Thomas >> >> > >> >> > Colin Sampaleanu wrote: >> >> > >> >> >> I spent a bit more time and got this going. Running the "tests" >> >> >> target from command-line went down for me from about 6:40 to 1:37. >> >> >> Note bad! >> >> >> >> >> >> To get things going, I set the <junit> element forkmode to >> >> >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> >> >> >> element, and added them as 3 separate single test <batchtests> > (still >> >> >> kept as <batchtest> instead of <test> so the default excludes >> would >> >> >> still work. It's not that great to have to name tests individually >> >> >> like this, but it's just a few. If this has to be done for a few >> >> >> more, it will actually get less verbose to just use a separate >> junit >> >> >> task instance, then one instance would have forkMode="perBatch", >> and >> >> >> one forkMode="perTest" (the default). >> >> >> >> >> >> Regards, >> >> >> Colin >> >> >> >> >> >> Colin Sampaleanu wrote: >> >> >> >> >> >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on >> the >> >> >>> junit task, which allows ant to still fork for junit tests, but > only >> >> >>> once for the entire task (instead of for each testcase). >> >> >>> Alternately, forkmode="perBatch" allows forking once per batch >> > element. >> >> >>> >> >> >>> This is pretty promising, since it could bring the time to run >> the >> >> >>> test suite from ant down to a similar value to when running in an >> >> >>> IDE, which is currently much faster. >> >> >>> >> >> >>> I've tried to give it a go (making sure to remove the ant 1.6.1 >> in >> >> >>> the lib dir, otherwise that will interfere), by adding >> >> >>> forkmode="once" to the junit element in the tests target. It is >> >> >>> currently breaking on SqlStateExceptionTranslatorTests, due to >> the >> >> >>> initial context factory builder already being set. This should be >> >> >>> resolvable by using a separate batch for that test, or some other >> >> >>> strategy. I am curious however why this doesn't break in the IDE >> >> >>> though. >> >> >>> >> >> >>> I don't have time to play with this any longer, but will give it >> a >> >> >>> go at some later date. If anybody feels like playing around with >> >> >>> this themselves, please go ahead by all means. >> >> >>> >> >> >>> Regards, >> >> >>> Colin >> >> >>> >> >> >>> ----- >> >> >>> >> >> >>> [junit] Testsuite: >> >> >>> org.springframework.jdbc.support.SQLStateExceptionTransla >> >> >>> torTests >> >> >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 > sec >> >> >>> >> >> >>> [junit] Testcase: testBadSqlGrammar took 0 sec >> >> >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec >> >> >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec >> >> >>> [junit] java.lang.ExceptionInInitializerError >> >> >>> [junit] at java.lang.Class.forName0(Native Method) >> >> >>> [junit] at java.lang.Class.forName(Class.java:141) >> >> >>> [junit] at >> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >> >>> <init>(JUnitTestRunner.java:204) >> >> >>> [junit] at >> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >> >>> <init>(JUnitTestRunner.java:177) >> >> >>> [junit] at >> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >> >>> launch(JUnitTestRunner.java:651) >> >> >>> [junit] at >> >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >> >>> main(JUnitTestRunner.java:537) >> >> >>> [junit] Caused by: java.lang.IllegalStateException: >> >> >>> InitialContextFactoryBui >> >> >>> lder already set >> >> >>> [junit] at >> >> >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde >> >> >>> r(NamingManager.java:687) >> >> >>> [junit] at >> >> >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java >> >> >>> :93) >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------- >> >> This SF.Net email is sponsored by BEA Weblogic Workshop >> >> FREE Java Enterprise J2EE developer tools! >> >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >> >> _______________________________________________ >> >> Springframework-developer mailing list >> >> Spr...@li... >> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > >> > >> > >> > >> > ------------------------------------------------------- >> > This SF.Net email is sponsored by BEA Weblogic Workshop >> > FREE Java Enterprise J2EE developer tools! >> > Get your free copy of BEA WebLogic Workshop 8.1 today. >> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >> > _______________________________________________ >> > Springframework-developer mailing list >> > Spr...@li... >> > https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jue...@we...> - 2004-07-18 15:58:40
|
Sounds plausible. I'd even like to see those warning messages on = initialization in Spring 1.1, to highlight the deprecation - noone will = notice deprecated bean properties else. And we need to be consistent: = Let's find all "interceptor" naming and replace them with "advice" = naming. =20 BTW, TransactionProxyFactoryBean's "preInterceptors" and = "postInterceptors" also accept Advisors, so "preAdvices" and = "postAdvices" wouldn't be entirely correct either and would still have = to accept an Object array. Is there a common term that covers both = direct advices and advisors with conditional advices? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: So 18.07.2004 14:10 An: spr...@li... Betreff: Re: [Springframework-developer] "advice" vs "interceptor" = properties I'd rather have the use of the word advice if it takes advice. If it says interceptor, people are going to think it takes just an = interceptor. Maybe we could handle the deprecation in two stages though. For 1.1 the old methods are deprecated. For 1.2 the old methods are deprecated, and also log a warning in the setter. Hopefully people look in their logs... For 1.3 they actually go away. Colin j=FCrgen h=F6ller [werk3AT] wrote: >In our current 1.1 codebase, we have an inconsistency regarding the use = of "advice" and "interceptor" in bean property names: AdvisedSupport has = a deprecated "addInterceptor" method now (without hinting at the = preferred method in javadoc, BTW), because of the preferred "addAdvice" = method. > >While Advice is more general (being a super interface of Interceptor), = a number of other properties use "interceptor" in the name while = accepting Object, for example TransactionProxyFactoryBean's = "preInterceptors" and "postInterceptors", and also ProxyFactoryBean's = "interceptorNames". > >We need to make this consistent. We could either keep the "interceptor" = property names, allowing all kinds of Advices there: This would mean = that AdvisedSupport's "addInterceptor" should not be deprecated. Or we = could use "advice" in all those names: That would mean renaming = (respectively deprecating) quite popular properties. > >When renaming bean properties, we need to consider that driving those = properties via XML bean definitions will not show any deprecation = warnings, just programmatic usage will. Consequently, many people will = not notice such deprecations, first discovering them when we remove the = deprecated bean properties... > >Thoughts? Suggestions? > >Juergen >=20 > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-07-18 14:24:08
|
Rob, I think that'd be great! It's been my intent to do that myself for all the text, but the only chapter I've actually managed to go through that deeply so far as the beans one. Colin Rob Harrop wrote: > All, > > My girlfriend is a professional proof reader who has checked quite a > few technical books of mine in the past, and she has volunteered to > proof read the Spring documentation and makes amendments as necessary. > I'm not sure how everyone feels about this but if you think it would > be beneficial then I will get her started on a snapshot ASAP. > > robh |
|
From: Rob H. <ro...@ca...> - 2004-07-18 14:05:09
|
All, My girlfriend is a professional proof reader who has checked quite a few technical books of mine in the past, and she has volunteered to proof read the Spring documentation and makes amendments as necessary. I'm not sure how everyone feels about this but if you think it would be beneficial then I will get her started on a snapshot ASAP. robh |
|
From: <jue...@we...> - 2004-07-18 12:20:46
|
Those are implementations of the = javax.servlet.jsp.tagext.TryCatchFinally interface, to be called by the = JSP container. The only reason why we implement them is to reset the = requestContext member variable in doFinally. (This was requested by a = user for proper cleanup in any case.) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Seth Ladd Gesendet: So 18.07.2004 05:18 An: spr...@li... Betreff: [Springframework-developer] Unused Methods in = RequestContextAwareTag? Hello, There are two methods: doFinally() and doCatch() in RequestContextAwareTag, that don't seem to be called by anything. At least, Eclipse doesn't show anyone as the caller (except subclasses that override those methods). I'm guessing that they should be called by RequestContextAwareTag inside doStartTag, inside the catches or the finally block (which needs to be added). Does anyone know what those methods do? Should they still exist? Thanks! Seth ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-07-18 12:05:47
|
I'd rather have the use of the word advice if it takes advice. If it says interceptor, people are going to think it takes just an interceptor. Maybe we could handle the deprecation in two stages though. For 1.1 the old methods are deprecated. For 1.2 the old methods are deprecated, and also log a warning in the setter. Hopefully people look in their logs... For 1.3 they actually go away. Colin jürgen höller [werk3AT] wrote: >In our current 1.1 codebase, we have an inconsistency regarding the use of "advice" and "interceptor" in bean property names: AdvisedSupport has a deprecated "addInterceptor" method now (without hinting at the preferred method in javadoc, BTW), because of the preferred "addAdvice" method. > >While Advice is more general (being a super interface of Interceptor), a number of other properties use "interceptor" in the name while accepting Object, for example TransactionProxyFactoryBean's "preInterceptors" and "postInterceptors", and also ProxyFactoryBean's "interceptorNames". > >We need to make this consistent. We could either keep the "interceptor" property names, allowing all kinds of Advices there: This would mean that AdvisedSupport's "addInterceptor" should not be deprecated. Or we could use "advice" in all those names: That would mean renaming (respectively deprecating) quite popular properties. > >When renaming bean properties, we need to consider that driving those properties via XML bean definitions will not show any deprecation warnings, just programmatic usage will. Consequently, many people will not notice such deprecations, first discovering them when we remove the deprecated bean properties... > >Thoughts? Suggestions? > >Juergen > > |
|
From: Seth L. <set...@gm...> - 2004-07-18 03:18:10
|
Hello, There are two methods: doFinally() and doCatch() in RequestContextAwareTag, that don't seem to be called by anything. At least, Eclipse doesn't show anyone as the caller (except subclasses that override those methods). I'm guessing that they should be called by RequestContextAwareTag inside doStartTag, inside the catches or the finally block (which needs to be added). Does anyone know what those methods do? Should they still exist? Thanks! Seth |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-17 20:27:41
|
Juergen, I like consistency too. I would prefer "advice" names as it's a general term and "interceptor" is one possible implementation strategy. Regards, Dmitriy. jürgen höller [werk3AT] wrote: >In our current 1.1 codebase, we have an inconsistency regarding the use of "advice" and "interceptor" in bean property names: AdvisedSupport has a deprecated "addInterceptor" method now (without hinting at the preferred method in javadoc, BTW), because of the preferred "addAdvice" method. > >While Advice is more general (being a super interface of Interceptor), a number of other properties use "interceptor" in the name while accepting Object, for example TransactionProxyFactoryBean's "preInterceptors" and "postInterceptors", and also ProxyFactoryBean's "interceptorNames". > >We need to make this consistent. We could either keep the "interceptor" property names, allowing all kinds of Advices there: This would mean that AdvisedSupport's "addInterceptor" should not be deprecated. Or we could use "advice" in all those names: That would mean renaming (respectively deprecating) quite popular properties. > >When renaming bean properties, we need to consider that driving those properties via XML bean definitions will not show any deprecation warnings, just programmatic usage will. Consequently, many people will not notice such deprecations, first discovering them when we remove the deprecated bean properties... > >Thoughts? Suggestions? > >Juergen > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_idG21&alloc_id040&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Rainer S. <Rai...@ab...> - 2004-07-17 20:01:24
|
After some distractions I'm dealing with portlets again. What is the current status of spring support for portlet programming? In the mailing lists the topic wasn't discussed since early May. Regards, Rainer |
|
From: Rod J. <rod...@in...> - 2004-07-17 19:37:08
|
I think the JMS stuff causes static sideffects that causes the other failures. It's not that the JMS tests themselves fail. R ----- Original Message ----- From: "Mark Pollack" <Mar...@Co...> To: <spr...@li...> Sent: Saturday, July 17, 2004 8:03 PM Subject: Re: [Springframework-developer] Ant 1.6.2 > Hi, > > I ran all the tests inside eclipse, there were some failures, but not JMS > stuff. > > Cheers, > Mark > > > I believe it's the JMS stuff. I've raised it with Mark. > > > > ----- Original Message ----- > > From: "Colin Sampaleanu" <col...@ex...> > > To: <spr...@li...> > > Sent: Saturday, July 17, 2004 3:23 AM > > Subject: Re: [Springframework-developer] Ant 1.6.2 > > > > > >> It would still be nice to get all or most of the tests working in > >> Eclipse again, but it'll have to wait a while. In the meantime, it's > >> reasonable to run tests individually in Eclispe while writing code, and > >> then run everything from ant right before checking in to make sure > >> nothing's broken. > >> > >> Colin > >> > >> > >> Thomas Risberg wrote: > >> > >> > Colin, > >> > > >> > This is excellent. It seems like I can run the tests faster than I > >> > can type this email :-) The failing JUnit tests within Eclipse were > >> > starting to bother me and testing with Ant was too slow. Now the Ant > >> > tests take only 10% extra compared to running within Eclipse. > >> > Definitely worth the upgrade!!!! Thanks for figuring this out. > >> > > >> > Thomas > >> > > >> > Colin Sampaleanu wrote: > >> > > >> >> I spent a bit more time and got this going. Running the "tests" > >> >> target from command-line went down for me from about 6:40 to 1:37. > >> >> Note bad! > >> >> > >> >> To get things going, I set the <junit> element forkmode to > >> >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> > >> >> element, and added them as 3 separate single test <batchtests> (still > >> >> kept as <batchtest> instead of <test> so the default excludes would > >> >> still work. It's not that great to have to name tests individually > >> >> like this, but it's just a few. If this has to be done for a few > >> >> more, it will actually get less verbose to just use a separate junit > >> >> task instance, then one instance would have forkMode="perBatch", and > >> >> one forkMode="perTest" (the default). > >> >> > >> >> Regards, > >> >> Colin > >> >> > >> >> Colin Sampaleanu wrote: > >> >> > >> >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on the > >> >>> junit task, which allows ant to still fork for junit tests, but only > >> >>> once for the entire task (instead of for each testcase). > >> >>> Alternately, forkmode="perBatch" allows forking once per batch > > element. > >> >>> > >> >>> This is pretty promising, since it could bring the time to run the > >> >>> test suite from ant down to a similar value to when running in an > >> >>> IDE, which is currently much faster. > >> >>> > >> >>> I've tried to give it a go (making sure to remove the ant 1.6.1 in > >> >>> the lib dir, otherwise that will interfere), by adding > >> >>> forkmode="once" to the junit element in the tests target. It is > >> >>> currently breaking on SqlStateExceptionTranslatorTests, due to the > >> >>> initial context factory builder already being set. This should be > >> >>> resolvable by using a separate batch for that test, or some other > >> >>> strategy. I am curious however why this doesn't break in the IDE > >> >>> though. > >> >>> > >> >>> I don't have time to play with this any longer, but will give it a > >> >>> go at some later date. If anybody feels like playing around with > >> >>> this themselves, please go ahead by all means. > >> >>> > >> >>> Regards, > >> >>> Colin > >> >>> > >> >>> ----- > >> >>> > >> >>> [junit] Testsuite: > >> >>> org.springframework.jdbc.support.SQLStateExceptionTransla > >> >>> torTests > >> >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 sec > >> >>> > >> >>> [junit] Testcase: testBadSqlGrammar took 0 sec > >> >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec > >> >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec > >> >>> [junit] java.lang.ExceptionInInitializerError > >> >>> [junit] at java.lang.Class.forName0(Native Method) > >> >>> [junit] at java.lang.Class.forName(Class.java:141) > >> >>> [junit] at > >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >> >>> <init>(JUnitTestRunner.java:204) > >> >>> [junit] at > >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >> >>> <init>(JUnitTestRunner.java:177) > >> >>> [junit] at > >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >> >>> launch(JUnitTestRunner.java:651) > >> >>> [junit] at > >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >> >>> main(JUnitTestRunner.java:537) > >> >>> [junit] Caused by: java.lang.IllegalStateException: > >> >>> InitialContextFactoryBui > >> >>> lder already set > >> >>> [junit] at > >> >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde > >> >>> r(NamingManager.java:687) > >> >>> [junit] at > >> >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java > >> >>> :93) > >> >> > >> > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by BEA Weblogic Workshop > >> FREE Java Enterprise J2EE developer tools! > >> Get your free copy of BEA WebLogic Workshop 8.1 today. > >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > >> _______________________________________________ > >> Springframework-developer mailing list > >> Spr...@li... > >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > >> > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by BEA Weblogic Workshop > > FREE Java Enterprise J2EE developer tools! > > Get your free copy of BEA WebLogic Workshop 8.1 today. > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Mark P. <Mar...@Co...> - 2004-07-17 19:03:02
|
Hi, I ran all the tests inside eclipse, there were some failures, but not JMS stuff. Cheers, Mark > I believe it's the JMS stuff. I've raised it with Mark. > > ----- Original Message ----- > From: "Colin Sampaleanu" <col...@ex...> > To: <spr...@li...> > Sent: Saturday, July 17, 2004 3:23 AM > Subject: Re: [Springframework-developer] Ant 1.6.2 > > >> It would still be nice to get all or most of the tests working in >> Eclipse again, but it'll have to wait a while. In the meantime, it's >> reasonable to run tests individually in Eclispe while writing code, and >> then run everything from ant right before checking in to make sure >> nothing's broken. >> >> Colin >> >> >> Thomas Risberg wrote: >> >> > Colin, >> > >> > This is excellent. It seems like I can run the tests faster than I >> > can type this email :-) The failing JUnit tests within Eclipse were >> > starting to bother me and testing with Ant was too slow. Now the Ant >> > tests take only 10% extra compared to running within Eclipse. >> > Definitely worth the upgrade!!!! Thanks for figuring this out. >> > >> > Thomas >> > >> > Colin Sampaleanu wrote: >> > >> >> I spent a bit more time and got this going. Running the "tests" >> >> target from command-line went down for me from about 6:40 to 1:37. >> >> Note bad! >> >> >> >> To get things going, I set the <junit> element forkmode to >> >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> >> >> element, and added them as 3 separate single test <batchtests> (still >> >> kept as <batchtest> instead of <test> so the default excludes would >> >> still work. It's not that great to have to name tests individually >> >> like this, but it's just a few. If this has to be done for a few >> >> more, it will actually get less verbose to just use a separate junit >> >> task instance, then one instance would have forkMode="perBatch", and >> >> one forkMode="perTest" (the default). >> >> >> >> Regards, >> >> Colin >> >> >> >> Colin Sampaleanu wrote: >> >> >> >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on the >> >>> junit task, which allows ant to still fork for junit tests, but only >> >>> once for the entire task (instead of for each testcase). >> >>> Alternately, forkmode="perBatch" allows forking once per batch > element. >> >>> >> >>> This is pretty promising, since it could bring the time to run the >> >>> test suite from ant down to a similar value to when running in an >> >>> IDE, which is currently much faster. >> >>> >> >>> I've tried to give it a go (making sure to remove the ant 1.6.1 in >> >>> the lib dir, otherwise that will interfere), by adding >> >>> forkmode="once" to the junit element in the tests target. It is >> >>> currently breaking on SqlStateExceptionTranslatorTests, due to the >> >>> initial context factory builder already being set. This should be >> >>> resolvable by using a separate batch for that test, or some other >> >>> strategy. I am curious however why this doesn't break in the IDE >> >>> though. >> >>> >> >>> I don't have time to play with this any longer, but will give it a >> >>> go at some later date. If anybody feels like playing around with >> >>> this themselves, please go ahead by all means. >> >>> >> >>> Regards, >> >>> Colin >> >>> >> >>> ----- >> >>> >> >>> [junit] Testsuite: >> >>> org.springframework.jdbc.support.SQLStateExceptionTransla >> >>> torTests >> >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 sec >> >>> >> >>> [junit] Testcase: testBadSqlGrammar took 0 sec >> >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec >> >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec >> >>> [junit] java.lang.ExceptionInInitializerError >> >>> [junit] at java.lang.Class.forName0(Native Method) >> >>> [junit] at java.lang.Class.forName(Class.java:141) >> >>> [junit] at >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >>> <init>(JUnitTestRunner.java:204) >> >>> [junit] at >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >>> <init>(JUnitTestRunner.java:177) >> >>> [junit] at >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >>> launch(JUnitTestRunner.java:651) >> >>> [junit] at >> >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >> >>> main(JUnitTestRunner.java:537) >> >>> [junit] Caused by: java.lang.IllegalStateException: >> >>> InitialContextFactoryBui >> >>> lder already set >> >>> [junit] at >> >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde >> >>> r(NamingManager.java:687) >> >>> [junit] at >> >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java >> >>> :93) >> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Thomas R. <tho...@tr...> - 2004-07-17 18:30:23
|
We could add an update(PreparedStatementCreator, KeyHolder) method to
JdbcTemplate - should we get rid of the update(PreparedStatementCreator,
List) at the same time to keep things simpler? This would force the use
of the KeyHolder.
Thomas
jürgen höller [werk3AT] wrote:
>Oh, I didn't notice this. I was just wondering because JdbcTemplate's update(PreparedStatementCreator, List) method still takes a List for generated keys... Shouldn't it use a KeyHolder too? KeyHolder and co would have to reside in the core package then, I guess, because jdbc.core.support is intended to refer to jdbc.core but not the other way round. jdbc.support would be OK too, provided that KeyHolder does not depend on jdbc.core.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Thomas Risberg
>Gesendet: Sa 17.07.2004 19:31
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Generated keys support
>
>
>
>I added a KeyHolder interface and a GeneratedKeyHolder class (in
>jdbc.support). They are used by the SqlUpdate.update(Object[],
>KeyHolder) method.
>
>Here is an example:
>
> SqlUpdate su = new SqlUpdate(dataSource, "insert into Show2
>(name) values(?)");
> su.declareParameter(new SqlParameter("name", Types.VARCHAR));
> su.setReturnGeneratedKeys(true);
> su.setGeneratedKeysColumnNames(new String[] {"id"}); //this has
>no effect for MySQL only DB2
> su.compile();
> Object[] val = {"Sven"};
> KeyHolder kh = new GeneratedKeyHolder();
> int updateCnt = su.update(val, kh);
> int myKey = kh.getKey().intValue();
> System.out.println("Key: " + myKey);
> List myKeys = kh.getKeyList();
> System.out.println(myKeys);
>
>Direct JdbcTemplate use would look like:
>
> KeyHolder kh = new GeneratedKeyHolder();
> int rowsAffected =
>getJdbcTemplate().update(newPreparedStatementCreator(args),
>kh.getKeyList());
>
>
>Thomas
>
>jürgen höller [werk3AT] wrote:
>
>
>
>>Thomas,
>>
>>We discussed changing the List argument for generated keys into a GeneratedKeysHolder class or the like, for easier access to a single generated key (the typical use case). If we change that, we should do so before 1.1 RC1, even if this means having 1.1 RC1 mid or late next week rather than on Monday.
>>
>>Juergen
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
|
|
From: <jue...@we...> - 2004-07-17 17:59:23
|
Oh, I didn't notice this. I was just wondering because JdbcTemplate's =
update(PreparedStatementCreator, List) method still takes a List for =
generated keys... Shouldn't it use a KeyHolder too? KeyHolder and co =
would have to reside in the core package then, I guess, because =
jdbc.core.support is intended to refer to jdbc.core but not the other =
way round. jdbc.support would be OK too, provided that KeyHolder does =
not depend on jdbc.core.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Sa 17.07.2004 19:31
An: spr...@li...
Betreff: Re: [Springframework-developer] Generated keys support
I added a KeyHolder interface and a GeneratedKeyHolder class (in
jdbc.support). They are used by the SqlUpdate.update(Object[],
KeyHolder) method.
Here is an example:
SqlUpdate su =3D new SqlUpdate(dataSource, "insert into Show2
(name) values(?)");
su.declareParameter(new SqlParameter("name", Types.VARCHAR));
su.setReturnGeneratedKeys(true);
su.setGeneratedKeysColumnNames(new String[] {"id"}); //this has
no effect for MySQL only DB2
su.compile();
Object[] val =3D {"Sven"};
KeyHolder kh =3D new GeneratedKeyHolder();
int updateCnt =3D su.update(val, kh);
int myKey =3D kh.getKey().intValue();
System.out.println("Key: " + myKey);
List myKeys =3D kh.getKeyList();
System.out.println(myKeys);
Direct JdbcTemplate use would look like:
KeyHolder kh =3D new GeneratedKeyHolder();
int rowsAffected =3D
getJdbcTemplate().update(newPreparedStatementCreator(args),
kh.getKeyList());
Thomas
j=FCrgen h=F6ller [werk3AT] wrote:
>Thomas,
>
>We discussed changing the List argument for generated keys into a =
GeneratedKeysHolder class or the like, for easier access to a single =
generated key (the typical use case). If we change that, we should do so =
before 1.1 RC1, even if this means having 1.1 RC1 mid or late next week =
rather than on Monday.
>
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dclick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>=20
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Thomas R. <tho...@tr...> - 2004-07-17 17:31:26
|
I added a KeyHolder interface and a GeneratedKeyHolder class (in
jdbc.support). They are used by the SqlUpdate.update(Object[],
KeyHolder) method.
Here is an example:
SqlUpdate su = new SqlUpdate(dataSource, "insert into Show2
(name) values(?)");
su.declareParameter(new SqlParameter("name", Types.VARCHAR));
su.setReturnGeneratedKeys(true);
su.setGeneratedKeysColumnNames(new String[] {"id"}); //this has
no effect for MySQL only DB2
su.compile();
Object[] val = {"Sven"};
KeyHolder kh = new GeneratedKeyHolder();
int updateCnt = su.update(val, kh);
int myKey = kh.getKey().intValue();
System.out.println("Key: " + myKey);
List myKeys = kh.getKeyList();
System.out.println(myKeys);
Direct JdbcTemplate use would look like:
KeyHolder kh = new GeneratedKeyHolder();
int rowsAffected =
getJdbcTemplate().update(newPreparedStatementCreator(args),
kh.getKeyList());
Thomas
jürgen höller [werk3AT] wrote:
>Thomas,
>
>We discussed changing the List argument for generated keys into a GeneratedKeysHolder class or the like, for easier access to a single generated key (the typical use case). If we change that, we should do so before 1.1 RC1, even if this means having 1.1 RC1 mid or late next week rather than on Monday.
>
>Juergen
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
|
|
From: <jue...@we...> - 2004-07-17 16:44:23
|
Thomas, =20 We discussed changing the List argument for generated keys into a = GeneratedKeysHolder class or the like, for easier access to a single = generated key (the typical use case). If we change that, we should do so = before 1.1 RC1, even if this means having 1.1 RC1 mid or late next week = rather than on Monday. =20 Juergen |
|
From: <jue...@we...> - 2004-07-17 16:39:50
|
In our current 1.1 codebase, we have an inconsistency regarding the use = of "advice" and "interceptor" in bean property names: AdvisedSupport has = a deprecated "addInterceptor" method now (without hinting at the = preferred method in javadoc, BTW), because of the preferred "addAdvice" = method. =20 While Advice is more general (being a super interface of Interceptor), a = number of other properties use "interceptor" in the name while accepting = Object, for example TransactionProxyFactoryBean's "preInterceptors" and = "postInterceptors", and also ProxyFactoryBean's "interceptorNames". =20 We need to make this consistent. We could either keep the "interceptor" = property names, allowing all kinds of Advices there: This would mean = that AdvisedSupport's "addInterceptor" should not be deprecated. Or we = could use "advice" in all those names: That would mean renaming = (respectively deprecating) quite popular properties. =20 When renaming bean properties, we need to consider that driving those = properties via XML bean definitions will not show any deprecation = warnings, just programmatic usage will. Consequently, many people will = not notice such deprecations, first discovering them when we remove the = deprecated bean properties... =20 Thoughts? Suggestions? =20 Juergen |
|
From: Rod J. <rod...@in...> - 2004-07-17 08:18:27
|
I believe it's the JMS stuff. I've raised it with Mark. ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Saturday, July 17, 2004 3:23 AM Subject: Re: [Springframework-developer] Ant 1.6.2 > It would still be nice to get all or most of the tests working in > Eclipse again, but it'll have to wait a while. In the meantime, it's > reasonable to run tests individually in Eclispe while writing code, and > then run everything from ant right before checking in to make sure > nothing's broken. > > Colin > > > Thomas Risberg wrote: > > > Colin, > > > > This is excellent. It seems like I can run the tests faster than I > > can type this email :-) The failing JUnit tests within Eclipse were > > starting to bother me and testing with Ant was too slow. Now the Ant > > tests take only 10% extra compared to running within Eclipse. > > Definitely worth the upgrade!!!! Thanks for figuring this out. > > > > Thomas > > > > Colin Sampaleanu wrote: > > > >> I spent a bit more time and got this going. Running the "tests" > >> target from command-line went down for me from about 6:40 to 1:37. > >> Note bad! > >> > >> To get things going, I set the <junit> element forkmode to > >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> > >> element, and added them as 3 separate single test <batchtests> (still > >> kept as <batchtest> instead of <test> so the default excludes would > >> still work. It's not that great to have to name tests individually > >> like this, but it's just a few. If this has to be done for a few > >> more, it will actually get less verbose to just use a separate junit > >> task instance, then one instance would have forkMode="perBatch", and > >> one forkMode="perTest" (the default). > >> > >> Regards, > >> Colin > >> > >> Colin Sampaleanu wrote: > >> > >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on the > >>> junit task, which allows ant to still fork for junit tests, but only > >>> once for the entire task (instead of for each testcase). > >>> Alternately, forkmode="perBatch" allows forking once per batch element. > >>> > >>> This is pretty promising, since it could bring the time to run the > >>> test suite from ant down to a similar value to when running in an > >>> IDE, which is currently much faster. > >>> > >>> I've tried to give it a go (making sure to remove the ant 1.6.1 in > >>> the lib dir, otherwise that will interfere), by adding > >>> forkmode="once" to the junit element in the tests target. It is > >>> currently breaking on SqlStateExceptionTranslatorTests, due to the > >>> initial context factory builder already being set. This should be > >>> resolvable by using a separate batch for that test, or some other > >>> strategy. I am curious however why this doesn't break in the IDE > >>> though. > >>> > >>> I don't have time to play with this any longer, but will give it a > >>> go at some later date. If anybody feels like playing around with > >>> this themselves, please go ahead by all means. > >>> > >>> Regards, > >>> Colin > >>> > >>> ----- > >>> > >>> [junit] Testsuite: > >>> org.springframework.jdbc.support.SQLStateExceptionTransla > >>> torTests > >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 sec > >>> > >>> [junit] Testcase: testBadSqlGrammar took 0 sec > >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec > >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec > >>> [junit] java.lang.ExceptionInInitializerError > >>> [junit] at java.lang.Class.forName0(Native Method) > >>> [junit] at java.lang.Class.forName(Class.java:141) > >>> [junit] at > >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >>> <init>(JUnitTestRunner.java:204) > >>> [junit] at > >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >>> <init>(JUnitTestRunner.java:177) > >>> [junit] at > >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >>> launch(JUnitTestRunner.java:651) > >>> [junit] at > >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. > >>> main(JUnitTestRunner.java:537) > >>> [junit] Caused by: java.lang.IllegalStateException: > >>> InitialContextFactoryBui > >>> lder already set > >>> [junit] at > >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde > >>> r(NamingManager.java:687) > >>> [junit] at > >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java > >>> :93) > >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
1239 messages has been excluded from this view by a project administrator.
