springframework-developer — Spring Framework developers list

Re: [Springframework-developer] BeanWrapperImpl abstraction

[<jue...@we...>]

OK, I see. But I don't see a strong need to factor a base class out, =
actually. Rather, I see a need to make some of the currently private =
methods in BeanWrapperImpl protected, to allow for easier subclassing - =
in particular:

- getPropertyValue(String propertyName, String actualName, String key)
- setPropertyValue(String propertyName, String actualName, String key, =
Object value)

Can you try to figure out the exact set of methods that you need =
protected rather than private? We can then still decide to factor out a =
base class; but for a start, it would be good enough to allow for =
subclassing BeanWrapperImpl itself.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Alef Arendsen
Sent: Tuesday, June 08, 2004 2:19 PM
To: spr...@li...
Subject: RE: [Springframework-developer] BeanWrapperImpl abstraction


> I wouldn't mind such a refactoring. However, I don't see the clear
> distinction between the new base class and BeanWrapperImpl: If the
base
> class contains everything including bean introspection, what exactly
is
> BeanWrapperImpl supposed to add - respectively, what does your own
> subclass do differently?

To allow for partial results to be returned from (Hibernate) queries but
still letting the clients believe it's a concrete object, my own
BeanWrapper is backed by a PropertyValues object rather than the real
object. A call to getWrappedInstance() returns a Proxy, proxying to
BeanWrapper to retrieve the values.

This allows me to without changing anything to the view (the view can
still use the databinder and the actual wrapped instance as internally
that uses the BeanWrapper backed by the PropertyValues) switch from
full-objects to partial objects being returned to the view or fat
client.

Reason for all this: complex domain model with huge objects (healthcare
and the like) with stringent security requirements (certain parts of
objects just cannot be transferred over the wire for example). Both the
security requirements are met as well as the performance troubles
(heavily interlinked domain model, where clients hardly ever need to
view more than 5% of all data available). The latter could probably be
solved by using the open session in view stuff, but it's problematic
with fat and remote clients.

> I assume that your own subclass wouldn't implement the BeanWrapper
> interface in the first place, because it has its own API way. I just
> wonder what it looks like then :-)
Yes it does implement BeanWrapper ;-). It has the exact same
functionality (you cannot modify properties with it, just read them).

> I doubt that there will ever be an alternative implementation of the
> BeanWrapper interface itself. It still makes sense to decouple
interface
> and implementation here, if just for testability. BeanWrapperImpl
already
> is a quite complex piece that you shouldn't necessarily work with
> directly.
It's a rare use case, but actually makes sense (to me ;-). Same
functionality, different wrapped object.

> If the changes don't affect the public BeanWrapper API, I wouldn't
mind
> including them in 1.0.3 - provided that we're just talking about a
> refactoring that does not modify existing functionality.
In my use case the only thing that changes is the wrapped instance (more
specifically, the data container actually holding the data of the
(proxied) interface being wrapped). Basically I would stick with the
current API of the BeanWrapper and implement the AbstractBeanWrapper as
a somewhat strategy-like class, where the current BeanWrapperImpl just
has to override get/setPropertyValue(propertyName, actualName, key)
method, currently delegating to the read/writeMethods of the object
being wrapped (there is where I need to make changes).

alef



-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Persistent jobs with Quartz

[<jue...@we...>]

Hi everybody,

Up to 1.0.2, our Quartz support focuses on non-persistent jobs. Of =
course, you can configure a persistent JobStore via Quartz properties. =
The out-of-the-box options that Quartz provides are limited, though:

- JobStoreTX: Quartz will use its own Commons DBCP connection pool, =
performing its own transaction management. So if you use already use a =
connection pool within your app, you'll end up with a separate pool just =
for Quartz.

- JobStoreCMT: Quartz will use a J2EE container DataSource, and rely on =
JTA respectively EJB CMT for transaction management. You can make job =
registrations participate in enclosing transactions, but just when using =
JTA.

So what I've done is added a further option to our scheduling.quartz =
package: LocalDataSourceJobStore, using a Spring-configured DataSource =
and participating in Spring's transaction management. It is driven by =
SchedulerFactoryBean's new "dataSource" property, which will =
automatically configure that JobStore (similar to =
LocalSessionFactoryBean and LocalDataSourceConnectionProvider).

-----

Note that a JobDetail needs to respect an obvious limitation to be =
persistable with any JDBC-based JobStore: All the elements in the =
JobDataMap need to be serializable. This in particular means that =
MethodInvokingJobDetailFactoryBean does not work with persistent jobs, =
and that you cannot put Spring bean references into a JobDataMap.

Instead, put your bean references into the Scheduler's SchedulerContext, =
via SchedulerFactoryBean's "schedulerContextAsMap" property (introduced =
in 1.0.2). All those elements will be exposed to all Quartz jobs, and =
Spring's QuartzJobBean automatically applies them as bean property =
values too, just like elements in the JobDataMap.

-----

A further enhancement to SchedulerFactoryBean - unrelated to the above - =
is the "jobSchedulingDataLocations" property. Any resource specified =
there is expected to be an XML file that conforms to Quartz 1.3's =
"job_scheduling_data_1_0" DTD, defining jobs and triggers. =
SchedulerFactoryBean will automatically register those too, just like =
any jobs and triggers that are directly defined on itself.

I'll commit those enhancements tomorrow, after testing them in the =
target application. I guess they're a straightforward addition to =
1.0.2's Quartz support, so I'm all for making those part of 1.0.3.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

RE: [Springframework-developer] BeanWrapperImpl abstraction

[Alef A. <al...@jt...>]

> I wouldn't mind such a refactoring. However, I don't see the clear
> distinction between the new base class and BeanWrapperImpl: If the
base
> class contains everything including bean introspection, what exactly
is
> BeanWrapperImpl supposed to add - respectively, what does your own
> subclass do differently?

To allow for partial results to be returned from (Hibernate) queries but
still letting the clients believe it's a concrete object, my own
BeanWrapper is backed by a PropertyValues object rather than the real
object. A call to getWrappedInstance() returns a Proxy, proxying to
BeanWrapper to retrieve the values.

This allows me to without changing anything to the view (the view can
still use the databinder and the actual wrapped instance as internally
that uses the BeanWrapper backed by the PropertyValues) switch from
full-objects to partial objects being returned to the view or fat
client.

Reason for all this: complex domain model with huge objects (healthcare
and the like) with stringent security requirements (certain parts of
objects just cannot be transferred over the wire for example). Both the
security requirements are met as well as the performance troubles
(heavily interlinked domain model, where clients hardly ever need to
view more than 5% of all data available). The latter could probably be
solved by using the open session in view stuff, but it's problematic
with fat and remote clients.

> I assume that your own subclass wouldn't implement the BeanWrapper
> interface in the first place, because it has its own API way. I just
> wonder what it looks like then :-)
Yes it does implement BeanWrapper ;-). It has the exact same
functionality (you cannot modify properties with it, just read them).

> I doubt that there will ever be an alternative implementation of the
> BeanWrapper interface itself. It still makes sense to decouple
interface
> and implementation here, if just for testability. BeanWrapperImpl
already
> is a quite complex piece that you shouldn't necessarily work with
> directly.
It's a rare use case, but actually makes sense (to me ;-). Same
functionality, different wrapped object.

> If the changes don't affect the public BeanWrapper API, I wouldn't
mind
> including them in 1.0.3 - provided that we're just talking about a
> refactoring that does not modify existing functionality.
In my use case the only thing that changes is the wrapped instance (more
specifically, the data container actually holding the data of the
(proxied) interface being wrapped). Basically I would stick with the
current API of the BeanWrapper and implement the AbstractBeanWrapper as
a somewhat strategy-like class, where the current BeanWrapperImpl just
has to override get/setPropertyValue(propertyName, actualName, key)
method, currently delegating to the read/writeMethods of the object
being wrapped (there is where I need to make changes).

alef

Re: [Springframework-developer] BeanWrapperImpl abstraction

[<jue...@we...>]

Alef,

I wouldn't mind such a refactoring. However, I don't see the clear =
distinction between the new base class and BeanWrapperImpl: If the base =
class contains everything including bean introspection, what exactly is =
BeanWrapperImpl supposed to add - respectively, what does your own =
subclass do differently?

I assume that your own subclass wouldn't implement the BeanWrapper =
interface in the first place, because it has its own API way. I just =
wonder what it looks like then :-)

I doubt that there will ever be an alternative implementation of the =
BeanWrapper interface itself. It still makes sense to decouple interface =
and implementation here, if just for testability. BeanWrapperImpl =
already is a quite complex piece that you shouldn't necessarily work =
with directly.

In particular, BeanWrapperImpl has some public methods that are *not* in =
the BeanWrapper interface, for advanced functionality that is not =
typically needed in application code.

If the changes don't affect the public BeanWrapper API, I wouldn't mind =
including them in 1.0.3 - provided that we're just talking about a =
refactoring that does not modify existing functionality.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Tuesday, June 08, 2004 10:37 AM
To: spr...@li...
Subject: Re: [Springframework-developer] BeanWrapperImpl abstraction


Alef

>Would it be an idea to do a small refactoring of the BeanWrapper (for
1.1 or 1.2) and to create the following:

AbstractBeanWrapper:
- customer editors
- introspection stuff
- convenience methods (getPropertyNameTokens and some of the other ones)

BeanWrapperImpl:
- backed by an object and doing the actual setting and getting of
properties

>Yes yes, I know, extending the BeanWrapper is a rare use case, but by
doing it I don't have to change a thing to my web layer ;-)

I'm in favour of this refactoring. After all, the BeanWrapper interface =
only
makes sense if BeanWrapperImpl isn't the only possible impl.

Rgds
Rod




-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] spring build.22 Build Successful

[Alef A. <al...@jt...>]

Like discussed earlier, building will occur every day (if modifications
have been found) at about 0:15 (CET) from now on (this one is done at
noon, have to test it a bit). Future builds will also include the
modifications done during the past day. Testing for now will be done on
Tomcat 4 and 5. Testing on other servers available will be added later.

=20

Rgds,

Alef

[Springframework-developer] spring build.22 Build Successful

[<al...@jt...>]

<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.22</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>06/08/2004 11:58:37</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>8 minutes 18 seconds</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: /jteam/build/checkout/spring/s=
pring/test/org/springframework/mail/MailTestSuite.java uses or overrides a =
deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation for de=
tails.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1458)                </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2">                            All Tests Pas=
sed                        </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></tr><tr><td colspan=3D"2">&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;               =
     (0)                </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;(5)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building jar: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></t=
r><tr><td class=3D"distributables-data">Building war: /jteam/build/checkout=
/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><tr cl=
ass=3D"distributables-oddrow"><td class=3D"distributables-data">Building ja=
r: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/war/WEB-IN=
F/lib/jpetstore.jar</td></tr><tr><td class=3D"distributables-data">Building=
 war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/dist/jp=
etstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] BeanWrapperImpl abstraction

[Rod J. <rod...@in...>]

Alef

>Would it be an idea to do a small refactoring of the BeanWrapper (for
1.1 or 1.2) and to create the following:

AbstractBeanWrapper:
- customer editors
- introspection stuff
- convenience methods (getPropertyNameTokens and some of the other ones)

BeanWrapperImpl:
- backed by an object and doing the actual setting and getting of
properties

>Yes yes, I know, extending the BeanWrapper is a rare use case, but by
doing it I don't have to change a thing to my web layer ;-)

I'm in favour of this refactoring. After all, the BeanWrapper interface only
makes sense if BeanWrapperImpl isn't the only possible impl.

Rgds
Rod

[Springframework-developer] spring Build Failed

[<al...@jt...>]

<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 FAILED</td></tr><tr><td cl=
ass=3D"header-data"><span class=3D"header-label">Ant Error Message:&nbsp;</=
span>file:/jteam/build/checkout/spring/spring/build.xml:1: The markup in th=
e document preceding the root element must be well-formed.</td></tr><tr><td=
 class=3D"header-data"><span class=3D"header-label">Date of build:&nbsp;</s=
pan>06/08/2004 00:51:32</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Time to build:&nbsp;</span>0 seconds</td></tr><tr><td cla=
ss=3D"header-data"><span class=3D"header-label">Last changed:&nbsp;</span>0=
6/07/2004 11:37:18</td></tr><tr><td class=3D"header-data"><span class=3D"he=
ader-label">Last log entry:&nbsp;</span>improved RequestHandledEvent and Me=
thodInvokingFactoryBean</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>
<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: (1458)                </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2">                            All Tests Pas=
sed                        </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></tr><tr><td colspan=3D"2">&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;               =
     (1)                </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">/changelog.txt</td><td class=
=3D"modifications-data">improved RequestHandledEvent and MethodInvokingFact=
oryBean</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"></table>
</body></html>

Re: [Springframework-developer] CVS Lock

[Darren D. <da...@da...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 07 June 2004 23:49, Alef Arendsen wrote:
> It seems like CVS is stuck. Luke, you seem to have a lock somewhere
> (integrationtest/ejbtest/simple/ejb). I would have thought anonymous CVS
> wouldn't have any problems there (I'm using anon CVS for the automatic
> builds).

I just updated and committed some stuff through Eclipse.. seems ok.

=2D --=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxPwWKLMLAN01aw0RAmjsAJ43J/RzsBiGVrF+YezPtRy8o8U8NACfdXZ2
nBEnkHXojKeR+gfJkN0/CLU=3D
=3DBg6l
=2D----END PGP SIGNATURE-----

[Springframework-developer] RE: [springframework] Autobuilds

[Darren D. <da...@da...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> It would be nice to have some
> automatic retrieval process, but that's not necessary for now. I was
> talking about the versions of the applications servers (stated in the
> build.xml right now). The automated build should reflect the current
> state of the CVS as much as possible (including server versions tested
> against).

I just commited changes to build files such that:

 * server properties are externalised in a CVS file called=20
servers.properties

 * if the correct server binary is not found locally, it will automatically=
=20
be downloaded (not tested through proxy servers or anything other than a=20
direct connection)

should be pretty clear, let me know if something doesn't work as expected?
D.

=2D --=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxPvOKLMLAN01aw0RAnXYAJ9IjWUCafPI9VKksixbOao+gKki+QCfUbcW
MwjA6GbIXs7H4oRKIUVxPA0=3D
=3DcNJQ
=2D----END PGP SIGNATURE-----

[Springframework-developer] CVS Lock

[Alef A. <al...@jt...>]

It seems like CVS is stuck. Luke, you seem to have a lock somewhere
(integrationtest/ejbtest/simple/ejb). I would have thought anonymous CVS
wouldn't have any problems there (I'm using anon CVS for the automatic
builds).

Is there a way to get the lock out of the way?

Alef

[Springframework-developer] BeanWrapperImpl abstraction

[Alef A. <al...@jt...>]

Juergen,

I'm refactoring one of our proprietary utilities at the moment to let it
use Spring more. We don't want to use the open-session-in-view stuff and
have defined standard views for read-only data from a complex domain
model. The views state what they want to render (especially handy when
showing just parts of objects in for example a list) and get proxies
backed by maps instead of the actual objects.

We originally realized this by building our own data wrapper (way before
we starting using Spring), but I'm refactoring it to use the BeanWrapper
instead. Instead of an actual object backing the BeanWrapper, this is
one uses PropertyValues (like I said, it used to be maps).

While creating a new BeanWrapper, I'm encountering a lot of duplication
of functionality, specifically the caching of introspection results (I
basically had to copy the CachedIntroSpectionResults class) and the
registering of propertyeditors.

Would it be an idea to do a small refactoring of the BeanWrapper (for
1.1 or 1.2) and to create the following:

AbstractBeanWrapper:
- customer editors
- introspection stuff
- convenience methods (getPropertyNameTokens and some of the other ones)

BeanWrapperImpl:
- backed by an object and doing the actual setting and getting of
properties

Yes yes, I know, extending the BeanWrapper is a rare use case, but by
doing it I don't have to change a thing to my web layer ;-)

Alef

RE: [Springframework-developer] Commons Validator support

[Daniel M. <mi...@pa...>]

Juergen, all,

I agree that those classes copied and pasted from Struts are messy. I didn't
rewrite them because I haven't felt like getting dirty when I wasn't at work
lately :)

I'm not sure what is available in CV 1.1 though. It's been a long time since
I looked at that. I had originally tried to use it but changed my mind
because it was marked "alpha". As far as I know, this is still the case (CV
is at 1.2 now too). At any rate, is it going to be much easier to integrate
Spring and CV cleanly with v1.2 than with 1.0.2?

I totally agree that the CV project should maintain the FieldChecks class.
Currently it is the opposite; FieldChecks is the class that Spring is
supposed to maintain to provide the interface between CV and
Errors.rejectValue. It would be nice if the CV project would abstract the
framework-specific part of the FieldChecks class out to a simple interface
something like this:

public interface ValidationErrorPublisher {
    /**
     * Framework-specific error message publisher.
     *
     * @param field The field to be validated.
     * @param va The ValidatorAction for which the error occurred.
     * @param parameters Parameters passed to the Validator via
setParameter().
     */
    void publishError(Field field, ValidatorAction va, Map parameters);
}

Then we could just maintain an implementation of this instead of the entire
FieldChecks class with all of its validation code. That would take care of
FieldChecks--AND a standard version of validation-rules.xml could even be
provided by CV because frameworks would no longer have to tell CV how to
call each validation rule.

I also agree that JavascriptValidatorTag should be maintained by CV. They
should at least provide a version of this class with abstract dependency
retrieval methods (getValidatorResources and getMessage) so that a framework
could simply extend the abstract class to provide this tag.

As it stands, the commons-validator was never really fully abstracted when
it was moved from Struts to its own project. Consequently, we deal with
these headaches to make it integrate into Spring. I think I need to talk to
the CV developers to get some of these things factored out once and for all.
Hmmm...sounds like a giant undertaking...

In the mean time, could a zip file containing Spring-CommonsValidator.jar,
validator-rules.xml, an example validation.xml, and an example spring
config.xml be hosted on springframework.org? It is totally stand-alone as
is. I believe all of the xml files are in the sandbox. If not, I can supply
them.

Thoughts, comments?

Thanks,
Daniel


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jürgen höller [werk3AT]
Sent: Friday, June 04, 2004 12:00 PM
To: spr...@li...
Subject: [Springframework-developer] Commons Validator support


Matt, Daniel, Keith,

I've just reviewed the Commons Validator support in the sandbox, and I have
come to the conclusion that it is not ready for prime time yet. This is not
the fault of the integration classes; it's rather the fault of Commons
Validator 1.0.2's scope.

I object to shipping a 31 KB FieldChecks class and a 24 KB
JavascriptValidatorTag class that are copied-and-pasted from Struts. Generic
versions of those should really be part of Commons Validator itself, and I
understand that they might be as of Commons Validator 1.1. If we'd ship
modified copies ourselves, we'd have to maintain them - this is certainly
not worthwhile.

How useful is our Commons Validator integration without FieldChecks and
JavascriptValidatorTag? I guess it would be too bare-bones without them...
So it seems to me that we won't be able to ship proper Commons Validator
integration (i.e. without copying-and-pasting) before Commons Validator 1.1.
Or should we try to build on a current Commons Validator snapshot?

Thoughts? Opinions? Suggestions on how to make the current version available
outside of the standard Spring distribution, without official support? Of
course, we could simply leave it in the sandbox for the time being...

Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Added BLOB/CLOB support to SqlUpdate and StoredProcedure

[<tho...@tr...>]

Juergen,

> Do you see a chance to address the special parameter types issue within the
> 1.0.3 timeframe?

I should be able to do this - might need it for code I'm writing at work as
well.

I have added it as an issue in JIRA.

Thomas

Re: [Springframework-developer] Commons Validator support

[Seth L. <se...@eh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| I object to shipping a 31 KB FieldChecks class and a 24 KB
| JavascriptValidatorTag class that are copied-and-pasted from Struts.
| Generic versions of those should really be part of Commons Validator
| itself, and I understand that they might be as of Commons Validator
| 1.1. If we'd ship modified copies ourselves, we'd have to maintain
| them - this is certainly not worthwhile.

I just looked through their CVS, and didn't see a FieldChecks class.
They are currenly on 1.1 and have a 1.2 waiting in the wings.

| without them... So it seems to me that we won't be able to ship
| proper Commons Validator integration (i.e. without
| copying-and-pasting) before Commons Validator 1.1. Or should we try
| to build on a current Commons Validator snapshot?

No objections to building against a snapshot.  We do it for attributes
anyway. :)


| official support? Of course, we could simply leave it in the sandbox
| for the time being...

I'm fine with that, as long as it's still available.  We used it to make
our migration from struts to spring very easy.  Also, until the
attributes/declarative validation stuff appears, the commons-validator
is all we have for that type of work.

Seth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAwNObKZsFSwtW+wIRAhSYAJ0eW/g4E35QakNH5T5TBWcSNwW/twCfWan3
N9fHdcQahIPIWRQzQMqpcv0=
=tiax
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Added BLOB/CLOB support to SqlUpdate and StoredProcedure

[<jue...@we...>]

Great stuff, Thomas! This takes us one step closer to completing the =
scope of the jdbc.object package.
=20
Now we just need to move the BatchSqlUpdate class over to the main =
source tree, and add support for special parameter types (like Oracle =
arrays) to SqlOperation - then it will be quite hard to find a further =
gap :-)
=20
Do you see a chance to address the special parameter types issue within =
the 1.0.3 timeframe?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Fr 04.06.2004 19:57
An: spr...@li...
Betreff: [Springframework-developer] Added BLOB/CLOB support to =
SqlUpdate and StoredProcedure



OK, I'm done adding support  for BLOB/CLOB to SqlUpdate and
StoredProcedure.  I have commited these changes and you are welcome to
take them for a spin.  If  you notice any problems let me know.  I'll
add some mocked unit tests to our testsuite the next couple of days.=20
All tests I have now are live connection ones.

Here is a short example of usage.

I'm reusing the LobHandler that Juergen added recently.  It works very
well and it supports the following input types for LOBs:

BLOB - byte array or java.io.InputStream
CLOB - String, java.io.InputStream or java.io.Reader

If you are running in an appserver with a connection pool that wraps
your connection, depending on which LobHandler you use, you might have
to set a NativeJdbcExtractor.  For Oracle 9i and Weblogic 8.1 I used the
following setup:

      LobHandler lobHandler =3D new OracleLobHandler();
      NativeJdbcExtractor jdbcExtractor =3D new =
WebLogicNativeJdbcExtractor();
      lobHandler.setNativeJdbcExtractor(jdbcExtractor);

This should of course be set via IoC for a real app.

Now you need to create your SqlUpdate and declare you parameters:

       String sql =3D "insert into docs (doc_id, content) values(?, ?)";
       SqlUpdate su =3D new SqlUpdate(ds, sql);
       su.declareParameter(new SqlParameter("id", Types.INTEGER));
       su.declareParameter(new SqlParameter("lob", Types.BLOB,
lobHandler));
       su.compile();

The LOB parameter is declared with a new constructor that takes the
LobHandler as the third argument.  If you don't specify a LobHandler we
will automatically generate a DefaultLobHandler.

Next we need to create an array with all parameters and call the
update() method to insert each row.  The LOB value must be passed in as
an SqlLobValue object together with the length (unless you use a byte
array or String in which case we can easily figure out the length).=20
SqlLobValue is a new class that holds the actual LOB value plus the
LobCreator that the framework internally populates during the update.

       Object[] inval =3D new Object[2];
       inval[0] =3D new Integer(newId);
       File in =3D new File("some.doc");
       InputStream is =3D new FileInputStream(in);
       inval[1] =3D new SqlLobValue(is, (int) in.length());
       int count =3D su.update(inval);
       is.close();

That is it.  It works the same way for CLOBs and it also works for
parameters passed in to a StoredProcedure.

While making this change I combined the setXxxxx logic for
PreparedStatement and CallableStatement to one static method that I
added to JdbcUtils.  If you notice anything odd due to this refactoring,
please let me know.

Thomas



-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Added BLOB/CLOB support to SqlUpdate and StoredProcedure

[Thomas R. <tho...@tr...>]

OK, I'm done adding support  for BLOB/CLOB to SqlUpdate and 
StoredProcedure.  I have commited these changes and you are welcome to 
take them for a spin.  If  you notice any problems let me know.  I'll 
add some mocked unit tests to our testsuite the next couple of days.  
All tests I have now are live connection ones.

Here is a short example of usage.

I'm reusing the LobHandler that Juergen added recently.  It works very 
well and it supports the following input types for LOBs:

BLOB - byte array or java.io.InputStream
CLOB - String, java.io.InputStream or java.io.Reader

If you are running in an appserver with a connection pool that wraps 
your connection, depending on which LobHandler you use, you might have 
to set a NativeJdbcExtractor.  For Oracle 9i and Weblogic 8.1 I used the 
following setup:

      LobHandler lobHandler = new OracleLobHandler();
      NativeJdbcExtractor jdbcExtractor = new WebLogicNativeJdbcExtractor();
      lobHandler.setNativeJdbcExtractor(jdbcExtractor);

This should of course be set via IoC for a real app.

Now you need to create your SqlUpdate and declare you parameters:

       String sql = "insert into docs (doc_id, content) values(?, ?)";
       SqlUpdate su = new SqlUpdate(ds, sql);
       su.declareParameter(new SqlParameter("id", Types.INTEGER));
       su.declareParameter(new SqlParameter("lob", Types.BLOB, 
lobHandler));
       su.compile();

The LOB parameter is declared with a new constructor that takes the 
LobHandler as the third argument.  If you don't specify a LobHandler we 
will automatically generate a DefaultLobHandler.

Next we need to create an array with all parameters and call the 
update() method to insert each row.  The LOB value must be passed in as 
an SqlLobValue object together with the length (unless you use a byte 
array or String in which case we can easily figure out the length).  
SqlLobValue is a new class that holds the actual LOB value plus the 
LobCreator that the framework internally populates during the update.

       Object[] inval = new Object[2];
       inval[0] = new Integer(newId);
       File in = new File("some.doc");
       InputStream is = new FileInputStream(in);
       inval[1] = new SqlLobValue(is, (int) in.length());
       int count = su.update(inval);
       is.close();

That is it.  It works the same way for CLOBs and it also works for 
parameters passed in to a StoredProcedure.

While making this change I combined the setXxxxx logic for 
PreparedStatement and CallableStatement to one static method that I 
added to JdbcUtils.  If you notice anything odd due to this refactoring, 
please let me know.

Thomas

[Springframework-developer] Commons Validator support

[<jue...@we...>]

Matt, Daniel, Keith,

I've just reviewed the Commons Validator support in the sandbox, and I =
have come to the conclusion that it is not ready for prime time yet. =
This is not the fault of the integration classes; it's rather the fault =
of Commons Validator 1.0.2's scope.

I object to shipping a 31 KB FieldChecks class and a 24 KB =
JavascriptValidatorTag class that are copied-and-pasted from Struts. =
Generic versions of those should really be part of Commons Validator =
itself, and I understand that they might be as of Commons Validator 1.1. =
If we'd ship modified copies ourselves, we'd have to maintain them - =
this is certainly not worthwhile.

How useful is our Commons Validator integration without FieldChecks and =
JavascriptValidatorTag? I guess it would be too bare-bones without =
them... So it seems to me that we won't be able to ship proper Commons =
Validator integration (i.e. without copying-and-pasting) before Commons =
Validator 1.1. Or should we try to build on a current Commons Validator =
snapshot?

Thoughts? Opinions? Suggestions on how to make the current version =
available outside of the standard Spring distribution, without official =
support? Of course, we could simply leave it in the sandbox for the time =
being...

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: [Springframework-developer] Import tag for XML bean definitions

[Kirill M. <ki...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Estes, James D - St. Louis, MO wrote:

| Example:
| You have an Application Context XML file that contains your DAO beans,
| but you want your JUnit tests to run with a different dataSource (dbcp)
| than your actual web application (jndi).  So you have 3 xml files:  the
| main dao xml, a dbcp dataSource xml file, and a jndi dataSource xml
| file.
| With the include approach, my dao file would directly point to the
| implementation I want, and I would have to change it (or use ant to do
| it for me) when I switch between the 2 environments.

~  To be honest, I've imlemented the import just for this situation.
~  But from the other side - I have 2 main Application Context XML files -
~  one for tests and one for production. Each contains dataSource specifics.
~  And each includes "generic" configuraton file which contains beans common
~  for these two environments.

~  So no need to switch et all.

~  Regards,
~  KIR

- --
Kirill Maximov (aka KIR) | http://www.maxkir.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAwJw9E0YZ3264U5QRAhTuAJ4iuNEsTaawQ9/9+A3DDvahQDOV8gCfSQoY
edchfor67HVIWM5RYGoNqQ8=
=320W
-----END PGP SIGNATURE-----

RE: [Springframework-developer] RE: [springframework] Autobuilds

[Darren D. <da...@da...>]

> No, no server binaries in the CVS!

ok, just wasn't sure if you meant that or not :-)


> It would be nice to have some
> automatic retrieval process, but that's not necessary for now. I was
> talking about the versions of the applications servers (stated in the
> build.xml right now). The automated build should reflect the current
> state of the CVS as much as possible (including server versions tested
> against).

Better to take the properties out of build.xml all together in that case
and refer to a 'servers.properties' file (added to CVS) and a
'local-servers.properties' file (in .cvsignore) that can override it if
need be.

Auto retrieval of binaries can easily be added to autobuilds, I just neve=
r
got round to it.  The servers.properties file will have to maintain a URL
that they can be FTP'd from if the local d/l is not up to date.

D.


--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm

RE: [Springframework-developer] Import tag for XML bean definitions

[Tom T. <tom...@pr...>]

> So for my example above, the dao would be in a jar along with a
> dao-index.xml file that pointed to each of the needed files.  And I
> could include them all in my web application context with a config
> location of springindex:com/foo/dao/dao-index.xml.  OR if Spring does
> allow include directives, I would (again keeping the include or
> composition file separate) have a config location of
> classpath:com/foo/dao/dao-index.xml.

I don't think this will work: "classpath:" denotes a resource *location*
while "springindex:" denotes a *type*...

Good point though, to limit the import functionality to a "composed bean
definitions file"-definition.

Tom.

RE: [Springframework-developer] RE: [springframework] Autobuilds

[Rod J. <rod...@in...>]

>No, no server binaries in the CVS! 

+1000

RE: [Springframework-developer] RE: [springframework] Autobuilds

[Alef A. <al...@jt...>]

No, no server binaries in the CVS! It would be nice to have some
automatic retrieval process, but that's not necessary for now. I was
talking about the versions of the applications servers (stated in the
build.xml right now). The automated build should reflect the current
state of the CVS as much as possible (including server versions tested
against).

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Darren Davison
> Sent: Friday, June 04, 2004 2:30 PM
> To: spr...@li...
> Subject: [Springframework-developer] RE: [springframework] Autobuilds
>=20
>=20
>=20
> > Ok,
> >
> > I'd like to propose to keep the latest versions of the application
> > servers used in the automatic build process in the CVS. Once the
> > automated testing is in place I won't ever touch the configuration
> > again, testing always happens against CVS HEAD.
> >
> > Furthermore I'll have to modify some of the build files to change
the
> > flow a bit, but those will be minor changes. I'll let you know when
> > things are in place!
>=20
> Alef,
>=20
> (I've moved this to the main dev list as it's less appropriate on the
> other one)
>=20
> Are you talking about keeping the server binaries in CVS?  This was
> discussed when I embarked upon this before Christmas and the general
> consensus was that we shouldn't do it.  It is a very large overhead
(JBoss
> / Tomcat x 2 / Resin x 2 etc. =3D a lot of MB) for people keeping up =
to
date
> with CVS who don't need to use autobuilds.
>=20
> Regards,
> --
> Darren Davison
> Public Key: http://www.davison.uk.net/pages/key.htm
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

RE: [Springframework-developer] Import tag for XML bean definitions

[Estes, J. D - S. L. M. <jam...@us...>]

I've been thinking about this quite a bit lately.  My first instinct
when using Spring was that I should be able to do this...but as I
learned more about Spring and dependency injection, I felt it was not
appropriate to be able to do includes in a bean file.  What it amounts
to is a dependency that you are allowing the bean file itself to seek
out and resolve...instead of allowing the caller/container/environment
do this for you by loading all the appropriate configs together (or
through a parent hierarchy).

Example: =20
You have an Application Context XML file that contains your DAO beans,
but you want your JUnit tests to run with a different dataSource (dbcp)
than your actual web application (jndi).  So you have 3 xml files:  the
main dao xml, a dbcp dataSource xml file, and a jndi dataSource xml
file. =20
With the include approach, my dao file would directly point to the
implementation I want, and I would have to change it (or use ant to do
it for me) when I switch between the 2 environments. =20
If I use the injection approach, my JUnit would setup a hierarchy with
the dao xml and the dbcp dataSource xml by directly creating an instance
of the ClassPathXmlApplicationContext with the 2 files as the
configLocations.  The Web Application would load the dao xml and the
jndi dataSource xml via the configLocation (using classpath: pathname
for the dao and normal file path for the jndi xml file).  No complex
changes are required for it to work in both instances.  The dependencies
are resolved appropriately by the application in use.

It would be nice (for clarity/documentation purposes) to be able to
define abstract beans in the file.  Essentially a placeholder saying "I
know this bean is not in this file, but it is assumed that it will be
provided by another xml file in the same or parent container".  And then
possibly have a validation error when a container (once composed) does
not have an 'implementation' for the bean.  This essentially already
happens by just referencing the bean, but again, the abstract bean would
just be for clarity.

I can, however see the need for more easily composing and packaging a
set of bean files.  If my dao project internally used several xml config
files, I would not want to force the main project to know that much
about the internals of the dao project (e.g. "To use this dao, pull the
jar in and then create your spring application context with the
following xml files present:  classpath:com/foo/dao/DaoCore-context.xml,
classpath:com/foo/dao/DaoFinance-context.xml,
classpath:com/foo/dao/DaoUsers-context.xml,
Classpath:com/foo/dao/DaoHibernate-context.xml). =20

For this kind of purpose, I think the include would be nice, but I would
want to keep includes out of my actual bean files and have a special
kind of composite bean file that has includes in it (or I would just
keep them separate myself in practice, but I think it keeps things more
clean this way).  It would also be possible to have a springindex: type
of path that would point to a special kind of bean file (on the
classpath or in the file system) with a list/include of the bean config
files that should be loaded from the classpath.=20
So for my example above, the dao would be in a jar along with a
dao-index.xml file that pointed to each of the needed files.  And I
could include them all in my web application context with a config
location of springindex:com/foo/dao/dao-index.xml.  OR if Spring does
allow include directives, I would (again keeping the include or
composition file separate) have a config location of
classpath:com/foo/dao/dao-index.xml.


Just my thoughts.

James

[Springframework-developer] RE: [springframework] Autobuilds

[Darren D. <da...@da...>]

> Ok,
>
> I'd like to propose to keep the latest versions of the application
> servers used in the automatic build process in the CVS. Once the
> automated testing is in place I won't ever touch the configuration
> again, testing always happens against CVS HEAD.
>
> Furthermore I'll have to modify some of the build files to change the
> flow a bit, but those will be minor changes. I'll let you know when
> things are in place!

Alef,

(I've moved this to the main dev list as it's less appropriate on the
other one)

Are you talking about keeping the server binaries in CVS?  This was
discussed when I embarked upon this before Christmas and the general
consensus was that we shouldn't do it.  It is a very large overhead (JBos=
s
/ Tomcat x 2 / Resin x 2 etc. =3D a lot of MB) for people keeping up to d=
ate
with CVS who don't need to use autobuilds.

Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm