springframework-developer

RE: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

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

I think it's a good idea to decouple the handlermappings from the
interceptors. I don't think it's such a huge refactoring. Juergen, could
you shed your light on the following:

- refactoring of AbstractHandlerMapping into AbstractMapping, factoring
out functionality used for both AbstractHandlerMapping and
AbstractInterceptorMapping
- subclass of AbstractMapping: AbstractUrlMapping, responsible for URL
related stuff (including PathHelper)
- subclasses: AbstractUrlInterceptorMapping and
AbstractUrlHandlerMapping

From there on the old hierarchy for handler mappings can continue,
interceptor structure could be the same. We don't really need to change
anything to the HandlerExecutionChain AFAIK.

Opinions?

Alef



> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Seth Ladd
> Sent: Saturday, June 19, 2004 5:16 AM
> To: spr...@li...
> Subject: [Springframework-developer] Proposal for Handler/Interceptor
> Enhancement
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello,
>=20
> I've been using the Handler/Interceptor feature of Spring MVC and I
> really like it.  I'd like to propose an enhancement to it that I think
> will make it more flexible and easier to configure in the
*-servlet.xml
> file.
>=20
> Right now, you must specify a new HandlerMapping class when you want
to
> create different combinations of Interceptors.I'd like to propose that
> Interceptor -> Handler binding is done more like Filters and outside
of
> the HandlerMapping class.
>=20
> One solution would be an InterceptorMapping class, which is configured
> like a HandlerMapping class.  It could contain a map of URIs to
> interceptors.  This InterceptorMapping class would be given to the
> HandlerMapping class.  The HandlerMapping class then calls something
> like interceptorMapping.findInterceptors(servletRequest) when it's
ready
> to build a HandlerExecutionChain.
>=20
> This would allow for all Handlers to use BeanNameHandlerMapping (or a
> single HandlerMapping), but be configured with different Interceptors.
> The binding of which Interceptor to be applied to which Handler is now
> not part of the HandlerMapping.  This cuts down on the number of
> HandlerMappings to specify and configure, especially in
high-Interceptor
> usage scenarios.
>=20
> Thoughts?  Comments?  If this is unclear, please let me know.  Also,
if
> there's a better way to do this with existing code, then even better.
:)
>=20
> Mahalo!
> Seth
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iD8DBQFA06veKZsFSwtW+wIRAm+/AJ4hW4eVNWZgoZfe0Mk/WaBzhzZgXACfV1zP
> O5hGTiOJRmxYO+mfntWlHOE=3D
> =3D0RPV
> -----END PGP SIGNATURE-----
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco,
CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code
NWMGYKND
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

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

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

Alef Arendsen wrote:

| I think it's a good idea to decouple the handlermappings from the
| interceptors. I don't think it's such a huge refactoring. Juergen, could
| you shed your light on the following:
|
| - refactoring of AbstractHandlerMapping into AbstractMapping, factoring
| out functionality used for both AbstractHandlerMapping and
| AbstractInterceptorMapping
| - subclass of AbstractMapping: AbstractUrlMapping, responsible for URL
| related stuff (including PathHelper)
| - subclasses: AbstractUrlInterceptorMapping and
| AbstractUrlHandlerMapping
|
| From there on the old hierarchy for handler mappings can continue,
| interceptor structure could be the same. We don't really need to change
| anything to the HandlerExecutionChain AFAIK.
|
| Opinions?

The more I think about this, the more I think it will be useful.  For
instance, I'd like to have the OpenSessionInViewInterceptor to apply to
everything (/*) where other Interceptors apply to certain Controllers.
I'm starting to get a proliferation of UrlHandlerMapping objects just to
map different combinations of Interceptors.

Jurgen, any more thoughts on this?  I might even implement this one soon
because it will greatly simplify things.

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

iD8DBQFA2OseKZsFSwtW+wIRAm96AJ48uc9AfJ1AO6KTA7hx0OIy+IA/HQCggVpG
Qvwdm8Kqp0iITFuRY6bOW6Q=
=RNla
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

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

> The more I think about this, the more I think it will be useful.  For
> instance, I'd like to have the OpenSessionInViewInterceptor to apply to
> everything (/*) where other Interceptors apply to certain Controllers.
> I'm starting to get a proliferation of UrlHandlerMapping objects just to
> map different combinations of Interceptors.
>
> Jurgen, any more thoughts on this?  I might even implement this one soon
> because it will greatly simplify things.

I think the proposal sounds good. I think the point about 2 types of
interceptors is valid.

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

[Tim C. <tc...@ta...>]

I recently had a discussion about this with a friend as I ran into the 
same exact need.
I think the idea of having a separate Interceptor mapping would be a 
good idea but at the same time it would mean alot more duplication.
 From what it sounds like it would be similar to using a 
PropertiesMethodNameResolver.
 From the PetClinic example you see:

    <!--
      - This bean is a MethodNameResolver definition for a 
MultiActionController.
      - It maps URLs to methods for the "clinicController" bean.
      -->
    <bean id="clinicControllerResolver" 
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameResolver">
        <property name="mappings">
        <props>
            <prop key="/welcome.htm">welcomeHandler</prop>
            <prop key="/vets.htm">vetsHandler</prop>
            <prop key="/owner.htm">ownerHandler</prop>
        </props>
        </property>
    </bean>

But yet those same urls are now duplicated in the UrlHandlerMapping:

    <!--
     - This bean is an explicit URL mapper that is used by the 
"petclinic" DispatcherServlet
     - It is used instead of the default BeanNameUrlHandlerMapping.
     -->
    <bean id="urlMapping" 
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="mappings">
            <props>
                <prop key="/welcome.htm">clinicController</prop>
                <prop key="/vets.htm">clinicController</prop>
                <prop key="/owner.htm">clinicController</prop>
                <prop key="/findOwners.htm">findOwnersForm</prop>
                <prop key="/editOwner.htm">editOwnerForm</prop>
                <prop key="/addOwner.htm">addOwnerForm</prop>
                <prop key="/addVisit.htm">addVisitForm</prop>
                <prop key="/addPet.htm">addPetForm</prop>
                <prop key="/editPet.htm">editPetForm</prop>
            </props>
        </property>
    </bean>

In the example of a complex application that might have many 
URLs/Interceptor combinations you are not really going to make things 
any less complicated as you will end up having a huge amout of these. I 
wonder if an alternative approach would be to be able to attach 
interceptors directly to controllers:

    <bean id="clinicControllerResolver" 
class="org.springframework.web.servlet.mvc.multiaction.PropertiesMethodNameResolver">
        <property name="interceptors">
            <list>
                <ref bean="signonInterceptor"/>
            </list>
        </property>
        <property name="mappings">
        <props>
            <prop key="/welcome.htm">welcomeHandler</prop>
            <prop key="/vets.htm">vetsHandler</prop>
            <prop key="/owner.htm">ownerHandler</prop>
        </props>
        </property>
    </bean>

    In this way it would be very similar to the SpringAOP concept and 
removes having to find/replace all on a changed/removed URL.
It is also very easy for a maintainer to then come in and see.. oh this 
Controller has to pass thru these interceptors.

-Tim

Rod Johnson wrote:

>>The more I think about this, the more I think it will be useful.  For
>>instance, I'd like to have the OpenSessionInViewInterceptor to apply to
>>everything (/*) where other Interceptors apply to certain Controllers.
>>I'm starting to get a proliferation of UrlHandlerMapping objects just to
>>map different combinations of Interceptors.
>>
>>Jurgen, any more thoughts on this?  I might even implement this one soon
>>because it will greatly simplify things.
>>    
>>
>
>I think the proposal sounds good. I think the point about 2 types of
>interceptors is valid.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

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

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


| In the example of a complex application that might have many
| URLs/Interceptor combinations you are not really going to make things
| any less complicated as you will end up having a huge amout of these. I
| wonder if an alternative approach would be to be able to attach
| interceptors directly to controllers:

I'm OK with the complication *as an option* because I'm trying to
divorce the mapping of the interceptors for the mapping of the URLs to
Controllers.

For simple situations, it should be easy to bind a interceptor to a
HandlerMapping directly.

Seth

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

iD8DBQFA3H7GKZsFSwtW+wIRAuMnAJ4zUHVyIYFqRZJJLhCL8RrmxFaymACeI4Qh
g/fHIX81ucIZvAx9SRQ4tHw=
=wztk
-----END PGP SIGNATURE-----

Re: [Springframework-developer] Proposal for Handler/Interceptor Enhancement

[Tim C. <tc...@ta...>]

But you can achieve the same thing in my solution without the 
duplication of URLs.

Seth Ladd wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> | In the example of a complex application that might have many
> | URLs/Interceptor combinations you are not really going to make things
> | any less complicated as you will end up having a huge amout of these. I
> | wonder if an alternative approach would be to be able to attach
> | interceptors directly to controllers:
>
> I'm OK with the complication *as an option* because I'm trying to
> divorce the mapping of the interceptors for the mapping of the URLs to
> Controllers.
>
> For simple situations, it should be easy to bind a interceptor to a
> HandlerMapping directly.
>
> Seth
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFA3H7GKZsFSwtW+wIRAuMnAJ4zUHVyIYFqRZJJLhCL8RrmxFaymACeI4Qh
> g/fHIX81ucIZvAx9SRQ4tHw=
> =wztk
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>