springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

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

Tim,

The only thing I can tell so far is that there shouldn't be any =20
difference in behavior between TransactionProxyFactoryBean and =20
ProxyFactoryBean. Could you please send the configuration of the =20
relevant classes before and after the changes you made?


Steven Devijver
Senior consultant
@ Interface21
ste...@in...



On 12 Sep 2005, at 23:10, Tim Kettering wrote:

>
> I hate to come off sounding like a broken record here, but I asked =20
> about
> this issue last week in the hopes that someone could elaborate =20
> further on
> it, but didn=92t get any reply on it.  I=92m thinking maybe it got =
lost =20
> in the
> events over the weekend, so I=92m re-posting both emails I sent =20
> below, in the
> hopes that someone might afford a look at it and point me in the right
> direction.  Thanks in advance!
>
> In a nutshell, I'm seeing different behavior on how interceptors =20
> are applied
> to an proxy object purely based on whether it is using =20
> ProxyFactoryBean or
> TransactionProxyFactoryBean. (details are in the email below)
>
>
> =3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I'm running into some rather unusual behavior that I cannot explain =20=

> - so I
> thought I'd bring it up here, either I'm doing something wrong, or =20
> there (a
> far more remote possibility) is something wrong w/ Spring.
>
> I previously had an object that was wrapped in a
> TransactionProxyFactoryBean, and this object also had an Acegi =20
> security
> method interceptor applied to it.
>
> In my refactoring of the code to move the transactional concerns to =20=

> a higher
> abstraction layer, I changed the object wrapper from
> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted to =20=

> keep the
> Acegi method interceptor at this level, I upated the =20
> 'postInterceptors'
> property to 'interceptorNames', and set the name of the Acegi =20
> interceptor in
> there.
>
> from this:
>
>         <property name=3D"postInterceptors">
>             <list>
>                 <ref bean=3D"serviceMethodSecurityInterceptor"/>
>             </list>
>         </property>
>
> to this:
>
>         <property name=3D"interceptorNames">
>             <list>
>                 <value>serviceMethodSecurityInterceptor</value>
>             </list>
>         </property>
>
> Some of the test cases I have broke after this change.  I started =20
> digging
> around a bit to find out why, and what I've turned up, to the best =20
> I can
> figure out is that when applying an interceptor via =20
> 'interceptorNames', the
> interceptor gets selectively applied.    This is the configuration =20
> for the
> method interceptor.  As you can see, we are applying access control =20=

> on three
> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>
>     <bean id=3D"serviceMethodSecurityInterceptor"
> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurit=
=20
> yInter
> ceptor">
>         <property name=3D"authenticationManager"><ref
> bean=3D"authenticationManager"/></property>
>          <property name=3D"accessDecisionManager"><ref
> bean=3D"decisionManager"/></property>
>         <property name=3D"afterInvocationManager"><ref
> bean=3D"afterInvocationManager"/></property>
>         <property name=3D"objectDefinitionSource">
>             <value>
>                 =20
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_=
=20
> ACL_RE
> AD
>
> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AF=
=20
> TER_AC
> L_READ
>             </value>
>         </property>
>     </bean>
>
> And as far as I can see - when using TransactionProxyFactoryBean, =20
> all three
> methods get applied correctly.  i.e. integration tests that test =20
> the 'get',
> 'getTopicList' and 'getTopicChildren' all work properly.
>
> But when changing to use ProxyFactoryBean, the 'get' method =20
> integration test
> fails (the interceptor apparently is not called), while =20
> 'getTopicList' and
> 'getTopicChildren' work integration test works fine.  The only =20
> differnence
> in how the methods that are tested is that 'get' is defined in an =20
> higher
> level interface (Service) instead of (TopicService).  The =20
> integration test
> calls topicService.get() ....
>
> I'm hoping that someone can help shine additional light on this =20
> difference
> in behavior with the interceptors, and what I might be doing wrong?
>
> Thanks in advance,
>
> -tim
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Following up on the previous email I sent yesterday, I explored one =20=

> more
> scenario.  Since the hiearchy for the 'Service' interface is like =20
> this.
>
> Service
>    -'.get()'
>
>   + TopicService (extends Service)
>   - .getTopicList()
>   - .getTopicChildren()
>
> And as I've mentioned in my previous email, the Acegi security method
> interceptor does not seem to be kicking in on the 'get()' method =20
> when called
> on a TopicService implementation, although it does kick in for the =20
> other two
> methods defined under TopicService when using ProxyFactoryBean and
> 'interceptorNames' property.
>
> So I tested out earlier today what would happen if I defined the =20
> 'get()'
> method at the TopicService interface level, and updated the =20
> security method
> interceptor from
>
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> to
>
> com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ
>
> And the result is that it worked.  So, I'm hoping that someone with =20=

> a better
> understanding of what the differences between the ProxyFactoryBean =20
> advising
> process and the TransactionProxyFactoryBean would be - could =20
> clarify what is
> going on, since to me, they should work the same?
>
> Thanks.
>
> -tim
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle =20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * =20
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/=20
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Tim K. <tim...@vi...>]

I hate to come off sounding like a broken record here, but I asked about
this issue last week in the hopes that someone could elaborate further =
on
it, but didn=92t get any reply on it.  I=92m thinking maybe it got lost =
in the
events over the weekend, so I=92m re-posting both emails I sent below, =
in the
hopes that someone might afford a look at it and point me in the right
direction.  Thanks in advance!

In a nutshell, I'm seeing different behavior on how interceptors are =
applied
to an proxy object purely based on whether it is using ProxyFactoryBean =
or
TransactionProxyFactoryBean. (details are in the email below)


=3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I'm running into some rather unusual behavior that I cannot explain - so =
I
thought I'd bring it up here, either I'm doing something wrong, or there =
(a
far more remote possibility) is something wrong w/ Spring.

I previously had an object that was wrapped in a
TransactionProxyFactoryBean, and this object also had an Acegi security
method interceptor applied to it.=A0=20

In my refactoring of the code to move the transactional concerns to a =
higher
abstraction layer, I changed the object wrapper from
TransactionProxyFactoryBean to ProxyFactoryBean.=A0 Since I wanted to =
keep the
Acegi method interceptor at this level, I upated the 'postInterceptors'
property to 'interceptorNames', and set the name of the Acegi =
interceptor in
there.=A0=20

from this:

=A0=A0=A0 =A0=A0=A0 <property name=3D"postInterceptors">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <list>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <ref =
bean=3D"serviceMethodSecurityInterceptor"/>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </list>
=A0=A0=A0 =A0=A0=A0 </property>

to this:

=A0=A0=A0 =A0=A0=A0 <property name=3D"interceptorNames">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <list>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =
<value>serviceMethodSecurityInterceptor</value>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </list>
=A0=A0=A0 =A0=A0=A0 </property>

Some of the test cases I have broke after this change.=A0 I started =
digging
around a bit to find out why, and what I've turned up, to the best I can
figure out is that when applying an interceptor via 'interceptorNames', =
the
interceptor gets selectively applied.=A0=A0=A0 This is the configuration =
for the
method interceptor.=A0 As you can see, we are applying access control on =
three
different methods.=A0 'get', 'getTopicList' and 'getTopicChildren'.=A0=20

=A0=A0=A0 <bean id=3D"serviceMethodSecurityInterceptor"
class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurity=
Inter
ceptor">
=A0=A0=A0 =A0=A0=A0 <property name=3D"authenticationManager"><ref
bean=3D"authenticationManager"/></property>
=A0=A0=A0=A0 =A0=A0=A0 <property name=3D"accessDecisionManager"><ref
bean=3D"decisionManager"/></property>
=A0=A0=A0 =A0=A0=A0 <property name=3D"afterInvocationManager"><ref
bean=3D"afterInvocationManager"/></property>
=A0=A0=A0 =A0=A0=A0 <property name=3D"objectDefinitionSource">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <value>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =
com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0
com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_A=
CL_RE
AD
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0
com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AFT=
ER_AC
L_READ
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </value>
=A0=A0=A0 =A0=A0=A0 </property>
=A0=A0=A0 </bean>=A0=A0=A0 =A0=A0=A0=20

And as far as I can see - when using TransactionProxyFactoryBean, all =
three
methods get applied correctly.=A0 i.e. integration tests that test the =
'get',
'getTopicList' and 'getTopicChildren' all work properly.=A0=20

But when changing to use ProxyFactoryBean, the 'get' method integration =
test
fails (the interceptor apparently is not called), while 'getTopicList' =
and
'getTopicChildren' work integration test works fine.=A0 The only =
differnence
in how the methods that are tested is that 'get' is defined in an higher
level interface (Service) instead of (TopicService).=A0 The integration =
test
calls topicService.get() ....

I'm hoping that someone can help shine additional light on this =
difference
in behavior with the interceptors, and what I might be doing wrong?

Thanks in advance,

-tim

=3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Following up on the previous email I sent yesterday, I explored one more
scenario.  Since the hiearchy for the 'Service' interface is like this.

Service=20
   -'.get()'

  + TopicService (extends Service)
  - .getTopicList()
  - .getTopicChildren()

And as I've mentioned in my previous email, the Acegi security method
interceptor does not seem to be kicking in on the 'get()' method when =
called
on a TopicService implementation, although it does kick in for the other =
two
methods defined under TopicService when using ProxyFactoryBean and
'interceptorNames' property. =20

So I tested out earlier today what would happen if I defined the 'get()'
method at the TopicService interface level, and updated the security =
method
interceptor from

com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ

to=20

com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ

And the result is that it worked.  So, I'm hoping that someone with a =
better
understanding of what the differences between the ProxyFactoryBean =
advising
process and the TransactionProxyFactoryBean would be - could clarify =
what is
going on, since to me, they should work the same?

Thanks.

-tim

Re: [Springframework-developer] Spring MVC and validation

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

On 12 Sep 2005, at 22:06, Thomas Van de Velde wrote:

> That would be excellent stuff Steven!
>
> I have used this on a very large scale and combined it with a JSP  
> tag that reads the annotation and writes appropriate JavaScript.   
> On the server side, the annotation can be read to execute server- 
> side validation logic.
>
> With your solution I'd be worried about typos in the validation  
> rules.  Wouldn't it be better to have something more explicit  
> licate @ValidateRequired, @ValidateEmail, and @ValidateDate, ....
>

We could obviously  create these annotation classes as shorthand  
notations but writing your own constraints is much more powerful, in  
the end that's what Valang is about.

I'm not sure if there is a common set of validation annotation  
classes but to me it makes sense to not couple these annotations to  
Spring or Valang. With annotations all you would need to do is have a  
Spring Validator implementation that reads the annotations of a class  
and validates the objects that come in. These annotated classes could  
then be used with Struts or WebWork or any other framework that wants  
to support them.

> To respond to Sean's question, you could have a  
> @ValidateRequiredIfBlank("mybean.afield") but there are limits to  
> this of course.
>
> I guess you'd also have to pass another parameter that points to  
> the key of a message that you want to show for validation messages.
>
> Thomas
>
> On 9/12/05, Steven Devijver <ste...@in...> wrote:
> I've had a couple of requests now to include support for annotations.
> Basically we could do something like this:
>
>
> public @interface Validate {
>      String constraint();
>      String code();
>      String message();
>      String[] arguments();
> }
>
> So you could do:
>
> package test;
>
> public class MyClass {
>
>      private String firstName = null;
>      @Validate(
>          constraint = "? not blank",
>          code = "firstName_blank"
>      )
>      public String getFirstName() { return this.firstName; }
>      public void setFirstName(String firstName) { this.firstName =
> firstName; }
>
>      private String lastName = null;
>      @Validate("? not blank") // would use code:
> test.MyClass_lastName_invalid
>      public String getLastName() { return this.lastName; }
>      public void setLastName(String lastName) { this.lastName =
> lastName; }
> }
>
> Any thoughts on this?
>
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>
>
>
> On 12 Sep 2005, at 14:51, Sean Miller wrote:
>
>
>
>
> > This looks like a really neat option for single-field validations;
> > is there an obvious way of handling multi-field validations as
> > annotations, like
> >
> > collision : (firstName is not blank or lastName is not blank) and
> > userid is not blank : 'Fill in either name or id'
> >
> > Cheers,
> > Sean Miller.
> >
> > Thomas Van de Velde wrote:
> >
> >
> >
> >
> >
> >> I am wondering if it'd make sense to have the validation rules
> >> defined as annotations.
> >> e.g.
> >>
> >> @RequiredField
> >> @EmailAddress
> >>
> >> I've worked with forms that contains 2 000 + fields and
> >> maintaining external XML files is really cumbersome in such a
> >> case?  Any thoughts, pros/cons?
> >>
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/
> > bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework- 
> developer
> >
> >
> >
> >
> >
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Extending IoC with Component Model

[Maxim <mf...@gm...>]

I'm looking into extending Spring with a Component Model similar to
the OpenOffice UNO
(http://udk.openoffice.org/common/man/componentmodel.html).

The initial proposal is posted at
"http://www.jroller.com/page/mfateev?entry=3Dextending_inversion_of_control=
_paradigm".

Any feedback is very wellcome.

Maxim.

Re: [Springframework-developer] Spring MVC and validation

[Thomas V. de V. <tho...@ac...>]

That would be excellent stuff Steven!

I have used this on a very large scale and combined it with a JSP tag that=
=20
reads the annotation and writes appropriate JavaScript. On the server side,=
=20
the annotation can be read to execute server-side validation logic.

With your solution I'd be worried about typos in the validation rules.=20
Wouldn't it be better to have something more explicit licate=20
@ValidateRequired, @ValidateEmail, and @ValidateDate, ....

To respond to Sean's question, you could have a @ValidateRequiredIfBlank("
mybean.afield") but there are limits to this of course.=20

I guess you'd also have to pass another parameter that points to the key of=
=20
a message that you want to show for validation messages.

Thomas

On 9/12/05, Steven Devijver <ste...@in...> wrote:
>=20
> I've had a couple of requests now to include support for annotations.
> Basically we could do something like this:
>=20
>=20
> public @interface Validate {
> String constraint();
> String code();
> String message();
> String[] arguments();
> }
>=20
> So you could do:
>=20
> package test;
>=20
> public class MyClass {
>=20
> private String firstName =3D null;
> @Validate(
> constraint =3D "? not blank",
> code =3D "firstName_blank"
> )
> public String getFirstName() { return this.firstName; }
> public void setFirstName(String firstName) { this.firstName =3D
> firstName; }
>=20
> private String lastName =3D null;
> @Validate("? not blank") // would use code:
> test.MyClass_lastName_invalid
> public String getLastName() { return this.lastName; }
> public void setLastName(String lastName) { this.lastName =3D
> lastName; }
> }
>=20
> Any thoughts on this?
>=20
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>=20
>=20
>=20
> On 12 Sep 2005, at 14:51, Sean Miller wrote:
>=20
>=20
>=20
>=20
> > This looks like a really neat option for single-field validations;
> > is there an obvious way of handling multi-field validations as
> > annotations, like
> >
> > collision : (firstName is not blank or lastName is not blank) and
> > userid is not blank : 'Fill in either name or id'
> >
> > Cheers,
> > Sean Miller.
> >
> > Thomas Van de Velde wrote:
> >
> >
> >
> >
> >
> >> I am wondering if it'd make sense to have the validation rules
> >> defined as annotations.
> >> e.g.
> >>
> >> @RequiredField
> >> @EmailAddress
> >>
> >> I've worked with forms that contains 2 000 + fields and
> >> maintaining external XML files is really cumbersome in such a
> >> case? Any thoughts, pros/cons?
> >>
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/
> > bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Spring MVC and validation

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

I've had a couple of requests now to include support for annotations.  
Basically we could do something like this:


public @interface Validate {
     String constraint();
     String code();
     String message();
     String[] arguments();
}

So you could do:

package test;

public class MyClass {

     private String firstName = null;
     @Validate(
         constraint = "? not blank",
         code = "firstName_blank"
     )
     public String getFirstName() { return this.firstName; }
     public void setFirstName(String firstName) { this.firstName =  
firstName; }

     private String lastName = null;
     @Validate("? not blank") // would use code:  
test.MyClass_lastName_invalid
     public String getLastName() { return this.lastName; }
     public void setLastName(String lastName) { this.lastName =  
lastName; }
}

Any thoughts on this?

Steven Devijver
Senior consultant
@ Interface21
ste...@in...



On 12 Sep 2005, at 14:51, Sean Miller wrote:




> This looks like a really neat option for single-field validations;  
> is there an obvious way of handling multi-field validations as  
> annotations, like
>
> collision : (firstName is not blank or lastName is not blank) and  
> userid is not blank : 'Fill in either name or id'
>
> Cheers,
> Sean Miller.
>
> Thomas Van de Velde wrote:
>
>
>
>
>
>> I am wondering if it'd make sense to have the validation rules  
>> defined as annotations.
>> e.g.
>>
>> @RequiredField
>> @EmailAddress
>>
>> I've worked with forms that contains 2 000 + fields and  
>> maintaining external XML files is really cumbersome in such a  
>> case?  Any thoughts, pros/cons?
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>

Re: [Springframework-developer] Spring MVC and validation

[Sean M. <se...@se...>]

This looks like a really neat option for single-field validations; is 
there an obvious way of handling multi-field validations as annotations, 
like

collision : (firstName is not blank or lastName is not blank) and userid 
is not blank : 'Fill in either name or id'

Cheers,
Sean Miller.

Thomas Van de Velde wrote:

> I am wondering if it'd make sense to have the validation rules defined 
> as annotations. 
>
> e.g.
>
> @RequiredField
> @EmailAddress
>
> I've worked with forms that contains 2 000 + fields and maintaining 
> external XML files is really cumbersome in such a case?  Any thoughts, 
> pros/cons?

Re: [Springframework-developer] Spring MVC and validation

[Thomas V. de V. <tho...@ac...>]

I am wondering if it'd make sense to have the validation rules defined as=
=20
annotations.=20

e.g.

@RequiredField
@EmailAddress

I've worked with forms that contains 2 000 + fields and maintaining externa=
l=20
XML files is really cumbersome in such a case? Any thoughts, pros/cons?

Cheers,
Thomas

On 9/12/05, Paul Sundling <tk...@tk...> wrote:
>=20
> I'll definitely investigate Valang in depth. Thanks. Just the
> existence of some documentation puts it ahead of the commons validator
> integration support in Spring modules. :)
>=20
> Valang looks pretty powerful, although it's still missing some basic
> functionality like email, credit card validation. Perhaps that sort of
> stuff probably belongs more in the ValidatorUtils since Valang seems to
> be a general purpose tool. Regular expressions were alluded to
> (customizing date parser), but I didn't see them specifically listed.
>=20
> At some point I hope a validation framework gets integrated into Spring
> MVC.
>=20
> Thanks again. I'll go into lurker mode now. :)
>=20
> Paul Sundling
>=20
>=20
> On Mon, 2005-09-12 at 14:32 +1000, Oliver Hutchison wrote:
> > > > Hi Paul,
> > > >
> > > > Have you looked at Valang already?
> > > >
> > > >
> > > http://opensource2.atlassian.com/confluence/spring/display/MODULES/Us=
i
> > > > ng+Valang+validator
> > > >
> > > > It's a declarative validation language that has some powerful
> > > > constructs and its feature set is growing. It's build on top of
> > > > Spring's validation package. It currently isn't released
> > > yet but the
> > > > code is stable and a lot of people use it in production.
> > >
> > > I can second this recommendation. For one, Valang is much
> > > easier to read than the commons-validator XML file.
> >
> > I'm also using Valang in production and love it. The only reason I can
> > see why you'd want to use commons-validator is for the automatic
> > JavaScript validation support but within the week I hope to make the
> > code for my Valang to JavaScript translator available which will allow
> > you to have your server side Valang rules automatically translated into
> > client side JavaScript.
> >
> > Ollie
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
=20
> QA
> > Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Spring MVC and validation

[Paul S. <tk...@tk...>]

I'll definitely investigate Valang in depth.  Thanks.  Just the
existence of some documentation puts it ahead of the commons validator
integration support in Spring modules. :)  

Valang looks pretty powerful, although it's still missing some basic
functionality like email, credit card validation.  Perhaps that sort of
stuff probably belongs more in the ValidatorUtils since Valang seems to
be a general purpose tool.  Regular expressions were alluded to
(customizing date parser), but I didn't see them specifically listed.

At some point I hope a validation framework gets integrated into Spring
MVC.  

Thanks again.  I'll go into lurker mode now. :)

Paul Sundling


On Mon, 2005-09-12 at 14:32 +1000, Oliver Hutchison wrote:
>  > > Hi Paul,
> > > 
> > > Have you looked at Valang already?
> > > 
> > > 
> > http://opensource2.atlassian.com/confluence/spring/display/MODULES/Usi
> > > ng+Valang+validator
> > > 
> > > It's a declarative validation language that has some powerful 
> > > constructs and its feature set is growing. It's build on top of 
> > > Spring's validation package. It currently isn't released 
> > yet but the 
> > > code is stable and a lot of people use it in production.
> > 
> > I can second this recommendation.  For one, Valang is much 
> > easier to read than the commons-validator XML file.
> 
> I'm also using Valang in production and love it. The only reason I can
> see why you'd want to use commons-validator is for the automatic
> JavaScript validation support but within the week I hope to make the
> code for my Valang to JavaScript translator available  which will allow
> you to have your server side Valang rules automatically translated into
> client side JavaScript.
> 
> Ollie
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Spring MVC and validation

[Oliver H. <Ol...@ou...>]

=20
> > Hi Paul,
> >=20
> > Have you looked at Valang already?
> >=20
> >=20
> http://opensource2.atlassian.com/confluence/spring/display/MODULES/Usi
> > ng+Valang+validator
> >=20
> > It's a declarative validation language that has some powerful=20
> > constructs and its feature set is growing. It's build on top of=20
> > Spring's validation package. It currently isn't released=20
> yet but the=20
> > code is stable and a lot of people use it in production.
>=20
> I can second this recommendation.  For one, Valang is much=20
> easier to read than the commons-validator XML file.

I'm also using Valang in production and love it. The only reason I can
see why you'd want to use commons-validator is for the automatic
JavaScript validation support but within the week I hope to make the
code for my Valang to JavaScript translator available  which will allow
you to have your server side Valang rules automatically translated into
client side JavaScript.

Ollie

Re: [Springframework-developer] Spring MVC and validation

[Seth L. <set...@gm...>]

On 9/11/05, Steven Devijver <ste...@gm...> wrote:
> Hi Paul,
>=20
> Have you looked at Valang already?
>=20
> http://opensource2.atlassian.com/confluence/spring/display/MODULES/Using+=
Valang+validator
>=20
> It's a declarative validation language that has some powerful
> constructs and its feature set is growing. It's build on top of
> Spring's validation package. It currently isn't released yet but the
> code is stable and a lot of people use it in production.

I can second this recommendation.  For one, Valang is much easier to
read than the commons-validator XML file.

Seth

Re: [Springframework-developer] 1.2.5 release

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

Thanks, Thomas - and sorry for the inconvenience.

Developers: There are still a few issues open for 1.2.5, as listed in JIRA.
Everything major should have been addressed already; we're waiting for user
feedback on a couple of things. However, it would be great if we could
address some of the open minor things as well - in the course of this week.

Everybody: I would appreciate tests of current nightly 1.2.5 snapshots! Even
plain sanity checking would be helpful: e.g. dropping the snapshot
spring.jar into your application's integration test suite and seeing whether
everything still passes - no matter which Spring 1.2.x version you're
currently using.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Sunday, September 11, 2005 5:55 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.2.5 release

I've reverted the named parameter changes.  I'll add them to the sandbox
when I get a chance.

Thomas


On Sep 9, 2005, at 6:40 PM, Juergen Hoeller wrote:

> Yes, I'm aware that this wasn't clear. I wanted to leave the option 
> for a
> 1.2.5 release open but didn't clearly communicate that: I just told 
> some people in private to keep definitive 1.3 stuff in the sandbox for 
> the time being.
>
> So that was mainly a note to myself: I need to put definite 
> announcements out when CVS HEAD moves on to the next major version, 
> with a maintenance branch created for the previous version.
>
> I've just changed all version numbers to 1.2.5, so future nightly 
> snapshots will have that name. I've also updated JIRA accordingly, 
> separating
> 1.2.5
> issues from 1.3 RC1 issues.
>
> BTW, additional tests and other stuff that does make sense for 1.2.x 
> should stay in the main sources, as well as minor new stuff. It's 
> really only definitive 1.3 features that should move to the sandbox.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Thomas Risberg
> Sent: Saturday, September 10, 2005 12:21 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] 1.2.5 release
>
> I'll move it over to the sandbox the next couple of days.
>
> 1.2.5 wasn't on the roadmap earlier so I went ahead with 1.3 features
> - I changed the version to 1.3-dev - we should change that to 1.2.5 so 
> the downloadable nightly snapshots are named accordingly.
>
> Thomas
>
> On Sep 9, 2005, at 5:26 PM, Juergen Hoeller wrote:
>
>
>> Thomas,
>>
>> Do you have the chance to move those classes to the sandbox, 
>> potentially holding the JdbcTemplate extensions in a special 
>> JdbcTemplate subclass for the time being? I can do that move as well, 
>> of course, but I don't want to infer with any local changes you might 
>> already have made but not committed yet.
>>
>> In general, we should have clarified the role of CVS HEAD. We need 
>> definitive announcements once HEAD turns to the next major release.
>> Currently it still serves as basis for 1.2.5, which will then lead to 
>> a 1.2.x maintenance branch (for potential future patches), with CVS 
>> HEAD becoming the basis for 1.3.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of Thomas Risberg
>> Sent: Friday, September 09, 2005 2:20 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] 1.2.5 release
>>
>> Juergen,
>>
>> I'd prefer to keep the named parameters for a 1.3RC1 release - there 
>> are still some lose ends and little testing has been done on most of 
>> it.
>>
>> Thomas
>>
>>
>> On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:
>>
>>
>>
>>> Everyone,
>>>
>>> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
>>> resolving the already known issues in the 1.2.x line, as reported on 
>>> our JIRA and partly already fixed in CVS (currently with target 1.3 
>>> RC1). The
>>> 1.2.5 release, if desired, would have to happen end of next week.
>>> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a
>>> 1.2
>>> maintenance branch alongside.
>>>
>>> Ideally, the 1.2.5 release would include all minor fixes done since
>>> 1.2.4
>>> (there were quite a few, including javadoc fixes). Hence, I would 
>>> like to create it from CVS HEAD rather than from a 1.2.4 branch.
>>> This
>>> means that already committed 1.3 features would have to be 
>>> temporarily moved to the sandbox, unless we decide to release them 
>>> in
>>> 1.2.5 already.
>>>
>>> The request log filter and named JDBC statement parameters are 
>>> candidates for 1.2.5, I guess, as they have been planned for 1.2.x 
>>> initially.
>>> Thomas,
>>> if you'd like to not release named JDBC statement parameters before
>>> 1.3 RC1,
>>> I would temporarily move it to the sandbox and back after the actual
>>> 1.2.5 release. I'll leave that decision up to you.
>>>
>>> Regards,
>>>
>>> Juergen
>>>
>>> -----
>>> Juergen Hoeller
>>> Interface21 - Spring Services from the Source 
>>> http://www.springframework.com
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is Sponsored by the Better Software Conference & EXPO 
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>>> Practices Agile & Plan-Driven Development * Managing Projects & 
>>> Teams
>>> * Testing & QA Security * Process Improvement & Measurement * 
>>> http://www.sqe.com/ bsce5sf 
>>> _______________________________________________
>>> Springframework-developer mailing list 
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>> developer
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO 
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security
>> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf 
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO 
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security * Process Improvement & Measurement * 
>> http://www.sqe.com/ bsce5sf 
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security
> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security * Process Improvement & Measurement * 
> http://www.sqe.com/ bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.2.5 release

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

I've reverted the named parameter changes.  I'll add them to the  
sandbox when I get a chance.

Thomas


On Sep 9, 2005, at 6:40 PM, Juergen Hoeller wrote:

> Yes, I'm aware that this wasn't clear. I wanted to leave the option  
> for a
> 1.2.5 release open but didn't clearly communicate that: I just told  
> some
> people in private to keep definitive 1.3 stuff in the sandbox for  
> the time
> being.
>
> So that was mainly a note to myself: I need to put definite  
> announcements
> out when CVS HEAD moves on to the next major version, with a  
> maintenance
> branch created for the previous version.
>
> I've just changed all version numbers to 1.2.5, so future nightly  
> snapshots
> will have that name. I've also updated JIRA accordingly, separating  
> 1.2.5
> issues from 1.3 RC1 issues.
>
> BTW, additional tests and other stuff that does make sense for  
> 1.2.x should
> stay in the main sources, as well as minor new stuff. It's really only
> definitive 1.3 features that should move to the sandbox.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On  
> Behalf Of
> Thomas Risberg
> Sent: Saturday, September 10, 2005 12:21 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] 1.2.5 release
>
> I'll move it over to the sandbox the next couple of days.
>
> 1.2.5 wasn't on the roadmap earlier so I went ahead with 1.3 features
> - I changed the version to 1.3-dev - we should change that to 1.2.5  
> so the
> downloadable nightly snapshots are named accordingly.
>
> Thomas
>
> On Sep 9, 2005, at 5:26 PM, Juergen Hoeller wrote:
>
>
>> Thomas,
>>
>> Do you have the chance to move those classes to the sandbox,
>> potentially holding the JdbcTemplate extensions in a special
>> JdbcTemplate subclass for the time being? I can do that move as well,
>> of course, but I don't want to infer with any local changes you might
>> already have made but not committed yet.
>>
>> In general, we should have clarified the role of CVS HEAD. We need
>> definitive announcements once HEAD turns to the next major release.
>> Currently it still serves as basis for 1.2.5, which will then lead to
>> a 1.2.x maintenance branch (for potential future patches), with CVS
>> HEAD becoming the basis for 1.3.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On
>> Behalf Of Thomas Risberg
>> Sent: Friday, September 09, 2005 2:20 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] 1.2.5 release
>>
>> Juergen,
>>
>> I'd prefer to keep the named parameters for a 1.3RC1 release - there
>> are still some lose ends and little testing has been done on most of
>> it.
>>
>> Thomas
>>
>>
>> On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:
>>
>>
>>
>>> Everyone,
>>>
>>> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
>>> resolving the already known issues in the 1.2.x line, as reported on
>>> our JIRA and partly already fixed in CVS (currently with target 1.3
>>> RC1). The
>>> 1.2.5 release, if desired, would have to happen end of next week.
>>> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a
>>> 1.2
>>> maintenance branch alongside.
>>>
>>> Ideally, the 1.2.5 release would include all minor fixes done since
>>> 1.2.4
>>> (there were quite a few, including javadoc fixes). Hence, I would
>>> like to create it from CVS HEAD rather than from a 1.2.4 branch.  
>>> This
>>> means that already committed 1.3 features would have to be
>>> temporarily moved to the sandbox, unless we decide to release  
>>> them in
>>> 1.2.5 already.
>>>
>>> The request log filter and named JDBC statement parameters are
>>> candidates for 1.2.5, I guess, as they have been planned for 1.2.x
>>> initially.
>>> Thomas,
>>> if you'd like to not release named JDBC statement parameters before
>>> 1.3 RC1,
>>> I would temporarily move it to the sandbox and back after the actual
>>> 1.2.5 release. I'll leave that decision up to you.
>>>
>>> Regards,
>>>
>>> Juergen
>>>
>>> -----
>>> Juergen Hoeller
>>> Interface21 - Spring Services from the Source
>>> http://www.springframework.com
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>> Practices Agile & Plan-Driven Development * Managing Projects &  
>>> Teams
>>> * Testing & QA Security * Process Improvement & Measurement *
>>> http://www.sqe.com/ bsce5sf
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-
>>> developer
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security
>> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security * Process Improvement & Measurement *
>> http://www.sqe.com/ bsce5sf
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO  
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices  
> Agile &
> Plan-Driven Development * Managing Projects & Teams * Testing & QA  
> Security
> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] Spring MVC and validation

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

Hi Paul,

Have you looked at Valang already?

http://opensource2.atlassian.com/confluence/spring/display/MODULES/Using+Va=
lang+validator

It's a declarative validation language that has some powerful
constructs and its feature set is growing. It's build on top of
Spring's validation package. It currently isn't released yet but the
code is stable and a lot of people use it in production.

Steven

On 9/11/05, Paul Sundling <tk...@tk...> wrote:
> I've been pretty successful getting core Spring in my organization so
> far, with 5 other developers now that have touched it.  Thanks for the
> quick turn around on my last feature request.  You guys rock!
>=20
> In less than a month I plan to do a presentation on Spring MVC.  I'm
> planning to advocate Spring MVC as a possible next generation
> architecture.  Struts is already available in the prototype stage and is
> moving ahead.  I'd like to put together a Spring MVC prototype to
> challenge it before Struts becomes a corporate standard.  Overall Spring
> MVC compares well, but the lack of more complete common validation
> support is a major point in Struts favor. The auto generated javascript
> to go with validation was nice too.  It should be easy to mix built in
> validation with custom validation like you can do when extending Struts
> ValidatorForm.
>=20
> There is already org.springframework.validation.ValidationUtils , but it
> has only support for the most basic validation (rejectIfEmpty and
> rejectIfEmptyAndWhitespace).  There is also the Spring Modules
> (https://springmodules.dev.java.net/) commons validator integration,
> which is at 0.2 and is does not even have rudimentary documentation in
> place yet.  There is Aurora MVC (http://www.auroramvc.org/aurora-
> web/docs/html/validation.html) which builds on top of Spring MVC.  Of
> course, there is always creating them programmatically too.  I'm
> guessing lots of Spring MVC programmers working on big projects probably
> have homegrown utility classes for this...
>=20
> It seems that are a proliferation of approaches on how to deal with
> common validations that always come up.  For those experienced with
> Struts, it's a normal expectation that a developer doesn't have to write
> their own email validation code...
>=20
> I'm willing to roll up my sleeves and help if needed.  I have had
> patches commited on Struts and Maven.  I'll preface this by saying that
> I haven't done a thorough analysis of the source code of various
> options.  I apologize in advance if the message is therefor naive.
>=20
> So what should be done here?  Here are some possible approaches that I
> was thinking about.
>=20
> 1) Add more basic validations to
> org.springframework.validation.ValidationUtils like RejectInvalidEmail
> and RejectOutsideDateRange.  This could get large since there are 4
> signature variations of each validation.
> 2) Polish up the Spring Modules commons validator integration and roll
> it in Spring MVC.  I'm not sure how production ready the code is, but
> there are only a dozen classes, so it's probably not too complicated.
> 3) Add docs and examples to the Spring Modules and prominently mention
> it on the Spring site as a solution for common stuff and how production
> ready it is.
> 4) Everyone else feels things are fine the way they are and it's fine if
> developers just create homegrown utility classes for popular
> validations.
> 5) Some other option I haven't thought of...  <Your idea here.>
>=20
> So what is the plan?  What can I do to help?  The last big thread on
> this was back in May.
>=20
> Paul Sundling
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>

[Springframework-developer] Spring MVC and validation

[Paul S. <tk...@tk...>]

I've been pretty successful getting core Spring in my organization so
far, with 5 other developers now that have touched it.  Thanks for the
quick turn around on my last feature request.  You guys rock!

In less than a month I plan to do a presentation on Spring MVC.  I'm
planning to advocate Spring MVC as a possible next generation
architecture.  Struts is already available in the prototype stage and is
moving ahead.  I'd like to put together a Spring MVC prototype to
challenge it before Struts becomes a corporate standard.  Overall Spring
MVC compares well, but the lack of more complete common validation
support is a major point in Struts favor. The auto generated javascript
to go with validation was nice too.  It should be easy to mix built in
validation with custom validation like you can do when extending Struts
ValidatorForm.

There is already org.springframework.validation.ValidationUtils , but it
has only support for the most basic validation (rejectIfEmpty and
rejectIfEmptyAndWhitespace).  There is also the Spring Modules
(https://springmodules.dev.java.net/) commons validator integration,
which is at 0.2 and is does not even have rudimentary documentation in
place yet.  There is Aurora MVC (http://www.auroramvc.org/aurora-
web/docs/html/validation.html) which builds on top of Spring MVC.  Of
course, there is always creating them programmatically too.  I'm
guessing lots of Spring MVC programmers working on big projects probably
have homegrown utility classes for this...

It seems that are a proliferation of approaches on how to deal with
common validations that always come up.  For those experienced with
Struts, it's a normal expectation that a developer doesn't have to write
their own email validation code...

I'm willing to roll up my sleeves and help if needed.  I have had
patches commited on Struts and Maven.  I'll preface this by saying that
I haven't done a thorough analysis of the source code of various
options.  I apologize in advance if the message is therefor naive.

So what should be done here?  Here are some possible approaches that I
was thinking about.

1) Add more basic validations to
org.springframework.validation.ValidationUtils like RejectInvalidEmail
and RejectOutsideDateRange.  This could get large since there are 4
signature variations of each validation.
2) Polish up the Spring Modules commons validator integration and roll
it in Spring MVC.  I'm not sure how production ready the code is, but
there are only a dozen classes, so it's probably not too complicated.
3) Add docs and examples to the Spring Modules and prominently mention
it on the Spring site as a solution for common stuff and how production
ready it is.
4) Everyone else feels things are fine the way they are and it's fine if
developers just create homegrown utility classes for popular
validations.
5) Some other option I haven't thought of...  <Your idea here.> 

So what is the plan?  What can I do to help?  The last big thread on
this was back in May.

Paul Sundling

[Springframework-developer] spring Build Failed

[<al...@in...>]

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

Re: [Springframework-developer] 1.2.5 release

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

Yes, I'm aware that this wasn't clear. I wanted to leave the option for a
1.2.5 release open but didn't clearly communicate that: I just told some
people in private to keep definitive 1.3 stuff in the sandbox for the time
being.

So that was mainly a note to myself: I need to put definite announcements
out when CVS HEAD moves on to the next major version, with a maintenance
branch created for the previous version.

I've just changed all version numbers to 1.2.5, so future nightly snapshots
will have that name. I've also updated JIRA accordingly, separating 1.2.5
issues from 1.3 RC1 issues.

BTW, additional tests and other stuff that does make sense for 1.2.x should
stay in the main sources, as well as minor new stuff. It's really only
definitive 1.3 features that should move to the sandbox.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Saturday, September 10, 2005 12:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.2.5 release

I'll move it over to the sandbox the next couple of days.

1.2.5 wasn't on the roadmap earlier so I went ahead with 1.3 features
- I changed the version to 1.3-dev - we should change that to 1.2.5 so the
downloadable nightly snapshots are named accordingly.

Thomas

On Sep 9, 2005, at 5:26 PM, Juergen Hoeller wrote:

> Thomas,
>
> Do you have the chance to move those classes to the sandbox, 
> potentially holding the JdbcTemplate extensions in a special 
> JdbcTemplate subclass for the time being? I can do that move as well, 
> of course, but I don't want to infer with any local changes you might 
> already have made but not committed yet.
>
> In general, we should have clarified the role of CVS HEAD. We need 
> definitive announcements once HEAD turns to the next major release.
> Currently it still serves as basis for 1.2.5, which will then lead to 
> a 1.2.x maintenance branch (for potential future patches), with CVS 
> HEAD becoming the basis for 1.3.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of Thomas Risberg
> Sent: Friday, September 09, 2005 2:20 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] 1.2.5 release
>
> Juergen,
>
> I'd prefer to keep the named parameters for a 1.3RC1 release - there 
> are still some lose ends and little testing has been done on most of 
> it.
>
> Thomas
>
>
> On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:
>
>
>> Everyone,
>>
>> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
>> resolving the already known issues in the 1.2.x line, as reported on 
>> our JIRA and partly already fixed in CVS (currently with target 1.3 
>> RC1). The
>> 1.2.5 release, if desired, would have to happen end of next week.
>> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a
>> 1.2
>> maintenance branch alongside.
>>
>> Ideally, the 1.2.5 release would include all minor fixes done since
>> 1.2.4
>> (there were quite a few, including javadoc fixes). Hence, I would 
>> like to create it from CVS HEAD rather than from a 1.2.4 branch. This 
>> means that already committed 1.3 features would have to be 
>> temporarily moved to the sandbox, unless we decide to release them in 
>> 1.2.5 already.
>>
>> The request log filter and named JDBC statement parameters are 
>> candidates for 1.2.5, I guess, as they have been planned for 1.2.x 
>> initially.
>> Thomas,
>> if you'd like to not release named JDBC statement parameters before
>> 1.3 RC1,
>> I would temporarily move it to the sandbox and back after the actual
>> 1.2.5 release. I'll leave that decision up to you.
>>
>> Regards,
>>
>> Juergen
>>
>> -----
>> Juergen Hoeller
>> Interface21 - Spring Services from the Source 
>> http://www.springframework.com
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO 
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security * Process Improvement & Measurement * 
>> http://www.sqe.com/ bsce5sf 
>> _______________________________________________
>> Springframework-developer mailing list 
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-
>> developer
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security
> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security * Process Improvement & Measurement * 
> http://www.sqe.com/ bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] spring build.343 Build Successful

[<al...@in...>]

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

Re: [Springframework-developer] 1.2.5 release

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

I'll move it over to the sandbox the next couple of days.

1.2.5 wasn't on the roadmap earlier so I went ahead with 1.3 features  
- I changed the version to 1.3-dev - we should change that to 1.2.5  
so the downloadable nightly snapshots are named accordingly.

Thomas

On Sep 9, 2005, at 5:26 PM, Juergen Hoeller wrote:

> Thomas,
>
> Do you have the chance to move those classes to the sandbox,  
> potentially
> holding the JdbcTemplate extensions in a special JdbcTemplate  
> subclass for
> the time being? I can do that move as well, of course, but I don't  
> want to
> infer with any local changes you might already have made but not  
> committed
> yet.
>
> In general, we should have clarified the role of CVS HEAD. We need
> definitive announcements once HEAD turns to the next major release.
> Currently it still serves as basis for 1.2.5, which will then lead  
> to a
> 1.2.x maintenance branch (for potential future patches), with CVS HEAD
> becoming the basis for 1.3.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On  
> Behalf Of
> Thomas Risberg
> Sent: Friday, September 09, 2005 2:20 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] 1.2.5 release
>
> Juergen,
>
> I'd prefer to keep the named parameters for a 1.3RC1 release -  
> there are
> still some lose ends and little testing has been done on most of it.
>
> Thomas
>
>
> On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:
>
>
>> Everyone,
>>
>> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
>> resolving the already known issues in the 1.2.x line, as reported on
>> our JIRA and partly already fixed in CVS (currently with target 1.3
>> RC1). The
>> 1.2.5 release, if desired, would have to happen end of next week.
>> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a  
>> 1.2
>> maintenance branch alongside.
>>
>> Ideally, the 1.2.5 release would include all minor fixes done since
>> 1.2.4
>> (there were quite a few, including javadoc fixes). Hence, I would  
>> like
>> to create it from CVS HEAD rather than from a 1.2.4 branch. This  
>> means
>> that already committed 1.3 features would have to be temporarily  
>> moved
>> to the sandbox, unless we decide to release them in 1.2.5 already.
>>
>> The request log filter and named JDBC statement parameters are
>> candidates for 1.2.5, I guess, as they have been planned for 1.2.x
>> initially.
>> Thomas,
>> if you'd like to not release named JDBC statement parameters before
>> 1.3 RC1,
>> I would temporarily move it to the sandbox and back after the actual
>> 1.2.5 release. I'll leave that decision up to you.
>>
>> Regards,
>>
>> Juergen
>>
>> -----
>> Juergen Hoeller
>> Interface21 - Spring Services from the Source
>> http://www.springframework.com
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices Agile & Plan-Driven Development * Managing Projects & Teams
>> * Testing & QA Security * Process Improvement & Measurement *
>> http://www.sqe.com/ bsce5sf
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework- 
>> developer
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO  
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices  
> Agile &
> Plan-Driven Development * Managing Projects & Teams * Testing & QA  
> Security
> * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] 1.2.5 release

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

Thomas,

Do you have the chance to move those classes to the sandbox, potentially
holding the JdbcTemplate extensions in a special JdbcTemplate subclass for
the time being? I can do that move as well, of course, but I don't want to
infer with any local changes you might already have made but not committed
yet.

In general, we should have clarified the role of CVS HEAD. We need
definitive announcements once HEAD turns to the next major release.
Currently it still serves as basis for 1.2.5, which will then lead to a
1.2.x maintenance branch (for potential future patches), with CVS HEAD
becoming the basis for 1.3.

Juergen
 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Thomas Risberg
Sent: Friday, September 09, 2005 2:20 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.2.5 release

Juergen,

I'd prefer to keep the named parameters for a 1.3RC1 release - there are
still some lose ends and little testing has been done on most of it.

Thomas


On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:

> Everyone,
>
> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
> resolving the already known issues in the 1.2.x line, as reported on 
> our JIRA and partly already fixed in CVS (currently with target 1.3 
> RC1). The
> 1.2.5 release, if desired, would have to happen end of next week.
> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a 1.2 
> maintenance branch alongside.
>
> Ideally, the 1.2.5 release would include all minor fixes done since
> 1.2.4
> (there were quite a few, including javadoc fixes). Hence, I would like 
> to create it from CVS HEAD rather than from a 1.2.4 branch. This means 
> that already committed 1.3 features would have to be temporarily moved 
> to the sandbox, unless we decide to release them in 1.2.5 already.
>
> The request log filter and named JDBC statement parameters are 
> candidates for 1.2.5, I guess, as they have been planned for 1.2.x 
> initially.
> Thomas,
> if you'd like to not release named JDBC statement parameters before
> 1.3 RC1,
> I would temporarily move it to the sandbox and back after the actual 
> 1.2.5 release. I'll leave that decision up to you.
>
> Regards,
>
> Juergen
>
> -----
> Juergen Hoeller
> Interface21 - Spring Services from the Source 
> http://www.springframework.com
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices Agile & Plan-Driven Development * Managing Projects & Teams 
> * Testing & QA Security * Process Improvement & Measurement * 
> http://www.sqe.com/ bsce5sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile &
Plan-Driven Development * Managing Projects & Teams * Testing & QA Security
* Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: difference in how interceptors work w/ TransactionProxyFactoryBean and ProxyFactoryBean?

[Tim K. <tim...@gm...>]

Following up on the previous email I sent yesterday, I explored one more=20
scenario. Since the hiearchy for the 'Service' interface is like this.

Service=20
-'.get()'

+ TopicService (extends Service)
- .getTopicList()
- .getTopicChildren()

And as I've mentioned in my previous email, the Acegi security method=20
interceptor does not seem to be kicking in on the 'get()' method when calle=
d=20
on a TopicService implementation, although it does kick in for the other tw=
o=20
methods defined under TopicService when using ProxyFactoryBean and=20
'interceptorNames' property.=20

So I tested out earlier today what would happen if I defined the 'get()'=20
method at the TopicService interface level, and updated the security method=
=20
interceptor from

com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ

to=20

com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ

And the result is that it worked. So, I'm hoping that someone with a better=
=20
understanding of what the differences between the ProxyFactoryBean advising=
=20
process and the TransactionProxyFactoryBean would be - could clarify what i=
s=20
going on, since to me, they should work the same?

Thanks.

-tim

Re: [Springframework-developer] 1.2.5 release

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

Juergen,

I'd prefer to keep the named parameters for a 1.3RC1 release - there  
are still some lose ends and little testing has been done on most of it.

Thomas


On Sep 9, 2005, at 6:35 AM, Juergen Hoeller wrote:

> Everyone,
>
> I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
> resolving the already known issues in the 1.2.x line, as reported  
> on our
> JIRA and partly already fixed in CVS (currently with target 1.3  
> RC1). The
> 1.2.5 release, if desired, would have to happen end of next week.
> Afterwards, CVS HEAD would be dedicated to 1.3 development, with a 1.2
> maintenance branch alongside.
>
> Ideally, the 1.2.5 release would include all minor fixes done since  
> 1.2.4
> (there were quite a few, including javadoc fixes). Hence, I would  
> like to
> create it from CVS HEAD rather than from a 1.2.4 branch. This means  
> that
> already committed 1.3 features would have to be temporarily moved  
> to the
> sandbox, unless we decide to release them in 1.2.5 already.
>
> The request log filter and named JDBC statement parameters are  
> candidates
> for 1.2.5, I guess, as they have been planned for 1.2.x initially.  
> Thomas,
> if you'd like to not release named JDBC statement parameters before  
> 1.3 RC1,
> I would temporarily move it to the sandbox and back after the  
> actual 1.2.5
> release. I'll leave that decision up to you.
>
> Regards,
>
> Juergen
>
> -----
> Juergen Hoeller
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

[Springframework-developer] 1.2.5 release

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

Everyone,

I'm inclined to do a Spring 1.2.5 release before going for 1.3 RC1:
resolving the already known issues in the 1.2.x line, as reported on our
JIRA and partly already fixed in CVS (currently with target 1.3 RC1). The
1.2.5 release, if desired, would have to happen end of next week.
Afterwards, CVS HEAD would be dedicated to 1.3 development, with a 1.2
maintenance branch alongside.

Ideally, the 1.2.5 release would include all minor fixes done since 1.2.4
(there were quite a few, including javadoc fixes). Hence, I would like to
create it from CVS HEAD rather than from a 1.2.4 branch. This means that
already committed 1.3 features would have to be temporarily moved to the
sandbox, unless we decide to release them in 1.2.5 already.

The request log filter and named JDBC statement parameters are candidates
for 1.2.5, I guess, as they have been planned for 1.2.x initially. Thomas,
if you'd like to not release named JDBC statement parameters before 1.3 RC1,
I would temporarily move it to the sandbox and back after the actual 1.2.5
release. I'll leave that decision up to you.

Regards,

Juergen

-----
Juergen Hoeller
Interface21 - Spring Services from the Source
http://www.springframework.com

[Springframework-developer] difference in how interceptors work w/ TransactionProxyFactoryBean and ProxyFactoryBean?

[Tim K. <tim...@gm...>]

I'm running into some rather unusual behavior that I cannot explain - so I=
=20
thought I'd bring it up here, either I'm doing something wrong, or there (a=
=20
far more remote possibility) is something wrong w/ Spring.

I previously had an object that was wrapped in a=20
TransactionProxyFactoryBean, and this object also had an Acegi security=20
method interceptor applied to it.=20

In my refactoring of the code to move the transactional concerns to a highe=
r=20
abstraction layer, I changed the object wrapper from=20
TransactionProxyFactoryBean to ProxyFactoryBean. Since I wanted to keep the=
=20
Acegi method interceptor at this level, I upated the 'postInterceptors'=20
property to 'interceptorNames', and set the name of the Acegi interceptor i=
n=20
there.=20

from this:

<property name=3D"postInterceptors">
<list>
<ref bean=3D"serviceMethodSecurityInterceptor"/>
</list>
</property>

to this:

<property name=3D"interceptorNames">
<list>
<value>serviceMethodSecurityInterceptor</value>
</list>
</property>

Some of the test cases I have broke after this change. I started digging=20
around a bit to find out why, and what I've turned up, to the best I can=20
figure out is that when applying an interceptor via 'interceptorNames', the=
=20
interceptor gets selectively applied. This is the configuration for the=20
method interceptor. As you can see, we are applying access control on three=
=20
different methods. 'get', 'getTopicList' and 'getTopicChildren'.=20

<bean id=3D"serviceMethodSecurityInterceptor" class=3D"
net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor
">
<property name=3D"authenticationManager"><ref=20
bean=3D"authenticationManager"/></property>
<property name=3D"accessDecisionManager"><ref=20
bean=3D"decisionManager"/></property>
<property name=3D"afterInvocationManager"><ref=20
bean=3D"afterInvocationManager"/></property>
<property name=3D"objectDefinitionSource">
<value>
com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_ACL=
_READ
com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AFTER=
_ACL_READ
</value>
</property>
</bean>=20

And as far as I can see - when using TransactionProxyFactoryBean, all three=
=20
methods get applied correctly. i.e. integration tests that test the 'get',=
=20
'getTopicList' and 'getTopicChildren' all work properly.=20

But when changing to use ProxyFactoryBean, the 'get' method integration tes=
t=20
fails (the interceptor apparently is not called), while 'getTopicList' and=
=20
'getTopicChildren' work integration test works fine. The only differnence i=
n=20
how the methods that are tested is that 'get' is defined in an higher level=
=20
interface (Service) instead of (TopicService). The integration test calls=
=20
topicService.get() ....

I'm hoping that someone can help shine additional light on this difference=
=20
in behavior with the interceptors, and what I might be doing wrong?

Thanks in advance,

-tim

[Springframework-developer] spring build.342 Build Successful

[<al...@in...>]

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