Menu
▾
▴
Re: [Springframework-developer] Road map (security)
|
From: <jue...@we...> - 2004-03-11 23:22:35
|
BTW, I'm quite impressed with what you've achieved already (as I told = you in a private mail a couple of days ago). And it definitely has some = of the best documentation that I've ever seen in a 0.1 release! :-) =20 Keep up the good work! =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Do 11.03.2004 23:00 An: spr...@li... Betreff: Re: [Springframework-developer] Road map (security) Ben, I've indeed not included daughter respectively sister projects like RCP = and security in the road map. Those are complex enough to be hosted as = separate projects, with separate release cycles and separate road map. = My mail just focussed on the road map of the Spring core. Of course, the = road maps should be aligned to a certain degree. I'm delighted to see all the work that you put into your security = system, and also to see the interest in it. As we discussed in private = mails before, the final word on standard Spring security support is not = out yet: Actually, there might never be standard Spring security but = just very basic hooks in the framework that all for easy integration of = separate products like the Acegi Security System. Security requirements can be complex and vary widely, so I do see the = value of letting separate security products evolve independently. I take = a pragmatic stance here: Let's see how things evolve. We will of course = link to your project from the Spring website, referring to it as a = security system for Spring, with focus on integration with J2EE = container security. Feel free to suggest to an appropriate tagline :-) Regarding hosting, I don't have a strong opinion on separate SourceForge = projects versus separate modules within the main Spring project. My = basic guideline is: If it's closely integrated with the Spring core but = still worth a separate project, then a module within the main Spring = project is appropriate, like in the case of RCP and the Eclipse beans = plugin. The Acegi Security System is probably more generic here. Persistence solutions like Hibernate and iBATIS SQL Maps are separate = projects but integrate nicely with Spring; the same applies to web = frameworks like Struts and WebWork. So I wouldn't be surprised to see = cross-cutting add-ons like security systems evolve in a similar fashion, = particularly if they allow for standalone usage outside of a full Spring = context as well. It's good to see Spring create an ecosystem here :-) Juergen ________________________________ Von: spr...@li... im Auftrag = von Ben Alex Gesendet: Do 11.03.2004 21:40 An: spr...@li... Betreff: RE: [Springframework-developer] Road map (security) > How about declarative security, should somehow also be > mentioned in the roadmap. Any ideas so far about how to go about it? Thought I'd jump in here. The Acegi Security System for Spring project = now has a home at SoureForge. I'm currently writing automated container integration unit tests (ie unzip a stock standard container release, = install the security module to it, and run unit tests). CVS and a new ZIP = release will be at SourceForge in a day or two, and anyone interested is welcome = to participate in development. Whilst I initially wrote the above project with a view to inclusion in Spring, I also recognise there are no Spring-specific dependencies apart from standard bean context and interceptor services. As such, from a technical perspective security could be effectively developed in a = separate project, or as a separate module under Spring CVS. There is no technical requirement in having it in Spring core. The real issue is whether from = a marketing perspective the Spring Framework needs its very own security capability/project, an "official" separate security project that users = are pointed towards, or a list of external (untested) security projects that claim to support Spring. It would be nice to avoid duplication of efforts on security, = particularly given most of it involves writing adapters between the project security = and the container's native security. Maximising the user and developer base = of a single security project will also have obvious benefits in terms of = testing, issue identification, support and improvement. Ben ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
