springframework-developer Mailing List for Spring Framework (Page 270)

Brought to you by: colins, jhoeller, johnsonr, robharrop, trevormarshall

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

Flat | Threaded

<< < 1 .. 268 269 270 271 272 .. 465 > >> (Page 270 of 465)

Re: [Springframework-developer] SqlTypeValue and SqlLobValue

From: Tom T. <tom...@pr...> - 2004-06-29 06:27:13

Thanks Juergen! SqlTypeValues work fine now.

Regards,
Tom.

On Mon, 28 Jun 2004 23:10:49 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Indeed, PreparedStatementCreatorFactory and
> CallableStatementCreatorFactory need to apply the NativeJdbcExtractor for
> unwrapping the PreparedStatement respectively CallableStatement. I had
> just tested this with a plain JdbcTemplate, that's why I had not noticed
> the missing unwrapping.
>=20=20
> I've just fixed this, to be committed in a couple of minutes...
>=20=20
> BTW, I've also moved the "resultSetType" and "updatableResults"
> properties from SqlOperation up to RdbmsOperation, as SqlCall should
> share those to pass them to the CallableStatementCreatorFactory.
>=20=20
> Juergen

RE: [Springframework-developer] JMS questions

From: Mark P. <mar...@co...> - 2004-06-29 03:09:59

Hi,

I'm developing the JMS support for Spring so I hope I can answer your
questions.  The class that you can use for you sending needs is =
JmsSender
with 1.0.2 and 1.1 implementations.  The interface is likely to be =
renamed
JmsTemplate.  This replaced the classes P2pTemplate and PubSubTemplate,
which are no longer in the sandbox.

Inside an EJB the call to =20

topicSession =3D
     topicConnection.createTopicSession(true,=20
			 Session.AUTO_ACKNOWLEDGE );

Should ignore the values set to both the transaction and the =
acknowledgement
mode.  The values come from the transaction properties declared on the =
EJB.
Section 17.3.5 of the ejb spec talks about this.

For BEA, the behavior of using JMS inside an JMS is discussed at
http://e-docs.bea.com/wls/docs81/jms/j2ee_components.html, which might
provide some insight.   For example, to get the tx enlistment behavior =
you
need to declare the jms connection factory as a resource-ref in the
deployment descriptor to get the advanced functionality of its JMS =
wrapper
classes.

The fact that you are affecting the behavior of the app by changing the =
tx
mode, indicates that somehow the container isn't managing the tx mode.   =
You
probably don't see a message published when txmode =3D true because you =
need
to explicity do topicSession.commit() if the container isn't managing =
the
tx.  The timing issue in the case of tx=3Dfalse is expected, since the =
db
update and jms than aren't occurring together, the jms message probably =
gets
to the client first quite frequently I'd guess.

The JMS transaction support from the spring JmsSender class is basically
delegated to the behavior on the container since it just a wrapper to =
the
execution of a createSession method.  Check the configuration of the app
server to make sure jms tx's get enlisted.=20

The container would try to use XA if you request the db update and the =
jms
update in the same transaction and would throw an exception if the jms
connection factory was not XA-enabled.  Depending on your performance
requirements, you might not want to go that route.   Instead you could
separate out the separate out the db update and the jms update into two
separate EJBs, with independent tx's, and have the db update occur =
first.
You have so examine if the failure scenario is ok for you in that case.
Alternatively, you could send the update information in the update =
message
itself, which would probably be better since otherwise you could have =
the
case of potentially many (100's) of clients all asking the database for =
the
same information at the same time. =20

Email me privately if you want to work through this is more gory detail =
that
might not be appropriate for a larger audience. =20

Cheers,
Mark

Email:  mar...@co...







> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Les A. Hazlewood
> Sent: Monday, June 28, 2004 3:19 PM
> To: spr...@li...
> Subject: [Springframework-developer] JMS questions
>=20
>=20
> Hiya folks,
>=20
> I was wondering if anyone had any thoughts on when the JMS=20
> components would be integrated into a Spring release?  I'm=20
> not looking for any specific dates...just a ballpark figure=20
> (and yes, I know that this is an Open Source product, so I=20
> take ballpark figures with a grain of salt...I'm just looking=20
> for something, anything).
>=20
> Also, I was wondering if anyone could help me out with some=20
> insight....
>=20
> Here's my issue:
>=20
> An EJB method is called from a remote client.  In response to=20
> that method call, some data is processed, saved back to the=20
> db, and then a JMS message is published to all clients who=20
> care about that data.  The data is not committed until the=20
> end of the transaction.
>=20
> The JMS message is received by a client which then=20
> immediately requests the data that was just updated.
>=20
> Occasionally, when the client requests this data, it doesn't=20
> get what it expects.  The reason for this is that we think=20
> the client is making a request for the data before the first=20
> transaction has had a chance to commit/flush.
>=20
> So, basically, we'd like to sync the JMS sending to only send=20
> upon transaction commit, to ensure that the data will be in=20
> the db by the time the clients request it.
>=20
> I tried setting the JMS transacted attribute to true when=20
> creating a topic session, i.e.
>=20
> topicSession =3D
>     topicConnection.createTopicSession(true,=20
> Session.AUTO_ACKNOWLEDGE );
>=20
>=20
> After reading the JMS spec, this is all that should be=20
> necessary when participating in transactions in a J2EE container.
>=20
> However, we're seeing that the client's don't receive _any_=20
> messages from the server when set to true.  When set to=20
> false, the messages are being sent, but that synchronization=20
> issue pops its head up.
>=20
> Does anyone have any insights on why this is happening?
>=20
> Also, does the Spring JMS support in the sandbox already work=20
> with integrating into transactions, like the Spring Hibernate=20
> support does?
>=20
> Any ideas would be graciously received.
>=20
> Regards,
>=20
> Les
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &=20
> Training. Attend Black Hat Briefings & Training, Las Vegas=20
> July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] spring build.39 Build Successful

From: <al...@jt...> - 2004-06-28 22:09:51

<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&nbsp;-&nbsp;     =
               build.39</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>06/29/2004 00:15:34</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 35 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>06/28/2004 19:08:16</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>added "getAttributesMap" accessor, for "attributesMap[key]=
"-style bean property values</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">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</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">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (39)                </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">src/org/springframework/web/s=
ervlet/view/AbstractView.java</td><td class=3D"modifications-data">added "g=
etAttributesMap" accessor, for "attributesMap[key]"-style bean property val=
ues</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/jdbc/core/support/AbstractS=
qlTypeValue.java</td><td class=3D"modifications-data">added "typeName" to S=
qlTypeValue signature</td></tr><tr class=3D"modifications-evenrow"><td clas=
s=3D"modifications-data">modified</td><td class=3D"modifications-data">jhoe=
ller</td><td class=3D"modifications-data">src/org/springframework/jdbc/core=
/support/SqlLobValue.java</td><td class=3D"modifications-data">added "typeN=
ame" to SqlTypeValue signature</td></tr><tr class=3D"modifications-oddrow">=
<td class=3D"modifications-data">modified</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">src/org/springframework/j=
dbc/core/JdbcTemplate.java</td><td class=3D"modifications-data">added "type=
Name" to SqlTypeValue signature</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">src/org/springframework=
/jdbc/core/SqlTypeValue.java</td><td class=3D"modifications-data">added "ty=
peName" to SqlTypeValue signature</td></tr><tr class=3D"modifications-oddro=
w"><td class=3D"modifications-data">modified</td><td class=3D"modifications=
-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewor=
k/jdbc/core/StatementCreatorUtils.java</td><td class=3D"modifications-data"=
>added "typeName" to SqlTypeValue signature</td></tr><tr class=3D"modificat=
ions-evenrow"><td class=3D"modifications-data">added</td><td class=3D"modif=
ications-data">johnsonr</td><td class=3D"modifications-data">test/org/sprin=
gframework/beans/factory/xml/FixedMethodReplacer.java</td><td class=3D"modi=
fications-data">Added ReplaceOverride support</td></tr><tr class=3D"modific=
ations-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"m=
odifications-data">johnsonr</td><td class=3D"modifications-data">test/org/s=
pringframework/beans/factory/xml/OverrideOneMethod.java</td><td class=3D"mo=
difications-data">Added ReplaceOverride support</td></tr><tr class=3D"modif=
ications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">johnsonr</td><td class=3D"modifications-data">test/=
org/springframework/beans/factory/xml/OverrideOneMethodSubclass.java</td><t=
d class=3D"modifications-data">Added ReplaceOverride support</td></tr><tr c=
lass=3D"modifications-oddrow"><td class=3D"modifications-data">added</td><t=
d class=3D"modifications-data">johnsonr</td><td class=3D"modifications-data=
">test/org/springframework/beans/factory/xml/ReverseMethodReplacer.java</td=
><td class=3D"modifications-data">Added ReplaceOverride support</td></tr><t=
r class=3D"modifications-evenrow"><td class=3D"modifications-data">modified=
</td><td class=3D"modifications-data">johnsonr</td><td class=3D"modificatio=
ns-data">test/org/springframework/beans/factory/xml/XmlBeanFactoryTestSuite=
.java</td><td class=3D"modifications-data">Added ReplaceOverride support</t=
d></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D"mod=
ifications-data">test/org/springframework/beans/factory/xml/delegationOverr=
ides.xml</td><td class=3D"modifications-data">Added ReplaceOverride support=
</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-da=
ta">modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D=
"modifications-data">src/org/springframework/beans/factory/xml/DefaultXmlBe=
anDefinitionParser.java</td><td class=3D"modifications-data">Added ReplaceO=
verride support</td></tr><tr class=3D"modifications-oddrow"><td class=3D"mo=
difications-data">modified</td><td class=3D"modifications-data">johnsonr</t=
d><td class=3D"modifications-data">src/org/springframework/beans/factory/xm=
l/spring-beans.dtd</td><td class=3D"modifications-data">Added ReplaceOverri=
de support</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifi=
cations-data">added</td><td class=3D"modifications-data">johnsonr</td><td c=
lass=3D"modifications-data">src/org/springframework/beans/factory/support/M=
ethodReplacer.java</td><td class=3D"modifications-data">Added ReplaceOverri=
de support</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modific=
ations-data">added</td><td class=3D"modifications-data">johnsonr</td><td cl=
ass=3D"modifications-data">src/org/springframework/beans/factory/support/Re=
placeOverride.java</td><td class=3D"modifications-data">Added ReplaceOverri=
de support</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">johnsonr</td><t=
d class=3D"modifications-data">src/org/springframework/beans/factory/suppor=
t/LookupOverride.java</td><td class=3D"modifications-data">Added ReplaceOve=
rride support: MethodOverride.matches now needsowning MethodOverrides as an=
 argument to detect overloading</td></tr><tr class=3D"modifications-oddrow"=
><td class=3D"modifications-data">modified</td><td class=3D"modifications-d=
ata">johnsonr</td><td class=3D"modifications-data">src/org/springframework/=
beans/factory/support/MethodOverride.java</td><td class=3D"modifications-da=
ta">Added ReplaceOverride support: MethodOverride.matches now needsowning M=
ethodOverrides as an argument to detect overloading</td></tr><tr class=3D"m=
odifications-evenrow"><td class=3D"modifications-data">modified</td><td cla=
ss=3D"modifications-data">johnsonr</td><td class=3D"modifications-data">src=
/org/springframework/beans/factory/support/MethodOverrides.java</td><td cla=
ss=3D"modifications-data">Added ReplaceOverride support: MethodOverride.mat=
ches now needsowning MethodOverrides as an argument to detect overloading</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">johnsonr</td><td class=3D"mo=
difications-data">src/org/springframework/beans/factory/support/CglibSubcla=
ssingInstantiationStrategy.java</td><td class=3D"modifications-data">Added =
ReplaceOverride support</td></tr><tr class=3D"modifications-evenrow"><td cl=
ass=3D"modifications-data">modified</td><td class=3D"modifications-data">jo=
hnsonr</td><td class=3D"modifications-data">src/org/springframework/beans/f=
actory/support/AbstractBeanDefinition.java</td><td class=3D"modifications-d=
ata">Added ReplaceOverride support</td></tr><tr class=3D"modifications-oddr=
ow"><td class=3D"modifications-data">modified</td><td class=3D"modification=
s-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewo=
rk/jdbc/support/JdbcUtils.java</td><td class=3D"modifications-data">reworke=
d SqlTypeValue and SqlLobValue, resolved package cross-dependencies between=
 jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><td=
 class=3D"modifications-data">added</td><td class=3D"modifications-data">jh=
oeller</td><td class=3D"modifications-data">src/org/springframework/jdbc/co=
re/support/AbstractSqlTypeValue.java</td><td class=3D"modifications-data">r=
eworked SqlTypeValue and SqlLobValue, resolved package cross-dependencies b=
etween jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-oddrow=
"><td class=3D"modifications-data">added</td><td class=3D"modifications-dat=
a">jhoeller</td><td class=3D"modifications-data">src/org/springframework/jd=
bc/core/support/SqlLobValue.java</td><td class=3D"modifications-data">rewor=
ked SqlTypeValue and SqlLobValue, resolved package cross-dependencies betwe=
en jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><=
td class=3D"modifications-data">deleted</td><td class=3D"modifications-data=
">jhoeller</td><td class=3D"modifications-data">src/org/springframework/jdb=
c/object/SqlLobValueCloser.java</td><td class=3D"modifications-data">rework=
ed SqlTypeValue and SqlLobValue, resolved package cross-dependencies betwee=
n jdbc.core and jdbc.object</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/jdbc=
/object/StoredProcedure.java</td><td class=3D"modifications-data">reworked =
SqlTypeValue and SqlLobValue, resolved package cross-dependencies between j=
dbc.core and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">src/org/springframework/jdbc/c=
ore/CallableStatementCreatorFactory.java</td><td class=3D"modifications-dat=
a">reworked SqlTypeValue and SqlLobValue, resolved package cross-dependenci=
es between jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-od=
drow"><td class=3D"modifications-data">added</td><td class=3D"modifications=
-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewor=
k/jdbc/core/DisposableSqlTypeValue.java</td><td class=3D"modifications-data=
">reworked SqlTypeValue and SqlLobValue, resolved package cross-dependencie=
s between jdbc.core and jdbc.object</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">src/org/springframe=
work/jdbc/core/JdbcTemplate.java</td><td class=3D"modifications-data">rewor=
ked SqlTypeValue and SqlLobValue, resolved package cross-dependencies betwe=
en jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-oddrow"><t=
d class=3D"modifications-data">added</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">src/org/springframework/jdbc/c=
ore/ParameterDisposer.java</td><td class=3D"modifications-data">reworked Sq=
lTypeValue and SqlLobValue, resolved package cross-dependencies between jdb=
c.core and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><td cla=
ss=3D"modifications-data">modified</td><td class=3D"modifications-data">jho=
eller</td><td class=3D"modifications-data">src/org/springframework/jdbc/cor=
e/PreparedStatementCreatorFactory.java</td><td class=3D"modifications-data"=
>reworked SqlTypeValue and SqlLobValue, resolved package cross-dependencies=
 between jdbc.core and jdbc.object</td></tr><tr class=3D"modifications-oddr=
ow"><td class=3D"modifications-data">deleted</td><td class=3D"modifications=
-data">jhoeller</td><td class=3D"modifications-data">src/org/springframewor=
k/jdbc/core/SqlLobValue.java</td><td class=3D"modifications-data">reworked =
SqlTypeValue and SqlLobValue, resolved package cross-dependencies between j=
dbc.core and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">src/org/springframework/jdbc/c=
ore/SqlTypeValue.java</td><td class=3D"modifications-data">reworked SqlType=
Value and SqlLobValue, resolved package cross-dependencies between jdbc.cor=
e and jdbc.object</td></tr><tr class=3D"modifications-oddrow"><td class=3D"=
modifications-data">added</td><td class=3D"modifications-data">jhoeller</td=
><td class=3D"modifications-data">src/org/springframework/jdbc/core/Stateme=
ntCreatorUtils.java</td><td class=3D"modifications-data">reworked SqlTypeVa=
lue and SqlLobValue, resolved package cross-dependencies between jdbc.core =
and jdbc.object</td></tr><tr class=3D"modifications-evenrow"><td class=3D"m=
odifications-data">modified</td><td class=3D"modifications-data">jhoeller</=
td><td class=3D"modifications-data">samples/imagedb/src/org/springframework=
/samples/imagedb/DefaultImageDatabase.java</td><td class=3D"modifications-d=
ata">polishing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"mod=
ifications-data">modified</td><td class=3D"modifications-data">jhoeller</td=
><td class=3D"modifications-data">src/org/springframework/jdbc/core/support=
/AbstractLobCreatingPreparedStatementCallback.java</td><td class=3D"modific=
ations-data">polishing</td></tr><tr class=3D"modifications-evenrow"><td cla=
ss=3D"modifications-data">modified</td><td class=3D"modifications-data">jho=
eller</td><td class=3D"modifications-data">src/org/springframework/jdbc/cor=
e/support/AbstractLobStreamingResultSetExtractor.java</td><td class=3D"modi=
fications-data">polishing</td></tr><tr class=3D"modifications-oddrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">src/org/springframework/jdbc/c=
ore/ParameterMapper.java</td><td class=3D"modifications-data">polishing</td=
></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">=
modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mod=
ifications-data">src/org/springframework/jdbc/core/SqlProvider.java</td><td=
 class=3D"modifications-data">polishing</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">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] JMS questions

From: Les A. H. <le...@ha...> - 2004-06-28 21:17:29

Quoting sk...@fe...:

> By transactions and JMS I assume you mean a transacted JMS Session with
> some support for that in the P2pTemplate or the PubSubTemplate for commits
> and rollbacks. I don't see that level of support in there currently.

I just may have to play with the source code then ;)

> But really it sounds to me like you need to manage event propagation with
> some type of bean transaction. Iff, if and only if, your transacted bean
> does something good put a message on a JMS Destination. It doesn't sound to
> me like your having JMS problems but general transaction flow problems.
> That is your, messages were being sent fine, until you started tweaking the
> nobs, but are being sent at the wrong time in a transactions lifecycle.

Yes, thats exactly what is happening.  However, in a Spring environment, I was
hoping that I could configure my JMS publisher to "send-on-commit" only,
instead of sending immediately during the middle of a transaction.

This is occurring in a POJO that is proxied by a TransactionProxyFactoryBean, so
the transaction management is done via Spring (by using the J2EE 
UserTransaction).  I guess to achieve that behavior in Spring managed
transaction would be to have the JMS session managed by Spring as well?

I wonder if using a TransactionTemplate would help in the interim.  I'll keep
chugging...

Regards,

Les

Re: [Springframework-developer] SqlTypeValue and SqlLobValue

From: <jue...@we...> - 2004-06-28 21:12:53

Indeed, PreparedStatementCreatorFactory and =
CallableStatementCreatorFactory need to apply the NativeJdbcExtractor =
for unwrapping the PreparedStatement respectively CallableStatement. I =
had just tested this with a plain JdbcTemplate, that's why I had not =
noticed the missing unwrapping.
=20
I've just fixed this, to be committed in a couple of minutes...
=20
BTW, I've also moved the "resultSetType" and "updatableResults" =
properties from SqlOperation up to RdbmsOperation, as SqlCall should =
share those to pass them to the CallableStatementCreatorFactory.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Mo 28.06.2004 20:49
An: spr...@li...
Betreff: Re: [Springframework-developer] SqlTypeValue and SqlLobValue



Hello Juergen,

Thanks for the changes!

However, a NativeJdbcExtractor _was_ specified on the JdbcTemplate, so I
did some debugging.

I'm using Commons DBCP (1.1) with CommonsDbcpNativeJdbcExtractor, and
its isNativeConnectionNecessaryForNativePreparedStatements() method is
inherited from NativeJdbcExtractorAdapter and always returns false.

Therefore, in the execute(PreparedStatementCreator psc,
PreparedStatementCallback action) method in JdbcTemplate, the conToUse
passed to psc.createPreparedStatement() at line 323 is the wrapped
connection, while it should be the native one for things to work the way
they are implemented right now.

I'm extending MappingSqlQuery, and my execute method looks like this:

public void execute(String[] codes) {
    execute(new Object[]{new AbstractSqlTypeValue() {
        protected Object createTypeValue(Connection con) throws
        SQLException {
            System.out.println("nativeJdbcExtractor =3D " +
            getJdbcTemplate().getNativeJdbcExtractor());
            System.out.println("con =3D " + con);
            try {
                throw new RuntimeException();
            } catch (RuntimeException ex) {
                ex.printStackTrace();
            }
            return null;
        }
    }});
}

Relevant output:

nativeJdbcExtractor =3D
org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtracto=
r@396c7
con =3D org.apache.commons.dbcp.PoolableConnection@19fe5e6
java.lang.RuntimeException
        at
        =
discharge.TestCustomType$1.createTypeValue(TestCustomType.java:39)
        at
        =
org.springframework.jdbc.core.support.AbstractSqlTypeValue.setTypeValue(A=
bstractSqlTypeValue.java:57)
        at
        =
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValue(Sta=
tementCreatorUtils.java:97)
        at
        =
org.springframework.jdbc.core.StatementCreatorUtils.setParameterValue(Sta=
tementCreatorUtils.java:61)
        at
        =
org.springframework.jdbc.core.PreparedStatementCreatorFactory$PreparedSta=
tementCreatorImpl.setValues(PreparedStatementCreatorFactory.java:179)
        at
        =
org.springframework.jdbc.core.PreparedStatementCreatorFactory$PreparedSta=
tementCreatorImpl.createPreparedStatement(PreparedStatementCreatorFactory=
.java:169)
        at
        =
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:323)=

        at
        =
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:369)
        at
        =
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:397)
        at
        =
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:418)
        at
        =
org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:111)
        at
        =
org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:121)
        at discharge.TestCustomType.execute(TestCustomType.java:34)

I'm not sure how to fix this ;-)

In fact, I think the call to setValues() at line 169 in the
createPreparedStatement() method in PreparedStatementCreatorImpl in
PreparedStatementCreatorFactory [ahem], just shouldn't be there, and
should be done in doInPreparedStatement() in PreparedStatementCallback
instead (e.g. at line 374 in JdbcTemplate).

Hopefully you have a better idea though ;-)

Kind regards,
Tom.

P.S. This is against cvs version of about 10 hours ago.

On Mon, 28 Jun 2004 18:48:37 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Good points! I've just added the "typeName" parameter to setTypeValue =
and
> createTypeValue.
>=20
> Indeed, JdbcTemplate will normally work with the wrapped JDBC objects
> from the pool. However, you can specify a "nativeJdbcExtractor" on the
> JdbcTemplate instance: This will cause automatic unwrapping of all =
JDBC
> objects passed to callbacks. So if you specify that, you'll also get =
the
> native Connection respectively native PreparedStatement in your
> SqlTypeValue implementations.
>=20
> Juergen


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] chain ViewResolvers?

From: Timo V. <sic...@gm...> - 2004-06-28 21:07:57

Alef,


> <servlet>
>   <servlet-name>blah</servlet-name>
>  
> <servlet-class>org.spfr.web.servlet.DispatcherServlet</servlet-class>
> <init-param>
>     <param-name>detectAllViewResolvers</param-name>
>     <param-name>false</param-name>
>   </init-param>
> </servlet>

Thanks, I'll try that. My email should've gone to the user's list, 
sorry!

> Just curious, why do you need to do this? You've extended a
> controller and implemented a the viewresolvers interface?

I've written two ViewResolvers: a RedirectViewResolver and a 
DelegatingViewResolver. On resolveViewName() the RedirectViewResolver 
takes any view-name, creates a new RedirectView and returns that. The 
DelegatingViewResolver dispatches view names to registered 
ViewResolvers based on a prefix in the viewName; it has a default 
ViewResolver if no prefix matches. In my setup, for instance,  
"redirect:http://www.springframework.org" would be delegated to my 
RedirectViewResolver (without the "redirect:" prefix).

I wrote about this a while ago. Juergen said, it was not in the spirit 
of spring to have the controller know anything about the view; i.e. 
prefixing the viewName to influence the rendering. Basically, I agree, 
but I needed to do it anyway, since it solved a problem:

I have controllers in my web-app, which need to setup a fairly complex 
model for e.g. a "viewCustomer" view. When I need to view a customer 
from a different controller, e.g. after a completed "updateCustomer" 
form-view, I had the choice to copy-paste the complex model-creation 
code, or to redirect to the original "viewCustomer" view. Well, instead 
of copy-paste I could've abstracted things away, but I preferred the 
second solution anyway, since it allowed users to set bookmarks 
correctly. Since I want to stay in spring spirit, i.e. I do not want to 
hardcode the RedirectView creation and the redirection address in my 
update controllers, I store "redirect:viewCustomer" in the successView 
property via XML (and pass the customerId in the model).

Regards,

Timo

Re: [Springframework-developer] JMS questions

From: <sk...@fe...> - 2004-06-28 20:30:13

There was an email today, from Juergen, saying that JMS support would
"most likely" be in by the end of July? I don't recall what release that
cooresponds to not 1.1 final I believe it must have been some 1.2 version.
Check the archives from today for details, see Juergen post on releases.

By transactions and JMS I assume you mean a transacted JMS Session with
some support for that in the P2pTemplate or the PubSubTemplate for commits
and rollbacks. I don't see that level of support in there currently.

In general it sounds like your "auto-commit" option works with some
exceptions and your transacted JMS session does not work. BTW the ack mode
doesn't mean much for a transacted session. One generally passes in -1 or 0
to show that. Now that your telling the JMS Session to be transacted your
going to have to have some transaction code in there, commit or rollback
for example. It also matters where your transacted session is setup on the
sender or the receiver. I can't really tell but it sounds like you have
setup a transacted session when you send the message only and the session
is waiting for that commit to actually send the message. One would use this
type of functionality to send a group of messages atomically I would think.

But really it sounds to me like you need to manage event propagation with
some type of bean transaction. Iff, if and only if, your transacted bean
does something good put a message on a JMS Destination. It doesn't sound to
me like your having JMS problems but general transaction flow problems.
That is your, messages were being sent fine, until you started tweaking the
nobs, but are being sent at the wrong time in a transactions lifecycle.
FWIW.

SKroah

|---------+----------------------------------------------------->
| | "Les A. Hazlewood" <le...@ha...> |
| | Sent by: |
| | spr...@li...|
| | ceforge.net |
| | |
| | |
| | 06/28/2004 03:18 PM |
| | Please respond to |
| | springframework-developer |
| | |
|---------+----------------------------------------------------->
>----------------------------------------------------------------------------------------------|
| |
| To: spr...@li... |
| cc: |
| Subject: [Springframework-developer] JMS questions |
>----------------------------------------------------------------------------------------------|

Hiya folks,

I was wondering if anyone had any thoughts on when the JMS components would
be
integrated into a Spring release? I'm not looking for any specific
dates...just a ballpark figure (and yes, I know that this is an Open Source
product, so I take ballpark figures with a grain of salt...I'm just looking
for
something, anything).

Also, I was wondering if anyone could help me out with some insight....

Here's my issue:

An EJB method is called from a remote client. In response to that method
call,
some data is processed, saved back to the db, and then a JMS message is
published to all clients who care about that data. The data is not
committed
until the end of the transaction.

The JMS message is received by a client which then immediately requests the
data
that was just updated.

Occasionally, when the client requests this data, it doesn't get what it
expects. The reason for this is that we think the client is making a
request
for the data before the first transaction has had a chance to commit/flush.

So, basically, we'd like to sync the JMS sending to only send upon
transaction
commit, to ensure that the data will be in the db by the time the clients
request it.

I tried setting the JMS transacted attribute to true when creating a topic
session,
i.e.

topicSession =
topicConnection.createTopicSession(true, Session.AUTO_ACKNOWLEDGE );

After reading the JMS spec, this is all that should be necessary when
participating in transactions in a J2EE container.

However, we're seeing that the client's don't receive _any_ messages from
the
server when set to true. When set to false, the messages are being sent,
but
that synchronization issue pops its head up.

Does anyone have any insights on why this is happening?

Also, does the Spring JMS support in the sandbox already work with
integrating
into transactions, like the Spring Hibernate support does?

Any ideas would be graciously received.

Regards,

Les

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] JMS questions

From: Les A. H. <le...@ha...> - 2004-06-28 19:18:46

Hiya folks,

I was wondering if anyone had any thoughts on when the JMS components would be
integrated into a Spring release?  I'm not looking for any specific
dates...just a ballpark figure (and yes, I know that this is an Open Source
product, so I take ballpark figures with a grain of salt...I'm just looking for
something, anything).

Also, I was wondering if anyone could help me out with some insight....

Here's my issue:

An EJB method is called from a remote client.  In response to that method call,
some data is processed, saved back to the db, and then a JMS message is
published to all clients who care about that data.  The data is not committed
until the end of the transaction.

The JMS message is received by a client which then immediately requests the data
that was just updated.

Occasionally, when the client requests this data, it doesn't get what it
expects.  The reason for this is that we think the client is making a request
for the data before the first transaction has had a chance to commit/flush.

So, basically, we'd like to sync the JMS sending to only send upon transaction
commit, to ensure that the data will be in the db by the time the clients
request it.

I tried setting the JMS transacted attribute to true when creating a topic
session,
i.e.

topicSession =
    topicConnection.createTopicSession(true, Session.AUTO_ACKNOWLEDGE );


After reading the JMS spec, this is all that should be necessary when
participating in transactions in a J2EE container.

However, we're seeing that the client's don't receive _any_ messages from the
server when set to true.  When set to false, the messages are being sent, but
that synchronization issue pops its head up.

Does anyone have any insights on why this is happening?

Also, does the Spring JMS support in the sandbox already work with integrating
into transactions, like the Spring Hibernate support does?

Any ideas would be graciously received.

Regards,

Les

Re: [Springframework-developer] SqlTypeValue and SqlLobValue

From: Tom T. <tom...@pr...> - 2004-06-28 18:49:33

Hello Juergen,

Thanks for the changes!

However, a NativeJdbcExtractor _was_ specified on the JdbcTemplate, so I
did some debugging.

I'm using Commons DBCP (1.1) with CommonsDbcpNativeJdbcExtractor, and
its isNativeConnectionNecessaryForNativePreparedStatements() method is
inherited from NativeJdbcExtractorAdapter and always returns false.

Therefore, in the execute(PreparedStatementCreator psc,
PreparedStatementCallback action) method in JdbcTemplate, the conToUse
passed to psc.createPreparedStatement() at line 323 is the wrapped
connection, while it should be the native one for things to work the way
they are implemented right now.

I'm extending MappingSqlQuery, and my execute method looks like this:

public void execute(String[] codes) {
    execute(new Object[]{new AbstractSqlTypeValue() {
        protected Object createTypeValue(Connection con) throws
        SQLException {
            System.out.println("nativeJdbcExtractor =3D " +
            getJdbcTemplate().getNativeJdbcExtractor());
            System.out.println("con =3D " + con);
            try {
                throw new RuntimeException();
            } catch (RuntimeException ex) {
                ex.printStackTrace();
            }
            return null;
        }
    }});
}

Relevant output:

nativeJdbcExtractor =3D
org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtractor@=
396c7
con =3D org.apache.commons.dbcp.PoolableConnection@19fe5e6
java.lang.RuntimeException
        at
        discharge.TestCustomType$1.createTypeValue(TestCustomType.java:39)
        at
        org.springframework.jdbc.core.support.AbstractSqlTypeValue.setTypeV=
alue(AbstractSqlTypeValue.java:57)
        at
        org.springframework.jdbc.core.StatementCreatorUtils.setParameterVal=
ue(StatementCreatorUtils.java:97)
        at
        org.springframework.jdbc.core.StatementCreatorUtils.setParameterVal=
ue(StatementCreatorUtils.java:61)
        at
        org.springframework.jdbc.core.PreparedStatementCreatorFactory$Prepa=
redStatementCreatorImpl.setValues(PreparedStatementCreatorFactory.java:179)
        at
        org.springframework.jdbc.core.PreparedStatementCreatorFactory$Prepa=
redStatementCreatorImpl.createPreparedStatement(PreparedStatementCreatorFac=
tory.java:169)
        at
        org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.jav=
a:323)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
369)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
397)
        at
        org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:=
418)
        at
        org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:111)
        at
        org.springframework.jdbc.object.SqlQuery.execute(SqlQuery.java:121)
        at discharge.TestCustomType.execute(TestCustomType.java:34)

I'm not sure how to fix this ;-)

In fact, I think the call to setValues() at line 169 in the
createPreparedStatement() method in PreparedStatementCreatorImpl in
PreparedStatementCreatorFactory [ahem], just shouldn't be there, and
should be done in doInPreparedStatement() in PreparedStatementCallback
instead (e.g. at line 374 in JdbcTemplate).

Hopefully you have a better idea though ;-)

Kind regards,
Tom.

P.S. This is against cvs version of about 10 hours ago.

On Mon, 28 Jun 2004 18:48:37 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Good points! I've just added the "typeName" parameter to setTypeValue and
> createTypeValue.
>=20=20
> Indeed, JdbcTemplate will normally work with the wrapped JDBC objects
> from the pool. However, you can specify a "nativeJdbcExtractor" on the
> JdbcTemplate instance: This will cause automatic unwrapping of all JDBC
> objects passed to callbacks. So if you specify that, you'll also get the
> native Connection respectively native PreparedStatement in your
> SqlTypeValue implementations.
>=20=20
> Juergen

[Springframework-developer] Spring/AspectJ integration

From: Rod J. <rod...@in...> - 2004-06-28 18:19:00

All

I did a lot of work over the weekend on integrating Spring/AspectJ. After
the factory method IoC enhancement (which was motivated largely by AspectJ
integration, although it's otherwise useful), this hasn't required more
changes to the implementation of Spring: just experimentation with how
things work out in practice.

The fruit of this effort is in the new "samples" module, under the aspectj
directory.

This is an Eclipse AspectJ project, with two sub-projects: teacher and bank.

Teacher is based on Adrian Colyer's girl/boy/teacher example, which he
featured on his blog shortly after TSS Symposium. Thanks to Adrian for
solving the basic problem in Spring/AspectJ integration: how to configure
aspects using Dependency Injection. (Note btw the use of the "depends-on"
attribute to ensure that an aspect is configured before it's used. The
special aspect initialization bean Adrian's code used is not required.)

Bank is a new example, showing a few scenarios relevant to enterprise usage.
It's based around a Bank interface managing fine-grained Account objects. It
uses AspectJ to advise those objects, with aspects configured using Spring
DI. Advising fine-grained objects is a problem that proxy-based solutions
such as Spring's own AOP framework are not well suited to addressing.
AspectJ is perfect here.

I'm currently working on some more esoteric features, such as getting Spring
to configure "perthis" aspects, but the essential Spring/AspectJ integration
is in place. I'll be adding to and polishing the code in the samples module
over the next few weeks, with the aim of releasing it as a separate sample
download some time in July.

I think that integration with AspectJ is going to benefit many Spring users.
This is going to be one of the major new features of Spring 1.1. I encourage
users interested in AOP to check it out, and feed back comments or
contributions.

Btw there is no conflict with using AspectJ and Spring's own AOP framework
in the same application.

Currently there are no build scripts in the aspectj sample--it relies on
Eclipse. Any contribution of a build script will be gratefully received!

Rgds
Rod

Re: [Springframework-developer] SqlTypeValue and SqlLobValue

From: <jue...@we...> - 2004-06-28 16:47:56

Good points! I've just added the "typeName" parameter to setTypeValue =
and createTypeValue.
=20
Indeed, JdbcTemplate will normally work with the wrapped JDBC objects =
from the pool. However, you can specify a "nativeJdbcExtractor" on the =
JdbcTemplate instance: This will cause automatic unwrapping of all JDBC =
objects passed to callbacks. So if you specify that, you'll also get the =
native Connection respectively native PreparedStatement in your =
SqlTypeValue implementations.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Tom Turelinckx
Gesendet: Mo 28.06.2004 18:00
An: spr...@li...
Betreff: Re: [Springframework-developer] SqlTypeValue and SqlLobValue



Thomas, Juergen,

I've experimented a bit with the new SqlTypeValue support, and I 'm
wondering why only the sqlType is being passed as a parameter to
setTypeValue, but not the typeName...

When using an inner class implementation - which I don't actually agree
would be typical usage - you usually already know the sqlType;
otherwise, you usually need the typeName as well. Note that the typeName
"NUMBERS" is duplicated in the javadoc example.

The AbstractSqlTypeValue class is very convenient, but at least the
typeName, and probably also the sqlType would need to be passed to
createTypeValue().

So I suggest changing the respective signatures to:

void setTypeValue(PreparedStatement ps, int paramIndex, int sqlType,
String typeName) throws SQLException;

protected abstract Object createTypeValue(Connection con, int sqlType,
String typeName) throws SQLException;

This would allow "flexible" custom SqlTypeValues to be implemented:

public class OracleArraySqlTypeValue extends AbstractSqlTypeValue {
    private final Object value;

    public OracleArraySqlTypeValue(Object value) {
        this.value =3D value;
    }

    protected Object createTypeValue(Connection con, int sqlType, String
    typeName) throws SQLException {
        if (sqlType !=3D Types.ARRAY) {
            throw new IllegalArgumentException("only SQL Type ARRAY is
            supported by " + getClass());
        }
        return new ARRAY(ArrayDescriptor.createDescriptor(typeName,
        con), con, value);
    }
}

Unlike when using an inner class, the actual application classes are now
no longer dependent on Oracle classes. Moreover, you don't need to
copy-paste the implementation every time ;-)

Another issue I encountered is that both the PreparedStatement and
Connection are not the native, but wrapped objects. (I was using a
SqlQuery object and a Commons DBCP connection pool.)
Is it the responsibility of the SqlTypeValue implementation to unwrap
these, or could that be done by JdbcTemplate? I suppose most
SqlTypeValue implementations would need the native objects, and as they
are throw-away objects created with "new", you can't just wire the
NativeJdbcExtractor to them...

I think refactoring SqlLobValue as a (Disposable)SqlTypeValue was an
excellent idea :-)
I've tried some blob operations on Oracle, and everything still seems to
work (OracleLobHandler has its own NativeJdbcExtractor!). These weren't
extensive tests though...

Grateful if you could have a look at these issues!

Kind regards,
Tom.

On Mon, 28 Jun 2004 09:21:26 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Thomas,
>=20
> I've just committed a refactoring of the SqlTypeValue and SqlLobValue
> stuff. We had some package cross-dependencies there that I resolved
> (between jdbc.core and jdbc.support, caused by SqlTypeValue residing =
in
> jdbc.core but jdbc.support.JdbcUtils accessing it).
>=20
> I've gone beyond that in that I made SqlLobValue a subclass of
> SqlTypeValue: All the parameter value code (now in
> jdbc.core.StatementCreatorUtils rather than jdbc.support.JdbcUtils) =
needs
> to worry about is SqlTypeValue; it will automatically cover =
SqlLobValue
> too. Consequently, SqlLobValue resides in jdbc.core.support now
> (alongside AbstractLobCreatingPreparedStatementCallback and
> AbstractLobStreamingResultSetExtractor), as there's no need for any =
class
> in jdbc.core to know about it.
>=20
> Furthermore, SqlTypeValue is an interface now: I strongly believe that =
it
> should be an interface rather than an abstract class. For typical =
usage
> as inner class, there is no need for a value property in the first
> place... I've also added an AbstractSqlTypeValue class to
> jdbc.core.support that pre-implements the setTypeValue method by
> delegating to an " Object createTypeValue(Connection con)" method
> (assuming to be set with PreparedStatement.setObject).
>=20
> I hope you're happy with the changes; please have a look at them and =
tell
> me what you think. I hope I didn't misunderstand the purpose of
> SqlTypeValue, but I guess it's desirable to have it unified with
> SqlLobValue.It would also be good to run them against some Oracle =
samples
> once again :-)
>=20
> I've also noticed that there aren't specific unit tests for =
SqlTypeValue
> and SqlLobValue yet. We need to add some till 1.1 RC1. I've tested the
> new classes against our "imagedb" sample on MySQL, BTW, playing with
> various BLOB/CLOB access strategies.
>=20
> Juergen
>=20
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SqlTypeValue and SqlLobValue

From: Tom T. <tom...@pr...> - 2004-06-28 16:00:38

Thomas, Juergen,

I've experimented a bit with the new SqlTypeValue support, and I 'm
wondering why only the sqlType is being passed as a parameter to
setTypeValue, but not the typeName...

When using an inner class implementation - which I don't actually agree
would be typical usage - you usually already know the sqlType;
otherwise, you usually need the typeName as well. Note that the typeName
"NUMBERS" is duplicated in the javadoc example.

The AbstractSqlTypeValue class is very convenient, but at least the
typeName, and probably also the sqlType would need to be passed to
createTypeValue().

So I suggest changing the respective signatures to:

void setTypeValue(PreparedStatement ps, int paramIndex, int sqlType,
String typeName) throws SQLException;

protected abstract Object createTypeValue(Connection con, int sqlType,
String typeName) throws SQLException;

This would allow "flexible" custom SqlTypeValues to be implemented:

public class OracleArraySqlTypeValue extends AbstractSqlTypeValue {
    private final Object value;

    public OracleArraySqlTypeValue(Object value) {
        this.value =3D value;
    }

    protected Object createTypeValue(Connection con, int sqlType, String
    typeName) throws SQLException {
        if (sqlType !=3D Types.ARRAY) {
            throw new IllegalArgumentException("only SQL Type ARRAY is
            supported by " + getClass());
        }
        return new ARRAY(ArrayDescriptor.createDescriptor(typeName,
        con), con, value);
    }
}

Unlike when using an inner class, the actual application classes are now
no longer dependent on Oracle classes. Moreover, you don't need to
copy-paste the implementation every time ;-)

Another issue I encountered is that both the PreparedStatement and
Connection are not the native, but wrapped objects. (I was using a
SqlQuery object and a Commons DBCP connection pool.)
Is it the responsibility of the SqlTypeValue implementation to unwrap
these, or could that be done by JdbcTemplate? I suppose most
SqlTypeValue implementations would need the native objects, and as they
are throw-away objects created with "new", you can't just wire the
NativeJdbcExtractor to them...

I think refactoring SqlLobValue as a (Disposable)SqlTypeValue was an
excellent idea :-)
I've tried some blob operations on Oracle, and everything still seems to
work (OracleLobHandler has its own NativeJdbcExtractor!). These weren't
extensive tests though...

Grateful if you could have a look at these issues!

Kind regards,
Tom.

On Mon, 28 Jun 2004 09:21:26 +0200, "j=FCrgen h=F6ller [werk3AT]"
<jue...@we...> said:
> Thomas,
>=20=20
> I've just committed a refactoring of the SqlTypeValue and SqlLobValue
> stuff. We had some package cross-dependencies there that I resolved
> (between jdbc.core and jdbc.support, caused by SqlTypeValue residing in
> jdbc.core but jdbc.support.JdbcUtils accessing it).
>=20=20
> I've gone beyond that in that I made SqlLobValue a subclass of
> SqlTypeValue: All the parameter value code (now in
> jdbc.core.StatementCreatorUtils rather than jdbc.support.JdbcUtils) needs
> to worry about is SqlTypeValue; it will automatically cover SqlLobValue
> too. Consequently, SqlLobValue resides in jdbc.core.support now
> (alongside AbstractLobCreatingPreparedStatementCallback and
> AbstractLobStreamingResultSetExtractor), as there's no need for any class
> in jdbc.core to know about it.
>=20=20
> Furthermore, SqlTypeValue is an interface now: I strongly believe that it
> should be an interface rather than an abstract class. For typical usage
> as inner class, there is no need for a value property in the first
> place... I've also added an AbstractSqlTypeValue class to
> jdbc.core.support that pre-implements the setTypeValue method by
> delegating to an " Object createTypeValue(Connection con)" method
> (assuming to be set with PreparedStatement.setObject).
>=20=20
> I hope you're happy with the changes; please have a look at them and tell
> me what you think. I hope I didn't misunderstand the purpose of
> SqlTypeValue, but I guess it's desirable to have it unified with
> SqlLobValue.It would also be good to run them against some Oracle samples
> once again :-)
>=20=20
> I've also noticed that there aren't specific unit tests for SqlTypeValue
> and SqlLobValue yet. We need to add some till 1.1 RC1. I've tested the
> new classes against our "imagedb" sample on MySQL, BTW, playing with
> various BLOB/CLOB access strategies.
>=20=20
> Juergen
>=20=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] chain ViewResolvers?

From: Alef A. <al...@jt...> - 2004-06-28 15:16:43

Timo,

The DispatcherSerlvet is a JavaBean just as any other Spring-managed =
bean only this time, the properties have to be set as init-parameters in =
your web.xml alongside the servlet definition:

<servlet>
  <servlet-name>blah</servlet-name>
  <servlet-class>org.spfr.web.servlet.DispatcherServlet</servlet-class>
  <init-param>
    <param-name>detectAllViewResolvers</param-name>
    <param-name>false</param-name>
  </init-param>
</servlet>

Corresponding parameters are available for not detecting all handler =
mappings and exception resolvers.

Just curious, why do you need to do this? You've extended a controller =
and implemented a the viewresolvers interface?

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Timo Verhoeven
> Sent: Monday, June 28, 2004 5:00 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] chain ViewResolvers?
>=20
>=20
> Hi!
>=20
> I need to set the detectAllViewResolvers in the DispatcherServlet but =
I
> have no clue how to do this without subclassing it. I never define a
> DispatcherServlet bean in any of my XML files, so I cannot simply set
> this property via spring. The dispatcher servlet is "set up" in my
> web.xml, where AFAIK I cannot set bean properties.
>=20
> Am I missing something?!?
>=20
> Regards,
>=20
> Timo
>=20
>=20
> Am Dienstag, 4. Mai 2004 21:28 schrieb j=FCrgen h=F6ller [werk3AT]:
> > Already committed - the new DispatcherServlet bean property is =
called
> > "detectAllViewResolvers", default is true. If you're doing obscure
> > things with ViewResolvers, simply turn "detectAllViewResolvers" off
> > ;-)
> >
> > Juergen
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] chain ViewResolvers?

From: Timo V. <sic...@gm...> - 2004-06-28 14:44:43

Hi!

I need to set the detectAllViewResolvers in the DispatcherServlet but I=20
have no clue how to do this without subclassing it. I never define a=20
DispatcherServlet bean in any of my XML files, so I cannot simply set=20
this property via spring. The dispatcher servlet is "set up" in my=20
web.xml, where AFAIK I cannot set bean properties.=20

Am I missing something?!?

Regards,

Timo


Am Dienstag, 4. Mai 2004 21:28 schrieb j=FCrgen h=F6ller [werk3AT]:
> Already committed - the new DispatcherServlet bean property is called
> "detectAllViewResolvers", default is true. If you're doing obscure
> things with ViewResolvers, simply turn "detectAllViewResolvers" off
> ;-)
>
> Juergen

Re: [Springframework-developer] Include/import directive in XML bean definition files

From: Timo V. <sic...@gm...> - 2004-06-28 12:38:47

Am Montag, 28. Juni 2004 10:21 schrieb j=FCrgen h=F6ller [werk3AT]:
> For a start, we need to decide:
> - custom "include" element or XInclude support?

I'd suggest a mix: Implement the custom solution as a single simple=20
filter class, which turns the parsed infoset into a new infoset=20
including includes, now. The syntax should be real XIncude but the=20
functionality only a subset (i.e. no XPointer, no parse as text, no=20
fixups [see spec] etc.), until a blackbox solution is available=20
somewhere else or until somebody writes it for spring. Then the filter=20
could simply be replaced, provding full XInclude support, while=20
retaining backwards-compatibility.

Regards,

Timo

Re: [Springframework-developer] Include/import directive in XML bean definition files

From: Colin S. <col...@ex...> - 2004-06-28 12:18:35

+1

jürgen höller [werk3AT] wrote:

>For a start, we need to decide:
>- custom "include" element or XInclude support?
>- Spring 1.1 or 1.2 timeframe?
> 
>I personally prefer external config locations, and consider an "include" element as purely optional feature, particularly given that XML entity includes already work. I don't have a fixed opinion on the implementation strategy yet; if there's no clear consensus on the actual strategy within the next 2 weeks, I vote for moving this to Spring 1.2.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Timo Verhoeven
>Gesendet: Sa 26.06.2004 11:57
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Include/import directive in XML bean definition files
>
>
>
>
>Alef, Jürgen,
>
>I've done some research. The XInclude spec is quite short (in terms of
>the W3C), http://www.w3.org/TR/xinclude/ . Digest:
>
>XInclude transforms the infoset, thus happens after parsing. XInclude
>defines only two elements: include and fallback. Include uses IRIs
>(Internationalized Resource Identifiers, essentially URIs) to reference
>resources. It can import those resources as xml or text. In case of xml
>it can use XPointer to include only portions of the resource.
>
>  
>
>>How does the XInclude stuff retrieve the resources. Will it allow us
>>to specify resources in somewhat the same way as we do now
>>(classpath:, etcetera) and is it possible to integrate this with the
>>resource package we have?
>>    
>>
>
>AFAIK, IRIs/URIs can have application specific form. The XInclude spec
>explicitly says
>
>"The specifics of how an infoset is created are intentionally
>unspecified, to allow for flexibility by implementations and to avoid
>defining a particular processing model for components of the XML
>architecture. Particulars of whether DTD or XML schema validation are
>performed, for example, are not constrained by this specification."
>
>  
>
>>>Sounds plausible. I'm no XML expert, though: How could we make this
>>>work?
>>>      
>>>
>
>We "only" need a simple layer, which processes all XInclude elements of
>the infoset (the parsed XML). I couldn't find a simple black box
>solution, only this:
>
>- XIncluder, http://xincluder.sourceforge.net/ : Seems to be
>unmaintained, not feature complete; nevertheless it's the basis for
>some other projects (XOM, e.g.).
>
>- GNU JAXP, http://www.gnu.org/software/classpathx/jaxp/ : "includes a
>SAX filter that resolves XIncludes, provided no XPointers are used"
>
>- Cocoon XInclude transformer,
>http://cocoon.apache.org/2.1/userdocs/transformers/xinclude-transformer.html :
>Seems to be feature complete, but written for use in cocoon
>
>The Cocoon stuff might be worth reviewing.
>
>BTW, using DTDs for validation has a little drawback: DTDs are not
>namespace aware. Thus an updated Spring DTD for XInclude would force
>the user to use a fixed prefix (xi, e.g.). The example I posted was
>"incorrect", since it defined a namespace in the <beans> tag. FYI, the
>XInclude spec provides DTD templates (and an XML schema) for XInclude
>usage:
>
><!ELEMENT xi:include (xi:fallback?)>
><!ATTLIST xi:include
>    xmlns:xi        CDATA       #FIXED   
>"http://www.w3.org/2001/XInclude"
>    href            CDATA       #IMPLIED
>    parse           (xml|text)  "xml"
>    xpointer        CDATA       #IMPLIED
>    encoding        CDATA       #IMPLIED
>    accept          CDATA       #IMPLIED
>    accept-language CDATA       #IMPLIED
>  
>
>
><!ELEMENT xi:fallback ANY>
><!ATTLIST xi:fallback
>    xmlns:xi   CDATA   #FIXED   "http://www.w3.org/2001/XInclude"
>  
>
>
>
>Regards,
>
>Timo
>  
>

Re: [Springframework-developer] IoC container enhancements

From: Rod J. <rod...@in...> - 2004-06-28 11:56:44

To round out our Method Injection support, I've just added the ability for
the container to override a method to replace it with an arbitrary piece of
code, in an implementation of the MethodReplacer interface.

The XML syntax looks as follows:

<replaced-method name="doSomething"

    replacer="beanNameOfReplacer">

</replaced-method>



This is a less commonly useful feature than lookup Method Injection, but it
has certain uses. For example, a protected setRollbackOnly method could be
overridden by the container to use the TransactionContext, avoiding Spring
dependencies in testing. I would envisage most of the usages, like this one,
involving a fairly generic, reusable MethodReplacer.

An example of what could be done: a getDataSource() method could be
overridden to return a transactional DataSource if there's an active
transaction, otherwise a read-only DataSource.  Of course this kind of thing
can often be done with a custom TargetSource. However, there is a difference
here: Method Injection actually changes the class, so the class can invoke
methods on itself and get the new behaviour without going through a proxy.

I will try to put together examples and usage guidelines before 1.1 final is
released. If you're interested in the meantime, take a look at
XmlBeanFactoryTestSuite. I see Method Injection as very useful in a number
of corner cases, but not something to use without good reason.

Rgds

Rod

[Springframework-developer] Project problem

From: Claudio D'A. <cla...@ob...> - 2004-06-28 09:54:49

Hi,
we are using spring 1.0.2 in our project but we've an eccentric client
requirement.
We use ibatis (with spring integration) to perform the db query and we have
separeted backend and frontend.

When the user execute a request, a controller use a manager (be) to execute
the query to DB.

The requirement is:
An user have associated to a locale (nation)
The system must execute query using datasource that vary in base of locale.
I.E.
The user Mark has associated the locale ES
The user Claudio has associated the locale IT

the insert for Mark user must go to the datasource DataSource_es
the insert for Claudio user must go to the datasource DataSource_it

Is there an system in spring (or can you help me) to elab this requirement?

Thank's much

Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it

--
La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o !
in violazione degli scopi della presente.

Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi ed e' risultato NON infetto.

This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addresses. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful.

The message has been verified for virus and malaware and is safe.
(MI)

[Springframework-developer] Release schedule

From: <jue...@we...> - 2004-06-28 08:29:38

Hi everybody,=20

As many of you might already have noticed, we decided to go straight to =
1.1 RC1 as our next release. This means that there won't be an =
intermediate 1.0.3 release with minor enhancements but rather an earlier =
1.1 release candidate. The main reason is that we already have major new =
functionality in CVS that is worth of becoming 1.1.

The current plan is to release 1.1 RC1 on July 11th, with the following =
new features:=20

* refined Cglib2AopProxy implementation=20
* support for static factory methods in the BeanFactory=20
* method-based dependency injection aka lookup methods=20
* more powerful root/child bean definition concept=20
* "classpath*" prefix for retrieving all classpath resources with same =
name=20
* opened-up application event handling (allowing for Mule integration)=20
* nested transaction support (via JDBC 3.0 Savepoints)=20
* custom SQL type values as JDBC operation parameters
* BLOB/CLOB values as JDBC operation parameters (via LobHandler)
* BatchSqlUpdate class for convenient batch operations
* refined JdoDialect in preparation for JDO 2.0 compatibility=20
* convenience operations on JdoTemplate (a la HibernateTemplate)
* added OpenPersistenceManagerInViewInterceptor/Filter for JDO
* support for persistent Quartz jobs with Spring resource management=20
* explicit support for HTML checkboxes (via field marker parameters)

All of those features are already in CVS and open for review. We will =
spend the next two weeks reviewing and refining, and are grateful for =
any early feedback!

For 1.1 final by the end of July, we plan to have the following too:=20

* SQLException translation enhancements=20
* support for JDBC 3.0 auto-generated keys=20
* support for sending JMS messages (moved out of the sandbox)=20
* basic JSF integration helpers (analogous to our Struts helpers)=20
* form simplification macros (for JSP 2.0, Velocity, FreeMarker)=20

All remaining enhancement requests have been moved to 1.2 (to be =
expected in autumn), most notably Portlet support and JMX support. =
Furthermore, Keith's rules-based declarative validation is likely to =
become a subproject, with a first stable release to be expected within =
the Spring 1.2 timeframe.

Regards,=20

Juergen

Re: [Springframework-developer] Include/import directive in XML bean definition files

From: <jue...@we...> - 2004-06-28 08:20:46

For a start, we need to decide:
- custom "include" element or XInclude support?
- Spring 1.1 or 1.2 timeframe?
=20
I personally prefer external config locations, and consider an "include" =
element as purely optional feature, particularly given that XML entity =
includes already work. I don't have a fixed opinion on the =
implementation strategy yet; if there's no clear consensus on the actual =
strategy within the next 2 weeks, I vote for moving this to Spring 1.2.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Timo Verhoeven
Gesendet: Sa 26.06.2004 11:57
An: spr...@li...
Betreff: Re: [Springframework-developer] Include/import directive in XML =
bean definition files




Alef, J=FCrgen,

I've done some research. The XInclude spec is quite short (in terms of
the W3C), http://www.w3.org/TR/xinclude/ . Digest:

XInclude transforms the infoset, thus happens after parsing. XInclude
defines only two elements: include and fallback. Include uses IRIs
(Internationalized Resource Identifiers, essentially URIs) to reference
resources. It can import those resources as xml or text. In case of xml
it can use XPointer to include only portions of the resource.

> How does the XInclude stuff retrieve the resources. Will it allow us
> to specify resources in somewhat the same way as we do now
> (classpath:, etcetera) and is it possible to integrate this with the
> resource package we have?

AFAIK, IRIs/URIs can have application specific form. The XInclude spec
explicitly says

"The specifics of how an infoset is created are intentionally
unspecified, to allow for flexibility by implementations and to avoid
defining a particular processing model for components of the XML
architecture. Particulars of whether DTD or XML schema validation are
performed, for example, are not constrained by this specification."

> > Sounds plausible. I'm no XML expert, though: How could we make this
> > work?

We "only" need a simple layer, which processes all XInclude elements of
the infoset (the parsed XML). I couldn't find a simple black box
solution, only this:

- XIncluder, http://xincluder.sourceforge.net/ : Seems to be
unmaintained, not feature complete; nevertheless it's the basis for
some other projects (XOM, e.g.).

- GNU JAXP, http://www.gnu.org/software/classpathx/jaxp/ : "includes a
SAX filter that resolves XIncludes, provided no XPointers are used"

- Cocoon XInclude transformer,
http://cocoon.apache.org/2.1/userdocs/transformers/xinclude-transformer.h=
tml :
Seems to be feature complete, but written for use in cocoon

The Cocoon stuff might be worth reviewing.

BTW, using DTDs for validation has a little drawback: DTDs are not
namespace aware. Thus an updated Spring DTD for XInclude would force
the user to use a fixed prefix (xi, e.g.). The example I posted was
"incorrect", since it defined a namespace in the <beans> tag. FYI, the
XInclude spec provides DTD templates (and an XML schema) for XInclude
usage:

<!ELEMENT xi:include (xi:fallback?)>
<!ATTLIST xi:include
    xmlns:xi        CDATA       #FIXED  =20
"http://www.w3.org/2001/XInclude"
    href            CDATA       #IMPLIED
    parse           (xml|text)  "xml"
    xpointer        CDATA       #IMPLIED
    encoding        CDATA       #IMPLIED
    accept          CDATA       #IMPLIED
    accept-language CDATA       #IMPLIED
>

<!ELEMENT xi:fallback ANY>
<!ATTLIST xi:fallback
    xmlns:xi   CDATA   #FIXED   "http://www.w3.org/2001/XInclude"
>


Regards,

Timo


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] SqlTypeValue and SqlLobValue

From: <jue...@we...> - 2004-06-28 07:20:45

Thomas,
=20
I've just committed a refactoring of the SqlTypeValue and SqlLobValue =
stuff. We had some package cross-dependencies there that I resolved =
(between jdbc.core and jdbc.support, caused by SqlTypeValue residing in =
jdbc.core but jdbc.support.JdbcUtils accessing it).
=20
I've gone beyond that in that I made SqlLobValue a subclass of =
SqlTypeValue: All the parameter value code (now in =
jdbc.core.StatementCreatorUtils rather than jdbc.support.JdbcUtils) =
needs to worry about is SqlTypeValue; it will automatically cover =
SqlLobValue too. Consequently, SqlLobValue resides in jdbc.core.support =
now (alongside AbstractLobCreatingPreparedStatementCallback and =
AbstractLobStreamingResultSetExtractor), as there's no need for any =
class in jdbc.core to know about it.
=20
Furthermore, SqlTypeValue is an interface now: I strongly believe that =
it should be an interface rather than an abstract class. For typical =
usage as inner class, there is no need for a value property in the first =
place... I've also added an AbstractSqlTypeValue class to =
jdbc.core.support that pre-implements the setTypeValue method by =
delegating to an " Object createTypeValue(Connection con)" method =
(assuming to be set with PreparedStatement.setObject).
=20
I hope you're happy with the changes; please have a look at them and =
tell me what you think. I hope I didn't misunderstand the purpose of =
SqlTypeValue, but I guess it's desirable to have it unified with =
SqlLobValue.It would also be good to run them against some Oracle =
samples once again :-)
=20
I've also noticed that there aren't specific unit tests for SqlTypeValue =
and SqlLobValue yet. We need to add some till 1.1 RC1. I've tested the =
new classes against our "imagedb" sample on MySQL, BTW, playing with =
various BLOB/CLOB access strategies.
=20
Juergen
=20

RE: [Springframework-developer] IoC container enhancements

From: Tom T. <tom...@pr...> - 2004-06-28 06:27:49

Btw, I too prefer this over autowire-by-type in some cases and would
like it to be added, as it effectively provides control over both which
properties are autowired and which bean is wired to them.

Regards,
Tom.

On Mon, 28 Jun 2004 08:05:56 +0200, "Tom Turelinckx"
<tom...@pr...> said:
> Sorry, I only read your last mail, not the discussion in Confluence :$
> Shouldn't send mails after midnight ;-)
>=20
> Now that I've read it, I do agree with Juergen that an injection
> interface having a single method with a single parameter would be
> sufficient.
>=20
> A single interface with multiple setters would probably be used to
> combine DAO's often used together. I suppose you could just create an
> interface extending several other interfaces with a single setter each
> in that case?
>=20
> Best regards,
> Tom.
>=20
> On Mon, 28 Jun 2004 00:35:55 +0200, "Tom Turelinckx"
> <tom...@pr...> said:
> > James,
> >=20
> > What about a BeanPostProcessor?
> >=20
> > For example:
> >=20
> > public interface DaoAware {
> >     public void setDao( Dao dao );
> > }
> >=20
> > public class DaoAwareProcessor implements BeanPostProcessor,
> > InitializingBean {
> >     Dao dao;
> >=20
> >     public void setDao( Dao dao ) {
> >         this.dao =3D dao;
> >     }
> >=20
> >     public void afterPropertiesSet() throws Exception {
> >         if ( dao =3D=3D null ) {
> >             throw new ApplicationContextException( "dao property must be
> >             set on " + getClass() );
> >         }
> >     }
> >=20
> >     public Object postProcessBeforeInitialization( Object bean, String
> >     name ) {
> >         if ( bean instanceof DaoAware ) {
> >             ( ( DaoAware ) bean ).setDao( dao );
> >         }
> >         return bean;
> >     }
> >=20
> >     public Object postProcessAfterInitialization( Object bean, String
> >     name ) {
> >         return bean;
> >     }
> > }
> >=20
> > Kind regards,
> > Tom.
> >=20
> > On Sun, 27 Jun 2004 10:43:00 -0400, "James Cook"
> > <jim...@do...> said:
> > > Well, I will argue it a bit :-)
> > >=20
> > > We use it to simplify the mapping of our DAO's to our web tier by mak=
ing
> > > our
> > > servlet actions implement a DAOAware interface. It is extremely
> > > convenient
> > > to implement an interface and get the mapping for free. It is one step
> > > more
> > > explicit than autowire-by-type which I like. (Too much magic on large
> > > projects can create very difficult to debug scenarios.) It helps mini=
mize
> > > the size of our Spring configuration, and it *works*.
> > >=20
> > > I'm too close to the solution to notice "any oddness" in its
> > > configuration
> > > :-) Without some additional framework support, I don't see any other =
way
> > > to
> > > do it now. The single property<->value relationship in that configura=
tion
> > > could be expanded to take a collection of property<->value relationsh=
ips
> > > in
> > > order to support multiple setters in a single interface.
> > >=20
> > > It's OK if you don't want to internalize it into the framework since =
it
> > > is
> > > obviously supported now in some fashion. If you did come up with some=
 way
> > > to
> > > internalize it, perhaps it wouldn't get used much, I don't know. I kn=
ow
> > > our
> > > team greatly appreciates the convenience.
> > >=20
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...] On B=
ehalf
> > > > Of j=FCrgen h=F6ller [werk3AT]
> > > > Sent: Friday, June 25, 2004 1:19 PM
> > > > To: spr...@li...
> > > > Subject: Re: [Springframework-developer] IoC container enhancements
> > > >=20
> > > > While this would be easy enough to add, I doubt that many people wi=
ll use
> > > > it. IMHO, it feels a bit odd to first implement an interface that
> > > > specifies a setter and then still apply the property value via a
> > > > "property" key (which has to match the bean property of the setter =
in the
> > > > interface).
> > > >=20
> > > > If we do magic anyway, why not assume that the injection interface
> > > > specifies a single method with a single parameter? We could then in=
voke
> > > > that method with the specified argument value. This would at least =
remove
> > > > the "property" redundancy.
> > > >=20
> > > > I understand that this was the first way of IoC that XWork/WebWork2
> > > > supported, but I'm not convinced that it is really recommendable. F=
eel
> > > > free to argue about that :-)
> > > >=20
> > > > Juergen
> > > >=20
> > > >=20
> > > > ________________________________
> > > >=20
> > > > Von: spr...@li... im Auftr=
ag von
> > > > James Cook
> > > > Gesendet: Fr 25.06.2004 15:40
> > > > An: spr...@li...
> > > > Betreff: RE: [Springframework-developer] IoC container enhancements
> > > >=20
> > > >=20
> > > >=20
> > > > Since you are enhancing the injection support for the container, do=
 you
> > > > think it is worthwhile adding syntax to support Type 1 (Interface
> > > > Injection)
> > > > IoC?
> > > >=20
> > > > http://opensource.atlassian.com/confluence/spring/display/DISC/Addi=
ng+Inte
> > > > rf
> > > > ace+Injection+to+Spring
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: spr...@li...
> > > > > [mailto:spr...@li...] On=
 Behalf
> > > > > Of Rod Johnson
> > > > > Sent: Friday, June 25, 2004 3:50 AM
> > > > > To: spr...@li...
> > > > > Subject: Re: [Springframework-developer] IoC container enhancemen=
ts
> > > > >
> > > > > > Lookup methods can be combined with Setter Injection. They
> > > > > > can't presently be combined with Constructor Injection, but I
> > > > > > will add support for this, assuming that it's possible with
> > > > > > CGLIB.
> > > > >
> > > > >
> > > > > I've just removed this restriction.
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > > digital self defense, top technical experts, no vendor pitches,
> > > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > > _______________________________________________
> > > > > Springframework-developer mailing list
> > > > > Spr...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/springframework-deve=
loper
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > digital self defense, top technical experts, no vendor pitches,
> > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > digital self defense, top technical experts, no vendor pitches,
> > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > >=20
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] IoC container enhancements

From: Tom T. <tom...@pr...> - 2004-06-28 06:05:57

Sorry, I only read your last mail, not the discussion in Confluence :$
Shouldn't send mails after midnight ;-)

Now that I've read it, I do agree with Juergen that an injection
interface having a single method with a single parameter would be
sufficient.

A single interface with multiple setters would probably be used to
combine DAO's often used together. I suppose you could just create an
interface extending several other interfaces with a single setter each
in that case?

Best regards,
Tom.

On Mon, 28 Jun 2004 00:35:55 +0200, "Tom Turelinckx"
<tom...@pr...> said:
> James,
>=20
> What about a BeanPostProcessor?
>=20
> For example:
>=20
> public interface DaoAware {
>     public void setDao( Dao dao );
> }
>=20
> public class DaoAwareProcessor implements BeanPostProcessor,
> InitializingBean {
>     Dao dao;
>=20
>     public void setDao( Dao dao ) {
>         this.dao =3D dao;
>     }
>=20
>     public void afterPropertiesSet() throws Exception {
>         if ( dao =3D=3D null ) {
>             throw new ApplicationContextException( "dao property must be
>             set on " + getClass() );
>         }
>     }
>=20
>     public Object postProcessBeforeInitialization( Object bean, String
>     name ) {
>         if ( bean instanceof DaoAware ) {
>             ( ( DaoAware ) bean ).setDao( dao );
>         }
>         return bean;
>     }
>=20
>     public Object postProcessAfterInitialization( Object bean, String
>     name ) {
>         return bean;
>     }
> }
>=20
> Kind regards,
> Tom.
>=20
> On Sun, 27 Jun 2004 10:43:00 -0400, "James Cook"
> <jim...@do...> said:
> > Well, I will argue it a bit :-)
> >=20
> > We use it to simplify the mapping of our DAO's to our web tier by making
> > our
> > servlet actions implement a DAOAware interface. It is extremely
> > convenient
> > to implement an interface and get the mapping for free. It is one step
> > more
> > explicit than autowire-by-type which I like. (Too much magic on large
> > projects can create very difficult to debug scenarios.) It helps minimi=
ze
> > the size of our Spring configuration, and it *works*.
> >=20
> > I'm too close to the solution to notice "any oddness" in its
> > configuration
> > :-) Without some additional framework support, I don't see any other way
> > to
> > do it now. The single property<->value relationship in that configurati=
on
> > could be expanded to take a collection of property<->value relationships
> > in
> > order to support multiple setters in a single interface.
> >=20
> > It's OK if you don't want to internalize it into the framework since it
> > is
> > obviously supported now in some fashion. If you did come up with some w=
ay
> > to
> > internalize it, perhaps it wouldn't get used much, I don't know. I know
> > our
> > team greatly appreciates the convenience.
> >=20
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On Beh=
alf
> > > Of j=FCrgen h=F6ller [werk3AT]
> > > Sent: Friday, June 25, 2004 1:19 PM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-developer] IoC container enhancements
> > >=20
> > > While this would be easy enough to add, I doubt that many people will=
 use
> > > it. IMHO, it feels a bit odd to first implement an interface that
> > > specifies a setter and then still apply the property value via a
> > > "property" key (which has to match the bean property of the setter in=
 the
> > > interface).
> > >=20
> > > If we do magic anyway, why not assume that the injection interface
> > > specifies a single method with a single parameter? We could then invo=
ke
> > > that method with the specified argument value. This would at least re=
move
> > > the "property" redundancy.
> > >=20
> > > I understand that this was the first way of IoC that XWork/WebWork2
> > > supported, but I'm not convinced that it is really recommendable. Feel
> > > free to argue about that :-)
> > >=20
> > > Juergen
> > >=20
> > >=20
> > > ________________________________
> > >=20
> > > Von: spr...@li... im Auftrag=
 von
> > > James Cook
> > > Gesendet: Fr 25.06.2004 15:40
> > > An: spr...@li...
> > > Betreff: RE: [Springframework-developer] IoC container enhancements
> > >=20
> > >=20
> > >=20
> > > Since you are enhancing the injection support for the container, do y=
ou
> > > think it is worthwhile adding syntax to support Type 1 (Interface
> > > Injection)
> > > IoC?
> > >=20
> > > http://opensource.atlassian.com/confluence/spring/display/DISC/Adding=
+Inte
> > > rf
> > > ace+Injection+to+Spring
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: spr...@li...
> > > > [mailto:spr...@li...] On B=
ehalf
> > > > Of Rod Johnson
> > > > Sent: Friday, June 25, 2004 3:50 AM
> > > > To: spr...@li...
> > > > Subject: Re: [Springframework-developer] IoC container enhancements
> > > >
> > > > > Lookup methods can be combined with Setter Injection. They
> > > > > can't presently be combined with Constructor Injection, but I
> > > > > will add support for this, assuming that it's possible with
> > > > > CGLIB.
> > > >
> > > >
> > > > I've just removed this restriction.
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > > digital self defense, top technical experts, no vendor pitches,
> > > > unmatched networking opportunities. Visit www.blackhat.com
> > > > _______________________________________________
> > > > Springframework-developer mailing list
> > > > Spr...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo=
per
> > >=20
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >=20
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] IoC container enhancements

From: Oliver H. <Ol...@ou...> - 2004-06-27 23:11:48

I also believe that interface injection is a valid pattern and should be =
supported explicitly by the mapping docs. It seems a pity that Spring =
uses Type 1 under the covers (the Bean*Aware interfaces come to mind) =
but has no support for specifying custom interface injection.

Couldn't it be added quite simply through an extension of the root/child =
support?

With the current support you can do this:

  <bean id=3D"org.whatever.Interface" class=3D"org.whatever.Interface">
    <property name=3D"a"><value>1</value></property>
    <property name=3D"b"><value>2</value></property>
  </bean>
 =20
  <bean id=3D"implementingBean" class=3D"org.whatever.InterfaceImpl"
	parent=3D"org.whatever.Interface" />

But would it be possible to implement a BeanFactoryPostProcessor that =
could detect any beans that implement org.whatever.Interface and =
automatically apply the parent attribute to them?=20



> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of James Cook
> Sent: Monday, 28 June 2004 12:43 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] IoC container enhancements
>=20
>=20
> Well, I will argue it a bit :-)
>=20
> We use it to simplify the mapping of our DAO's to our web=20
> tier by making our servlet actions implement a DAOAware=20
> interface. It is extremely convenient to implement an=20
> interface and get the mapping for free. It is one step more=20
> explicit than autowire-by-type which I like. (Too much magic=20
> on large projects can create very difficult to debug=20
> scenarios.) It helps minimize the size of our Spring=20
> configuration, and it *works*.
>=20
> I'm too close to the solution to notice "any oddness" in its=20
> configuration
> :-) Without some additional framework support, I don't see=20
> any other way to do it now. The single property<->value=20
> relationship in that configuration could be expanded to take=20
> a collection of property<->value relationships in order to=20
> support multiple setters in a single interface.
>=20
> It's OK if you don't want to internalize it into the=20
> framework since it is obviously supported now in some=20
> fashion. If you did come up with some way to internalize it,=20
> perhaps it wouldn't get used much, I don't know. I know our=20
> team greatly appreciates the convenience.
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On=20
> > Behalf Of j=FCrgen h=F6ller [werk3AT]
> > Sent: Friday, June 25, 2004 1:19 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] IoC container enhancements
> >=20
> > While this would be easy enough to add, I doubt that many=20
> people will=20
> > use it. IMHO, it feels a bit odd to first implement an=20
> interface that=20
> > specifies a setter and then still apply the property value via a=20
> > "property" key (which has to match the bean property of the=20
> setter in=20
> > the interface).
> >=20
> > If we do magic anyway, why not assume that the injection interface=20
> > specifies a single method with a single parameter? We could then=20
> > invoke that method with the specified argument value. This would at=20
> > least remove the "property" redundancy.
> >=20
> > I understand that this was the first way of IoC that XWork/WebWork2=20
> > supported, but I'm not convinced that it is really=20
> recommendable. Feel=20
> > free to argue about that :-)
> >=20
> > Juergen
> >=20
> >=20
> > ________________________________
> >=20
> > Von: spr...@li...=20
> im Auftrag=20
> > von James Cook
> > Gesendet: Fr 25.06.2004 15:40
> > An: spr...@li...
> > Betreff: RE: [Springframework-developer] IoC container enhancements
> >=20
> >=20
> >=20
> > Since you are enhancing the injection support for the container, do=20
> > you think it is worthwhile adding syntax to support Type 1=20
> (Interface
> > Injection)
> > IoC?
> >=20
> >=20
> http://opensource.atlassian.com/confluence/spring/display/DISC/Adding+
> > Inte
> > rf
> > ace+Injection+to+Spring
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On=20
> > > Behalf Of Rod Johnson
> > > Sent: Friday, June 25, 2004 3:50 AM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-developer] IoC container=20
> enhancements
> > >
> > > > Lookup methods can be combined with Setter Injection.=20
> They can't=20
> > > > presently be combined with Constructor Injection, but I=20
> will add=20
> > > > support for this, assuming that it's possible with CGLIB.
> > >
> > >
> > > I've just removed this restriction.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > >=20
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s> =
pringframework-developer
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s> =
pringframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

RE: [Springframework-developer] IoC container enhancements

From: Tom T. <tom...@pr...> - 2004-06-27 22:36:00

James,

What about a BeanPostProcessor?

For example:

public interface DaoAware {
    public void setDao( Dao dao );
}

public class DaoAwareProcessor implements BeanPostProcessor,
InitializingBean {
    Dao dao;

    public void setDao( Dao dao ) {
        this.dao =3D dao;
    }

    public void afterPropertiesSet() throws Exception {
        if ( dao =3D=3D null ) {
            throw new ApplicationContextException( "dao property must be
            set on " + getClass() );
        }
    }

    public Object postProcessBeforeInitialization( Object bean, String
    name ) {
        if ( bean instanceof DaoAware ) {
            ( ( DaoAware ) bean ).setDao( dao );
        }
        return bean;
    }

    public Object postProcessAfterInitialization( Object bean, String
    name ) {
        return bean;
    }
}

Kind regards,
Tom.

On Sun, 27 Jun 2004 10:43:00 -0400, "James Cook"
<jim...@do...> said:
> Well, I will argue it a bit :-)
>=20
> We use it to simplify the mapping of our DAO's to our web tier by making
> our
> servlet actions implement a DAOAware interface. It is extremely
> convenient
> to implement an interface and get the mapping for free. It is one step
> more
> explicit than autowire-by-type which I like. (Too much magic on large
> projects can create very difficult to debug scenarios.) It helps minimize
> the size of our Spring configuration, and it *works*.
>=20
> I'm too close to the solution to notice "any oddness" in its
> configuration
> :-) Without some additional framework support, I don't see any other way
> to
> do it now. The single property<->value relationship in that configuration
> could be expanded to take a collection of property<->value relationships
> in
> order to support multiple setters in a single interface.
>=20
> It's OK if you don't want to internalize it into the framework since it
> is
> obviously supported now in some fashion. If you did come up with some way
> to
> internalize it, perhaps it wouldn't get used much, I don't know. I know
> our
> team greatly appreciates the convenience.
>=20
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of j=FCrgen h=F6ller [werk3AT]
> > Sent: Friday, June 25, 2004 1:19 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] IoC container enhancements
> >=20
> > While this would be easy enough to add, I doubt that many people will u=
se
> > it. IMHO, it feels a bit odd to first implement an interface that
> > specifies a setter and then still apply the property value via a
> > "property" key (which has to match the bean property of the setter in t=
he
> > interface).
> >=20
> > If we do magic anyway, why not assume that the injection interface
> > specifies a single method with a single parameter? We could then invoke
> > that method with the specified argument value. This would at least remo=
ve
> > the "property" redundancy.
> >=20
> > I understand that this was the first way of IoC that XWork/WebWork2
> > supported, but I'm not convinced that it is really recommendable. Feel
> > free to argue about that :-)
> >=20
> > Juergen
> >=20
> >=20
> > ________________________________
> >=20
> > Von: spr...@li... im Auftrag v=
on
> > James Cook
> > Gesendet: Fr 25.06.2004 15:40
> > An: spr...@li...
> > Betreff: RE: [Springframework-developer] IoC container enhancements
> >=20
> >=20
> >=20
> > Since you are enhancing the injection support for the container, do you
> > think it is worthwhile adding syntax to support Type 1 (Interface
> > Injection)
> > IoC?
> >=20
> > http://opensource.atlassian.com/confluence/spring/display/DISC/Adding+I=
nte
> > rf
> > ace+Injection+to+Spring
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: spr...@li...
> > > [mailto:spr...@li...] On Beh=
alf
> > > Of Rod Johnson
> > > Sent: Friday, June 25, 2004 3:50 AM
> > > To: spr...@li...
> > > Subject: Re: [Springframework-developer] IoC container enhancements
> > >
> > > > Lookup methods can be combined with Setter Injection. They
> > > > can't presently be combined with Constructor Injection, but I
> > > > will add support for this, assuming that it's possible with
> > > > CGLIB.
> > >
> > >
> > > I've just removed this restriction.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by Black Hat Briefings & Training.
> > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > > digital self defense, top technical experts, no vendor pitches,
> > > unmatched networking opportunities. Visit www.blackhat.com
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

1239 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 268 269 270 271 272 .. 465 > >> (Page 270 of 465)