Announcement Announcement Module
Collapse
No announcement yet.
Intialize ServletFilter w/ PropertyPlaceholderConfigurer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intialize ServletFilter w/ PropertyPlaceholderConfigurer

    Hi!

    I have two filters in my webapp (based on OncePerRequestFilter). Both of these filters use some <init-param>s, that I would like to move to a 'global' propertyfile. For the 'normal' beans (defined in my application context file) the PropertyPlaceholder* works fine - the tokens get replaced with the values from the propertyfile. For the filters, Spring seems to skip the post-processing - possibly because the filters are only mentioned in the web.xml, and not in the application context. The filters do get initialized with their init-parameters, (I'm using the ContextLoaderListener), but the post-processing does not take place (i.e., their parameters are all set to ${my.property.A}, {$my.property.B}

    So what my question boils down to is: how do I tell Spring to do the bean-factory postprocessing on these filters? Or am I going about this in the wrong way?

    Thanks for any suggestions!

    Regards,
    Edwin

  • #2
    Spring can't process Filters that live outside the application context. What you need to do is get the Filters to live within the application context so you can take advantage of autowiring, collaborators, lifecycle services, event publishing and so on. In Acegi Security we have a very useful bean that does this called net.sf.acegisecurity.util.FilterToBeanProxy (take a peek at http://cvs.sourceforge.net/viewcvs.p...=1.4&view=auto). There are numerous examples of its usage within Acegi Security, as we have half a dozen or so filters that get loaded via it. People often use FilterToBeanProxy outside of Acegi Security applications given it's so general-purpose.

    Comment


    • #3
      Yeah, I suspected something like that was going on. Your suggestion looks like a useful one - I'll look into it.

      One thing surprises me though - it seems to me that Spring sort-of 'knows' about the filters (tthey're based on the OncePerRequestFilter) - so Spring takes care of populating the filter properties based on the filter init parameters, it just doesn't do the postprocessing.

      I guess I sort of expected the web.xml to be sort of an add-on to the application context.

      So I gues the same thing would go for servlets?

      Thanks for your help!

      Comment


      • #4
        For Servlets people typically use org.springframework.web.servlet.DispatcherServlet, which loads its own xxxx-servlet.xml.

        Comment

        Working...
        X