springframework-developer — Spring Framework developers list

[Springframework-developer] LocaleContext

[Juergen H. <ju...@in...>]

I've introduced a LocaleContext abstraction and LocaleContextHolder class in
"org.springframework.context.i18n". DispatcherServlet automatically
populates LocaleContextHolder's ThreadLocal (delegating to LocaleResolver),
and MessageSourceAccessor automatically uses the current Locale from there
(falling back to the system default Locale).

The LocaleContext is essentially analogous to Acegi's SecurityContext. I
guess it's better to keep such contexts separate, though, else it'll be
unclear who choses the Context implementation to use etc. To express this,
it might make sense to remove the generic Context interface from Acegi, only
keeping a SecurityContext, held in a SecurityContextHolder.

Thoughts?

Juergen

[Springframework-developer] Null vs. void return value for MethodInvoker

[Colin S. <col...@ex...>]

Juerge, care to comment on this issue?
   http://opensource.atlassian.com/projects/spring/browse/SPR-854

[Springframework-developer] spring build.239 Build Fixed

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

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050408001548Lbuild.239

Re: [Springframework-developer] spring Build Failed

[Rob H. <ro...@ca...>]

I'll do it now.

Rob

Alef Arendsen wrote:

>Rob,
>
>Any chance you can change the ports you're doing the tests with to some
>exotic ones? We're running some stuff on the server here, which seem to
>conflict.
>
>If you give me some pointers I can do it as well if you want.
>
>Rgds,
>Alef
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf
>Of Alef Arendsen
>Sent: Thursday, April 07, 2005 12:30 AM
>To: spr...@li...
>Subject: [Springframework-developer] spring Build Failed
>Importance: High
>
>View results here ->
>http://opensource.jteam.nl/build/buildresults/spring?log=log200504070016
>03
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

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

1112894650
FAILED
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,017 sec

    [junit] Testcase: testNaming took 0 sec
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,242 sec
    [junit] Testsuite: org.springframework.jmx.support.ConnectorServerFactoryBeanTests
    [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,242 sec

    [junit] Testcase: testStartupWithLocatedServer took 0,097 sec
    [junit] Testcase: testStartupWithSuppliedServer took 0,052 sec
    [junit] Testcase: testRegisterWithMBeanServer took 0,044 sec
    [junit] Testcase: testNoRegisterWithMBeanServer took 0,036 sec
    [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 0,093 sec
    [junit] Testsuite: org.springframework.jmx.support.JmxUtilsTests
    [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 0,093 sec

    [junit] Testcase: testIsMBeanWithDynamicMBean took 0 sec
    [junit] Testcase: testIsMBeanWithStandardMBeanWrapper took 0,015 sec
    [junit] Testcase: testIsMBeanWithStandardMBeanInherited took 0,005 sec
    [junit] Testcase: testNotAnMBean took 0,001 sec
    [junit] Testcase: testSimpleMBean took 0,009 sec
    [junit] Testcase: testSimpleMBeanThroughInheritance took 0,009 sec
    [junit] Testcase: testGetAttributeNameWithStrictCasing took 0,036 sec
    [junit] 	FAILED
    [junit] Incorrect casing on attribute name expected:<Name> but was:<Class>
    [junit] junit.framework.ComparisonFailure: Incorrect casing on attribute name expected:<Name> but was:<Class>
    [junit] 	at org.springframework.jmx.support.JmxUtilsTests.testGetAttributeNameWithStrictCasing(JmxUtilsTests.java:78)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] Re: Spring Framework 1.2 RC1 released

[Matt S. <sga...@us...>]

I've been using 1.2 RC1 since its release and it's working great for me! 
  I especially appreciate the updates to JdbcTemplate and spring-beans.dtd.

Matt

Juergen Hoeller wrote:
> Dear Spring community,
> 
> It's Spring time :-)
> 
> I'm pleased to announce that Spring 1.2 RC1 has just been released. This
> release introduces a number of major new features:
> 
> * finer-grained distribution jar files, alongside the full spring.jar
> * AOP Alliance interfaces are now contained in spring-aop.jar and spring.jar
> 
> * XML bean definition improvements ("ref" and "value" shortcut attributes
> etc)
> * improved AOP TargetSourceCreator mechanism (supporting
> LazyInitTargetSource too)
> 
> * transaction annotation support for JDK 1.5+ (annotation called
> "Transactional")
> * improved WebLogicJtaTransactionManager (transaction names, isolation
> levels)
> 
> * SqlRowSet support for JDBC (in conjunction with JdbcTemplate's
> "queryForRowSet")
> * Hibernate3 support (in orm.hibernate3; Hibernate 2.1 support is still
> available)
> 
> * JMX support for export of Spring beans as managed resources and for MBean
> access
> * Commons Attributes and JDK 1.5+ annotations for JMX MBean export
> 
> This release also contains many minor enhancements, for example:
> 
> * factored out BindingErrorProcessor strategy for ServletRequestDataBinder
> * improved ParameterMethodNameResolver for Web MVC MultiActionController
> 
> For a detailed list of enhancements and bug fixes, see the changelog.
> 
> This release candidate is already considered stable and recommended for
> development use. We expect Spring 1.2 final to be released in late April.
> 
> Watch out for the Spring Web Flow preview release to follow later this week
> (for use with Spring 1.2)! Web Flow will also become part of the nightly
> build at that time.
> 
> Cheers,
> 
> Juergen
> 
> -----
> Juergen Hoeller
> Interface21 - Spring Services from the Source
> http://www.springframework.com
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [Springframework-developer] webflow: improving FormAction

[Erwin V. <erw...@er...>]

I'm sure there are valid use-cases which are easily supported with a 
subclass like I showed, or with method injection as Keith mentioned. 
However, I don't think it is typically a good idea to have Spring manage 
'domain objects', and a form object is typically a domain object or a simple 
DTO. I would say the common case is that the Spring application context 
manages 'service objects': services, DAOs, controllers, ...

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Thursday, April 07, 2005 5:09 PM
Subject: Re: [Springframework-developer] webflow: improving FormAction


> In case of a normalized domain model wizards will typically include
> form fields that span beyond the single class currently created by
> FormAction. Creating the form object in Spring offers the advantage
> that related entities could be set on the form object - as required.
> This would for example avoid that getPerson() would return null. It's
> just more flexible.
>
>>
>> Mmm, interesting idea, but I'm not sure we should add this (e.g. why 
>> doesn't
>> the
>> BaseCommandController has this feature?). Anyway, it would be trivial to 
>> do
>> this
>> in a FormAction subclass:
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

RE: [Springframework-developer] spring Build Failed

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

Rob,

Any chance you can change the ports you're doing the tests with to some
exotic ones? We're running some stuff on the server here, which seem to
conflict.

If you give me some pointers I can do it as well if you want.

Rgds,
Alef


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Alef Arendsen
Sent: Thursday, April 07, 2005 12:30 AM
To: spr...@li...
Subject: [Springframework-developer] spring Build Failed
Importance: High

View results here ->
http://opensource.jteam.nl/build/buildresults/spring?log=3Dlog20050407001=
6
03


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] webflow: improving FormAction

[Steven D. <ste...@gm...>]

In case of a normalized domain model wizards will typically include
form fields that span beyond the single class currently created by
FormAction. Creating the form object in Spring offers the advantage
that related entities could be set on the form object - as required.
This would for example avoid that getPerson() would return null. It's
just more flexible.

> 
> Mmm, interesting idea, but I'm not sure we should add this (e.g. why doesn't
> the
> BaseCommandController has this feature?). Anyway, it would be trivial to do
> this
> in a FormAction subclass:
>

Re: [Springframework-developer] webflow: improving FormAction

[Erwin V. <erw...@er...>]

> Next to the "formObjectClass" property I think it would the useful to
> add a "formObjectBean" string property which could be any bean ref id
> in the bean factory (must be prototypes). This way one could control
> the creation of the beans through Spring. You could for example
> already fill in default values which could facilitate the re-use of
> domain classes as form objects.

Mmm, interesting idea, but I'm not sure we should add this (e.g. why doesn't 
the
BaseCommandController has this feature?). Anyway, it would be trivial to do 
this
in a FormAction subclass:

public class MyFormAction extends FormAction {
    private MyBean myBean;
    public void setMyBean(MyBean myBean) {
        this.myBean = myBean;
    }
    protected Object loadRequiredFormObject(RequestContext context) throws 
FormObjectRetrievalFailureException, IllegalStateException {
        return myBean;
    }
}

> Another remark regarding usage of domain classes as form objects is
> about jumping over properties in the form object. Say my form object
> is a Manager instance which has a "person" property. Person has a
> "name" property. Is it possible to add a "person.name" HTTP parameter
> that would set the "name" property on the "person" property?

This is possible with the Spring DataBinder. Ofcourse the "getPerson()" 
method
on the Manager class should not return null in that case.

Erwin 

RE: [Springframework-developer] Re: webflow: improving FormAction

[Keith D. <ke...@in...>]

Yes, that's fully supported.

If you'd like to pull a 'formObject' from the context, you should be able to
override the loadFormObject or createFormObject method - you should be able
to do that dynamically using method injection.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Steven Devijver
Sent: Thursday, April 07, 2005 10:31 AM
To: spr...@li...
Subject: [Springframework-developer] Re: webflow: improving FormAction

Apparently "person.name" is supported, that is Spring supports the
dotted notation when setting properties. As FormAction re-uses
org.springframework.validation.DataBinder I suppose dotted HTTP
parameters are supported.

On Apr 7, 2005 3:59 PM, Steven Devijver <ste...@gm...> wrote:
> Guys,
> 
> Next to the "formObjectClass" property I think it would the useful to
> add a "formObjectBean" string property which could be any bean ref id
> in the bean factory (must be prototypes). This way one could control
> the creation of the beans through Spring. You could for example
> already fill in default values which could facilitate the re-use of
> domain classes as form objects.
> 
> Another remark regarding usage of domain classes as form objects is
> about jumping over properties in the form object. Say my form object
> is a Manager instance which has a "person" property. Person has a
> "name" property. Is it possible to add a "person.name" HTTP parameter
> that would set the "name" property on the "person" property?
> 
> regards
> 
> Steven
> 
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] webflow: improving FormAction

[David H. <dh...@ob...>]

>=20-----Original=20Message-----
>=20Another=20remark=20regarding=20usage=20of=20domain=20classes=20as=20fo=
rm=20objects=20is
>=20about=20jumping=20over=20properties=20in=20the=20form=20object.=20Say=20=
my=20form=20object
>=20is=20a=20Manager=20instance=20which=20has=20a=20"person"=20property.=20=
Person=20has=20a
>=20"name"=20property.=20Is=20it=20possible=20to=20add=20a=20"person.name"=
=20HTTP=20parameter
>=20that=20would=20set=20the=20"name"=20property=20on=20the=20"person"=20p=
roperty?
>=20

Unless=20I'm=20misunderstanding=20your=20question,=20the=20current=20bindi=
ng
infrastructure=20already=20does=20this.

-=20Dave


>=20regards
>=20
>=20Steven
>=20
>=20--
>=20"If=20you=20want=20to=20be=20a=20different=20fish,=20you=20gotta=20jum=
p=20out=20of=20the
school."
>=20--=20Captain=20Beefheart
>=20
>=20
>=20-------------------------------------------------------
>=20SF=20email=20is=20sponsored=20by=20-=20The=20IT=20Product=20Guide
>=20Read=20honest=20&=20candid=20reviews=20on=20hundreds=20of=20IT=20Produ=
cts=20from=20real
users.
>=20Discover=20which=20products=20truly=20live=20up=20to=20the=20hype.=20S=
tart=20reading=20now.
>=20http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>=20_______________________________________________
>=20Springframework-developer=20mailing=20list
>=20S...@li...
>=20https://lists.sourceforge.net/lists/listinfo/springframework-developer=

>=20
>
________________________________________________________________________
>=20This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star=
.=20The
>=20service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20=
on=20a=20proactive
>=20anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20=
globe,=20visit:
>=20http://www.star.net.uk
>
________________________________________________________________________

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________

[Springframework-developer] Re: webflow: improving FormAction

[Steven D. <ste...@gm...>]

Apparently "person.name" is supported, that is Spring supports the
dotted notation when setting properties. As FormAction re-uses
org.springframework.validation.DataBinder I suppose dotted HTTP
parameters are supported.

On Apr 7, 2005 3:59 PM, Steven Devijver <ste...@gm...> wrote:
> Guys,
> 
> Next to the "formObjectClass" property I think it would the useful to
> add a "formObjectBean" string property which could be any bean ref id
> in the bean factory (must be prototypes). This way one could control
> the creation of the beans through Spring. You could for example
> already fill in default values which could facilitate the re-use of
> domain classes as form objects.
> 
> Another remark regarding usage of domain classes as form objects is
> about jumping over properties in the form object. Say my form object
> is a Manager instance which has a "person" property. Person has a
> "name" property. Is it possible to add a "person.name" HTTP parameter
> that would set the "name" property on the "person" property?
> 
> regards
> 
> Steven
> 
> --
> "If you want to be a different fish, you gotta jump out of the school."
> -- Captain Beefheart
> 


-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

[Springframework-developer] webflow: improving FormAction

[Steven D. <ste...@gm...>]

Guys,

Next to the "formObjectClass" property I think it would the useful to
add a "formObjectBean" string property which could be any bean ref id
in the bean factory (must be prototypes). This way one could control
the creation of the beans through Spring. You could for example
already fill in default values which could facilitate the re-use of
domain classes as form objects.

Another remark regarding usage of domain classes as form objects is
about jumping over properties in the form object. Say my form object
is a Manager instance which has a "person" property. Person has a
"name" property. Is it possible to add a "person.name" HTTP parameter
that would set the "name" property on the "person" property?

regards

Steven

-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] AbstractTransactionalSpringContextTests

[Colin S. <col...@ex...>]

As I read Keith's requirements, that's not quite what he was looking for 
in terms of the optional use of transactions. Most of the time the same 
context will be used for tests with and without transactions. So because 
the transactionManager property is there in the base class, there will 
always be a transactionManager even for tests that don't want it.

What would probably work is if there was a boolean switch (default on) 
to use transactions or not use them. However I still see some issues. If 
AbstractFlowExecutionTests does extend 
AbstractTransactionalSpringContextTests, that would mean that if 
somebody doesn't ever want transactions and has no transaction manager 
in the context, they must always turn off dependency checking. This 
might be ok, but is sort of suboptimal.


Rod Johnson wrote:

> Keith
>
> I've added a dependencyCheck property in 
> AbstractDependencyInjectionSpringContextTests.
>
> I've modified AbstractTransactionalSpringContextTests to not use 
> transactions if no PlatformTransactionManager is available. This will 
> only work if dependency checking is off.
>
> Please test this out and let me know if it fits your needs. I don't 
> have time today to do full testing myself.
>
> If it's fine, let me know and I'll complete the documentation for the 
> new features and improve the Javadoc overall.
>
> Rgds
> Rod
>
>>
>> Ideally I'd like to be able to test the Phonebook sample flows, or 
>> any other
>> flows, by extending AbstractTransactionalSpringContextTests, without 
>> being
>> *required* to set a transaction manager and run in the context of a 
>> TX.  In
>> other words, I'd like it to be configurable.  If it's not made 
>> configurable,
>> I'm only left with two options:
>> 1. Scale up Phonebook (or any other flow) to work with a 
>> transactional data
>> source
>> 2. Have a duplicate AbstractFlowExecutionTests hierarchy that just 
>> extends
>> from DependencyInjectedContextTests
>>
>> Neither of these are that great IMO.  The former means I can really only
>> integration test flows that need TX's (yes that will probably be the
>> majority, but...) or I have to mock out the TX Manager.  The latter 
>> means I
>> duplicate flow integration test code, to extend from two different base
>> classes.
>>
>> Keith
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Rod Johnson
>> Sent: Wednesday, April 06, 2005 6:55 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer]
>> AbstractTransactionalSpringContextTests
>>
>> Keith
>>
>> I will try to make any required enhancements today.
>>
>>
>>> - the ability to DISABLE dependency checking by object for the 
>>> autowired test - sometimes defaults really do make sense, why always 
>>> require a set method to be called for each public setter?
>>
>>
>> I've added a dependencyCheck property which you can call in a 
>> constructor. I've preserved the default dependency checking, which I 
>> think is useful.
>>
>>
>>> - the ability to turn off/on transaction management - right now 
>>> AbstractFlowExecutionTests is runnable only in the context of a 
>>> database transaction.  While this is great and all, if I want to 
>>> integration test flows outside of any transactional context, I'm 
>>> screwed.  I can't exactly subclass DependencyInjectedContextTests, 
>>> as I still WANT THE OPTION of being able to test flows in a 
>>> transaction context - for the flows that demand it.  But the current 
>>> structure doesn't give me that choice.
>>
>>
>> I don't quite understand what you want here. Can you please be more 
>> specific? How would you drive this option?
>>
>> Rgds
>> Rod
>

Re: [Springframework-developer] AbstractTransactionalSpringContextTests

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

Keith

I've added a dependencyCheck property in 
AbstractDependencyInjectionSpringContextTests.

I've modified AbstractTransactionalSpringContextTests to not use 
transactions if no PlatformTransactionManager is available. This will 
only work if dependency checking is off.

Please test this out and let me know if it fits your needs. I don't have 
time today to do full testing myself.

If it's fine, let me know and I'll complete the documentation for the 
new features and improve the Javadoc overall.

Rgds
Rod
> 
> Ideally I'd like to be able to test the Phonebook sample flows, or any other
> flows, by extending AbstractTransactionalSpringContextTests, without being
> *required* to set a transaction manager and run in the context of a TX.  In
> other words, I'd like it to be configurable.  If it's not made configurable,
> I'm only left with two options:
> 1. Scale up Phonebook (or any other flow) to work with a transactional data
> source
> 2. Have a duplicate AbstractFlowExecutionTests hierarchy that just extends
> from DependencyInjectedContextTests
> 
> Neither of these are that great IMO.  The former means I can really only
> integration test flows that need TX's (yes that will probably be the
> majority, but...) or I have to mock out the TX Manager.  The latter means I
> duplicate flow integration test code, to extend from two different base
> classes.
> 
> Keith
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf Of
> Rod Johnson
> Sent: Wednesday, April 06, 2005 6:55 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer]
> AbstractTransactionalSpringContextTests
> 
> Keith
> 
> I will try to make any required enhancements today.
> 
> 
>>- the ability to DISABLE dependency checking by object for the autowired 
>>test - sometimes defaults really do make sense, why always require a set 
>>method to be called for each public setter?
> 
> I've added a dependencyCheck property which you can call in a 
> constructor. I've preserved the default dependency checking, which I 
> think is useful.
> 
> 
>>- the ability to turn off/on transaction management - right now 
>>AbstractFlowExecutionTests is runnable only in the context of a database 
>>transaction.  While this is great and all, if I want to integration test 
>>flows outside of any transactional context, I'm screwed.  I can't 
>>exactly subclass DependencyInjectedContextTests, as I still WANT THE 
>>OPTION of being able to test flows in a transaction context - for the 
>>flows that demand it.  But the current structure doesn't give me that 
>>choice.
> 
> I don't quite understand what you want here. Can you please be more 
> specific? How would you drive this option?
> 
> Rgds
> Rod
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

RE: [Springframework-developer] Spring 1.2 and JMX 1.0

[Rob H. <rob...@in...>]

Please do. I'm just downloading WAS 5.0 now for my testing session =
tomorrow.

Rob

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Thierry TEMPLIER
Sent: 07 April 2005 12:34
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 and JMX 1.0

Rob,
I use to work with Websphere 5.*. Do you want that I
make some tests about the compatibility of Spring JMX
on this application server?
Thierry

> I'm spending some time before Monday looking at
> compatbility with=20
> various app servers to make sure everything works
> okay, but as Juergen=20
> says JMX 1.0 works for export just not proxy and
> JSR-160 (which requires=20
> 1.2 itself).
>=20
> Rob
>=20
> Juergen Hoeller wrote:
>=20
> >Actually, Spring's JMX support is already built to
> support JMX 1.0 wherever
> >possible. It should only require JMX 1.2 for
> proxy-based JMX MBean access
> >(the org.springframework.jmx.access package).
> Everything else should work
> >nicely on JMX 1.0 too, in particular exposure of
> Spring beans as MBeans.
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From:
>
spr...@li...
>
>[mailto:spr...@li...]On
> Behalf Of
> >Gonzales, Fabian
> >Sent: Tuesday, April 05, 2005 11:20 PM
> >To: spr...@li...
> >Subject: [Springframework-developer] Spring 1.2 and
> JMX 1.0
> >
> >
> >I am working on adding JMX support to our software,
> and would like to use
> >the JMX support in the 1.2 release of the Spring
> Framework. However, there
> >is a requirement to use WebLogic 8.1, which only
> supports JMX 1.0. From what
> >I understand Spring 1.2 only supports JMX 1.2. Are
> there any plans to
> >support JMX 1.0 in the future? If yes, what does
> the timeline look like?
> >
> >If I decide to add JMX 1.0 support myself, how
> involved would it be, and
> >what would be the best way to add JMX 1.0 support
> while ensuring maximum
> >compatibility with future Spring releases?
> >
> >- Fabian
> >
> >
> >
>
>-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT
> Products from real users.
> >Discover which products truly live up to the hype.
> Start reading now.
>
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> > =20
> >
>=20
>=20
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20

Take a look at my blog:
http://templth.blogspot.com/


=09

=09
	=09
__________________________________________________________________
D=E9couvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour =
vos
mails !=20
Cr=E9ez votre Yahoo! Mail sur http://fr.mail.yahoo.com/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 and JMX 1.0

[Thierry T. <te...@ya...>]

Rob,
I use to work with Websphere 5.*. Do you want that I
make some tests about the compatibility of Spring JMX
on this application server?
Thierry

> I'm spending some time before Monday looking at
> compatbility with 
> various app servers to make sure everything works
> okay, but as Juergen 
> says JMX 1.0 works for export just not proxy and
> JSR-160 (which requires 
> 1.2 itself).
> 
> Rob
> 
> Juergen Hoeller wrote:
> 
> >Actually, Spring's JMX support is already built to
> support JMX 1.0 wherever
> >possible. It should only require JMX 1.2 for
> proxy-based JMX MBean access
> >(the org.springframework.jmx.access package).
> Everything else should work
> >nicely on JMX 1.0 too, in particular exposure of
> Spring beans as MBeans.
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From:
>
spr...@li...
>
>[mailto:spr...@li...]On
> Behalf Of
> >Gonzales, Fabian
> >Sent: Tuesday, April 05, 2005 11:20 PM
> >To: spr...@li...
> >Subject: [Springframework-developer] Spring 1.2 and
> JMX 1.0
> >
> >
> >I am working on adding JMX support to our software,
> and would like to use
> >the JMX support in the 1.2 release of the Spring
> Framework. However, there
> >is a requirement to use WebLogic 8.1, which only
> supports JMX 1.0. From what
> >I understand Spring 1.2 only supports JMX 1.2. Are
> there any plans to
> >support JMX 1.0 in the future? If yes, what does
> the timeline look like?
> >
> >If I decide to add JMX 1.0 support myself, how
> involved would it be, and
> >what would be the best way to add JMX 1.0 support
> while ensuring maximum
> >compatibility with future Spring releases?
> >
> >- Fabian
> >
> >
> >
>
>-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT
> Products from real users.
> >Discover which products truly live up to the hype.
> Start reading now.
>
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
>
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >  
> >
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  

Take a look at my blog:
http://templth.blogspot.com/


	

	
		
__________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: [Springframework-developer] Spring 1.2 and JMX 1.0

[Rob H. <ro...@ca...>]

I'm spending some time before Monday looking at compatbility with 
various app servers to make sure everything works okay, but as Juergen 
says JMX 1.0 works for export just not proxy and JSR-160 (which requires 
1.2 itself).

Rob

Juergen Hoeller wrote:

>Actually, Spring's JMX support is already built to support JMX 1.0 wherever
>possible. It should only require JMX 1.2 for proxy-based JMX MBean access
>(the org.springframework.jmx.access package). Everything else should work
>nicely on JMX 1.0 too, in particular exposure of Spring beans as MBeans.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf Of
>Gonzales, Fabian
>Sent: Tuesday, April 05, 2005 11:20 PM
>To: spr...@li...
>Subject: [Springframework-developer] Spring 1.2 and JMX 1.0
>
>
>I am working on adding JMX support to our software, and would like to use
>the JMX support in the 1.2 release of the Spring Framework. However, there
>is a requirement to use WebLogic 8.1, which only supports JMX 1.0. From what
>I understand Spring 1.2 only supports JMX 1.2. Are there any plans to
>support JMX 1.0 in the future? If yes, what does the timeline look like?
>
>If I decide to add JMX 1.0 support myself, how involved would it be, and
>what would be the best way to add JMX 1.0 support while ensuring maximum
>compatibility with future Spring releases?
>
>- Fabian
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

[Springframework-developer] spring Build Failed

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

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050407001603

Re: [Springframework-developer] integrating custom XML spring dialects into the standard Spring XML config file

[<jas...@ma...>]

On 6 Apr 2005, at 17:11, Rod Johnson wrote:
> James
>
> We have talked about this and I even gave an example of possible 
> mechanisms at TSSJS last month.

Ah great - its not just me then :)

Got your TSSJS slides handy anywhere?

> I think it's important. We need to get 1.2 out the door now, but this 
> is one of the highest priority features for 1.3 IMO.

Totally - just wanted to float the idea to get folks pondering about 
it. Go 1.2!

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] integrating custom XML spring dialects into the standard Spring XML config file

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

James

We have talked about this and I even gave an example of possible 
mechanisms at TSSJS last month.

I think it's important. We need to get 1.2 out the door now, but this is 
one of the highest priority features for 1.3 IMO.

We should probably schedule a full discussion of this after all 1.2 
issues are resolved. Good input here.

Rgds
Rod
jas...@ma... wrote:
> On the ActiveMQ project we use Spring as our configuration mechanism to 
> configure message brokers, their wire formats, transport connectors, 
> persistence configurations etc. It works a treat. What we did to make 
> things a little easier for end users (who faced with reams of beans with 
> generic properties, can find configuration hard) - we made a custom 
> Spring XML language, with our own schema, which extends the normal 
> Spring XML language but constrains things a little - making it easier 
> for folks to see how to configure things and providing better IDE-editor 
> smart completion & better validation etc.
> 
> e.g. here's the DTD...
> 
> http://activemq.org/dtd/activemq.dtd
> 
> (as you can see its based on a cut and paste of the Spring DTD to extend 
> it; as spring's based on DTDs)
> 
> e.g.
> 
> <!DOCTYPE beans PUBLIC  "-//ACTIVEMQ//DTD//EN" 
> "http://activemq.org/dtd/activemq.dtd">
> <beans>
>   <broker>
>     <connector>
>       <tcpServerTransport uri="tcp://localhost:61616" backlog="1000" 
> useAsyncSend="true" maxOutstandingMessages="50"/>
>     </connector>
> 
>     <persistence>
>       <!-- you can point this to a different datasource -->
>       <jdbcPersistence dataSourceRef="derby-ds"/>
> 
>     </persistence>
>   </broker>
> <beans>
> 
> 
> So first step; it'd be good if Spring used an XML Schema so we can just 
> extend it :)
> 
> 
> Now all we do is provide our own BeanFactory implementation which is 
> like a regular XmlBeanFactory but we transform the XML from our extended 
> syntax into normal Spring, then let Spring do all the hard work.
> 
> 
> However here's a bigger thought. What if various different component 
> authors wrote their own extended Spring XML languages ('XML marcros' if 
> you like) for different subsystems. XML is all about being human/tool 
> editable and new custom languages make it easier to edit & add better 
> constraints. So the idea of new sub-languages is a good one. (e.g. 
> Geronimo's custom XML could be based on Spring too; I'm sure other 
> libraries/frameworks could add their own custom XML language - e.g. 
> Drools or Hibernate specific stuff or webflow stuff, AOP stuff etc).
> 
> What would really rock is if we could have a generic mechanism for 
> registering XML languages at different namespaces - then freely mixing 
> and matching these different XML configuration languages inside *any* 
> standard Spring XML config file using the normal Spring bean factory 
> implementations.
> 
> e.g. imagine the <broker> element above being the nice, brief way to 
> configure an ActiveMQ broker above. Sure we could do it more verbosely 
> using <bean> and <property> tags; but the ActiveMQ language is simpler & 
> easier to type/validate. But it'd be nice to mix and match this in any 
> XML config in any spring use case.
> 
> e.g.
> 
> <beans>
>    <!--- lets use ActiveMQ's custom XML along with some made up Drools 
> XML too -->
>   <language namespace="http://activemq.org/schema/3.0" 
> class="org.activemq.spring.XmlDialectImpl"/>
>   <language namespace="http://drools.org/rules" class="org. 
> drools.SpringXMLThingy"/>
> 
>   <broker xmlns="http://http://activemq.org/schema/3.0" 
> xmlns:drools="http://drools.org/rules">
>     <connector>
>     <!-- lets add a drools rule base -->
>     <drools:rulebase>
>         <drools:rule>
>         <drools:condition>x > 10</drools:condition>
>         <drools:parameter name="foo">
>            <!-- back to regular Spring again here -->
>             <ref>cheese</ref>
>         </drools:paramater>
>         </drools:rule>
>     </drools:rulebase>
>     </connector>
> </broker>
> 
> <!-- regular Spring again -->
> <bean id="cheese" class="com.acme.Foo">
> </bean>
>     
> 
> To give a concrete real use case for this; when using Spring to 
> configure ActiveMQ's JCA container for Message Driven POJOs (which could 
> use its own simplified XML language too), we often wanna deploy an 
> embedded ActiveMQ message broker inside the JCA container. Right now 
> rather than including a little XML fragment as above; we have to split 
> things into separate files.
> 
> Thinking generically; it'd be nice for folks to be able to register 
> different XML 'short hand' libraries with Spring, using standard spring 
> (rather than custom bean factories) to let all this kinda stuff 
> integrate together cleanly.
> 
> In principle, registering 'dialect handlers' with namespaces in the 
> standard Spring XML configuration file reader is fairly trivial. The 
> harder part is how to implement the transformation of some arbitrary XML 
> element (say drools:rulebase) to regular Spring configuration stuff (say 
> <bean class="org.drools.DefaultRuleBaseImpl">...</bean>). Right now in 
> ActiveMQ we ended up using XSLT as the W3C DOM API is such a PITA to 
> work with and we didn't wanna add a new dependency; but maybe we could 
> come up with a pure Spring based 'XML macro' mechanism we could all 
> integrate with?
> 
> I'm wondering have others thought along these kinda lines - or is it 
> just us :)
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

[Springframework-developer] integrating custom XML spring dialects into the standard Spring XML config file

[<jas...@ma...>]

On the ActiveMQ project we use Spring as our configuration mechanism to 
configure message brokers, their wire formats, transport connectors, 
persistence configurations etc. It works a treat. What we did to make 
things a little easier for end users (who faced with reams of beans 
with generic properties, can find configuration hard) - we made a 
custom Spring XML language, with our own schema, which extends the 
normal Spring XML language but constrains things a little - making it 
easier for folks to see how to configure things and providing better 
IDE-editor smart completion & better validation etc.

e.g. here's the DTD...

http://activemq.org/dtd/activemq.dtd

(as you can see its based on a cut and paste of the Spring DTD to 
extend it; as spring's based on DTDs)

e.g.

<!DOCTYPE beans PUBLIC  "-//ACTIVEMQ//DTD//EN" 
"http://activemq.org/dtd/activemq.dtd">
<beans>
   <broker>
     <connector>
       <tcpServerTransport uri="tcp://localhost:61616" backlog="1000" 
useAsyncSend="true" maxOutstandingMessages="50"/>
     </connector>

     <persistence>
       <!-- you can point this to a different datasource -->
       <jdbcPersistence dataSourceRef="derby-ds"/>

     </persistence>
   </broker>
<beans>


So first step; it'd be good if Spring used an XML Schema so we can just 
extend it :)


Now all we do is provide our own BeanFactory implementation which is 
like a regular XmlBeanFactory but we transform the XML from our 
extended syntax into normal Spring, then let Spring do all the hard 
work.


However here's a bigger thought. What if various different component 
authors wrote their own extended Spring XML languages ('XML marcros' if 
you like) for different subsystems. XML is all about being human/tool 
editable and new custom languages make it easier to edit & add better 
constraints. So the idea of new sub-languages is a good one. (e.g. 
Geronimo's custom XML could be based on Spring too; I'm sure other 
libraries/frameworks could add their own custom XML language - e.g. 
Drools or Hibernate specific stuff or webflow stuff, AOP stuff etc).

What would really rock is if we could have a generic mechanism for 
registering XML languages at different namespaces - then freely mixing 
and matching these different XML configuration languages inside *any* 
standard Spring XML config file using the normal Spring bean factory 
implementations.

e.g. imagine the <broker> element above being the nice, brief way to 
configure an ActiveMQ broker above. Sure we could do it more verbosely 
using <bean> and <property> tags; but the ActiveMQ language is simpler 
& easier to type/validate. But it'd be nice to mix and match this in 
any XML config in any spring use case.

e.g.

<beans>
    <!--- lets use ActiveMQ's custom XML along with some made up Drools 
XML too -->
   <language namespace="http://activemq.org/schema/3.0" 
class="org.activemq.spring.XmlDialectImpl"/>
   <language namespace="http://drools.org/rules" class="org. 
drools.SpringXMLThingy"/>

   <broker xmlns="http://http://activemq.org/schema/3.0" 
xmlns:drools="http://drools.org/rules">
     <connector>
	<!-- lets add a drools rule base -->
	<drools:rulebase>
	    <drools:rule>
		<drools:condition>x > 10</drools:condition>
		<drools:parameter name="foo">
		   <!-- back to regular Spring again here -->
		    <ref>cheese</ref>
		</drools:paramater>
	    </drools:rule>
	</drools:rulebase>
     </connector>
</broker>

<!-- regular Spring again -->
<bean id="cheese" class="com.acme.Foo">
</bean>
	

To give a concrete real use case for this; when using Spring to 
configure ActiveMQ's JCA container for Message Driven POJOs (which 
could use its own simplified XML language too), we often wanna deploy 
an embedded ActiveMQ message broker inside the JCA container. Right now 
rather than including a little XML fragment as above; we have to split 
things into separate files.

Thinking generically; it'd be nice for folks to be able to register 
different XML 'short hand' libraries with Spring, using standard spring 
(rather than custom bean factories) to let all this kinda stuff 
integrate together cleanly.

In principle, registering 'dialect handlers' with namespaces in the 
standard Spring XML configuration file reader is fairly trivial. The 
harder part is how to implement the transformation of some arbitrary 
XML element (say drools:rulebase) to regular Spring configuration stuff 
(say <bean class="org.drools.DefaultRuleBaseImpl">...</bean>). Right 
now in ActiveMQ we ended up using XSLT as the W3C DOM API is such a 
PITA to work with and we didn't wanna add a new dependency; but maybe 
we could come up with a pure Spring based 'XML macro' mechanism we 
could all integrate with?

I'm wondering have others thought along these kinda lines - or is it 
just us :)

James
-------
http://radio.weblogs.com/0112098/

RE: [Springframework-developer] AbstractTransactionalSpringContextTests

[Keith D. <ke...@in...>]

>I don't quite understand what you want here. Can you please be more 
>specific? How would you drive this option?

Ideally I'd like to be able to test the Phonebook sample flows, or any other
flows, by extending AbstractTransactionalSpringContextTests, without being
*required* to set a transaction manager and run in the context of a TX.  In
other words, I'd like it to be configurable.  If it's not made configurable,
I'm only left with two options:
1. Scale up Phonebook (or any other flow) to work with a transactional data
source
2. Have a duplicate AbstractFlowExecutionTests hierarchy that just extends
from DependencyInjectedContextTests

Neither of these are that great IMO.  The former means I can really only
integration test flows that need TX's (yes that will probably be the
majority, but...) or I have to mock out the TX Manager.  The latter means I
duplicate flow integration test code, to extend from two different base
classes.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rod Johnson
Sent: Wednesday, April 06, 2005 6:55 AM
To: spr...@li...
Subject: Re: [Springframework-developer]
AbstractTransactionalSpringContextTests

Keith

I will try to make any required enhancements today.

> - the ability to DISABLE dependency checking by object for the autowired 
> test - sometimes defaults really do make sense, why always require a set 
> method to be called for each public setter?
I've added a dependencyCheck property which you can call in a 
constructor. I've preserved the default dependency checking, which I 
think is useful.

> - the ability to turn off/on transaction management - right now 
> AbstractFlowExecutionTests is runnable only in the context of a database 
> transaction.  While this is great and all, if I want to integration test 
> flows outside of any transactional context, I'm screwed.  I can't 
> exactly subclass DependencyInjectedContextTests, as I still WANT THE 
> OPTION of being able to test flows in a transaction context - for the 
> flows that demand it.  But the current structure doesn't give me that 
> choice.
I don't quite understand what you want here. Can you please be more 
specific? How would you drive this option?

Rgds
Rod



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AbstractTransactionalSpringContextTests

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

Keith

I will try to make any required enhancements today.

> - the ability to DISABLE dependency checking by object for the autowired 
> test – sometimes defaults really do make sense, why always require a set 
> method to be called for each public setter?
I've added a dependencyCheck property which you can call in a 
constructor. I've preserved the default dependency checking, which I 
think is useful.

> - the ability to turn off/on transaction management – right now 
> AbstractFlowExecutionTests is runnable only in the context of a database 
> transaction.  While this is great and all, if I want to integration test 
> flows outside of any transactional context, I’m screwed.  I can’t 
> exactly subclass DependencyInjectedContextTests, as I still WANT THE 
> OPTION of being able to test flows in a transaction context – for the 
> flows that demand it.  But the current structure doesn’t give me that 
> choice.
I don't quite understand what you want here. Can you please be more 
specific? How would you drive this option?

Rgds
Rod