Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-03-11 22:17:29
|
Ben, =20 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. =20 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. =20 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 :-)=20 =20 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. =20 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 :-) =20 Juergen =20 ________________________________ 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 |
|
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 |
|
From: <sam...@ma...> - 2004-03-12 10:36:58
|
Quoting Ben Alex <ben...@ac...>: <snip> > > 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 Looking at Spring as a relative newcomer, I can see that in Spring itself there is already support for a wide number of API's and technology, any of which could be in seperate projects. Persoanlly, I prefer being able to download one big bundle then pick and choose what I use. Your project will certainly be of use to people, and having it inside Spring as a fully supported API adds to Spring as a whole - it will also lead people to think it will have a certain level of quality in line with the rest of the Spring code. I have no objections to it being included, but as a non-commiter its not reall my place to say... sam http://www.magpiebrain.com/ |
|
From: <ad...@tr...> - 2004-03-12 13:22:09
|
On 03-12-2004 10:18 +0000 sam...@ma... wrote: > Looking at Spring as a relative newcomer, I can see that in Spring itself > there is already support for a wide number of API's and technology, any > of which could be in separate projects. Persoanlly, I prefer being able > to download one big bundle then pick and choose what I use. Your project > will certainly be of use to people, and having it inside Spring as a > fully supported API adds to Spring as a whole - it will also lead people > to think it will have a certain level of quality in line with the rest of > the Spring code. I have no objections to it being included, but as a > non-commiter its not reall my place to say... I'd like to chime in here as well. One of the most valuable facets of=20 Spring for me has been the quality of the developers working on it. When=20 trying to evaluate how to approach a problem domain, it gives me lots of=20 confidence if the developers on this list have looked at a solution and=20 approve of it being in Spring core. For example, Ben's security framework looks great to me. But I know that if = Rod, J=FCrgen, Alef, etc, have looked at it and think it is solid then it=20 probably is. I guess I like to borrow the knowledge of the more experienced = developers. In conclusion, it is always a good idea to keep the framework flexible=20 enough that people can do whatever they please. However, having "approved"=20 implementations of certain capabilities, like security, is important. My 2 cents. A. --=20 Adam Sherman Tritus CG Inc. +1 (613) 797-6819 http://www.tritus.ca/ |
|
From: Keith D. <kd...@cs...> - 2004-03-12 14:44:26
|
I have to say I completely agree with this. The quality of the code is a= lso one of the main factors that attracted me to Spring. Something with the backing of the Spring name definitely adds to the credibility that it is worth taking a serious look at. I think Spring's "uber-jar" approach complimented with its individual jar= s for distributing specific portions is a good, balanced approach. While I= 've seen people who conveniently like everything in one bundle, we've all see= n people just as adament about wanting just a core IoC container and a smal= l footprint and that's it. I also think having sub-projects under the Spring umbrella/mission for larger, prudently selected high-interest efforts is a good approach. It allows them to evolve/release somewhat independently, but still stay an integrated part of the Spring community. Keith ----- Original Message -----=20 From: <ad...@tr...> To: <spr...@li...> Sent: Friday, March 12, 2004 8:02 AM Subject: RE: [Springframework-developer] Road map (security) > I'd like to chime in here as well. One of the most valuable facets of > Spring for me has been the quality of the developers working on it. Whe= n > trying to evaluate how to approach a problem domain, it gives me lots o= f > confidence if the developers on this list have looked at a solution and > approve of it being in Spring core. > > For example, Ben's security framework looks great to me. But I know tha= t if > Rod, J=FCrgen, Alef, etc, have looked at it and think it is solid then = it > probably is. I guess I like to borrow the knowledge of the more experienced > developers. > > In conclusion, it is always a good idea to keep the framework flexible > enough that people can do whatever they please. However, having "approv= ed" > implementations of certain capabilities, like security, is important. > > My 2 cents. > > A. > > --=20 > Adam Sherman > Tritus CG Inc. > +1 (613) 797-6819 > http://www.tritus.ca/ > > > ------------------------------------------------------- > 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=CCk > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ben A. <ben...@ac...> - 2004-03-12 23:04:38
|
=20 > For example, Ben's security framework looks great to me. But=20 > I know that if Rod, J=FCrgen, Alef, etc, have looked at it and=20 > think it is solid then it probably is. I guess I like to=20 > borrow the knowledge of the more experienced developers. Fully agree. People using Spring know its APIs and architecture is = robust and will still be there for you in 18 months. Unlike some other projects which seem to radically transform from version to version. > Your project will certainly be of use to people, and having it=20 > inside Spring as a fully supported API adds to Spring as a whole - it=20 > will also lead people to think it will have a certain level of quality = > in line with the rest of the Spring code. I have no objections to it=20 > being included, but as a non-commiter its not reall my place to say... I do not believe the current Acegi security project is of sufficient maturity to be contemplated for Spring core at this time. Whilst it's = had about 80 downloads now, it was only publicly released less than two = weeks ago! With more downloads, use, and public CVS so interested people can participate, its perceived and actual maturity should improve. I will upload to CVS and release a new public version in a few days. Yesterday I finished writing fully integrated container unit tests, = which should provide further confidence it works properly and can accommodate additional developers. Best regards Ben |
