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: Stefan D S. <ste...@us...> - 2004-07-30 16:13:08
|
All, Is there a good reference on using declarative transaction with Spring and iBatis? I know that setting up the transaction in Spring should be transparent of the persisent implementation used in the case of iBatis, but if I need several tables to be updated with several insert statement, a failure to one does not appear to roll back the previous ones. Is there something I failed to configure in the setup of either Spring or iBatis? Thank you. |
|
From: <jue...@we...> - 2004-07-30 08:44:14
|
The nicest scenario is if you do *not* use Open Session in View now but = just have classic per-transaction sessions. In that case, if you want to = add lazy loading, simply plug in OpenSessionInViewFilter/Interceptor in = "deferred close" mode, and the semantics will be exactly the same as = before - just with the additional chance to lazy load until view = rendering has been completed. =20 Compared to plugging in OpenSessionInViewFilter in "single session" = mode, which changes your semantics quite severely, the "deferred close" = mode is a great benefit, I think. =20 The only disadvantage that I can see is that you won't get a = request-scoped first-level cache, which a single Hibernate session would = give you. So it's essentially about a tradeoff: clean transactional = semantics (which does not allow for a request-scoped cache) plus lazy = loading, or a request-scoped cache (which incurs unclean transactional = semantics but avoids rebuilding of object graphs) plus lazy loading? =20 It's also worth noting that rebuilding persistent object graphs for each = transaction is not that inefficient if you use lazy loading heavily: = You'll just get the actually needed object graph anyway, thus the = reloading respectively rebuilding overhead is limited. =20 Since Hibernate 2.1.4, the latter even applies if your entire object = graphs are cached in the second-level cache: Hibernate does not = materialize lazy parts of the object graph now, even if they are = available from the second-level cache. This is quite a gain in = efficiency if your object graphs are very large, where even rebuilding = from the second-level cache incurs a significant overhead. They silently = changed this between Hibernate 2.1.3 and 2.1.4, but at least into the = right direction :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Do 29.07.2004 19:58 An: spr...@li... Betreff: Re: [Springframework-developer] New deferred close mode for = OpenSessionInViewFilter/Interceptor I think this is cool and potentially pretty useful, in terms of simplifying lazy relation handling. Now somebody using Open Session in View now can not automatically swap out to this variant though, since if they are depending on sharing the same objects between different invocations down to transactional services, they are going to get exceptions from Hibernate when it sees that the objects are from different sessions. On the other hand, this is great for somebody that does want to call down once to a use-case defined service which retturns a graph of data, and now doesn't have to worry about touching all lazy relationships that might be needed. This actually brings the Hibernate scenario closer in line to what you can do with JDO 2 and handling of non-transactional graphs. Colin j=FCrgen h=F6ller [werk3AT] wrote: >Colin, > >As I was just discussing the issue with a colleague of mine, and as = you're known to not like the Open Session in View pattern ;-) > >What do you think regarding this "deferred close" mode for = OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That combination of correct transactional semantics plus lazy loading in = the view is a quite nice way to avoid the drawbacks of the classic = OpenSessionInViewFilter (what's now called "single session" mode). It = should never cause side effects but still allow for flexible lazy = loading. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of j=FCrgen h=F6ller [werk3AT] >Sent: Friday, July 09, 2004 7:39 PM >To: spr...@li... >Subject: [Springframework-developer] New deferred close mode for >OpenSessionInViewFilter/Interceptor > > >Due to numerous recent requests in that direction, I've implemented a = new mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single session per request: > >Each data access operation respectively transactions uses its own = Hibernate Session (like when not using Open Session in View). Each of = those sessions will be registered for deferred close, though, actually = processed at request completion. This does allow for lazy loading with = each of those sessions, but you won't get a single first-level cache for = the entire request, as there can be multiple Sessions. > >OpenSessionInViewFilter/Interceptor still uses a single session per = request by default, but allows to activate deferred close mode instead = by specifying "singleSession"=3D"false" as init-param respectively bean = property. > >Juergen > > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Danilo L. R. <da...@fl...> - 2004-07-30 00:40:28
|
Thomas Risberg wrote: > We have some code in the sandbox that allows you to retrieve a cached > rowset ... Will the queryForRowSet included on Spring 1.1 ? I think this is usefull and easy to implement. Are there any reason to not include it ? Danilo. |
|
From: <al...@jt...> - 2004-07-29 23:14:19
|
<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.65</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>07/30/2004 00:16:28</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 22 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed: </span>07/29/2004 19:15:12</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try: </span>make bean property setters and getters accessible even if =
defined in a package-protected superclass</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: =
(19) </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">test/org/springframework/bean=
s/BeanWrapperTestSuite.java</td><td class=3D"modifications-data">make bean =
property setters and getters accessible even if defined in a package-protec=
ted superclass</td></tr><tr class=3D"modifications-oddrow"><td class=3D"mod=
ifications-data">added</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">test/org/springframework/beans/support/Deriv=
edFromProtectedBaseBean.java</td><td class=3D"modifications-data">make bean=
property setters and getters accessible even if defined in a package-prote=
cted superclass</td></tr><tr class=3D"modifications-evenrow"><td class=3D"m=
odifications-data">added</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">test/org/springframework/beans/support/Pro=
tectedBaseBean.java</td><td class=3D"modifications-data">make bean property=
setters and getters accessible even if defined in a package-protected supe=
rclass</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificatio=
ns-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cla=
ss=3D"modifications-data">src/org/springframework/beans/CachedIntrospection=
Results.java</td><td class=3D"modifications-data">make bean property setter=
s and getters accessible even if defined in a package-protected superclass<=
/td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-dat=
a">modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"=
modifications-data">src/org/springframework/web/servlet/tags/TransformTag.j=
ava</td><td class=3D"modifications-data">added HTML escaping, to correspond=
to TLD</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modificati=
ons-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">test/org/springframework/web/servlet/tags/Transf=
ormTestSuite.java</td><td class=3D"modifications-data">added HTML escaping,=
to correspond to TLD</td></tr><tr class=3D"modifications-evenrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">john=
sonr</td><td class=3D"modifications-data">test/org/springframework/aop/fram=
ework/AbstractAopProxyTests.java</td><td class=3D"modifications-data">Test =
serializability of non-interceptor advice types. Added CountingThrowsAdvice=
.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D=
"modifications-data">test/org/springframework/aop/framework/MethodCounter.j=
ava</td><td class=3D"modifications-data">Test serializability of non-interc=
eptor advice types. Added CountingThrowsAdvice.</td></tr><tr class=3D"modif=
ications-evenrow"><td class=3D"modifications-data">added</td><td class=3D"m=
odifications-data">johnsonr</td><td class=3D"modifications-data">test/org/s=
pringframework/aop/framework/CountingThrowsAdvice.java</td><td class=3D"mod=
ifications-data">Test serializability of non-interceptor advice types. Adde=
d CountingThrowsAdvice.</td></tr><tr class=3D"modifications-oddrow"><td cla=
ss=3D"modifications-data">modified</td><td class=3D"modifications-data">joh=
nsonr</td><td class=3D"modifications-data">test/org/springframework/beans/P=
erson.java</td><td class=3D"modifications-data">Person.echo throws Throwabl=
e</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-d=
ata">modified</td><td class=3D"modifications-data">johnsonr</td><td class=
=3D"modifications-data">test/org/springframework/beans/SerializablePerson.j=
ava</td><td class=3D"modifications-data">Person.echo throws Throwable</td><=
/tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mod=
ified</td><td class=3D"modifications-data">johnsonr</td><td class=3D"modifi=
cations-data">test/org/springframework/aop/support/NameMatchMethodPointcutT=
ests.java</td><td class=3D"modifications-data">Person.echo throws Throwable=
</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D=
"modifications-data">src/org/springframework/aop/framework/adapter/AfterRet=
urningAdviceInterceptor.java</td><td class=3D"modifications-data">Made advi=
ce wrappers public to allow use outside Spring (in other AOP frameworkswrap=
ping Spring-specific advice). Made serializable.</td></tr><tr class=3D"modi=
fications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">johnsonr</td><td class=3D"modifications-data">src/o=
rg/springframework/aop/framework/adapter/MethodBeforeAdviceInterceptor.java=
</td><td class=3D"modifications-data">Made advice wrappers public to allow =
use outside Spring (in other AOP frameworkswrapping Spring-specific advice)=
. Made serializable.</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">johns=
onr</td><td class=3D"modifications-data">src/org/springframework/aop/framew=
ork/adapter/ThrowsAdviceInterceptor.java</td><td class=3D"modifications-dat=
a">Made advice wrappers public to allow use outside Spring (in other AOP fr=
ameworkswrapping Spring-specific advice). Made serializable.</td></tr><tr c=
lass=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td=
><td class=3D"modifications-data">johnsonr</td><td class=3D"modifications-d=
ata">src/org/springframework/aop/framework/adapter/package.html</td><td cla=
ss=3D"modifications-data">Made advice wrappers public to allow use outside =
Spring (in other AOP frameworkswrapping Spring-specific advice). Made seria=
lizable.</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifica=
tions-data">modified</td><td class=3D"modifications-data">jhoeller</td><td =
class=3D"modifications-data">test/org/springframework/beans/factory/xml/Xml=
BeanFactoryTestSuite.java</td><td class=3D"modifications-data">fixed "getBe=
ansOfType" and "isSingleton" for parent bean definitions without class</td>=
</tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">mo=
dified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modif=
ications-data">src/org/springframework/beans/factory/support/AbstractBeanFa=
ctory.java</td><td class=3D"modifications-data">fixed "getBeansOfType" and =
"isSingleton" for parent bean definitions without class</td></tr><tr class=
=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td><t=
d class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data=
">src/org/springframework/beans/factory/support/DefaultListableBeanFactory.=
java</td><td class=3D"modifications-data">fixed "getBeansOfType" and "isSin=
gleton" for parent bean definitions without class</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: James C. <jim...@do...> - 2004-07-29 19:46:25
|
Can you guys elaborate on this deferred close mode a bit more? Did I = miss an earlier posting? We have done a ton of experimenting with Open Session In View and = dropped it in favor of a service layer pattern. There are a bunch of tradeoffs to either approach and I am interested in learning about a potential third approach. > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of Colin Sampaleanu > Sent: Thursday, July 29, 2004 1:59 PM > To: spr...@li... > Subject: Re: [Springframework-developer] New deferred close mode for > OpenSessionInViewFilter/Interceptor >=20 > I think this is cool and potentially pretty useful, in terms of > simplifying lazy relation handling. Now somebody using Open Session in > View now can not automatically swap out to this variant though, since = if > they are depending on sharing the same objects between different > invocations down to transactional services, they are going to get > exceptions from Hibernate when it sees that the objects are from > different sessions. On the other hand, this is great for somebody that > does want to call down once to a use-case defined service which = retturns > a graph of data, and now doesn't have to worry about touching all lazy > relationships that might be needed. This actually brings the Hibernate > scenario closer in line to what you can do with JDO 2 and handling of > non-transactional graphs. >=20 > Colin >=20 > j=FCrgen h=F6ller [werk3AT] wrote: >=20 > >Colin, > > > >As I was just discussing the issue with a colleague of mine, and as > you're known to not like the Open Session in View pattern ;-) > > > >What do you think regarding this "deferred close" mode for > OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That > combination of correct transactional semantics plus lazy loading in = the > view is a quite nice way to avoid the drawbacks of the classic > OpenSessionInViewFilter (what's now called "single session" mode). It > should never cause side effects but still allow for flexible lazy = loading. > > > >Juergen > > > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...]On = Behalf > >Of j=FCrgen h=F6ller [werk3AT] > >Sent: Friday, July 09, 2004 7:39 PM > >To: spr...@li... > >Subject: [Springframework-developer] New deferred close mode for > >OpenSessionInViewFilter/Interceptor > > > > > >Due to numerous recent requests in that direction, I've implemented a = new > mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single > session per request: > > > >Each data access operation respectively transactions uses its own > Hibernate Session (like when not using Open Session in View). Each of > those sessions will be registered for deferred close, though, actually > processed at request completion. This does allow for lazy loading with > each of those sessions, but you won't get a single first-level cache = for > the entire request, as there can be multiple Sessions. > > > >OpenSessionInViewFilter/Interceptor still uses a single session per > request by default, but allows to activate deferred close mode instead = by > specifying "singleSession"=3D"false" as init-param respectively bean > property. > > > >Juergen > > > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes = on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source = Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Oliver G. <oli...@gm...> - 2004-07-29 18:15:53
|
Hi Oliver Geisser wrote: > Hi, > > we are currently evaluating an architecture for our application which > will use the follwing frameworks: [...] Sorry, this was for the user mailing list. Will resend it there... Bye, Olli --og |
|
From: Colin S. <col...@ex...> - 2004-07-29 17:59:55
|
I think this is cool and potentially pretty useful, in terms of simplifying lazy relation handling. Now somebody using Open Session in View now can not automatically swap out to this variant though, since if they are depending on sharing the same objects between different invocations down to transactional services, they are going to get exceptions from Hibernate when it sees that the objects are from different sessions. On the other hand, this is great for somebody that does want to call down once to a use-case defined service which retturns a graph of data, and now doesn't have to worry about touching all lazy relationships that might be needed. This actually brings the Hibernate scenario closer in line to what you can do with JDO 2 and handling of non-transactional graphs. Colin jürgen höller [werk3AT] wrote: >Colin, > >As I was just discussing the issue with a colleague of mine, and as you're known to not like the Open Session in View pattern ;-) > >What do you think regarding this "deferred close" mode for OpenSessionInViewFilter/Interceptor that I've introduced a while ago? That combination of correct transactional semantics plus lazy loading in the view is a quite nice way to avoid the drawbacks of the classic OpenSessionInViewFilter (what's now called "single session" mode). It should never cause side effects but still allow for flexible lazy loading. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of jürgen höller [werk3AT] >Sent: Friday, July 09, 2004 7:39 PM >To: spr...@li... >Subject: [Springframework-developer] New deferred close mode for >OpenSessionInViewFilter/Interceptor > > >Due to numerous recent requests in that direction, I've implemented a new mode for OpenSessionInViewFilter/Interceptor, as alternative to a single session per request: > >Each data access operation respectively transactions uses its own Hibernate Session (like when not using Open Session in View). Each of those sessions will be registered for deferred close, though, actually processed at request completion. This does allow for lazy loading with each of those sessions, but you won't get a single first-level cache for the entire request, as there can be multiple Sessions. > >OpenSessionInViewFilter/Interceptor still uses a single session per request by default, but allows to activate deferred close mode instead by specifying "singleSession"="false" as init-param respectively bean property. > >Juergen > > |
|
From: Colin S. <col...@ex...> - 2004-07-29 17:52:00
|
The -kk solution doesn't really work because then even binary files will be pulled out as text, so they'd have to be treated separately. Additionally, I don't remember seeing any kind of control over this in Eclipse last time I looked at its ability to do merges. William G. Thompson, Jr. wrote: > i'm not sure i feel strongly either way...traditionally I've always > put $Id$ in every text file I management in CVS. This has also been > the case in every open source project I have been involved in or > used. That is not neccesarily a good enough reason to continue to do > it... > > In web app dev $Id$ comes in really handy to verify the build process > ran correctly and the thing you thought was deployed actually got > deployed. for instance we put $Id$ in HTML comments for our Views so > that we can view source in the running app to check the versions. > > however, I also understand the problem with branch/merge...but why > doesn't the -kk solution work? > > +0 for $Id$ > > later. > Bill > > > Dmitriy Kopylenko wrote: > >> Let's give others a chance ;-) >> >> Alef, Keith, Mark, Bill.... what's your vote? >> >> >> Rob Harrop wrote: >> >>> Nothing like a good old fashioned standoff :) >>> >>> Shootout at noon? >>> >>> Rob >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...] On >>> Behalf Of >>> Dmitriy Kopylenko >>> Sent: 29 July 2004 16:16 >>> To: spr...@li... >>> Subject: Re: [Springframework-developer] @since and @version tags >>> >>> 3 for (Rod, Dmitriy, Rob) >>> 3 against (Juergen, Thomas, Colin) >>> 1 neutral (Darren) >>> >>> >>> Colin Sampaleanu wrote: >>> >>> >>> >>>> I do like $Id tags to be able to look at files and see who to blame >>>> for the last changes :-), but I would rather be able to >>>> branch/merge comfortably in the future. With Tortoise and Eclipse, >>>> I can see the revision history _very_ easily anyways, wherever I am. >>>> >>>> So -1 for using them from now on (i.e let's get rid of them)... >>>> >>>> >>>> Dmitriy Kopylenko wrote: >>>> >>>> >>>> >>>>> Well, let's take a vote. I'm for $Id tags (+1) >>>>> >>>>> Regards, >>>>> Dmitriy. >>>>> >>>>> >>>>> jürgen höller [werk3AT] wrote: >>>>> >>>>> >>>>> >>>>>> I'd actually prefer if we drop $Id tags from all files. I >>>>>> personally don't think that they add much value. Of course, if a >>>>>> democratic decision goes in favor of those tags, well, I'll >>>>>> concede ;-) >>>>>> >>>>>> Regarding @since tags, we're currently using them with the >>>>>> creation date. That has been quite nice during our agile way >>>>>> towards 1.0. We could indeed reconsider to use version numbers >>>>>> there now. >>>>>> >>>>>> Any suggestions on how to apply a consistent style for all source >>>>>> files in a batch, without messing them up? $Id is probably easy, >>>>>> @since nearly impossible, parameter alignment easy again. >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Von: spr...@li... im >>>>>> Auftrag von Colin Sampaleanu >>>>>> Gesendet: Mi 28.07.2004 20:38 >>>>>> An: spr...@li... >>>>>> Betreff: Re: [Springframework-developer] @since and @version tags >>>>>> >>>>>> >>>>>> >>>>>> Dmitriy Kopylenko wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> I like id keywords...they're mainly in the code through my >>>>>>>> classes or >>>>>>>> classes I've edited... (Damn, if it's standardized, I won't >>>>>>>> know if I've >>>>>>>> worked on a particular file any more :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I also insert $Id:$ when I work on existing classes or create >>>>>>> new ones >>>>>>> ;-) >>>>>>> >>>>>>> Dmitriy. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I personally like $Id tags. But they do suck big time when trying to >>>>>> merge files back in after a branch, causing a conflict/change to >>>>>> exist >>>>>> when there shouldn't be any... There seems to be a trend to going >>>>>> away >>>>>> from using them in files, by some people, for this reason. >>>>>> >>>>>> Colin >>>>>> >>>>> |
|
From: Colin S. <col...@ex...> - 2004-07-29 17:46:15
|
+1 Dmitriy Kopylenko wrote: > +1 > > Rob Harrop wrote: > >> Is there any objection to me modifying the build script to produce a >> nice >> HTML JUnit report for the sandbox tests? >> >> Rob > |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-29 17:32:17
|
3 in favor 4 against 2 neutral William G. Thompson, Jr. wrote: > i'm not sure i feel strongly either way...traditionally I've always > put $Id$ in every text file I management in CVS. This has also been > the case in every open source project I have been involved in or > used. That is not neccesarily a good enough reason to continue to do > it... > > In web app dev $Id$ comes in really handy to verify the build process > ran correctly and the thing you thought was deployed actually got > deployed. for instance we put $Id$ in HTML comments for our Views so > that we can view source in the running app to check the versions. > > however, I also understand the problem with branch/merge...but why > doesn't the -kk solution work? > > +0 for $Id$ > > later. > Bill > > > Dmitriy Kopylenko wrote: > >> Let's give others a chance ;-) >> >> Alef, Keith, Mark, Bill.... what's your vote? >> >> >> Rob Harrop wrote: >> >>> Nothing like a good old fashioned standoff :) >>> >>> Shootout at noon? >>> >>> Rob >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...] On >>> Behalf Of >>> Dmitriy Kopylenko >>> Sent: 29 July 2004 16:16 >>> To: spr...@li... >>> Subject: Re: [Springframework-developer] @since and @version tags >>> >>> 3 for (Rod, Dmitriy, Rob) >>> 3 against (Juergen, Thomas, Colin) >>> 1 neutral (Darren) >>> >>> >>> Colin Sampaleanu wrote: >>> >>> >>> >>>> I do like $Id tags to be able to look at files and see who to blame >>>> for the last changes :-), but I would rather be able to >>>> branch/merge comfortably in the future. With Tortoise and Eclipse, >>>> I can see the revision history _very_ easily anyways, wherever I am. >>>> >>>> So -1 for using them from now on (i.e let's get rid of them)... >>>> >>>> >>>> Dmitriy Kopylenko wrote: >>>> >>>> >>>> >>>>> Well, let's take a vote. I'm for $Id tags (+1) >>>>> >>>>> Regards, >>>>> Dmitriy. >>>>> >>>>> >>>>> jürgen höller [werk3AT] wrote: >>>>> >>>>> >>>>> >>>>>> I'd actually prefer if we drop $Id tags from all files. I >>>>>> personally don't think that they add much value. Of course, if a >>>>>> democratic decision goes in favor of those tags, well, I'll >>>>>> concede ;-) >>>>>> >>>>>> Regarding @since tags, we're currently using them with the >>>>>> creation date. That has been quite nice during our agile way >>>>>> towards 1.0. We could indeed reconsider to use version numbers >>>>>> there now. >>>>>> >>>>>> Any suggestions on how to apply a consistent style for all source >>>>>> files in a batch, without messing them up? $Id is probably easy, >>>>>> @since nearly impossible, parameter alignment easy again. >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Von: spr...@li... im >>>>>> Auftrag von Colin Sampaleanu >>>>>> Gesendet: Mi 28.07.2004 20:38 >>>>>> An: spr...@li... >>>>>> Betreff: Re: [Springframework-developer] @since and @version tags >>>>>> >>>>>> >>>>>> >>>>>> Dmitriy Kopylenko wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> I like id keywords...they're mainly in the code through my >>>>>>>> classes or >>>>>>>> classes I've edited... (Damn, if it's standardized, I won't >>>>>>>> know if I've >>>>>>>> worked on a particular file any more :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I also insert $Id:$ when I work on existing classes or create >>>>>>> new ones >>>>>>> ;-) >>>>>>> >>>>>>> Dmitriy. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I personally like $Id tags. But they do suck big time when trying to >>>>>> merge files back in after a branch, causing a conflict/change to >>>>>> exist >>>>>> when there shouldn't be any... There seems to be a trend to going >>>>>> away >>>>>> from using them in files, by some people, for this reason. >>>>>> >>>>>> Colin >>>>>> >>>>> >>>>> >>>>> >>>> >>>> > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rob H. <ro...@ca...> - 2004-07-29 17:27:01
|
All, Added some more JMX modifications to the sandbox. The MBeanServer can now be set on the JmxMBeanAdapter using setter injection and a I provided an MBeanServerFactoryBean for this purpose. JmxMBeanAdapter will still try to locate the server using MBeanServerFactory if one is not supplied. Added the basis of support for attribute change notification and that seems to be functioning but you can't remove the listeners yet. The spec is VERY unclear on this aspect so I plan to test this with a few different JXM implementations to make sure it works! Rob |
|
From: William G. T. Jr. <wg...@ru...> - 2004-07-29 17:26:33
|
i'm not sure i feel strongly either way...traditionally I've always put $Id$ in every text file I management in CVS. This has also been the case in every open source project I have been involved in or used. That is not neccesarily a good enough reason to continue to do it... In web app dev $Id$ comes in really handy to verify the build process ran correctly and the thing you thought was deployed actually got deployed. for instance we put $Id$ in HTML comments for our Views so that we can view source in the running app to check the versions. however, I also understand the problem with branch/merge...but why doesn't the -kk solution work? +0 for $Id$ later. Bill Dmitriy Kopylenko wrote: > Let's give others a chance ;-) > > Alef, Keith, Mark, Bill.... what's your vote? > > > Rob Harrop wrote: > >> Nothing like a good old fashioned standoff :) >> >> Shootout at noon? >> >> Rob >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...] On >> Behalf Of >> Dmitriy Kopylenko >> Sent: 29 July 2004 16:16 >> To: spr...@li... >> Subject: Re: [Springframework-developer] @since and @version tags >> >> 3 for (Rod, Dmitriy, Rob) >> 3 against (Juergen, Thomas, Colin) >> 1 neutral (Darren) >> >> >> Colin Sampaleanu wrote: >> >> >> >>> I do like $Id tags to be able to look at files and see who to blame >>> for the last changes :-), but I would rather be able to branch/merge >>> comfortably in the future. With Tortoise and Eclipse, I can see the >>> revision history _very_ easily anyways, wherever I am. >>> >>> So -1 for using them from now on (i.e let's get rid of them)... >>> >>> >>> Dmitriy Kopylenko wrote: >>> >>> >>> >>>> Well, let's take a vote. I'm for $Id tags (+1) >>>> >>>> Regards, >>>> Dmitriy. >>>> >>>> >>>> jürgen höller [werk3AT] wrote: >>>> >>>> >>>> >>>>> I'd actually prefer if we drop $Id tags from all files. I >>>>> personally don't think that they add much value. Of course, if a >>>>> democratic decision goes in favor of those tags, well, I'll concede >>>>> ;-) >>>>> >>>>> Regarding @since tags, we're currently using them with the creation >>>>> date. That has been quite nice during our agile way towards 1.0. We >>>>> could indeed reconsider to use version numbers there now. >>>>> >>>>> Any suggestions on how to apply a consistent style for all source >>>>> files in a batch, without messing them up? $Id is probably easy, >>>>> @since nearly impossible, parameter alignment easy again. >>>>> >>>>> Juergen >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> Von: spr...@li... im >>>>> Auftrag von Colin Sampaleanu >>>>> Gesendet: Mi 28.07.2004 20:38 >>>>> An: spr...@li... >>>>> Betreff: Re: [Springframework-developer] @since and @version tags >>>>> >>>>> >>>>> >>>>> Dmitriy Kopylenko wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> I like id keywords...they're mainly in the code through my >>>>>>> classes or >>>>>>> classes I've edited... (Damn, if it's standardized, I won't know >>>>>>> if I've >>>>>>> worked on a particular file any more :-) >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I also insert $Id:$ when I work on existing classes or create new >>>>>> ones >>>>>> ;-) >>>>>> >>>>>> Dmitriy. >>>>>> >>>>>> >>>>> >>>>> >>>>> I personally like $Id tags. But they do suck big time when trying to >>>>> merge files back in after a branch, causing a conflict/change to exist >>>>> when there shouldn't be any... There seems to be a trend to going away >>>>> from using them in files, by some people, for this reason. >>>>> >>>>> Colin >>>>> >>>> >>>> >>> |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-29 17:25:46
|
+1 Rob Harrop wrote: >Is there any objection to me modifying the build script to produce a nice >HTML JUnit report for the sandbox tests? > >Rob > > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: <jue...@we...> - 2004-07-29 17:20:55
|
Colin, As I was just discussing the issue with a colleague of mine, and as = you're known to not like the Open Session in View pattern ;-) What do you think regarding this "deferred close" mode for = OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That combination of correct transactional semantics plus lazy loading in = the view is a quite nice way to avoid the drawbacks of the classic = OpenSessionInViewFilter (what's now called "single session" mode). It = should never cause side effects but still allow for flexible lazy = loading. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Friday, July 09, 2004 7:39 PM To: spr...@li... Subject: [Springframework-developer] New deferred close mode for OpenSessionInViewFilter/Interceptor Due to numerous recent requests in that direction, I've implemented a = new mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single session per request:=20 Each data access operation respectively transactions uses its own = Hibernate Session (like when not using Open Session in View). Each of = those sessions will be registered for deferred close, though, actually = processed at request completion. This does allow for lazy loading with = each of those sessions, but you won't get a single first-level cache for = the entire request, as there can be multiple Sessions.=20 OpenSessionInViewFilter/Interceptor still uses a single session per = request by default, but allows to activate deferred close mode instead = by specifying "singleSession"=3D"false" as init-param respectively bean = property.=20 Juergen =20 ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rob H. <ro...@ca...> - 2004-07-29 16:26:01
|
Is there any objection to me modifying the build script to produce a nice HTML JUnit report for the sandbox tests? Rob |
|
From: Mark P. <mar...@co...> - 2004-07-29 15:53:29
|
Hi, Sending again.... --------------------------- I don=92t vote often, but -1 for using $Id$ in @version. I don't think = end users really care to see the CVS id in the javadocs, it just adds noise. Maybe a non javadoc style comment in the code with $Id$ is a reasonable compromise? I'd like to see @since be the release # of spring since it = is more meaningful to users. =20 - Mark > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of Dmitriy Kopylenko > Sent: Thursday, July 29, 2004 11:36 AM > To: spr...@li... > Subject: Re: [Springframework-developer] @since and @version tags >=20 >=20 > Let's give others a chance ;-) >=20 > Alef, Keith, Mark, Bill.... what's your vote? >=20 >=20 > Rob Harrop wrote: >=20 > >Nothing like a good old fashioned standoff :) > > > >Shootout at noon? > > > >Rob > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...] On=20 > >Behalf Of Dmitriy Kopylenko > >Sent: 29 July 2004 16:16 > >To: spr...@li... > >Subject: Re: [Springframework-developer] @since and @version tags > > > >3 for (Rod, Dmitriy, Rob) > >3 against (Juergen, Thomas, Colin) > >1 neutral (Darren) > > > > > >Colin Sampaleanu wrote: > > > > =20 > > > >>I do like $Id tags to be able to look at files and see who to blame > >>for the last changes :-), but I would rather be able to=20 > branch/merge=20 > >>comfortably in the future. With Tortoise and Eclipse, I can see the=20 > >>revision history _very_ easily anyways, wherever I am. > >> > >>So -1 for using them from now on (i.e let's get rid of them)... > >> > >> > >>Dmitriy Kopylenko wrote: > >> > >> =20 > >> > >>>Well, let's take a vote. I'm for $Id tags (+1) > >>> > >>>Regards, > >>>Dmitriy. > >>> > >>> > >>>j=FCrgen h=F6ller [werk3AT] wrote: > >>> > >>> =20 > >>> > >>>>I'd actually prefer if we drop $Id tags from all files. I=20 > personally > >>>>don't think that they add much value. Of course, if a democratic=20 > >>>>decision goes in favor of those tags, well, I'll concede ;-) > >>>> > >>>>Regarding @since tags, we're currently using them with=20 > the creation > >>>>date. That has been quite nice during our agile way=20 > towards 1.0. We=20 > >>>>could indeed reconsider to use version numbers there now. > >>>> > >>>>Any suggestions on how to apply a consistent style for all source > >>>>files in a batch, without messing them up? $Id is probably easy,=20 > >>>>@since nearly impossible, parameter alignment easy again. > >>>> > >>>>Juergen > >>>> > >>>> > >>>>________________________________ > >>>> > >>>>Von: spr...@li... im > >>>>Auftrag von Colin Sampaleanu > >>>>Gesendet: Mi 28.07.2004 20:38 > >>>>An: spr...@li... > >>>>Betreff: Re: [Springframework-developer] @since and @version tags > >>>> > >>>> > >>>> > >>>>Dmitriy Kopylenko wrote: > >>>> > >>>>=20 > >>>> > >>>> =20 > >>>> > >>>>>>I like id keywords...they're mainly in the code through=20 > my classes=20 > >>>>>>or classes I've edited... (Damn, if it's standardized, I won't=20 > >>>>>>know if I've worked on a particular file any more :-) > >>>>>> > >>>>>> > >>>>>> =20 > >>>>>> =20 > >>>>>> > >>>>>I also insert $Id:$ when I work on existing classes or=20 > create new=20 > >>>>>ones > >>>>>;-) > >>>>> > >>>>>Dmitriy. > >>>>> =20 > >>>>> =20 > >>>>> > >>>> > >>>>I personally like $Id tags. But they do suck big time=20 > when trying to=20 > >>>>merge files back in after a branch, causing a conflict/change to=20 > >>>>exist when there shouldn't be any... There seems to be a trend to=20 > >>>>going away from using them in files, by some people, for this=20 > >>>>reason. > >>>> > >>>>Colin > >>>> =20 > >>>> > >>> =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.=20 > >>http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick > >>_______________________________________________ > >>Springframework-developer mailing list=20 > >>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.=20 > >http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick > >_______________________________________________ > >Springframework-developer mailing list=20 > >Spr...@li... > >https://lists.sourceforge.net/lists/listinfo/springframework- developer > > > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on = >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,=20 >one more big change to announce. We are now OSTG- Open Source=20 >Technology Group. Come see the changes on the new OSTG site.=20 >www.ostg.com _______________________________________________ >Springframework-developer mailing list=20 >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > =20 > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, = one more big change to announce. We are now OSTG- Open Source Technology = Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Mark P. <mar...@co...> - 2004-07-29 15:45:00
|
Hi, I don't vote often, but -1 for using $Id$ in @version. I don't think end users really care to see the CVS id in the javadocs, it just adds noise. Maybe a non javadoc style comment in the code with $Id$ is a reasonable compromise? I'd like to see @since be the release # of spring since it is more meaningful to users. - Mark > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] > On Behalf Of Dmitriy Kopylenko > Sent: Thursday, July 29, 2004 8:35 AM > To: spr...@li... > Subject: Re: [Springframework-developer] @since and @version tags > > > So far it's 3 in favor, 2 against > > > Rob Harrop wrote: > > >+1 here as well - I find that the $Id$ tag is quite useful. > > > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...] On > >Behalf Of Rod Johnson > >Sent: 29 July 2004 13:09 > >To: spr...@li... > >Subject: Re: [Springframework-developer] @since and @version tags > > > >+1 for $Id. > > > >I like to be able to see who last edited the file without looking at > >resource history (for example, offline). It also helps to > see whether a > >CVS commit has succeeded. > > > >----- Original Message ----- > >From: "Dmitriy Kopylenko" <dko...@ru...> > >To: <spr...@li...> > >Sent: Thursday, July 29, 2004 12:49 PM > >Subject: Re: [Springframework-developer] @since and @version tags > > > > > > > > > >>Well, let's take a vote. I'm for $Id tags (+1) > >> > >> > > > > > > > > > >------------------------------------------------------- |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-29 15:34:48
|
Let's give others a chance ;-) Alef, Keith, Mark, Bill.... what's your vote? Rob Harrop wrote: >Nothing like a good old fashioned standoff :) > >Shootout at noon? > >Rob > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...] On Behalf Of >Dmitriy Kopylenko >Sent: 29 July 2004 16:16 >To: spr...@li... >Subject: Re: [Springframework-developer] @since and @version tags > >3 for (Rod, Dmitriy, Rob) >3 against (Juergen, Thomas, Colin) >1 neutral (Darren) > > >Colin Sampaleanu wrote: > > > >>I do like $Id tags to be able to look at files and see who to blame >>for the last changes :-), but I would rather be able to branch/merge >>comfortably in the future. With Tortoise and Eclipse, I can see the >>revision history _very_ easily anyways, wherever I am. >> >>So -1 for using them from now on (i.e let's get rid of them)... >> >> >>Dmitriy Kopylenko wrote: >> >> >> >>>Well, let's take a vote. I'm for $Id tags (+1) >>> >>>Regards, >>>Dmitriy. >>> >>> >>>jürgen höller [werk3AT] wrote: >>> >>> >>> >>>>I'd actually prefer if we drop $Id tags from all files. I personally >>>>don't think that they add much value. Of course, if a democratic >>>>decision goes in favor of those tags, well, I'll concede ;-) >>>> >>>>Regarding @since tags, we're currently using them with the creation >>>>date. That has been quite nice during our agile way towards 1.0. We >>>>could indeed reconsider to use version numbers there now. >>>> >>>>Any suggestions on how to apply a consistent style for all source >>>>files in a batch, without messing them up? $Id is probably easy, >>>>@since nearly impossible, parameter alignment easy again. >>>> >>>>Juergen >>>> >>>> >>>>________________________________ >>>> >>>>Von: spr...@li... im >>>>Auftrag von Colin Sampaleanu >>>>Gesendet: Mi 28.07.2004 20:38 >>>>An: spr...@li... >>>>Betreff: Re: [Springframework-developer] @since and @version tags >>>> >>>> >>>> >>>>Dmitriy Kopylenko wrote: >>>> >>>> >>>> >>>> >>>> >>>>>>I like id keywords...they're mainly in the code through my classes or >>>>>>classes I've edited... (Damn, if it's standardized, I won't know >>>>>>if I've >>>>>>worked on a particular file any more :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I also insert $Id:$ when I work on existing classes or create new ones >>>>>;-) >>>>> >>>>>Dmitriy. >>>>> >>>>> >>>>> >>>> >>>>I personally like $Id tags. But they do suck big time when trying to >>>>merge files back in after a branch, causing a conflict/change to exist >>>>when there shouldn't be any... There seems to be a trend to going away >>>>from using them in files, by some people, for this reason. >>>> >>>>Colin >>>> >>>> >>> >>> >> >> >>------------------------------------------------------- >>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 OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Rob H. <ro...@ca...> - 2004-07-29 15:26:14
|
Nothing like a good old fashioned standoff :) Shootout at noon? Rob -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Dmitriy Kopylenko Sent: 29 July 2004 16:16 To: spr...@li... Subject: Re: [Springframework-developer] @since and @version tags 3 for (Rod, Dmitriy, Rob) 3 against (Juergen, Thomas, Colin) 1 neutral (Darren) Colin Sampaleanu wrote: > I do like $Id tags to be able to look at files and see who to blame=20 > for the last changes :-), but I would rather be able to branch/merge=20 > comfortably in the future. With Tortoise and Eclipse, I can see the=20 > revision history _very_ easily anyways, wherever I am. > > So -1 for using them from now on (i.e let's get rid of them)... > > > Dmitriy Kopylenko wrote: > >> Well, let's take a vote. I'm for $Id tags (+1) >> >> Regards, >> Dmitriy. >> >> >> j=FCrgen h=F6ller [werk3AT] wrote: >> >>> I'd actually prefer if we drop $Id tags from all files. I personally = >>> don't think that they add much value. Of course, if a democratic=20 >>> decision goes in favor of those tags, well, I'll concede ;-) >>> >>> Regarding @since tags, we're currently using them with the creation=20 >>> date. That has been quite nice during our agile way towards 1.0. We=20 >>> could indeed reconsider to use version numbers there now. >>> >>> Any suggestions on how to apply a consistent style for all source=20 >>> files in a batch, without messing them up? $Id is probably easy,=20 >>> @since nearly impossible, parameter alignment easy again. >>> >>> Juergen >>> >>> >>> ________________________________ >>> >>> Von: spr...@li... im=20 >>> Auftrag von Colin Sampaleanu >>> Gesendet: Mi 28.07.2004 20:38 >>> An: spr...@li... >>> Betreff: Re: [Springframework-developer] @since and @version tags >>> >>> >>> >>> Dmitriy Kopylenko wrote: >>> >>> =20 >>> >>>>> I like id keywords...they're mainly in the code through my classes = or >>>>> classes I've edited... (Damn, if it's standardized, I won't know=20 >>>>> if I've >>>>> worked on a particular file any more :-) >>>>> >>>>> >>>>> =20 >>>> >>>> >>>> I also insert $Id:$ when I work on existing classes or create new = ones >>>> ;-) >>>> >>>> Dmitriy. >>>> =20 >>> >>> >>> >>> I personally like $Id tags. But they do suck big time when trying to >>> merge files back in after a branch, causing a conflict/change to = exist >>> when there shouldn't be any... There seems to be a trend to going = away >>> from using them in files, by some people, for this reason. >>> >>> Colin >> >> > > > > > ------------------------------------------------------- > 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-29 15:14:51
|
3 for (Rod, Dmitriy, Rob) 3 against (Juergen, Thomas, Colin) 1 neutral (Darren) Colin Sampaleanu wrote: > I do like $Id tags to be able to look at files and see who to blame > for the last changes :-), but I would rather be able to branch/merge > comfortably in the future. With Tortoise and Eclipse, I can see the > revision history _very_ easily anyways, wherever I am. > > So -1 for using them from now on (i.e let's get rid of them)... > > > Dmitriy Kopylenko wrote: > >> Well, let's take a vote. I'm for $Id tags (+1) >> >> Regards, >> Dmitriy. >> >> >> jürgen höller [werk3AT] wrote: >> >>> I'd actually prefer if we drop $Id tags from all files. I personally >>> don't think that they add much value. Of course, if a democratic >>> decision goes in favor of those tags, well, I'll concede ;-) >>> >>> Regarding @since tags, we're currently using them with the creation >>> date. That has been quite nice during our agile way towards 1.0. We >>> could indeed reconsider to use version numbers there now. >>> >>> Any suggestions on how to apply a consistent style for all source >>> files in a batch, without messing them up? $Id is probably easy, >>> @since nearly impossible, parameter alignment easy again. >>> >>> Juergen >>> >>> >>> ________________________________ >>> >>> Von: spr...@li... im >>> Auftrag von Colin Sampaleanu >>> Gesendet: Mi 28.07.2004 20:38 >>> An: spr...@li... >>> Betreff: Re: [Springframework-developer] @since and @version tags >>> >>> >>> >>> Dmitriy Kopylenko wrote: >>> >>> >>> >>>>> I like id keywords...they're mainly in the code through my classes or >>>>> classes I've edited... (Damn, if it's standardized, I won't know >>>>> if I've >>>>> worked on a particular file any more :-) >>>>> >>>>> >>>>> >>>> >>>> >>>> I also insert $Id:$ when I work on existing classes or create new ones >>>> ;-) >>>> >>>> Dmitriy. >>>> >>> >>> >>> >>> I personally like $Id tags. But they do suck big time when trying to >>> merge files back in after a branch, causing a conflict/change to exist >>> when there shouldn't be any... There seems to be a trend to going away >>> from using them in files, by some people, for this reason. >>> >>> Colin >> >> > > > > > ------------------------------------------------------- > 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: Stefan D S. <ste...@us...> - 2004-07-29 15:04:36
|
Even doing this in the SimpleFormController is returning empty string. RequestUtils.getStringParameter(request, "submit", "")); This is in the form. There is only one form on the page. <INPUT TYPE=3D"image" SRC=3D"/images/buttons/BLUESUBMIT.png" VALUE=3D"ins= ert" NAME=3D"submit"> = <INPUT TYPE=3D"image" SRC=3D"/images/buttons/DELETE.png" VALUE=3D"delete"= NAME=3D"delete"> <INPUT TYPE=3D"image" SRC=3D"/images/buttons/Cancel.png" VALUE=3D"cancel"= NAME=3D"cancel"> Wednesday, July 28, 2004 9:43 PM To: spr...@li... cc: = From: Seth Ladd <set...@gm...> Subject: Re: [Springframework-developer] Validation: multiple image butto= ns on forms On Wed, 28 Jul 2004 20:39:35 -0400, Stefan D Sookraj <ste...@us...> wrote: > > > Seth, > Thanks for the reply, but since this is need as part of my validator, i= s > there not a way to get a hold of the request in the validator? You can use the method onBindAndValidate(). That's in the Controller, but at least you get access to the Request object in there. > > BTW - I have a property on the command class, it is just not getting se= t > (bind?). It returns an empty string. Any exceptions? Maybe a misspelling? Does the log say anything? What is the name of your property? 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-29 15:04:23
|
I do like $Id tags to be able to look at files and see who to blame for the last changes :-), but I would rather be able to branch/merge comfortably in the future. With Tortoise and Eclipse, I can see the revision history _very_ easily anyways, wherever I am. So -1 for using them from now on (i.e let's get rid of them)... Dmitriy Kopylenko wrote: > Well, let's take a vote. I'm for $Id tags (+1) > > Regards, > Dmitriy. > > > jürgen höller [werk3AT] wrote: > >> I'd actually prefer if we drop $Id tags from all files. I personally >> don't think that they add much value. Of course, if a democratic >> decision goes in favor of those tags, well, I'll concede ;-) >> >> Regarding @since tags, we're currently using them with the creation >> date. That has been quite nice during our agile way towards 1.0. We >> could indeed reconsider to use version numbers there now. >> >> Any suggestions on how to apply a consistent style for all source >> files in a batch, without messing them up? $Id is probably easy, >> @since nearly impossible, parameter alignment easy again. >> >> Juergen >> >> >> ________________________________ >> >> Von: spr...@li... im Auftrag >> von Colin Sampaleanu >> Gesendet: Mi 28.07.2004 20:38 >> An: spr...@li... >> Betreff: Re: [Springframework-developer] @since and @version tags >> >> >> >> Dmitriy Kopylenko wrote: >> >> >> >>>> I like id keywords...they're mainly in the code through my classes or >>>> classes I've edited... (Damn, if it's standardized, I won't know if >>>> I've >>>> worked on a particular file any more :-) >>>> >>>> >>>> >>> >>> I also insert $Id:$ when I work on existing classes or create new ones >>> ;-) >>> >>> Dmitriy. >>> >> >> >> I personally like $Id tags. But they do suck big time when trying to >> merge files back in after a branch, causing a conflict/change to exist >> when there shouldn't be any... There seems to be a trend to going away >> from using them in files, by some people, for this reason. >> >> Colin > |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-29 14:19:03
|
Claus, it's already been corrected in CVS Dmitriy. Claus Ibsen wrote: >Reading the changelog for the newly released version if found this typo. > >* deprected RegexpMethodPointcut to allow for other regexp syntaxes besides >Perl5: use Perl5RegexpMethodPointcut > >There is an 'a' missing in deprecated ;) > > > > > >------------------------------------------------------- >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: Rod J. <rod...@in...> - 2004-07-29 14:16:49
|
Thanks Claus--I noticed about 2 minutes after Juergen did the upload. It's already fixed in CVS, along with 1 or 2 more. R ----- Original Message ----- From: "Claus Ibsen" <cs...@ma...> To: <spr...@li...> Sent: Thursday, July 29, 2004 2:52 PM Subject: [Springframework-developer] typo in changelog.txt for v1.1rc1 > Reading the changelog for the newly released version if found this typo. > > * deprected RegexpMethodPointcut to allow for other regexp syntaxes besides > Perl5: use Perl5RegexpMethodPointcut > > There is an 'a' missing in deprecated ;) > > > > > > ------------------------------------------------------- > 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: Claus I. <cs...@ma...> - 2004-07-29 14:00:26
|
Reading the changelog for the newly released version if found this typo. * deprected RegexpMethodPointcut to allow for other regexp syntaxes besides Perl5: use Perl5RegexpMethodPointcut There is an 'a' missing in deprecated ;) |
1239 messages has been excluded from this view by a project administrator.
