Spring Security
  1. Spring Security
  2. SEC-1953

Support Java Config model in Spring Security

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.2.0.M2
    • Component/s: Namespace
    • Labels:
      None

      Description

      Spring 3.1 provides improved support for Java config like namespace handlers. I would like to be able to go XML less in a number of my applications and the main module keeping me from that goal currently is Spring Security.

        Activity

        Hide
        Rob Winch added a comment -

        Note: A few attempts have been made at this, but we are going to revisit this for 3.2

        Show
        Rob Winch added a comment - Note: A few attempts have been made at this, but we are going to revisit this for 3.2
        Hide
        Hannes Schmidt added a comment - - edited

        I think this is all about the trade-off between the verbosity required for standard configuration on one hand and the complexity and feasibility of exotic configurations on the other. The XML namespace for Spring Security was unfairly favoring standard configurations by being very concise in those cases. Less common configurations were much harder to get right and exotic ones were a nightmare.

        The litmus test for this effort should be: Can the user achieve every possible configuration without introducing new mechanisms? One shouldn't have to write a BeanPostProcessor or a namespace handler for a particular configuration. Neither should one have to translate one configuration syntax into another, XML using namespaces into plain XML beans for example. If that means that common configuration be more verbose, so be it. I'd rather climb an initial hurdle of learning all the building blocks – if the building blocks empower me to do everything I want – than a trivial first step with a large paradigmatic gap to the second one.

        Show
        Hannes Schmidt added a comment - - edited I think this is all about the trade-off between the verbosity required for standard configuration on one hand and the complexity and feasibility of exotic configurations on the other. The XML namespace for Spring Security was unfairly favoring standard configurations by being very concise in those cases. Less common configurations were much harder to get right and exotic ones were a nightmare. The litmus test for this effort should be: Can the user achieve every possible configuration without introducing new mechanisms? One shouldn't have to write a BeanPostProcessor or a namespace handler for a particular configuration. Neither should one have to translate one configuration syntax into another, XML using namespaces into plain XML beans for example. If that means that common configuration be more verbose, so be it. I'd rather climb an initial hurdle of learning all the building blocks – if the building blocks empower me to do everything I want – than a trivial first step with a large paradigmatic gap to the second one.
        Hide
        Rob Winch added a comment -

        You can see the progress here http://bit.ly/13Bgd23

        Show
        Rob Winch added a comment - You can see the progress here http://bit.ly/13Bgd23
        Hide
        Yuan Ji added a comment -

        This is excellent. When will it be released?

        I tried in my project, and it works very well. See my post Spring Application without XML Config

        Show
        Yuan Ji added a comment - This is excellent. When will it be released? I tried in my project, and it works very well. See my post Spring Application without XML Config
        Hide
        Rob Winch added a comment -

        I'm currently targeting a milestone release within the next month. However, I am hung up on a few issues that need sorted out before I am comfortable releasing it even in a milestone version. In short, the beans created using the Security Java Config do not participate in life cycle methods and due to the number of permutations of Security configuration available (many of which have optional dependencies) this is fairly difficult to get to work.

        Show
        Rob Winch added a comment - I'm currently targeting a milestone release within the next month. However, I am hung up on a few issues that need sorted out before I am comfortable releasing it even in a milestone version. In short, the beans created using the Security Java Config do not participate in life cycle methods and due to the number of permutations of Security configuration available (many of which have optional dependencies) this is fairly difficult to get to work.
        Hide
        Yuan Ji added a comment -

        Anything I can help? I can use my app to test.

        Show
        Yuan Ji added a comment - Anything I can help? I can use my app to test.
        Hide
        Rob Winch added a comment -

        Thanks for the offer for help. At the moment I don't think there is much that can be done to help. If this changes, I will be sure to let you know. Thanks again

        Show
        Rob Winch added a comment - Thanks for the offer for help. At the moment I don't think there is much that can be done to help. If this changes, I will be sure to let you know. Thanks again

          People

          • Assignee:
            Rob Winch
            Reporter:
            Mike Youngstrom
          • Votes:
            20 Vote for this issue
            Watchers:
            28 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: