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: jack h. <hij...@ho...> - 2004-06-10 01:40:19
|
Hi,all
Two things I want to improve Spring framwork:
1) Add cache component to Spring
2) Add one ant task for generating Bean Dependency Graph. This
function I still consider.
Any suggestion?
regards!
Hope Ton
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
|
|
From: Rob M. <Rob...@pe...> - 2004-06-09 23:16:51
|
jürgen höller [werk3AT] wrote:
> Actually, Spring does provide a default StringArrayPropertyEditor that separates CSV into multiple String values, being able to convert the individual values then. So you should be able to register an editor for Long, driving it with a CSV String.
>
> Registering for an array itself is straightforward:
>
> binder.registerCustomEditor(Boolean[].class, new PropertyEditorSupport() {
> public void setAsText(String text) {
> Boolean[] array = new Boolean[];
> ...
> setValue(array);
> }
> });
>
Ah, okay. I didn't realize you could declare an array class reference
like that. Thanks for the nudge -- it worked like a charm.
Muchas gracias,
Rob
|
|
From: <jue...@we...> - 2004-06-09 22:31:01
|
Actually, Spring does provide a default StringArrayPropertyEditor that =
separates CSV into multiple String values, being able to convert the =
individual values then. So you should be able to register an editor for =
Long, driving it with a CSV String.
=20
Registering for an array itself is straightforward:
=20
binder.registerCustomEditor(Boolean[].class, new PropertyEditorSupport() =
{
public void setAsText(String text) {
Boolean[] array =3D new Boolean[];
...
setValue(array);
}
});
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Rob Moore
Gesendet: Do 10.06.2004 00:05
An: spr...@li...
Betreff: [Springframework-developer] Re: PropertyEditor question
j=FCrgen h=F6ller [werk3AT] wrote:
> Sure, simply register a custom editor for your property (respectively =
the property type Long[]) that takes the CSV value as text and converts =
it into a Long[] value.
>=20
> Juergen
>=20
>
I must have misunderstood -- I had the impression this the framework
already provided a property editor to perform this conversion from a CSV
to a specified object type.
So how does one indicate the editor should apply to an array rather than
a single object? IOW, in initBinder for my controller I have the =
following:
binder.registerCustomEditor(Boolean.class, new =
CustomBooleanEditor(true));
How would I specify that I want my custom editor to be used for an array
of Booleans rather than just a single Boolean?
Thanks,
Rob
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <al...@jt...> - 2004-06-09 22:17:12
|
<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.23</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build: </span>06/10/2004 00:15:56</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>8 minutes 33 seconds</td></tr><tr><td class=3D"header-data"><span=
class=3D"header-label">Last changed: </span>06/09/2004 18:34:02</td><=
/tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log ent=
ry: </span>updated to Quartz 1.3.4</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: /jteam/build/checkout/spring/s=
pring/test/org/springframework/mail/MailTestSuite.java uses or overrides a =
deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation for de=
tails.<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: (1458) </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2"> All Tests Pas=
sed </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></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: =
(23) </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">lib/quartz/quartz.jar</td><td=
class=3D"modifications-data">updated to Quartz 1.3.4</td></tr><tr class=3D=
"modifications-oddrow"><td class=3D"modifications-data">modified</td><td cl=
ass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sr=
c/org/springframework/aop/framework/adapter/UnknownAdviceTypeException.java=
</td><td class=3D"modifications-data">check for null advice</td></tr><tr cl=
ass=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td=
><td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-d=
ata">src/org/springframework/jdbc/support/nativejdbc/SimpleNativeJdbcExtrac=
tor.java</td><td class=3D"modifications-data">adapted javadoc to further te=
sts with a variety of connection pools</td></tr><tr class=3D"modifications-=
oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modifica=
tions-data">jhoeller</td><td class=3D"modifications-data">src/org/springfra=
mework/jdbc/support/nativejdbc/WebLogicNativeJdbcExtractor.java</td><td cla=
ss=3D"modifications-data">polishing</td></tr><tr class=3D"modifications-eve=
nrow"><td class=3D"modifications-data">modified</td><td class=3D"modificati=
ons-data">jhoeller</td><td class=3D"modifications-data">lib/jakarta-commons=
/commons-dbcp.jar</td><td class=3D"modifications-data">updated to Commons D=
BCP 1.2</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">lib/jakarta-commons/commons-pool.jar</td><td cla=
ss=3D"modifications-data">updated to Commons DBCP 1.2</td></tr><tr class=3D=
"modifications-evenrow"><td class=3D"modifications-data">modified</td><td c=
lass=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">s=
rc/org/springframework/jdbc/support/nativejdbc/CommonsDbcpNativeJdbcExtract=
or.java</td><td class=3D"modifications-data">adapted for Commons DBCP 1.2</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mo=
difications-data">test/org/springframework/aop/framework/CountingBeforeAdvi=
ce.java</td><td class=3D"modifications-data">polishing</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=
">test/org/springframework/aop/support/RegexpMethodPointcutTests.java</td><=
td class=3D"modifications-data">polishing</td></tr><tr class=3D"modificatio=
ns-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">jhoeller</td><td class=3D"modifications-data">src/org/spring=
framework/scheduling/quartz/JobDetailBean.java</td><td class=3D"modificatio=
ns-data">polishing</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">src/org/springframework/scheduling=
/quartz/MethodInvokingJobDetailFactoryBean.java</td><td class=3D"modificati=
ons-data">polishing</td></tr><tr class=3D"modifications-oddrow"><td class=
=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoel=
ler</td><td class=3D"modifications-data">src/org/springframework/orm/hibern=
ate/LocalDataSourceConnectionProvider.java</td><td class=3D"modifications-d=
ata">polishing</td></tr><tr class=3D"modifications-evenrow"><td class=3D"mo=
difications-data">modified</td><td class=3D"modifications-data">jhoeller</t=
d><td class=3D"modifications-data">src/org/springframework/jdbc/support/Dat=
abaseStartupValidator.java</td><td class=3D"modifications-data">polishing</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>added</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modif=
ications-data">src/org/springframework/scheduling/quartz/LocalDataSourceJob=
Store.java</td><td class=3D"modifications-data">added "jobSchedulingDataLoc=
ation" and "dataSource" properties to SchedulerFactoryBean</td></tr><tr cla=
ss=3D"modifications-evenrow"><td class=3D"modifications-data">added</td><td=
class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data"=
>src/org/springframework/scheduling/quartz/ResourceJobSchedulingDataProcess=
or.java</td><td class=3D"modifications-data">added "jobSchedulingDataLocati=
on" and "dataSource" properties to SchedulerFactoryBean</td></tr><tr class=
=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><td=
class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data"=
>src/org/springframework/scheduling/quartz/SchedulerFactoryBean.java</td><t=
d class=3D"modifications-data">added "jobSchedulingDataLocation" and "dataS=
ource" properties to SchedulerFactoryBean</td></tr><tr class=3D"modificatio=
ns-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"modi=
fications-data">kdonald</td><td class=3D"modifications-data">sandbox/src/or=
g/springframework/enum/support/StaticCodedEnumResolver.java</td><td class=
=3D"modifications-data">removed debug prinout</td></tr><tr class=3D"modific=
ations-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"m=
odifications-data">jhoeller</td><td class=3D"modifications-data">src/org/sp=
ringframework/beans/BeanWrapperImpl.java</td><td class=3D"modifications-dat=
a">automatically convert a value to an array with a single component when n=
ecessary, support converting any Collection into an array rather than just =
a List</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modificati=
ons-data">modified</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">test/org/springframework/beans/BeanWrapperTestSu=
ite.java</td><td class=3D"modifications-data">automatically convert a value=
to an array with a single component when necessary, support converting any=
Collection into an array rather than just a List</td></tr><tr class=3D"mod=
ifications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">trisberg</td><td class=3D"modifications-data">src/o=
rg/springframework/beans/factory/access/SingletonBeanFactoryLocator.java</t=
d><td class=3D"modifications-data">changed comments: useFactory changed to =
useBeanFactory</td></tr><tr class=3D"modifications-evenrow"><td class=3D"mo=
difications-data">modified</td><td class=3D"modifications-data">dkopylenko<=
/td><td class=3D"modifications-data">src/org/springframework/aop/framework/=
autoproxy/AbstractAutoProxyCreator.java</td><td class=3D"modifications-data=
">Coreccted typo in javadoc</td></tr><tr class=3D"modifications-oddrow"><td=
class=3D"modifications-data">modified</td><td class=3D"modifications-data"=
>kdonald</td><td class=3D"modifications-data">sandbox/src/org/springframewo=
rk/util/comparators/BeanPropertyComparator.java</td><td class=3D"modificati=
ons-data">polishing</td></tr><tr class=3D"modifications-evenrow"><td class=
=3D"modifications-data">added</td><td class=3D"modifications-data">jhoeller=
</td><td class=3D"modifications-data">src/org/springframework/jdbc/support/=
nativejdbc/WebSphereNativeJdbcExtractor.java</td><td class=3D"modifications=
-data">added WebSphereNativeJdbcExtractor</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: (5) </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 jar: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></t=
r><tr><td class=3D"distributables-data">Building war: /jteam/build/checkout=
/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><tr cl=
ass=3D"distributables-oddrow"><td class=3D"distributables-data">Building ja=
r: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/war/WEB-IN=
F/lib/jpetstore.jar</td></tr><tr><td class=3D"distributables-data">Building=
war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/dist/jp=
etstore.war</td></tr></table>
</body></html> |
|
From: Rob M. <Rob...@pe...> - 2004-06-09 22:05:50
|
jürgen höller [werk3AT] wrote: > Sure, simply register a custom editor for your property (respectively the property type Long[]) that takes the CSV value as text and converts it into a Long[] value. > > Juergen > > I must have misunderstood -- I had the impression this the framework already provided a property editor to perform this conversion from a CSV to a specified object type. So how does one indicate the editor should apply to an array rather than a single object? IOW, in initBinder for my controller I have the following: binder.registerCustomEditor(Boolean.class, new CustomBooleanEditor(true)); How would I specify that I want my custom editor to be used for an array of Booleans rather than just a single Boolean? Thanks, Rob |
|
From: <jue...@we...> - 2004-06-09 21:53:23
|
I've just factored out all getPropertyValue and =
setPropertyValue/setPropertyValues methods from BeanWrapper into a new =
org.springframework.beans.PropertyAccessor base interface. If this is =
what we agree on, I'm gonna commit it promptly. (A trivial change, =
actually: just affects the BeanWrapper interface itself.)
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Mi 09.06.2004 20:29
An: spr...@li...
Betreff: Re: [Springframework-developer] BeanWrapperImpl abstraction
Something like:
public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}
>This would be useful for use within our bean binder framework to allow =
the
binders to be configured with different strategies for setting / =
receiving
properties.
+1
Rod
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-06-09 21:16:20
|
Sure, simply register a custom editor for your property (respectively = the property type Long[]) that takes the CSV value as text and converts = it into a Long[] value. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Rob Moore Gesendet: Mi 09.06.2004 22:46 An: spr...@li... Betreff: [Springframework-developer] Re: Fw: PropertyEditor question j=FCrgen h=F6ller[ werk3AT] <juergen.hoeller <at> werk3at.com> writes: > > FYI, I've just made my suggestion work through the introduction of a = new feature: String arrays can now be > converted to other arrays, just like Lists can. So registering an = editor for an individual InetAddress > would work now, even if populated with a String array: Each String = gets converted to an InetAddress, just > like each List element would get converted when populated with a List. > > This code will be included in the upcoming 1.0 RC1. I have the need to convert a CSV value from a form post to an array of = Longs, so I was curious if this enhancement had ever made it to the code base. = I've poked around in the JavaDocs, but haven't found anything answering to this = description. Regards, Rob ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rob M. <Rob...@pe...> - 2004-06-09 20:46:58
|
jürgen höller[ werk3AT] <juergen.hoeller <at> werk3at.com> writes: > > FYI, I've just made my suggestion work through the introduction of a new feature: String arrays can now be > converted to other arrays, just like Lists can. So registering an editor for an individual InetAddress > would work now, even if populated with a String array: Each String gets converted to an InetAddress, just > like each List element would get converted when populated with a List. > > This code will be included in the upcoming 1.0 RC1. I have the need to convert a CSV value from a form post to an array of Longs, so I was curious if this enhancement had ever made it to the code base. I've poked around in the JavaDocs, but haven't found anything answering to this description. Regards, Rob |
|
From: Rod J. <rod...@in...> - 2004-06-09 18:29:50
|
Something like:
public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}
>This would be useful for use within our bean binder framework to allow the
binders to be configured with different strategies for setting / receiving
properties.
+1
Rod
|
|
From: Alef A. <al...@jt...> - 2004-06-09 07:15:03
|
> Which build infrastructure are you using? Is it CruiseControl? >=20 > I ask, because we are searching for a continuous integration tool, too. Yes, it uses CruiseControl. We're using it for like 3 years now and it works just fine. Alef |
|
From: <jue...@we...> - 2004-06-09 06:25:23
|
We can certainly introduce such an interface - as base interface of =
BeanWrapper - already for 1.0.3.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Keith Donald
Gesendet: Di 08.06.2004 16:16
An: spr...@li...
Betreff: RE: [Springframework-developer] BeanWrapperImpl abstraction
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
Something like:
public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}
This would be useful for use within our bean binder framework to allow =
the
binders to be configured with different strategies for setting / =
receiving
properties.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>
>
>
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>
> base
>
>>class contains everything including bean introspection, what exactly
>
> is
>
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>
>
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>
>
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>
>
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>
> interface
>
>>and implementation here, if just for testability. BeanWrapperImpl
>
> already
>
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>
>
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>
> mind
>
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>
> alef
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Choy R. <ch...@rc...> - 2004-06-09 05:18:30
|
I've been experimenting with BeanWrapperImpl ever since the Map setting
issue. In particular, I was trying to find ways of making implicit
concepts more explicit. I eventually came up with something similar
PropertyAccessor. I called it PropertyWrapper with a similar interface.
I've been toying with how stateless it should be.
Here are some of the concepts that I came up with:
PropertyPath - represents a property path like "child[3].name". knows if
it isNested.
PropertyPathPart - represents one part of a property path. E.g.
"child[3]". Can tokenize itself.
PropertyWrapper - encapsulation of how to access a Bean Wrapper
property. Perhaps include other metadata properties. Implementations
include ArrayPropertyWrapper and DefaultPropertyWrapper.
I heard we might go to an OGNL implementation anyways so it might not be
worth the effort.
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Keith Donald
> Sent: Tuesday, June 08, 2004 10:17 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
> Just a related suggestion:
>=20
> One point that was brought up on the rich client dev list was the
> suggestion
> to extract a "PropertyAccessor" interface that is independent of any
bean
> access mechanism. This could support different mechanisms for
accessing
> bean properties, for example, via standard java beans, via maps, or
via
> apache dyna beans. While BeanWrapper could serve in this regard, it
does
> have several methods that are specific to the javabeans model -
> specifically
> the bean metadata interfaces (PropertyDescriptor stuff.)
>=20
> Something like:
>=20
> public interface PropertyAccessor {
> public Object getPropertyValue(String propertyName);
> public void setPropertyValue(String propertyName, Object value);
> // get/set multiple
> }
>=20
> This would be useful for use within our bean binder framework to allow
the
> binders to be configured with different strategies for setting /
receiving
> properties.
>=20
> Keith
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of
> Dmitriy Kopylenko
> Sent: Tuesday, June 08, 2004 9:35 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
>=20
> I'll add my 2c. If there is a possibility for an alternative
> implementation
> of BeanWrapper indeed (which personally I can't see since
BeabWrapperImpl
> is
> sophisticated and
> robust enough) then adding a base abstract class would be a good idea.
> Otherwise I'm for Juergen's suggestion to "open up" some of the needed
> private methods to enable
> easy subclassing of BeanWrapperImpl directly.
>=20
> Regards,
> Dmitriy.
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> > OK, I see. But I don't see a strong need to factor a base class out,
> actually. Rather, I see a need to make some of the currently private
> methods
> in BeanWrapperImpl protected, to allow for easier subclassing - in
> particular:
> >
> > - getPropertyValue(String propertyName, String actualName, String
key)
> > - setPropertyValue(String propertyName, String actualName, String
key,
> Object value)
> >
> > Can you try to figure out the exact set of methods that you need
> protected
> rather than private? We can then still decide to factor out a base
class;
> but for a start, it would be good enough to allow for subclassing
> BeanWrapperImpl itself.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...]On
Behalf
> > Of Alef Arendsen
> > Sent: Tuesday, June 08, 2004 2:19 PM
> > To: spr...@li...
> > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
> >
> >
> >
> >>I wouldn't mind such a refactoring. However, I don't see the clear
> >>distinction between the new base class and BeanWrapperImpl: If the
> >
> > base
> >
> >>class contains everything including bean introspection, what exactly
> >
> > is
> >
> >>BeanWrapperImpl supposed to add - respectively, what does your own
> >>subclass do differently?
> >
> >
> > To allow for partial results to be returned from (Hibernate) queries
but
> > still letting the clients believe it's a concrete object, my own
> > BeanWrapper is backed by a PropertyValues object rather than the
real
> > object. A call to getWrappedInstance() returns a Proxy, proxying to
> > BeanWrapper to retrieve the values.
> >
> > This allows me to without changing anything to the view (the view
can
> > still use the databinder and the actual wrapped instance as
internally
> > that uses the BeanWrapper backed by the PropertyValues) switch from
> > full-objects to partial objects being returned to the view or fat
> > client.
> >
> > Reason for all this: complex domain model with huge objects
(healthcare
> > and the like) with stringent security requirements (certain parts of
> > objects just cannot be transferred over the wire for example). Both
the
> > security requirements are met as well as the performance troubles
> > (heavily interlinked domain model, where clients hardly ever need to
> > view more than 5% of all data available). The latter could probably
be
> > solved by using the open session in view stuff, but it's problematic
> > with fat and remote clients.
> >
> >
> >>I assume that your own subclass wouldn't implement the BeanWrapper
> >>interface in the first place, because it has its own API way. I just
> >>wonder what it looks like then :-)
> >
> > Yes it does implement BeanWrapper ;-). It has the exact same
> > functionality (you cannot modify properties with it, just read
them).
> >
> >
> >>I doubt that there will ever be an alternative implementation of the
> >>BeanWrapper interface itself. It still makes sense to decouple
> >
> > interface
> >
> >>and implementation here, if just for testability. BeanWrapperImpl
> >
> > already
> >
> >>is a quite complex piece that you shouldn't necessarily work with
> >>directly.
> >
> > It's a rare use case, but actually makes sense (to me ;-). Same
> > functionality, different wrapped object.
> >
> >
> >>If the changes don't affect the public BeanWrapper API, I wouldn't
> >
> > mind
> >
> >>including them in 1.0.3 - provided that we're just talking about a
> >>refactoring that does not modify existing functionality.
> >
> > In my use case the only thing that changes is the wrapped instance
(more
> > specifically, the data container actually holding the data of the
> > (proxied) interface being wrapped). Basically I would stick with the
> > current API of the BeanWrapper and implement the AbstractBeanWrapper
as
> > a somewhat strategy-like class, where the current BeanWrapperImpl
just
> > has to override get/setPropertyValue(propertyName, actualName, key)
> > method, currently delegating to the read/writeMethods of the object
> > being wrapped (there is where I need to make changes).
> >
> > alef
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in
Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: GNOME Foundation
> > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> > GNOME Users and Developers European Conference, 28-30th June in
Norway
> > http://2004/guadec.org
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Daniel M. <mi...@pa...> - 2004-06-09 02:48:33
|
Hello, One of the current critiques of the OpenSessionInViewFilter/Interceptor that ships with Spring is that a Hibernate session is open for the entire duration of the request (not just during the rendering of the view). The danger here is that a failed session (due to DataAccessException) will not be discarded. I have devised a new implementation that only adds slightly more complexity to the pattern, but maintains the benefit of lazy loading in the view without a thread-local session during filter/controller processing. Conveniently, the HandlerInterceptor interface has three methods: preHandle is called at the beginning of the request; postHandle is called after the controller has completed, but before the view is rendered; and afterCompletion is called after the view has been rendered. The current implementation of OpenSessionInViewInterceptor opens a thread-local Hibernate session in the preHandle method. Instead of opening the thread-local session in preHandle, it can be opened in postHandle. Now we have a session for just the view, but there is a problem: the data objects loaded for the view by the controller are not associated with our new session. The solution to this problem is to re-bind objects to this session that need lazy loading capabilities during view rendering. This can be accomplished by populating a list of data objects during filter/controller processing. The list is kept as a request attribute so any logic along the request chain prior to postHandle can simply add loaded data objects to this list. Then in the postHandle method each of these objects can be bound to the new session (there is one gotcha here that I will go over later). Next the view is rendered, lazily loading objects if/when necessary. Finally, afterCompletion closes the session. Like I said, there is a hiccup to watch out for when using this pattern... If separate instances of the same data object (e.g. two or more objects of the same type that have the same identifier) are placed in the list of objects to be added to the session, Hibernate's NonUniqueObjectException will be thrown. The problem here is that Hibernate cannot bind an object to the session if another object with the same identifier already exists in the session. There are two workarounds that I have thought of to deal with this problem: 1. Check the list before loading an object from the database. Actually it's easier to wait until after the object is already loaded, and then check if the list contains that object. If it does, discard the just-loaded-one and use the one from the list. That way your view will be referencing a single object in memory instead of two or more separate copies, which means lazy loading only needs to be performed one time instead of for each separate instance that must be initialized. 2. If scenario 1 is a problem (I have run into a few of these cases, but they are too complicated to explain here), the simplest thing to do is to pre-initialize all but one of the instances that would otherwise use lazy initialization. Luckily this case is not very common. There is usually only a single object (tree) that must be pre-initialized, and usually one of the objects clearly benefits from lazy initialization while the other(s) only need(s) very simple initializations that can easily be performed in a DAO/SAO. I see a few benefits of this implementation that (IMHO) make the exceptions worth dealing with: Flexibility: lazy loading is possible in the view. This cuts down on the number of service methods that must be created and maintained to initialize all objects (and their related objects) that will be accessed by the view. This also adds flexibility to the view, as it can be modified more extensively without requiring modifications on the SAO/DAO layer. Stability: command (form) objects (or any data objects for that matter) that have been loaded and modified but not persisted (e.g. validation failed) are not required to participate in the view-session. One can choose which objects will participate in the view session. Thus, they will never be inadvertently flushed to the database during some unrelated data access (this can happen with the OpenSessionInView implementations provided by Spring currently). I would be happy to implement a version of this to ship with Spring if there is a demand. Let me know what you think. Daniel Miller |
|
From: john b. <jb...@pe...> - 2004-06-08 20:16:01
|
I agree with Keith's suggestion. We recently did some work to allow =
data
binding to occur to a dom object instead of a bean. We ran into several
places where this was made difficult because of BeabWrapperImpl.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Tuesday, June 08, 2004 7:17 AM
To: spr...@li...
Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
Something like:
public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}
This would be useful for use within our bean binder framework to allow =
the
binders to be configured with different strategies for setting / =
receiving
properties.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and=20
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable=20
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>=20
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>=20
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
>=20
>=20
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>=20
> base
>=20
>>class contains everything including bean introspection, what exactly
>=20
> is
>=20
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>=20
>=20
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>=20
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>=20
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>=20
>=20
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>=20
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>=20
>=20
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>=20
> interface
>=20
>>and implementation here, if just for testability. BeanWrapperImpl
>=20
> already
>=20
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>=20
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>=20
>=20
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>=20
> mind
>=20
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>=20
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>=20
> alef
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-06-08 19:28:21
|
Brandon, =20 Have you had a chance to review Spring 1.0.2's support for SQL Maps 2.0? = Are you happy with it so far? If there's any further thing we can do, = let's try to nail it down for Spring 1.0.3, scheduled for end of June. =20 Actually, if SQL Maps 2.0 gets final early enough, we could ship it with = Spring 1.0.3 .That would be ideal timing :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Brandon Goodin Gesendet: Sa 29.05.2004 22:59 An: spr...@li... Betreff: RE: [Springframework-developer] Ibatis integration corrections = needed excellent, thanks a ton j=FCrgen. Brandon -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Saturday, May 29, 2004 2:39 PM To: spr...@li... Subject: Re: [Springframework-developer] Ibatis integration corrections needed I've just tried with a lazy-loading PaginatedList - works like a charm! = And it still works nicely with the old usage pattern too. Gonna commit it within the next 30 minutes... might take about 2 or 3 = hours to be available from public CVS, though. Brandon, thanks for that really valuable hint :-) Just in time for = 1.0.2, to be released tomorrow. Juergen ________________________________ Von: spr...@li... im Auftrag = von Brandon Goodin Gesendet: Sa 29.05.2004 22:25 An: spr...@li... Betreff: RE: [Springframework-developer] Ibatis integration corrections needed excellent, i'll give it a try. -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Saturday, May 29, 2004 2:07 PM To: spr...@li... Subject: Re: [Springframework-developer] Ibatis integration corrections needed Actually, this seems to work great: Specify the DataSource once on SqlMapClientFactoryBean rather than on each DAO, and still set the UserConnection in SqlMapClientTemplate. The latter simply fetches the DataSource from the SqlMapClient in this case. As far as I understand = that, this should allow for proper lazy loading... Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Sa 29.05.2004 21:46 An: spr...@li... Betreff: Re: [Springframework-developer] Ibatis integration corrections needed What about initializing the iBATIS TransactionManager in the way that = you suggested, and *still* pass in transactional Connections via setUserConnection? That could give the best of both worlds: = participating in all kinds of Spring-managed transactions, and allowing for lazy loading. = It would also avoid the need to pass the DataSource to each and every SQL-Maps-based DAO; a single passing of the DataSource to the SqlMapClientFactoryBean would then be sufficient. Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Sa 29.05.2004 21:24 An: spr...@li... Betreff: Re: [Springframework-developer] Ibatis integration corrections needed The problem is that we'd pass the DataSource to the iBATIS TransactionManager here, but not Spring-managed transactional = Connections. SQL Maps would fetch its own Connections from the given DataSource, = failing to participate in Spring-managed transactions (other than JTA). I'm aware that lazy loading won't work with Spring's current iBATIS integration strategy. However, I'm not aware of any other disadvantages; = can you give details in that respect? I wouldn't mind letting SQL Maps create its own Connections from the DataSource for lazy loading, if told to do so. But we'd need to figure = out a way to pass a transactional Connection in for the actual operation (like = we do currently) and still allow for lazy loading via a given DataSource. Juergen ________________________________ Von: spr...@li... im Auftrag = von Brandon Goodin Gesendet: Sa 29.05.2004 20:48 An: spr...@li... Betreff: RE: [Springframework-developer] Ibatis integration corrections needed The issue here of setting the datasource still remains. If you set the connection via the setUserConnection it doesn't take full advantage of ibatis. However, it is possible to allow for Spring to be the iBatis TransactionManager. You simply need to set up an EXTERNAL = TransactionConfig to use in the TransactionManager. Please review my previous code. It = shows exactly how that is set. If you feel that iBatis may need to provide = better integrtion points for Spring to take advantage of... feel free to = provide suggestions. Thanks, Brandon Goodin http://www.ibatis.com -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Saturday, May 29, 2004 11:53 AM To: spr...@li... Subject: Re: [Springframework-developer] Ibatis integration corrections needed Hi again, Brandon, While I agree that Spring allows iBATIS users to choose between Spring's = own transaction management and iBATIS transaction management, this does not necessarily affect the iBATIS support classes that we provide: Those = classes are specifically meant to integrate SQL Maps into Spring's resource and transaction management, potentially sharing transactions with other data access strategies within Spring (for example, plain JDBC or Hibernate). As far as I understand, the SqlMapClient API already allows for simple one-line operations when using its own resource and transaction = management. So effectively, you don't need to use Spring's SqlMapClientTemplate in = that scenario: Simply use the SqlMapClient instance directly. Of course, you = can still use Spring's SqlMapClientFactoryBean to set up your SqlMapClient = in the application context, passing it to your DAOs via bean references. A disadvantage that I see with direct SqlMapClient usage is that you = have to deal with checked SQLExceptions that your DAOs throw. However, that's = also the case with your iBATIS transaction demarcation code, so that will be consistent throughout the application. The alternative is to use = Spring's resource and transaction management: throwing unchecked = DataAccessExceptions from DAOs (like SqlMapClientTemplate does), and unchecked TransactionExceptions from transaction demarcation code (like Spring's PlatformTransactionManager interface and declarative demarcation = facilities do). So in the end, there are two choices for using Spring in combination = with iBATIS SQL Maps: either Spring resource and transaction management (-> coding your DAOs with SqlMapClientTemplate), or iBATIS resource and transaction management (-> coding your DAOs with SqlMapClient directly). = I don't see a need to rework SqlMapClientTemplate here: Simply use SqlMapClient directly in your scenario; you can still leverage all of Spring's IoC facilities. Juergen ________________________________ Von: spr...@li... im Auftrag = von Brandon Goodin Gesendet: Sa 29.05.2004 07:42 An: spr...@li... Betreff: RE: [Springframework-developer] Ibatis integration corrections needed Also, after some exploration I have discovered that Spring requires that = the Datasource be set via the <property name=3D"dataSource"> on the = SqlMapDaos. This is not good. What happens when someone wants to allow iBatis to = manage transactions on it's own? I think that the datasource requirement needs = to be removed. Setting the datasource via spring should be optional not required. Brandon Goodin http://www.ibatis.com ________________________________ From: spr...@li... [mailto:spr...@li...] On Behalf = Of Brandon Goodin Sent: Friday, May 28, 2004 6:57 PM To: spr...@li... Subject: [Springframework-developer] Ibatis integration corrections = needed Greetings, My name is Brandon Goodin. I am committer on the iBatis project. As I've = had time recently I've become increasingly more familiar with the Spring = product and began to explore the code base. I specifically have examined the = iBatis integration and noticed a problem in how the datasource is being set. In the SqlMapClientTemplate the execute method is using session.setUserConnection(con);. Setting the connection using setUserConnection on the SqlMapSession will not take full advantage of ibatis functionality (i.e. lazy loading will not work). The short explanation is that Spring needs to set the the Datasource via = the TransactionConfig which is stored in the TransactionManager. The TransactionManager needs to be set via the SqlMapExecutorDelegate of the SqlMapClient. The TransactionManager contains the TransactionConfig = which contains the datasource and various other pertinent config info for transactions. Following is a chunk from the XmlSqlMapClientBuilder that demonstrates = how the datasource should be configured in ibatis: ---- start code --- TransactionManager txManager =3D null; try { errorCtx.setMoreInfo("Check the transaction manager type or class."); TransactionConfig config =3D (TransactionConfig) = Resources.instantiate(type); config.setDataSource(dataSource); config.setMaximumConcurrentTransactions(client.getDelegate().getMaxTransa= cti ons()); errorCtx.setMoreInfo("Check the transactio nmanager properties or configuration."); config.initialize(initProperties); errorCtx.setMoreInfo(null); txManager =3D new TransactionManager(config); } catch (Exception e) { if (e instanceof SqlMapException) { throw (SqlMapException) e; } else { throw new SqlMapException("Error initializing TransactionManager. Could = not instantiate TransactionConfig. Cause: " + e, e); } } client.getDelegate().setTxManager(txManager); --- end code --- From what I can tell Spring allows for iBatis users to take advantage of = the iBatis transaction facilities if they choose (i.e. avoid using spring transaction management if they so choose). So, the only thing that is = left is for Spring to use the proper implementation of the TransactionConfig (com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig)= for the configuration of the datasource. The ExternalTransactionConfig = will allow for Spring to manage the commit and rollback functionality without losing valuable functionality in iBatis (lazy loading). I'd be happy to work on the Spring code base if you would like or = provide you with more insight if you need. Let me know. Thanks, Brandon Goodin http://www.ibatis.com <http://www.ibatis.com/> ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Oliver G. <oli...@gm...> - 2004-06-08 19:10:56
|
Hi Alef Arendsen wrote: > Like discussed earlier, building will occur every day (if modifications > have been found) at about 0:15 (CET) from now on (this one is done at > noon, have to test it a bit). Future builds will also include the > modifications done during the past day. Testing for now will be done on > Tomcat 4 and 5. Testing on other servers available will be added later. Which build infrastructure are you using? Is it CruiseControl? I ask, because we are searching for a continuous integration tool, too. Thanks, Olli |
|
From: Alef A. <al...@jt...> - 2004-06-08 15:53:05
|
> > We could add a small publishing step somewhere, that wouldn't be a big > > problem I guess. > > > > >=20 > +1 >=20 > If you could publish it to a static location on www.springframework.org, > then we > could provide a link from the main page. That shouldn't be too hard. I'll have a look into it later on. Alef |
|
From: <tho...@tr...> - 2004-06-08 14:56:36
|
Quoting Alef Arendsen <al...@jt...>: > > We could add a small publishing step somewhere, that wouldn't be a big > problem I guess. > > +1 If you could publish it to a static location on www.springframework.org, then we could provide a link from the main page. Thomas |
|
From: Darren D. <da...@da...> - 2004-06-08 14:39:37
|
> Currently, the build runs the jpetstore example including the apptests. > The results are published on a website and in an email that's great, it wasn't clear from the report mailed to the dev list whether the app tests were being executed too. Good stuff! > We could add a small publishing step somewhere, that wouldn't be a big > problem I guess. +1 Cheers, Darren. |
|
From: Keith D. <kd...@cs...> - 2004-06-08 14:16:51
|
Just a related suggestion:
One point that was brought up on the rich client dev list was the =
suggestion
to extract a "PropertyAccessor" interface that is independent of any =
bean
access mechanism. This could support different mechanisms for accessing
bean properties, for example, via standard java beans, via maps, or via
apache dyna beans. While BeanWrapper could serve in this regard, it =
does
have several methods that are specific to the javabeans model - =
specifically
the bean metadata interfaces (PropertyDescriptor stuff.)
Something like:
public interface PropertyAccessor {
public Object getPropertyValue(String propertyName);
public void setPropertyValue(String propertyName, Object value);
// get/set multiple
}
This would be useful for use within our bean binder framework to allow =
the
binders to be configured with different strategies for setting / =
receiving
properties.
Keith
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Dmitriy Kopylenko
Sent: Tuesday, June 08, 2004 9:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction
I'll add my 2c. If there is a possibility for an alternative =
implementation
of BeanWrapper indeed (which personally I can't see since =
BeabWrapperImpl is
sophisticated and=20
robust enough) then adding a base abstract class would be a good idea.
Otherwise I'm for Juergen's suggestion to "open up" some of the needed
private methods to enable=20
easy subclassing of BeanWrapperImpl directly.
Regards,
Dmitriy.
j=FCrgen h=F6ller [werk3AT] wrote:
> OK, I see. But I don't see a strong need to factor a base class out,
actually. Rather, I see a need to make some of the currently private =
methods
in BeanWrapperImpl protected, to allow for easier subclassing - in
particular:
>=20
> - getPropertyValue(String propertyName, String actualName, String key)
> - setPropertyValue(String propertyName, String actualName, String key,
Object value)
>=20
> Can you try to figure out the exact set of methods that you need =
protected
rather than private? We can then still decide to factor out a base =
class;
but for a start, it would be good enough to allow for subclassing
BeanWrapperImpl itself.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Alef Arendsen
> Sent: Tuesday, June 08, 2004 2:19 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction
>=20
>=20
>=20
>>I wouldn't mind such a refactoring. However, I don't see the clear
>>distinction between the new base class and BeanWrapperImpl: If the
>=20
> base
>=20
>>class contains everything including bean introspection, what exactly
>=20
> is
>=20
>>BeanWrapperImpl supposed to add - respectively, what does your own
>>subclass do differently?
>=20
>=20
> To allow for partial results to be returned from (Hibernate) queries =
but
> still letting the clients believe it's a concrete object, my own
> BeanWrapper is backed by a PropertyValues object rather than the real
> object. A call to getWrappedInstance() returns a Proxy, proxying to
> BeanWrapper to retrieve the values.
>=20
> This allows me to without changing anything to the view (the view can
> still use the databinder and the actual wrapped instance as internally
> that uses the BeanWrapper backed by the PropertyValues) switch from
> full-objects to partial objects being returned to the view or fat
> client.
>=20
> Reason for all this: complex domain model with huge objects =
(healthcare
> and the like) with stringent security requirements (certain parts of
> objects just cannot be transferred over the wire for example). Both =
the
> security requirements are met as well as the performance troubles
> (heavily interlinked domain model, where clients hardly ever need to
> view more than 5% of all data available). The latter could probably be
> solved by using the open session in view stuff, but it's problematic
> with fat and remote clients.
>=20
>=20
>>I assume that your own subclass wouldn't implement the BeanWrapper
>>interface in the first place, because it has its own API way. I just
>>wonder what it looks like then :-)
>=20
> Yes it does implement BeanWrapper ;-). It has the exact same
> functionality (you cannot modify properties with it, just read them).
>=20
>=20
>>I doubt that there will ever be an alternative implementation of the
>>BeanWrapper interface itself. It still makes sense to decouple
>=20
> interface
>=20
>>and implementation here, if just for testability. BeanWrapperImpl
>=20
> already
>=20
>>is a quite complex piece that you shouldn't necessarily work with
>>directly.
>=20
> It's a rare use case, but actually makes sense (to me ;-). Same
> functionality, different wrapped object.
>=20
>=20
>>If the changes don't affect the public BeanWrapper API, I wouldn't
>=20
> mind
>=20
>>including them in 1.0.3 - provided that we're just talking about a
>>refactoring that does not modify existing functionality.
>=20
> In my use case the only thing that changes is the wrapped instance =
(more
> specifically, the data container actually holding the data of the
> (proxied) interface being wrapped). Basically I would stick with the
> current API of the BeanWrapper and implement the AbstractBeanWrapper =
as
> a somewhat strategy-like class, where the current BeanWrapperImpl just
> has to override get/setPropertyValue(propertyName, actualName, key)
> method, currently delegating to the read/writeMethods of the object
> being wrapped (there is where I need to make changes).
>=20
> alef
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Alef A. <al...@jt...> - 2004-06-08 14:16:12
|
Currently, the build runs the jpetstore example including the apptests.
The results are published on a website and in an email. The website
includes results for all tests (see below), the XML log and some
additional information, gathered by CruiseControl. I can't expose the
website however, not really possible to expose only the Spring build and
not our other internal builds. Email is (at the moment) the best I can
do.
=20
If a test fails, the actual failing and the exception *will* be included
in the email by the way, when successful, it just doesn't include
everything.
=20
We could add a small publishing step somewhere, that wouldn't be a big
problem I guess.
=20
Also, I can enable the emailing you built into the autobuilds as well...
=20
=20
=20
.org.springframework.apptests.jpetstore.AllTests
=20
testHomePage
Success
1.036
=20
testHelpPage
Success
0.427
=20
testPurchase
Success
10.241
=20
testSearch
Success
0.786
=20
<javascript:displayProperties('.org.springframework.apptests.jpetstore.A
llTests');>=20
=20
=20
=20
.org.springframework.apptests.jpetstore.AllTests
=20
testHomePage
Success
0.656
=20
testHelpPage
Success
0.487
=20
testPurchase
Success
9.458
=20
testSearch
Success
0.575
=09
=20
Alef
=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Darren Davison
> Sent: Tuesday, June 08, 2004 3:46 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] spring build.22 Build
Successful
>=20
> >Like discussed earlier, building will occur every day (if
modifications
> have been found) >at about 0:15 (CET) from now on (this one is done at
> noon,
> have to test it a bit). Future >builds will also include the
modifications
> done during the past day. Testing for now will >be done on Tomcat 4
and 5.
> Testing on other servers available will be added later.
>=20
> Alef,
>=20
> does the build actually execute the HttpUnit tests for the jpetstore
> sample
> via autobuilds? What happens to the junit report file if it does?
>=20
> My intention originally was to build a webapp somewhere that could
show
> combined results of such tests by having the various build servers
mail or
> (http) post those files to a central location. There's enough info in
> them
> to be able to determine operating systems, server versions and one or
two
> other metrics of interest - I think that would be pretty cool.
>=20
> Darren.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
=20
|
|
From: Colin S. <col...@ex...> - 2004-06-08 14:15:03
|
This is good. Just last week I had a co-worker ask me if Spring provided=20 support for persistent Quartz jobs... j=FCrgen h=F6ller [werk3AT] wrote: >Hi everybody, > >Up to 1.0.2, our Quartz support focuses on non-persistent jobs. Of cours= e, you can configure a persistent JobStore via Quartz properties. The out= -of-the-box options that Quartz provides are limited, though: > >- JobStoreTX: Quartz will use its own Commons DBCP connection pool, perf= orming its own transaction management. So if you use already use a connec= tion pool within your app, you'll end up with a separate pool just for Qu= artz. > >- JobStoreCMT: Quartz will use a J2EE container DataSource, and rely on = JTA respectively EJB CMT for transaction management. You can make job reg= istrations participate in enclosing transactions, but just when using JTA= . > >So what I've done is added a further option to our scheduling.quartz pac= kage: LocalDataSourceJobStore, using a Spring-configured DataSource and p= articipating in Spring's transaction management. It is driven by Schedule= rFactoryBean's new "dataSource" property, which will automatically config= ure that JobStore (similar to LocalSessionFactoryBean and LocalDataSource= ConnectionProvider). > >----- > >Note that a JobDetail needs to respect an obvious limitation to be persi= stable with any JDBC-based JobStore: All the elements in the JobDataMap n= eed to be serializable. This in particular means that MethodInvokingJobDe= tailFactoryBean does not work with persistent jobs, and that you cannot p= ut Spring bean references into a JobDataMap. > >Instead, put your bean references into the Scheduler's SchedulerContext,= via SchedulerFactoryBean's "schedulerContextAsMap" property (introduced = in 1.0.2). All those elements will be exposed to all Quartz jobs, and Spr= ing's QuartzJobBean automatically applies them as bean property values to= o, just like elements in the JobDataMap. > >----- > >A further enhancement to SchedulerFactoryBean - unrelated to the above -= is the "jobSchedulingDataLocations" property. Any resource specified the= re is expected to be an XML file that conforms to Quartz 1.3's "job_sched= uling_data_1_0" DTD, defining jobs and triggers. SchedulerFactoryBean wil= l automatically register those too, just like any jobs and triggers that = are directly defined on itself. > >I'll commit those enhancements tomorrow, after testing them in the targe= t application. I guess they're a straightforward addition to 1.0.2's Quar= tz support, so I'm all for making those part of 1.0.3. > >Juergen > =20 > |
|
From: Dmitriy K. <dko...@ru...> - 2004-06-08 13:35:05
|
I'll add my 2c. If there is a possibility for an alternative implementation of BeanWrapper indeed (which personally I can't see since BeabWrapperImpl is sophisticated and robust enough) then adding a base abstract class would be a good idea. Otherwise I'm for Juergen's suggestion to "open up" some of the needed private methods to enable easy subclassing of BeanWrapperImpl directly. Regards, Dmitriy. jürgen höller [werk3AT] wrote: > OK, I see. But I don't see a strong need to factor a base class out, actually. Rather, I see a need to make some of the currently private methods in BeanWrapperImpl protected, to allow for easier subclassing - in particular: > > - getPropertyValue(String propertyName, String actualName, String key) > - setPropertyValue(String propertyName, String actualName, String key, Object value) > > Can you try to figure out the exact set of methods that you need protected rather than private? We can then still decide to factor out a base class; but for a start, it would be good enough to allow for subclassing BeanWrapperImpl itself. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Alef Arendsen > Sent: Tuesday, June 08, 2004 2:19 PM > To: spr...@li... > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction > > > >>I wouldn't mind such a refactoring. However, I don't see the clear >>distinction between the new base class and BeanWrapperImpl: If the > > base > >>class contains everything including bean introspection, what exactly > > is > >>BeanWrapperImpl supposed to add - respectively, what does your own >>subclass do differently? > > > To allow for partial results to be returned from (Hibernate) queries but > still letting the clients believe it's a concrete object, my own > BeanWrapper is backed by a PropertyValues object rather than the real > object. A call to getWrappedInstance() returns a Proxy, proxying to > BeanWrapper to retrieve the values. > > This allows me to without changing anything to the view (the view can > still use the databinder and the actual wrapped instance as internally > that uses the BeanWrapper backed by the PropertyValues) switch from > full-objects to partial objects being returned to the view or fat > client. > > Reason for all this: complex domain model with huge objects (healthcare > and the like) with stringent security requirements (certain parts of > objects just cannot be transferred over the wire for example). Both the > security requirements are met as well as the performance troubles > (heavily interlinked domain model, where clients hardly ever need to > view more than 5% of all data available). The latter could probably be > solved by using the open session in view stuff, but it's problematic > with fat and remote clients. > > >>I assume that your own subclass wouldn't implement the BeanWrapper >>interface in the first place, because it has its own API way. I just >>wonder what it looks like then :-) > > Yes it does implement BeanWrapper ;-). It has the exact same > functionality (you cannot modify properties with it, just read them). > > >>I doubt that there will ever be an alternative implementation of the >>BeanWrapper interface itself. It still makes sense to decouple > > interface > >>and implementation here, if just for testability. BeanWrapperImpl > > already > >>is a quite complex piece that you shouldn't necessarily work with >>directly. > > It's a rare use case, but actually makes sense (to me ;-). Same > functionality, different wrapped object. > > >>If the changes don't affect the public BeanWrapper API, I wouldn't > > mind > >>including them in 1.0.3 - provided that we're just talking about a >>refactoring that does not modify existing functionality. > > In my use case the only thing that changes is the wrapped instance (more > specifically, the data container actually holding the data of the > (proxied) interface being wrapped). Basically I would stick with the > current API of the BeanWrapper and implement the AbstractBeanWrapper as > a somewhat strategy-like class, where the current BeanWrapperImpl just > has to override get/setPropertyValue(propertyName, actualName, key) > method, currently delegating to the read/writeMethods of the object > being wrapped (there is where I need to make changes). > > alef > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2004-06-08 13:33:56
|
>Like discussed earlier, building will occur every day (if modifications have been found) >at about 0:15 (CET) from now on (this one is done at noon, have to test it a bit). Future >builds will also include the modifications done during the past day. Testing for now will >be done on Tomcat 4 and 5. Testing on other servers available will be added later. Alef, does the build actually execute the HttpUnit tests for the jpetstore sample via autobuilds? What happens to the junit report file if it does? My intention originally was to build a webapp somewhere that could show combined results of such tests by having the various build servers mail or (http) post those files to a central location. There's enough info in them to be able to determine operating systems, server versions and one or two other metrics of interest - I think that would be pretty cool. Darren. |
|
From: Alef A. <al...@jt...> - 2004-06-08 13:20:05
|
Ok subclassing sounds good. I'll have a look at a list of candidates tonight, don't have much time = before then. Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Tuesday, June 08, 2004 2:46 PM > To: spr...@li... > Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction >=20 > OK, I see. But I don't see a strong need to factor a base class out, > actually. Rather, I see a need to make some of the currently private > methods in BeanWrapperImpl protected, to allow for easier subclassing = - in > particular: >=20 > - getPropertyValue(String propertyName, String actualName, String key) > - setPropertyValue(String propertyName, String actualName, String key, > Object value) >=20 > Can you try to figure out the exact set of methods that you need = protected > rather than private? We can then still decide to factor out a base = class; > but for a start, it would be good enough to allow for subclassing > BeanWrapperImpl itself. >=20 > Juergen >=20 >=20 > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On = Behalf > Of Alef Arendsen > Sent: Tuesday, June 08, 2004 2:19 PM > To: spr...@li... > Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction >=20 >=20 > > I wouldn't mind such a refactoring. However, I don't see the clear > > distinction between the new base class and BeanWrapperImpl: If the > base > > class contains everything including bean introspection, what exactly > is > > BeanWrapperImpl supposed to add - respectively, what does your own > > subclass do differently? >=20 > To allow for partial results to be returned from (Hibernate) queries = but > still letting the clients believe it's a concrete object, my own > BeanWrapper is backed by a PropertyValues object rather than the real > object. A call to getWrappedInstance() returns a Proxy, proxying to > BeanWrapper to retrieve the values. >=20 > This allows me to without changing anything to the view (the view can > still use the databinder and the actual wrapped instance as internally > that uses the BeanWrapper backed by the PropertyValues) switch from > full-objects to partial objects being returned to the view or fat > client. >=20 > Reason for all this: complex domain model with huge objects = (healthcare > and the like) with stringent security requirements (certain parts of > objects just cannot be transferred over the wire for example). Both = the > security requirements are met as well as the performance troubles > (heavily interlinked domain model, where clients hardly ever need to > view more than 5% of all data available). The latter could probably be > solved by using the open session in view stuff, but it's problematic > with fat and remote clients. >=20 > > I assume that your own subclass wouldn't implement the BeanWrapper > > interface in the first place, because it has its own API way. I just > > wonder what it looks like then :-) > Yes it does implement BeanWrapper ;-). It has the exact same > functionality (you cannot modify properties with it, just read them). >=20 > > I doubt that there will ever be an alternative implementation of the > > BeanWrapper interface itself. It still makes sense to decouple > interface > > and implementation here, if just for testability. BeanWrapperImpl > already > > is a quite complex piece that you shouldn't necessarily work with > > directly. > It's a rare use case, but actually makes sense (to me ;-). Same > functionality, different wrapped object. >=20 > > If the changes don't affect the public BeanWrapper API, I wouldn't > mind > > including them in 1.0.3 - provided that we're just talking about a > > refactoring that does not modify existing functionality. > In my use case the only thing that changes is the wrapped instance = (more > specifically, the data container actually holding the data of the > (proxied) interface being wrapped). Basically I would stick with the > current API of the BeanWrapper and implement the AbstractBeanWrapper = as > a somewhat strategy-like class, where the current BeanWrapperImpl just > has to override get/setPropertyValue(propertyName, actualName, key) > method, currently delegating to the read/writeMethods of the object > being wrapped (there is where I need to make changes). >=20 > alef >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 |
1239 messages has been excluded from this view by a project administrator.
