Fw: [Springframework-developer] Ordering HandlerMappings and other beans

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

reply to again

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Sent: Monday, April 07, 2003 8:51 PM
Subject: Re: [Springframework-developer] Ordering HandlerMappings and other
beans


> Agreed to all. I like the ordered idea and may use it to solve an AOP
> problem I'm working on. All ordered go before all unordered, I presume.
>
> I haven't seen your separator suggestion, but I don't mind changes to
> BeanNameUrlHandler, which is a bit basic anyway.
>
> Rod
>
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: "Rod Johnson" <rod...@in...>
> Sent: Monday, April 07, 2003 8:42 PM
> Subject: Re: [Springframework-developer] Ordering HandlerMappings and
other
> beans
>
>
> > You're right, of course - BeanNameUrlHandlerMapping is the default, so
> SimpleUrlHandlerMapping makes more sense.
> >
> > I assume you agree not only to the naming issue, but to the ordering
issue
> and the BeanNameUrlHandlerMapping separator change too? ;-)
> >
> > Juergen
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Rod Johnson [mailto:rod...@in...]
> > Gesendet: Mo 07.04.2003 20:52
> > An: jürgen höller [werk3AT];
> spr...@li...
> > Cc:
> > Betreff: Re: [Springframework-developer] Ordering HandlerMappings and
> other beans
> >
> >
> >
> > Agreed. What about SimpleUrlHandlerMapping, as it's not the default?
> >
> > ----- Original Message -----
> > From: "jürgen höller [werk3AT]" <jue...@we...>
> > To: <spr...@li...>
> > Sent: Monday, April 07, 2003 5:14 PM
> > Subject: RE: [Springframework-developer] Ordering HandlerMappings and
> other
> > beans
> >
> >
> > A naming issue: UrlHandlerMapping should probably be called
> > DefaultUrlHanderMapping or some other more meaningful name. Especially
> with
> > AbstractUrlHandlerMapping in addition to BeanNameUrlHandlerMapping,
naming
> a
> > concrete implementation UrlHandlerMapping seems inappropriate.
> >
> > Of course, this would mean a name change that affects ControllerServlet
> > context config files. But I think that we should prefer proper names and
> > proper structure to backward compatibility, at least as long as there
> isn't
> > an official release.
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: jürgen höller [werk3AT]
> > Sent: Monday, April 07, 2003 5:09 PM
> > To: spr...@li...
> > Subject: [Springframework-developer] Ordering HandlerMappings and other
> > beans
> >
> >
> > Hi Rod, everyone,
> >
> > I've just developed a custom HandlerMapping strategy for one of our
> > applications and faced the issue that I wanted to retrieve beans of a
> > certain class from the ApplicationContext in a specifyable order.
Looking
> > for a solution, I've recognized that exactly the same issue occurs with
> > HandlerMappings themselves too. Currently, ControllerServlet solves this
> via
> > sorting by bean name ("a.urlMap", "b.urlMap"), but frankly, I've never
> > particularly liked that solution.
> >
> > So I've applied a new approach to both HandlerMapping order and the
> problem
> > in the custom application. Details of the HandlerMapping solution
follow:
> >
> > - I've introduced a Ordered interface to com.interface21.core, featuring
> one
> > single method "int getOrder()", and an associated OrderComparator. The
> > getOrder() method simply returns an int value, higher value meaning
> greater
> > in terms of sorting resp. lower priority. This is somewhat analogous to
> > Servlet load-on-startup values. OrderComparator sorts by order value,
> > treating non-Ordered objects as greatest resp. lowest priority.
> >
> > - ControllerServlet now sorts HandlerMappings (and HandlerAdapters, for
> > consistency's sake) by sorting them with OrderComparator, rather than by
> > bean name. Non-Ordered instances are thus applied in an arbitrary order,
> but
> > instances can choose to implement Ordered to be able to specify a higher
> > priority. Of course, the obvious way is adding an "order" bean property
> with
> > getter and setter, to allow specifying the order value in the
> > ApplicationContext configuration.
> >
> > - There's AbstractUrlHandlerMapping now, an abstract base class for
> > url-based HandlerMapping implementations. In addition to refactored
things
> > like unified handler initialization code (propagating ApplicationContext
> and
> > LocaleResolver) for both BeanNameUrlHandlerMapping and
UrlHandlerMapping,
> it
> > offers a property-based Ordered implementation.
> >
> > An example snippet from an applicationContext.xml file:
> >
> > <bean name="myUrlMap"
> > class="com.interface21.web.servlet.handler.UrlHandlerMapping">
> > <property name="order">0</property>
> > <property name="mappings">
> > /example.do=exampleController
> > </property>
> > </bean>
> >
> > <bean name="yourUrlMap"
> > class="com.interface21.web.servlet.handler.UrlHandlerMapping">
> > <property name="order">1</property>
> > <property name="mappings">
> > /example.do=/exampleFormController
> > /exampleForm.do=exampleFormController
> > </property>
> > </bean>
> >
> > According to the order values, myUrlMap gets applied first, thus
> > "/example.do" will lead to exampleController's execution. If one sets
> > myUrlMap's order value to "2" or omits its order line, yourUrlMap will
get
> > applied first, thus "/example.do" will lead to exampleFormController's
> > execution.
> >
> > I consider this more elegant and more flexible than sorting by bean
name.
> > After all, servlets don't get started in the order of their name for a
> > reason... ;-) Fortunately, an application developer doesn't have to care
> > about the Ordered interface if he doesn't want to: A single
HandlerMapping
> > definition doesn't need to specify an order value, and a HandlerMapping
> > implementation doesn't need to implement Ordered.
> >
> > If noone objects, I will check in the changes promptly, as they go hand
in
> > hand with other things like the UrlHandlerMapping refactoring and some
> > ControllerServlet polishing.
> >
> > Juergen
> >
> >
> > DI Jürgen Höller
> > Senior System Architect
> > __________________________________
> >
> > werk3ATS - division systementwicklung
> > part of werk3AT internetmedien oeg
> >
> > europaplatz 4
> > A - 4020 linz
> >
> > t.  +43 (0) 732 71 65 29 502
> > f.  +43 (0) 732 71 65 29 3
> > jue...@we...
> > www.werk3at.com
> > __________________________________
> > werk3ATS - WIR ENTWICKELN ERFOLG
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ValueWeb:
> > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> > No other company gives more support or power for your dedicated server
> > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
>