springframework-developer — Spring Framework developers list

[Springframework-developer] Replacing EBJs with Spring suggestions

[Garvey, P. M \(GE C. Finance\) <pau...@ge...>]

=20
Springers:

             I need your thoughts on an architectual issue.  I have an
application running on a websphere app server that uses IIOP to
communicate
with an EJB application running on another websphere instance on another
websphere app server. I want to replace the 2 application with Spring.
Any suggestions on how I can have 2 spring application communicating
with each other? They will remain on 2 separtate websphere instances on=20
2 separate app servers? I am new to Spring so bear with me. I need to
know what features in Spring allows me to replace my  controller
application
to EJB application communication.


-Paul

RE: [Springframework-developer] Spring MVC and validation

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

The Valang to JavaScript translation support has now been commited to
the Spring Modules sandbox. So if you're using Valang, you can now have
JavaScript validation automatically generated from your server-side
validation rules. Documentation is here:

http://opensource2.atlassian.com/confluence/spring/display/MODULES/Using
+your+Valang+rules+to+generate+client+side+JavaScript.=20

Cheers,

Oliver

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Oliver Hutchison
> Sent: Monday, 12 September 2005 2:32 PM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Spring MVC and validation
>=20
> I'm also using Valang in production and love it. The only=20
> reason I can see why you'd want to use commons-validator is=20
> for the automatic JavaScript validation support but within=20
> the week I hope to make the code for my Valang to JavaScript=20
> translator available  which will allow you to have your=20
> server side Valang rules automatically translated into client=20
> side JavaScript.

[Springframework-developer] spring build.343 Build Fixed

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

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

Re: [Springframework-developer] Extending IoC with Component Model

[John D. H. <jh...@gm...>]

Very interesting.

I've just made public a simple project to show something like this using=20
Java Annotations (@Obtain and @Build) to do something similiar in terms of=
=20
grouping definitions together.

See http://dash-framework.sourceforge.net (and forgive the pitiful html and=
=20
documentation).

Some caveats:=20
* this project isn't directly Spring related but I indend to back it with a=
=20
Spring Context.
* I think Dash could be complemented by this IoC component model.

Thanks!
John

On 9/12/05, Maxim <mf...@gm...> wrote:
>=20
> I'm looking into extending Spring with a Component Model similar to
> the OpenOffice UNO
> (http://udk.openoffice.org/common/man/componentmodel.html).
>=20
> The initial proposal is posted at
> "
> http://www.jroller.com/page/mfateev?entry=3Dextending_inversion_of_contro=
l_paradigm
> ".
>=20
> Any feedback is very wellcome.
>=20
> Maxim.
>=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
>=20
>=20


--=20
John D. Heintz
Software Craftsman
Austin, TX
(512) 633-1198

jh...@po...
http://johnheintz.homeip.net

Re: [Springframework-developer] Why no autowiring of properties in ActionSupport?

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

Its certainly possible but we have DelegatingActionProxy which is a lot 
more powerful.

Rob

Steven Devijver wrote:

> Hi,
>
> Why does ActionSupport does not do autowiring of subclass properties?  
> It seems to me this would improve the value-offer of this integration  
> strategy for Struts.
>
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-- 
Rob Harrop
Principal Consultant
Interface21 - Spring Services from the Source
http://www.springframework.com 

[Springframework-developer] Why no autowiring of properties in ActionSupport?

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

Hi,

Why does ActionSupport does not do autowiring of subclass properties?  
It seems to me this would improve the value-offer of this integration  
strategy for Struts.

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

Re: [Springframework-developer] OT: spam with raw language in spanish in Springframework home page

[Dmitriy K. <dko...@ru...>]

Removed. Just curious - what did it say?

Dmitriy.


On Sep 14, 2005, at 1:46 PM, Gustavo Faerman wrote:

> Do not know the appropiate channel but just in case,
> There is a posting in spanish in the www.springframework.org home  
> page that is actually full of #$%&* in spanish. Subject for that  
> posting says : Desprecio Spring.
>
> It better must be removed from there.
>
> Gustavo.
>
>

[Springframework-developer] OT: spam with raw language in spanish in Springframework home page

[Gustavo F. <gfa...@gm...>]

Do not know the appropiate channel but just in case,
There is a posting in spanish in the
www.springframework.org<http://www.springframework.org>home page that
is actually full of #$%&* in spanish. Subject for that
posting says : Desprecio Spring.

It better must be removed from there.

Gustavo.

[Springframework-developer] Re: OT: spam with raw language in spanish in Springframework home page

[Gustavo F. <gfa...@gm...>]

The offending posting is in the support page, sorry about the wrong pointer=
.

On 9/14/05, Gustavo Faerman <gfa...@gm...> wrote:
>=20
> Do not know the appropiate channel but just in case,
> There is a posting in spanish in the www.springframework.org<http://www.s=
pringframework.org>home page that is actually full of #$%&* in spanish. Sub=
ject for that=20
> posting says : Desprecio Spring.
>=20
> It better must be removed from there.
>=20
> Gustavo.
>=20
>=20
>

[Springframework-developer] TESTE PLUGIN VIA TERRA

[flavio\.desiqueira <fla...@te...>]

----------------------------------------------------------------

----------------------------------------------------------------

Flavio de Siqueira
PlugIn Internet Corporativa
Fone: (51) 3287 1741
----------------------------------------------------------------

[Springframework-developer] spring Build Failed

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

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

Re: [Springframework-developer] New JDBC feature - named parameters

[James E. <jam...@gm...>]

http://opensource2.atlassian.com/projects/spring/browse/SPR-303

Hey Thomas, I'm glad to see this getting some traction.  I have a few
questions though.

Will the implementation support pulling the values from a bean (where
the names in the query match property names in the bean)?  The
original argument against was to just use ibatis...but with what you
have it is so close.  I'd probably need to (for the most part) map my
bean to and from a hashmap for the execute calls.

I'm going to be looking at the code soon, but my first reaction to the
auto-expanding list was one of fear.  I'm sure it has been implemented
optimally, but just to voice my fear:  does passing in a list as a
value simply trigger a replacement of that value/marker with a comma
separated list of other markers (?s)?  Or is it one that will replace
the marker with a comma-separated list of the values.  If it is the
former, the hit is not too bad...assuming most use cases are such that
only a set number or combination winds up getting used (like between 3
and 10).  And (in the case of Oracle) only that many statements are
cached and all is well.  But if its the latter (replaced with
comma-separated values) then every single call is unique...and the db=20
(oracle anyway) will die (especially if this call is made frequently)
because the statement cache will constantly be pushing out statements
for these new ones that appear to be unique.

Anyway I hope I'm not insulting you...I'm sure you know this, like I
said, just voicing my initial gut-fear.

Thanks again Thomas,
James

On 9/7/05, Thomas Risberg <tho...@tr...> wrote:
> I added support for named parameters some days ago.  Here is an example: =
  =20
>                                                    =20
>=20
>    public List getPreferredBeer() {
>     Map params =3D new HashMap(2);
>     params.put("unwantedBrand", "Heineken");
>     params.put("maxPrice", new BigDecimal(25.00));
>     List l =3D getJdbcTemplate().queryForList(
>       "select id, price, brand from beers " +
>       "where price < :maxPrice and brand <> :unwantedBrand",
>       params);
>     return l;
>   }
>=20
> I put together a PDF document that highlights additional usage -
> http://www.springdeveloper.com/documents/spring-1_3-jdbc-example.pdf
>=20
> Take a recent snapshot for a spin and let me know if something is missing=
 or
> not working.  I'm still working on adding some additional tests.
>=20
> Thomas
>=20
>

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

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

Colin,=20

Thanks for clarifying this. I'm wondering then what would be my best option=
=20
here then. I have a fair bit of beans that are declared in the config, and=
=20
they all implement some common interfaces, and some slightly different ones=
,=20
so my head already hurts from thinking I need to go through all of them and=
=20
apply the right interfaces, and not to mention making sure they stay in syn=
c=20
with any new changes.

Some ideas I thought - creating my own "fixed" version of ProxyFactoryBean=
=20
that works similiarly to the TransactionProxyFactory behavior. Or this coul=
d=20
be introduced in the spring codebase as an alternative.=20

Or introduce the fixed strategy (along with wrapping prototypes) into=20
ProxyFactoryBean, and make it configurable via an property? So that the=20
default would be the classic approach, and for those who need the newer=20
approach, it could be set.=20

Just throwin out ideas here. I'd like this to be resolved on the spring=20
codebase side - than me plowing through all my configs, and adding=20
interfaces, only as a last resort, if a fix is untenable.

Thanks!

-tim

On 9/13/05, Colin Sampaleanu <col...@ex...> wrote:
>=20
> Personally, I think that makes some sense, but it's quite probably too
> risky to the extent of breaking backwards compatibility. you would have
> some code that is now proxied with ProxyFactoryBean that depends on
> having the class proxied as well (via the cglib proxy) that would no
> longer have the class proxied (if that class implements any interfaces).
>=20
> But it's a bummer that the behavior is different. This probably deserves
> a JavaDoc comment at the minimum.
>=20
> The other thing that has also always bothered me about the difference
> between ProxyFactoryBeand and TransactionProxyFactoryBean is that only
> the former can handle prototypes. There's no good reason for that; you
> do need to wrap prototypes transactionally too.
>=20
> Dmitriy Kopylenko wrote:
>=20
> > The difference is - if you don't specify the iterfaces to proxy, the
> > TransactionProxyFactoryBean will "auto discover" and add all the
> > interfaces implemented by the target class (if "proxyTargetClass"
> > flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy
> > in such a scenario.
> >
> > May be we should change the behavior of TransactionProxyFactoryBean
> > so it's consistent with ProxyFactoryBean in this regard? Juergen,
> > Colin, Rod, what do you think?
> >
> > Dmitriy.
> >
> >
> > On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:
> >
> >> Tim,
> >>
> >> try to add "proxyInterfaces" property to the ProxyFactoryBean
> >> definition:
> >>
> >> <property name=3D"proxyInterfaces">
> >> <list>
> >> <value>com.vivakos.vps.service.Service</value>
> >> <value>com.vivakos.vps.service.content.TopicService</ value>
> >> </list>
> >> </property>
> >>
> >> Regards,
> >> Dmitriy.
> >>
> >>
> >> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
> >>
> >>
> >>>
> >>> 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't get any reply on it. I'm thinking maybe it got lost
> >>> in the
> >>> events over the weekend, so I'm re-posting both emails I sent
> >>> below, in the
> >>> hopes that someone might afford a look at it and point me in the righ=
t
> >>> 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.
> >>>
> >>> 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. 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.
> >>>
> >>> 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
> >>> 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. This is the configuration
> >>> for the
> >>> method interceptor. As you can see, we are applying access control
> >>> on three
> >>> different methods. 'get', 'getTopicList' and 'getTopicChildren'.
> >>>
> >>> <bean id=3D"serviceMethodSecurityInterceptor"
> >>> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecu=
ri
> >>> tyInter
> >>> 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>
> >>>
> >>> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
> >>>
> >>> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFT=
ER
> >>> _ACL_RE
> >>> AD
> >>>
> >>> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC=
_A
> >>> FTER_AC
> >>> L_READ
> >>> </value>
> >>> </property>
> >>> </bean>
> >>>
> >>> And as far as I can see - when using TransactionProxyFactoryBean,
> >>> all three
> >>> methods get applied correctly. i.e. integration tests that test
> >>> the 'get',
> >>> 'getTopicList' and 'getTopicChildren' all work properly.
> >>>
> >>> 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. The only
> >>> differnence
> >>> in how the methods that are tested is that 'get' is defined in an
> >>> higher
> >>> level interface (Service) instead of (TopicService). 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 ORIG=
INAL =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
> >>> -'.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.
> >>>
> >>> 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
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> 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-develope=
r
> >>>
> >>>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> 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 *=20
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.=20
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] No Spring build the last few days

[Alef A. <ale...@in...>]

Since we had troubles with our network over the last few days, there hasn't
been any S[pring build since last Saturday. Everything is fixed now, so we
should be back in busines tonight.

Rgds,
Alef

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

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

Personally, I think that makes some sense, but it's quite probably too 
risky to the extent of breaking backwards compatibility. you would have 
some code that is now proxied with ProxyFactoryBean that depends on 
having the class proxied as well (via the cglib proxy) that would no 
longer have the class proxied (if that class implements any interfaces).

But it's a bummer that the behavior is different. This probably deserves 
a JavaDoc comment at the minimum.

The other thing that has also always bothered me about the difference 
between ProxyFactoryBeand and TransactionProxyFactoryBean is that only 
the former can handle prototypes. There's no good reason for that; you 
do need to wrap prototypes transactionally too.

Dmitriy Kopylenko wrote:

> The difference is - if you don't specify the iterfaces to proxy, the  
> TransactionProxyFactoryBean will "auto discover" and add all the  
> interfaces implemented by the target class (if "proxyTargetClass"  
> flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy  
> in such a scenario.
>
> May be we should change the behavior of TransactionProxyFactoryBean  
> so it's consistent with ProxyFactoryBean in this regard? Juergen,  
> Colin, Rod, what do you think?
>
> Dmitriy.
>
>
> On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:
>
>> Tim,
>>
>> try to add "proxyInterfaces" property to the ProxyFactoryBean  
>> definition:
>>
>> <property name="proxyInterfaces">
>>     <list>
>>             <value>com.vivakos.vps.service.Service</value>
>>             <value>com.vivakos.vps.service.content.TopicService</ value>
>>     </list>
>> </property>
>>
>> Regards,
>> Dmitriy.
>>
>>
>> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
>>
>>
>>>
>>> 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’t get any reply on it.  I’m thinking maybe it got  lost 
>>> in the
>>> events over the weekend, so I’m 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)
>>>
>>>
>>> ====== ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE)  ============
>>> 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.
>>>
>>> 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.  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.
>>>
>>> from this:
>>>
>>>         <property name="postInterceptors">
>>>             <list>
>>>                 <ref bean="serviceMethodSecurityInterceptor"/>
>>>             </list>
>>>         </property>
>>>
>>> to this:
>>>
>>>         <property name="interceptorNames">
>>>             <list>
>>>                 <value>serviceMethodSecurityInterceptor</value>
>>>             </list>
>>>         </property>
>>>
>>> Some of the test cases I have broke after this change.  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.    This is the configuration  
>>> for the
>>> method interceptor.  As you can see, we are applying access  control 
>>> on three
>>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>>
>>>     <bean id="serviceMethodSecurityInterceptor"
>>> class="net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri 
>>> tyInter
>>> ceptor">
>>>         <property name="authenticationManager"><ref
>>> bean="authenticationManager"/></property>
>>>          <property name="accessDecisionManager"><ref
>>> bean="decisionManager"/></property>
>>>         <property name="afterInvocationManager"><ref
>>> bean="afterInvocationManager"/></property>
>>>         <property name="objectDefinitionSource">
>>>             <value>
>>>                  
>>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>>
>>> com.vivakos.vps.service.content.TopicService.getTopicList=TOPIC_AFTER 
>>> _ACL_RE
>>> AD
>>>
>>> com.vivakos.vps.service.content.TopicService.getTopicChildren=TOPIC_A 
>>> FTER_AC
>>> L_READ
>>>             </value>
>>>         </property>
>>>     </bean>
>>>
>>> And as far as I can see - when using TransactionProxyFactoryBean,  
>>> all three
>>> methods get applied correctly.  i.e. integration tests that test  
>>> the 'get',
>>> 'getTopicList' and 'getTopicChildren' all work properly.
>>>
>>> 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.  The only  
>>> differnence
>>> in how the methods that are tested is that 'get' is defined in an  
>>> higher
>>> level interface (Service) instead of (TopicService).  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
>>>
>>> ========= FOLLOW UP EMAIL SENT A DAY AFTER THE ORIGINAL ==========
>>>
>>> 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
>>>    -'.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.
>>>
>>> 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=TOPIC_AFTER_ACL_READ
>>>
>>> to
>>>
>>> com.vivakos.vps.service.content.Topic.get=TOPIC_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
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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] More Fun with Validation

[Jae G. <ja...@gn...>]

  i could definately use the regex type functionality now. 

  would you be able to post the code for the RegExVistor (or even better,
could it be checked directly into the sandbox?)

--
-jae

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
ty...@me...
Sent: Tuesday, September 13, 2005 4:35 PM
To: spr...@li...
Subject: Re: [Springframework-developer] More Fun with Validation

Hi again Steven,

One other thing that we just worked on in our sandbox was a simple Regular
Expression  Function for using the ValangVisitor interface. Now we can use
this to handle all kinds of difference scenarios
(phone/email/creditcard/ssn/etc).  I have included an example of how we are
wiring it up, for anyone who is interested.  I know know there was talk
about something similar the other day.

Let me know if you think this would be useful for Valang.  Or if there would
be better way to implement this.

Thanks,
   Tyler

<bean id="visitorValidator"
class="org.springmodules.validation.ValangValidatorFactoryBean">
<property name="valang">
	<value><![CDATA[
			{ phoneNumber : isPhoneNumber(?) == TRUE : 'Invalid
Phone Number. Must be in format (###)###-####' }
				{ email : isEmail(?) == TRUE : 'Invalid
E-mail Address.  Must be in format a@b.c' }
		      ]]>
</value>
</property>

<!-- Here, we inject necessary properties to create the Function -->
<property name="visitor">
		<bean class="org.springmodules.validation.RegExVisitor">
		<property
name="regExPatternString"><value>\(\d{3}\)\d{3}-\d{4}</value></property>
		<property
name="functionName"><value>isPhoneNumber</value></property>
		<property name="visitor">
			<bean
class="org.govgrnds.core.validation.valang.RegExVisitor">
				<property name="regExPatternString">
<value>"(\w+)@(\w+\.)(\w+)(\.\w+)*</value>
</property>
				<property name="functionName">
<value>isEmail</value>
</property>
			</bean>
		</property>
		</bean>
      </property>
</bean>


> Hi Steven,
>    ValidatingSupport does support my needs quite well. I was moreso 
> talking about the interceptors that are in the 
> "org.springmodules.orm.support.validation" package. Also 
> ValidatingSupport really be under the org.springmodules.orm package 
> when it is not orm specfic. I guess I'm being a little picky :)
>
> I have attached my code, like I said its not perfect and took we about 
> a whole 10 minutes to do. But it is working for us right now pretty
nicely.
>
> Also we are setting basic validation funcations for standard 
> validations like phonenumber, email, etc. Are there standard 
> validation functions like these for Valang already?
>
> /*
>  * Copyright 2004-2005 the original author or authors.
>  *
>  * Licensed under the Apache License, Version 2.0 (the "License");
>  * you may not use this file except in compliance with the License.
>  * You may obtain a copy of the License at
>  *
>  *      http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
> implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.springmodules.orm.support.validation;
>
> import org.aopalliance.intercept.MethodInterceptor;
> import org.aopalliance.intercept.MethodInvocation;
> import org.apache.commons.logging.Log; import 
> org.apache.commons.logging.LogFactory;
> import org.springframework.beans.factory.InitializingBean;
> import org.springmodules.orm.support.validation.ValidatingSupport;
>
>
> /**
>  * <p>
>  *  Interceptor Process different validations on method invocations,
>  * uses springmodules
>  *  ValidatingSupport to validate any method from any bean and not 
> just
>  * ORM beans like in the  HibernateIntercepter examples.
>  * </p>
>  *
>  * <p>
>  * Combination of springmodules and acegisecurity's
>  *   validationexamples. Took the pieces we needed  and
>  *  glued them together
>  * </p>
>  *
>  *
>  *
>  *  @author Tyler Nelson
>  *  @see org.springmodules.orm.support.validation.ValidatingSupport
>  *
>  */
> public class ValidatingInterceptor extends ValidatingSupport 
> implements MethodInterceptor,  InitializingBean {
>
>    protected final Log log = LogFactory.getLog(getClass());
>
>    private Class[] argumentClasses;
>
>    public void afterPropertiesSet() throws Exception {
>
>    }
>
>    /**
> 	 * <p>This method binds and unbinds the validator maps
>          * configured in the validators
> 	 * property.
> 	 *
> 	 * @param methodInvocation the method invocation
> 	 * @return the result of the method invocation
> 	 */
> 	public Object invoke(MethodInvocation mi) throws Throwable {
>
> 		try {
> 			bindValidators();
>
> 			Object[] args = mi.getArguments();
>
> 	        for (int i = 0; i < args.length; i++) {
> 	            if (isValidatable(args[i])) {
> 	                if (log.isDebugEnabled()) {
> 	                    log.debug("Validatingnterceptor calling "
>         + "for: '"  + args[i] + "'");
> 	                }
> 	                ValidatingSupport.validate(args[i],
> mi.getMethod().getName());
> 	            }
> 	        }
>
>
> 			return mi.proceed();
> 		}
> 		finally {
> 			unbindValidators();
> 		}
>
> 	}
>
> 	/**
> 	 * @return Returns the argumentClasses.
> 	 */
> 	public Class[] getArgumentClasses() {
> 	    return argumentClasses;
> 	}
> 	/**
> 	 * @param argumentClasses The argumentClasses to set.
> 	 */
> 	public void setArgumentClasses(Class[] argumentClasses) {
> 	    this.argumentClasses = argumentClasses;
> 	}
> 	/**
> 	 * Determines if an attribute needs to be validated
> 	 *
> 	 * @param argument
> 	 * @return
> 	 */
> 	private boolean isValidatable(Object argument) {
> 	    // if argumentClasses is null or empty advise all arguments
> 	    if(argumentClasses == null || argumentClasses.length < 1){
> 	        return true;
> 	    }
>
>         if (argument == null) {
>             return false;
>         }
>
>         for (int i = 0; i < argumentClasses.length; i++) {
>             if 
> (argumentClasses[i].isAssignableFrom(argument.getClass()))
> {
>                 return true;
>             }
>         }
>
>         return false;
>     }
> }
>
>
>
>> Tyler,
>>
>> What kind of validation do you want to do? Obviously 
>> ValidatingSupport can be reused in other scenario's than just 
>> persistence. The event mechanism should be sufficiently powerful to 
>> leverage it in other place. Could you please provide some code 
>> example of the integration with Acegi?
>>
>> Thanks
>>
>> Steven Devijver
>> Senior consultant
>> @ Interface21
>> ste...@in...
>>
>>
>>
>> On 13 Sep 2005, at 17:16, ty...@me... wrote:
>>
>>> Hi,
>>>   With all this talk about Validation made me want to speak up. I am 
>>> currently using Valang validation which works great. However I 
>>> wanted a way to trigger the validation on different layers of our 
>>> application. I was thinking of injecting a map of Validator object 
>>> into a method interceptor. Then I found ValidatingInterceptor and 
>>> ValidatingSupport in SpringModules, which does this already. However 
>>> it seems to be very ORM specific where it doesn't need to be.
>>>
>>> To make it more generic, I combined it with a ValidationInterceptor 
>>> that Ben Alex had in the Acegi Domain project. Like the Acegi 
>>> version I included a way to filter out objects on the interceptor 
>>> level.
>>> However it
>>> seems a little redundant right now since ValidatingSupport figures 
>>> out via the map keys. I see real value in adding something like this 
>>> interceptor to Spring Modules. Does anyone have any interest in 
>>> using it?
>>>
>>> Thanks,
>>>      Tyler
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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-develop
>>> er
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> 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-develope
>> r
>>
>
>
>
> -------------------------------------------------------
> 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:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] More Fun with Validation

[<ty...@me...>]

Hi again Steven,

One other thing that we just worked on in our sandbox was a simple Regula=
r
Expression  Function for using the ValangVisitor interface. Now we can us=
e
this to handle all kinds of difference scenarios
(phone/email/creditcard/ssn/etc).  I have included an example of how we
are wiring it up, for anyone who is interested.  I know know there was
talk about something similar the other day.

Let me know if you think this would be useful for Valang.  Or if there
would be better way to implement this.

Thanks,
   Tyler

<bean id=3D"visitorValidator"
class=3D"org.springmodules.validation.ValangValidatorFactoryBean">
<property name=3D"valang">
	<value><![CDATA[
			{ phoneNumber : isPhoneNumber(?) =3D=3D TRUE : 'Invalid Phone Number. =
Must
be in format (###)###-####' }
				{ email : isEmail(?) =3D=3D TRUE : 'Invalid E-mail Address.  Must be =
in
format a@b.c' }
		      ]]>
</value>
</property>

<!-- Here, we inject necessary properties to create the Function -->
<property name=3D"visitor">
		<bean class=3D"org.springmodules.validation.RegExVisitor">
		<property
name=3D"regExPatternString"><value>\(\d{3}\)\d{3}-\d{4}</value></property=
>
		<property name=3D"functionName"><value>isPhoneNumber</value></property>
		<property name=3D"visitor">
			<bean class=3D"org.govgrnds.core.validation.valang.RegExVisitor">
				<property name=3D"regExPatternString">
<value>"(\w+)@(\w+\.)(\w+)(\.\w+)*</value>
</property>
				<property name=3D"functionName">
<value>isEmail</value>
</property>
			</bean>
		</property>
		</bean>
      </property>
</bean>


> Hi Steven,
>    ValidatingSupport does support my needs quite well. I was moreso
> talking about the interceptors that are in the
> "org.springmodules.orm.support.validation" package. Also
> ValidatingSupport really be under the org.springmodules.orm package
> when it is not orm specfic. I guess I'm being a little picky :)
>
> I have attached my code, like I said its not perfect and took we about =
a
> whole 10 minutes to do. But it is working for us right now pretty nicel=
y.
>
> Also we are setting basic validation funcations for standard validation=
s
> like phonenumber, email, etc. Are there standard validation functions l=
ike
> these for Valang already?
>
> /*
>  * Copyright 2004-2005 the original author or authors.
>  *
>  * Licensed under the Apache License, Version 2.0 (the "License");
>  * you may not use this file except in compliance with the License.
>  * You may obtain a copy of the License at
>  *
>  *      http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.springmodules.orm.support.validation;
>
> import org.aopalliance.intercept.MethodInterceptor;
> import org.aopalliance.intercept.MethodInvocation;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> import org.springframework.beans.factory.InitializingBean;
> import org.springmodules.orm.support.validation.ValidatingSupport;
>
>
> /**
>  * <p>
>  *  Interceptor Process different validations on method invocations,
>  * uses springmodules
>  *  ValidatingSupport to validate any method from any bean and not just
>  * ORM beans like in the  HibernateIntercepter examples.
>  * </p>
>  *
>  * <p>
>  * Combination of springmodules and acegisecurity's
>  *   validationexamples. Took the pieces we needed  and
>  *  glued them together
>  * </p>
>  *
>  *
>  *
>  *  @author Tyler Nelson
>  *  @see org.springmodules.orm.support.validation.ValidatingSupport
>  *
>  */
> public class ValidatingInterceptor extends ValidatingSupport implements
> MethodInterceptor,  InitializingBean {
>
>    protected final Log log =3D LogFactory.getLog(getClass());
>
>    private Class[] argumentClasses;
>
>    public void afterPropertiesSet() throws Exception {
>
>    }
>
>    /**
> 	 * <p>This method binds and unbinds the validator maps
>          * configured in the validators
> 	 * property.
> 	 *
> 	 * @param methodInvocation the method invocation
> 	 * @return the result of the method invocation
> 	 */
> 	public Object invoke(MethodInvocation mi) throws Throwable {
>
> 		try {
> 			bindValidators();
>
> 			Object[] args =3D mi.getArguments();
>
> 	        for (int i =3D 0; i < args.length; i++) {
> 	            if (isValidatable(args[i])) {
> 	                if (log.isDebugEnabled()) {
> 	                    log.debug("Validatingnterceptor calling "
>         + "for: '"  + args[i] + "'");
> 	                }
> 	                ValidatingSupport.validate(args[i],
> mi.getMethod().getName());
> 	            }
> 	        }
>
>
> 			return mi.proceed();
> 		}
> 		finally {
> 			unbindValidators();
> 		}
>
> 	}
>
> 	/**
> 	 * @return Returns the argumentClasses.
> 	 */
> 	public Class[] getArgumentClasses() {
> 	    return argumentClasses;
> 	}
> 	/**
> 	 * @param argumentClasses The argumentClasses to set.
> 	 */
> 	public void setArgumentClasses(Class[] argumentClasses) {
> 	    this.argumentClasses =3D argumentClasses;
> 	}
> 	/**
> 	 * Determines if an attribute needs to be validated
> 	 *
> 	 * @param argument
> 	 * @return
> 	 */
> 	private boolean isValidatable(Object argument) {
> 	    // if argumentClasses is null or empty advise all arguments
> 	    if(argumentClasses =3D=3D null || argumentClasses.length < 1){
> 	        return true;
> 	    }
>
>         if (argument =3D=3D null) {
>             return false;
>         }
>
>         for (int i =3D 0; i < argumentClasses.length; i++) {
>             if (argumentClasses[i].isAssignableFrom(argument.getClass()=
))
> {
>                 return true;
>             }
>         }
>
>         return false;
>     }
> }
>
>
>
>> Tyler,
>>
>> What kind of validation do you want to do? Obviously
>> ValidatingSupport can be reused in other scenario's than just
>> persistence. The event mechanism should be sufficiently powerful to
>> leverage it in other place. Could you please provide some code
>> example of the integration with Acegi?
>>
>> Thanks
>>
>> Steven Devijver
>> Senior consultant
>> @ Interface21
>> ste...@in...
>>
>>
>>
>> On 13 Sep 2005, at 17:16, ty...@me... wrote:
>>
>>> Hi,
>>>   With all this talk about Validation made me want to speak up. I am
>>> currently using Valang validation which works great. However I
>>> wanted a
>>> way to trigger the validation on different layers of our
>>> application. I
>>> was thinking of injecting a map of Validator object into a method
>>> interceptor. Then I found ValidatingInterceptor and
>>> ValidatingSupport in
>>> SpringModules, which does this already. However it seems to be very
>>> ORM
>>> specific where it doesn=92t need to be.
>>>
>>> To make it more generic, I combined it with a ValidationInterceptor
>>> that
>>> Ben Alex had in the Acegi Domain project. Like the Acegi version I
>>> included a way to filter out objects on the interceptor level.
>>> However it
>>> seems a little redundant right now since ValidatingSupport figures
>>> out via
>>> the map keys. I see real value in adding something like this
>>> interceptor
>>> to Spring Modules. Does anyone have any interest in using it?
>>>
>>> Thanks,
>>>      Tyler
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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-develope=
r
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> 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/bsce5=
sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] More Fun with Validation

[<ty...@me...>]

Hi Steven,
   ValidatingSupport does support my needs quite well. I was moreso
talking about the interceptors that are in the
"org.springmodules.orm.support.validation" package. Also
ValidatingSupport really be under the org.springmodules.orm package
when it is not orm specfic. I guess I'm being a little picky :)

I have attached my code, like I said its not perfect and took we about a
whole 10 minutes to do. But it is working for us right now pretty nicely.

Also we are setting basic validation funcations for standard validations
like phonenumber, email, etc. Are there standard validation functions lik=
e
these for Valang already?

/*
 * Copyright 2004-2005 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implie=
d.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.springmodules.orm.support.validation;

import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.beans.factory.InitializingBean;
import org.springmodules.orm.support.validation.ValidatingSupport;


/**
 * <p>
 *  Interceptor Process different validations on method invocations,
 * uses springmodules
 *  ValidatingSupport to validate any method from any bean and not just
 * ORM beans like in the  HibernateIntercepter examples.
 * </p>
 *
 * <p>
 * Combination of springmodules and acegisecurity's
 *   validationexamples. Took the pieces we needed  and
 *  glued them together
 * </p>
 *
 *
 *
 *  @author Tyler Nelson
 *  @see org.springmodules.orm.support.validation.ValidatingSupport
 *
 */
public class ValidatingInterceptor extends ValidatingSupport implements
MethodInterceptor,  InitializingBean {

   protected final Log log =3D LogFactory.getLog(getClass());

   private Class[] argumentClasses;

   public void afterPropertiesSet() throws Exception {

   }

   /**
	 * <p>This method binds and unbinds the validator maps
         * configured in the validators
	 * property.
	 *
	 * @param methodInvocation the method invocation
	 * @return the result of the method invocation
	 */
	public Object invoke(MethodInvocation mi) throws Throwable {

		try {
			bindValidators();

			Object[] args =3D mi.getArguments();

	        for (int i =3D 0; i < args.length; i++) {
	            if (isValidatable(args[i])) {
	                if (log.isDebugEnabled()) {
	                    log.debug("Validatingnterceptor calling "
        + "for: '"  + args[i] + "'");
	                }
	                ValidatingSupport.validate(args[i],
mi.getMethod().getName());
	            }
	        }


			return mi.proceed();
		}
		finally {
			unbindValidators();
		}

	}

	/**
	 * @return Returns the argumentClasses.
	 */
	public Class[] getArgumentClasses() {
	    return argumentClasses;
	}
	/**
	 * @param argumentClasses The argumentClasses to set.
	 */
	public void setArgumentClasses(Class[] argumentClasses) {
	    this.argumentClasses =3D argumentClasses;
	}
	/**
	 * Determines if an attribute needs to be validated
	 *
	 * @param argument
	 * @return
	 */
	private boolean isValidatable(Object argument) {
	    // if argumentClasses is null or empty advise all arguments
	    if(argumentClasses =3D=3D null || argumentClasses.length < 1){
	        return true;
	    }

        if (argument =3D=3D null) {
            return false;
        }

        for (int i =3D 0; i < argumentClasses.length; i++) {
            if (argumentClasses[i].isAssignableFrom(argument.getClass()))=
 {
                return true;
            }
        }

        return false;
    }
}



> Tyler,
>
> What kind of validation do you want to do? Obviously
> ValidatingSupport can be reused in other scenario's than just
> persistence. The event mechanism should be sufficiently powerful to
> leverage it in other place. Could you please provide some code
> example of the integration with Acegi?
>
> Thanks
>
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>
>
>
> On 13 Sep 2005, at 17:16, ty...@me... wrote:
>
>> Hi,
>>   With all this talk about Validation made me want to speak up. I am
>> currently using Valang validation which works great. However I
>> wanted a
>> way to trigger the validation on different layers of our
>> application. I
>> was thinking of injecting a map of Validator object into a method
>> interceptor. Then I found ValidatingInterceptor and
>> ValidatingSupport in
>> SpringModules, which does this already. However it seems to be very
>> ORM
>> specific where it doesn=92t need to be.
>>
>> To make it more generic, I combined it with a ValidationInterceptor
>> that
>> Ben Alex had in the Acegi Domain project. Like the Acegi version I
>> included a way to filter out objects on the interceptor level.
>> However it
>> seems a little redundant right now since ValidatingSupport figures
>> out via
>> the map keys. I see real value in adding something like this
>> interceptor
>> to Spring Modules. Does anyone have any interest in using it?
>>
>> Thanks,
>>      Tyler
>>
>>
>>
>> -------------------------------------------------------
>> 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/bsce5=
sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] More Fun with Validation

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

Tyler,

What kind of validation do you want to do? Obviously =20
ValidatingSupport can be reused in other scenario's than just =20
persistence. The event mechanism should be sufficiently powerful to =20
leverage it in other place. Could you please provide some code =20
example of the integration with Acegi?

Thanks

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



On 13 Sep 2005, at 17:16, ty...@me... wrote:

> Hi,
>   With all this talk about Validation made me want to speak up. I am
> currently using Valang validation which works great. However I =20
> wanted a
> way to trigger the validation on different layers of our =20
> application. I
> was thinking of injecting a map of Validator object into a method
> interceptor. Then I found ValidatingInterceptor and =20
> ValidatingSupport in
> SpringModules, which does this already. However it seems to be very =20=

> ORM
> specific where it doesn=92t need to be.
>
> To make it more generic, I combined it with a ValidationInterceptor =20=

> that
> Ben Alex had in the Acegi Domain project. Like the Acegi version I
> included a way to filter out objects on the interceptor level. =20
> However it
> seems a little redundant right now since ValidatingSupport figures =20
> out via
> the map keys. I see real value in adding something like this =20
> interceptor
> to Spring Modules. Does anyone have any interest in using it?
>
> Thanks,
>      Tyler
>
>
>
> -------------------------------------------------------
> 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] More Fun with Validation

[<ty...@me...>]

Hi,
  With all this talk about Validation made me want to speak up. I am
currently using Valang validation which works great. However I wanted a
way to trigger the validation on different layers of our application. I
was thinking of injecting a map of Validator object into a method
interceptor. Then I found ValidatingInterceptor and ValidatingSupport in
SpringModules, which does this already. However it seems to be very ORM
specific where it doesn=92t need to be.

To make it more generic, I combined it with a ValidationInterceptor that
Ben Alex had in the Acegi Domain project. Like the Acegi version I
included a way to filter out objects on the interceptor level. However it
seems a little redundant right now since ValidatingSupport figures out vi=
a
the map keys. I see real value in adding something like this interceptor
to Spring Modules. Does anyone have any interest in using it?

Thanks,
     Tyler

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

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

Dmitriy,

Thanks for writing in.  The funny thing was that I actually had been using
the proxyInterfaces before, but after reviewing the javadocs, I had
determined that I didn't need to use this property because the javadocs
seemed to imply that the interfaces would be visible on their own, and that
using 'proxyInterfaces' was only necessary if you wanted to expose certain
interfaces but not others.  Am I mistaken?  

I was hoping to avoid having to use 'proxyInterfaces' because it increased
the verbosity of the xml files, since we have a fair bit of beans we are
proxying, and they all implement slightly different interfaces as well as an
common interface. 

But if indeed declaring 'proxyInterfaces' property is the "right way" to do
this, I will go and add it to all the bean definitions, but it seems
needlessly verbose to me, since TransactionProxyFactoryBean seems perfectly
capable of discovering all relevant interfaces on its own?

If I'm missing something here, please do let me know.

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Dmitriy Kopylenko
Sent: Monday, September 12, 2005 9:12 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Trying again. Difference in advised
behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

The difference is - if you don't specify the iterfaces to proxy, the  
TransactionProxyFactoryBean will "auto discover" and add all the  
interfaces implemented by the target class (if "proxyTargetClass"  
flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy  
in such a scenario.

May be we should change the behavior of TransactionProxyFactoryBean  
so it's consistent with ProxyFactoryBean in this regard? Juergen,  
Colin, Rod, what do you think?

Dmitriy.


On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:

> Tim,
>
> try to add "proxyInterfaces" property to the ProxyFactoryBean  
> definition:
>
> <property name="proxyInterfaces">
>     <list>
>             <value>com.vivakos.vps.service.Service</value>
>             <value>com.vivakos.vps.service.content.TopicService</ 
> value>
>     </list>
> </property>
>
> Regards,
> Dmitriy.
>
>
> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
>
>
>>
>> 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't get any reply on it.  I'm thinking maybe it got  
>> lost in the
>> events over the weekend, so I'm 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)
>>
>>
>> ====== ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE)  
>> ============
>> 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.
>>
>> 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.  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.
>>
>> from this:
>>
>>         <property name="postInterceptors">
>>             <list>
>>                 <ref bean="serviceMethodSecurityInterceptor"/>
>>             </list>
>>         </property>
>>
>> to this:
>>
>>         <property name="interceptorNames">
>>             <list>
>>                 <value>serviceMethodSecurityInterceptor</value>
>>             </list>
>>         </property>
>>
>> Some of the test cases I have broke after this change.  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.    This is the configuration  
>> for the
>> method interceptor.  As you can see, we are applying access  
>> control on three
>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>
>>     <bean id="serviceMethodSecurityInterceptor"
>> class="net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri 
>> tyInter
>> ceptor">
>>         <property name="authenticationManager"><ref
>> bean="authenticationManager"/></property>
>>          <property name="accessDecisionManager"><ref
>> bean="decisionManager"/></property>
>>         <property name="afterInvocationManager"><ref
>> bean="afterInvocationManager"/></property>
>>         <property name="objectDefinitionSource">
>>             <value>
>>                  
>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>
>> com.vivakos.vps.service.content.TopicService.getTopicList=TOPIC_AFTER 
>> _ACL_RE
>> AD
>>
>> com.vivakos.vps.service.content.TopicService.getTopicChildren=TOPIC_A 
>> FTER_AC
>> L_READ
>>             </value>
>>         </property>
>>     </bean>
>>
>> And as far as I can see - when using TransactionProxyFactoryBean,  
>> all three
>> methods get applied correctly.  i.e. integration tests that test  
>> the 'get',
>> 'getTopicList' and 'getTopicChildren' all work properly.
>>
>> 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.  The only  
>> differnence
>> in how the methods that are tested is that 'get' is defined in an  
>> higher
>> level interface (Service) instead of (TopicService).  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
>>
>> ========= FOLLOW UP EMAIL SENT A DAY AFTER THE ORIGINAL ==========
>>
>> 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
>>    -'.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.
>>
>> 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=TOPIC_AFTER_ACL_READ
>>
>> to
>>
>> com.vivakos.vps.service.content.Topic.get=TOPIC_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
>>
>>
>>
>> -------------------------------------------------------
>> 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

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

I wasn't familiar with Valang. It make sense to keep this in line with thei=
r=20
rule definitions. Are they checking the validity of the rules at run-time,=
=20
when the application context loads?=20

On 9/13/05, Oliver Hutchison <Ol...@ou...> wrote:
>=20
>=20
>=20
> > Basically we could do something like this:
> >
> >
> > public @interface Validate {
> > String constraint();
> > String code();
> > String message();
> > String[] arguments();
> > }
>=20
> I personally think it would be nicer to implement the annotation in a
> way that is consistent with the rule definitions used by
> ValangValidatorFactoryBean:
>=20
> public @interface Validate {
> String valang();
> }
>=20
> public class MyClass {
>=20
> @Validate("? not blank : 'First name should not be blank' :
> 'firstName_blank'")
> public String getFirstName() { return this.firstName; }
>=20
> Also how would you deal with validating nested objects? For instance,
> when editing contact details, our website will present the user with a
> list of states and also with the option of entering in an alternative
> state not in the list using a text field. Usually we bind directly onto
> our domain object but because we have introduced an additional field I
> create a form object that provides an accessor for the domain object and
> for the additional field and then bind what I can directly to the domain
> object and the additional fields onto the form object:
>=20
> class ContactForm {
> Contact contact;
> String otherState;
>=20
> // where possible bind directly to this domain object
> getContact() { return contact;}
>=20
> @Validate("? is not blank && contact.state is not blank :
> 'Please select or enter a state but not both')
> String getOtherState() { return otherState; }
> void setOtherState(String otherState) {this.otherState =3D
> otherState; }
> }
>=20
> How would you tell the annotation driven validator that it must also
> validate the Contact object? Would we need an additional annotation?
>=20
> public @interface ValidateNested {
> }
>=20
> class ContactForm {
> Contact contact;
> String otherState;
>=20
> @ValidateNested
> getContact() { return contact;}
> ...
>=20
>=20
> Ollie
>=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] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Dmitriy K. <dko...@ru...>]

The difference is - if you don't specify the iterfaces to proxy, the =20
TransactionProxyFactoryBean will "auto discover" and add all the =20
interfaces implemented by the target class (if "proxyTargetClass" =20
flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy =20=

in such a scenario.

May be we should change the behavior of TransactionProxyFactoryBean =20
so it's consistent with ProxyFactoryBean in this regard? Juergen, =20
Colin, Rod, what do you think?

Dmitriy.


On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:

> Tim,
>
> try to add "proxyInterfaces" property to the ProxyFactoryBean =20
> definition:
>
> <property name=3D"proxyInterfaces">
>     <list>
>             <value>com.vivakos.vps.service.Service</value>
>             <value>com.vivakos.vps.service.content.TopicService</=20
> value>
>     </list>
> </property>
>
> Regards,
> Dmitriy.
>
>
> On Sep 12, 2005, at 5:10 PM, 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 =20=

>> lost 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 =20
>> 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) =
=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> I'm running into some rather unusual behavior that I cannot =20
>> explain - 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 =20
>> to a higher
>> abstraction layer, I changed the object wrapper from
>> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted =20
>> to 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 =20
>> control on three
>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>
>>     <bean id=3D"serviceMethodSecurityInterceptor"
>> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri=
=20
>> tyInter
>> 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_A=
=20
>> FTER_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 =20
>> one 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 =20
>> with 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-=20
>> developer
>>
>>
>
>
>
> -------------------------------------------------------
> 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
>

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

[Dmitriy K. <dko...@ru...>]

Tim,

try to add "proxyInterfaces" property to the ProxyFactoryBean =20
definition:

<property name=3D"proxyInterfaces">
     <list>
             <value>com.vivakos.vps.service.Service</value>
             <value>com.vivakos.vps.service.content.TopicService</value>
     </list>
</property>

Regards,
Dmitriy.


On Sep 12, 2005, at 5:10 PM, 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
>

RE: [Springframework-developer] Spring MVC and validation

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

=20

> Basically we could do something like this:
>=20
>=20
> public @interface Validate {
>      String constraint();
>      String code();
>      String message();
>      String[] arguments();
> }

I personally think it would be nicer to implement the annotation in a
way that is consistent with the rule definitions used by
ValangValidatorFactoryBean:

public @interface Validate {
      String valang();
}

public class MyClass {

     @Validate("? not blank : 'First name should not be blank' :
'firstName_blank'")
     public String getFirstName() { return this.firstName; }

Also how would you deal with validating nested objects? For instance,
when editing contact details, our website will present the user with a
list of states and also with the option of entering in an alternative
state not in the list using a text field. Usually we bind directly onto
our domain object but because we have introduced an additional field I
create a form object that provides an accessor for the domain object and
for the additional field and then bind what I can directly to the domain
object and the additional fields onto the form object:

class ContactForm {
	Contact contact;
	String otherState;

	// where possible bind directly to this domain object
	getContact() { return contact;}=20

	@Validate("? is not blank && contact.state is not blank :
'Please select or enter a state but not both')
	String getOtherState() { return otherState; }
	void setOtherState(String otherState) {this.otherState =3D
otherState; }=09
}

How would you tell the annotation driven validator that it must also
validate the Contact object? Would we need an additional annotation?

public @interface ValidateNested {
}

class ContactForm {
	Contact contact;
	String otherState;

	@ValidateNested
	getContact() { return contact;}=20
...


Ollie