standalone.html 5.2 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
  1. <!--
  2. * ========================================================================
  3. *
  4. * Copyright 2005 Acegi Technology Pty Limited
  5. *
  6. * Licensed under the Apache License, Version 2.0 (the "License");
  7. * you may not use this file except in compliance with the License.
  8. * You may obtain a copy of the License at
  9. *
  10. * http://www.apache.org/licenses/LICENSE-2.0
  11. *
  12. * Unless required by applicable law or agreed to in writing, software
  13. * distributed under the License is distributed on an "AS IS" BASIS,
  14. * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  15. * See the License for the specific language governing permissions and
  16. * limitations under the License.
  17. *
  18. * ========================================================================
  19. -->
  20. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  21. <html xmlns="http://www.w3.org/1999/xhtml">
  22. <head>
  23. <title>Acegi Security Use Without Spring</title>
  24. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  25. </head>
  26. <body>
  27. <h1>Acegi Security Use Without Spring</h1>
  28. <h2>Introduction</h2>
  29. <p>Sometimes we get asked can Acegi Security be used without Spring.
  30. This page provides a detailed answer.</p>
  31. <h2>History</h2>
  32. <p>Acegi Security started out as a method interceptor for Spring IoC container
  33. managed beans. Typically such beans provide services layer functions.
  34. Over time Acegi Security grew to offer authentication services, <code>ThreadLocal</code> management,
  35. web request filtering, extra AOP support,
  36. ACL features, additional authentication mechanisms and so on (for those interested,
  37. see our <a href="changes-report.html">change log</a>).</p>
  38. <h2>Why Use Spring</h2>
  39. <p>There's plenty written about why the
  40. <a href="http://www.springframework.org">Spring Framework</a>
  41. is a good fit for modern applications. If you're not familiar with the benefits
  42. Spring offers, please take a few minutes to learn more about it. In numerous
  43. situations Spring will save you many months (or even years) of development time.
  44. Not to mention your solutions will be better architected
  45. (designed), better coded (implemented), and better supported (maintained) in the future.
  46. </p>
  47. <h2>Acegi Security Dependencies on Spring</h2>
  48. <p>Acegi Security relies on the Spring IoC container to wire its classes, and execute lifecycle
  49. methods such as <code>afterPropertiesSet()</code>. Some Acegi Security classes also
  50. publish events to the <code>ApplicationContext</code>, although you could provide a mock
  51. implementation of <code>ApplicationContext</code> easily enough which no-ops the method.
  52. In other words, if you particularly didn't want Spring in your application, you <i>could</i>
  53. avoid its use by writing equivalent getter, setter and lifecycle invocation processes
  54. in standard Java code. This is a natural consequence of the Spring way of development,
  55. which emphasises framework independence (it is <i>not</i> because we think there are good
  56. reasons people would <i>not</i> use Spring).</p>
  57. <p>If it sounds too hard (it's not) or counter-productive (it is) to replace Spring's IoC
  58. services, don't forget you can always deploy Acegi Security and the Spring
  59. IoC container solely for configuring Acegi Security. Spring does not mandate its
  60. use in every part of your application. It will work quite successfully doing nothing more than
  61. acting as a configuration mechanism for Acegi Security. Whilst some may regard this as excessive,
  62. it's really no different than the traditional approach of every framework having its very
  63. own XML or other proprietary configuration system. The main difference is that Spring is an
  64. actual de facto standard, and you can gradually introduce it to other parts of your application
  65. over time (if desired).</p>
  66. <p>Acegi Security does <i>not</i> use any other Spring capabilities. Most notably, the
  67. entire architecture is based around <code>Filter</code>s, not Spring's MVC framework.
  68. This allows it to be used with any MVC framework, or even with just straight JSPs.
  69. Acegi Security uses the AOP Alliance and AspectJ interfaces for method interception -
  70. it does not use any Spring-specific interfaces. As a consequence, Acegi Security is very
  71. portable to applications that do not leverage <i>any</i> of Spring's capabilities. We should note
  72. there are several very simple data access objects (DAOs) that use Spring's JDBC abstraction
  73. layer, although each of these are defined by a simple interface and it is very common in
  74. even native Spring-powered applications for these to be re-implemented using the application's
  75. persistence framework of choice (eg Hibernate).
  76. <h1>Conclusion</h1>
  77. <p>In summary, we recommend you take a look at Spring and consider using it in your
  78. applications. Irrespective of whether you do so or not, we strongly recommend you use it
  79. for configuration and lifecycle management of Acegi Security. If that is also not desired,
  80. Acegi Security can easily be executed without Spring at all, providing you implement
  81. similar IoC services. Acegi Security has very minimal dependencies directly on Spring,
  82. with it being useful in many non-Spring applications and with non-Spring frameworks.
  83. </body>
  84. </html>