Can you repost to that thread so we keep it together? Would help when the emails are archived to not have to jump threads...
On Fri, Jul 18, 2008 at 9:53 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > I've often thought that a good spinoff project from JSecurity would be a UI > and infrastructure for managing users, roles, permissions, etc. I've always > viewed it as something that would be a separate project that depends on the > JSecurity core. Every project with security has to manage the users > somehow, so why not have an OS project that lets you manage it all out of > the box? > > I'm not sure whether the infrastructure to mutate users, etc. belongs in > the JSecurity core or in a separate sub-project. If it did, I could see > something like a MutableRealm interface. But I don't know if we want to > make those kind of assumptions about the underlying model. I'd be more > comfortable making those assumptions in a sub-project that was optional and > was intended to get basic security up and running quickly. (useful for > simple web apps or for the beginning stages of advanced web apps) Heck, I > wish I had a simple UI for editing roles and permissions for my application > at work right now! > > Ideas? > > > > On Jul 18, 2008, at 9:40 AM, Les Hazlewood wrote: > > We should have the 2 outstanding remaining issues for 0.9.0 RC1 to be >> complete in the next few days. Any issues other than those 2 are >> essentially in the backlog. I think maybe it would be better to have a >> 'backlog' in the Apache Jira and manually copy over those 7 issues. >> >> That is, it probably isn't necessary to create a 'migrated' version just >> for >> those 7... >> >> Les >> >> On Fri, Jul 18, 2008 at 1:09 AM, Alan D. Cabrera <[EMAIL PROTECTED]> >> wrote: >> >> Do you guys think this is the way to go or no? >>> >>> >>> Regards, >>> Alan >>> >>> >>> On Jul 11, 2008, at 9:18 PM, Alan D. Cabrera wrote: >>> >>> Les, >>> >>>> >>>> If you make a version called, say, "moved-to-asf" I will be happy to >>>> copy >>>> anything in there over to the new Jira. >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> On Jul 10, 2008, at 8:39 PM, Les Hazlewood wrote: >>>> >>>> Ah, excellent question. >>>> >>>>> >>>>> The basic answer is that I was waiting for us to get the 0.9 release >>>>> out for our existing community before we switch to the Apache Jira >>>>> 100%. The _only_ reason being is that Jira will auto-generate release >>>>> notes for us, and if all the issues for a given release are entirely >>>>> under one Jira installation, then we can be sure it generates the >>>>> complete list. If we had half our resolved issues in one location and >>>>> the other half in Jira, it would be a pain to deal with when release >>>>> time comes, which is why I wanted to make a clean break at a >>>>> well-delimited point in time. >>>>> >>>>> Since there are only 2 outstanding issues for 0.9 RC1, I can just move >>>>> over the remaining issues (by hand) for 0.9 RC2 and above. This would >>>>> make the transition a tad earlier than I originally expected, but that >>>>> is as good a time as any probably. >>>>> >>>>> There's no easy way than by hand. May as well start w/ the new ones. >>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alan >>>>>> >>>>>> On Jul 10, 2008, at 3:34 PM, Jeremy Haile wrote: >>>>>> >>>>>> We haven't transitioned to the Apache JIRA yet. Our issues haven't >>>>>> >>>>>>> been migrated over yet. >>>>>>> >>>>>>> >>>>>>> On Jul 10, 2008, at 6:24 PM, Alan D. Cabrera wrote: >>>>>>> >>>>>> >>>>>> Why hasn't this been filed on the Apache Jira? >>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alan >>>>>>> >>>>>>> >>>>>> >>>>> On Thu, Jul 10, 2008 at 3:46 PM, Les Hazlewood <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>> >>>>>> http://issues.jsecurity.org/browse/JSEC-117 >>>>>> >>>>>> On Thu, Jul 10, 2008 at 3:37 PM, Les Hazlewood <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I was contacted via private email yesterday about a company that >>>>>>> wishes >>>>>>> to use JSecurity in their product, but they were concerned about our >>>>>>> use of >>>>>>> Commons Logging, citing the now familiar classloader issues. It was >>>>>>> interesting timing because of my proposal to use SLF4J last week. >>>>>>> >>>>>>> This gent's recommendation was that we have our own (very minimal) >>>>>>> Log >>>>>>> interface that we would use in our classes instead of Commons >>>>>>> Logging. He >>>>>>> brought up a number of cases of difficulty implementing frameworks in >>>>>>> companies that have their own proprietary logging framework (events, >>>>>>> monitoring, etc), and said it would be much easier and more flexible >>>>>>> if they >>>>>>> could implement their own version of a Log interface to do what they >>>>>>> need, >>>>>>> using their companies' APIs. >>>>>>> >>>>>>> I think it is a good idea, and would be super easy - it is basically >>>>>>> one interface (Log) and maybe a 2nd (LogFactory, whatever). Then our >>>>>>> default implementation could use the JVM logger or SLF4J to allow any >>>>>>> number >>>>>>> of pluggable logging implementations. This provides greater >>>>>>> flexibility for >>>>>>> any environment. We already do the same thing for caching (Cache, >>>>>>> CacheManager) which in turn delegates to Caching product >>>>>>> implementation >>>>>>> specific classes (ehcache, JCache, etc). Same concept. >>>>>>> >>>>>>> The thing that sounds clean to me about this, is that if it was >>>>>>> implemented, we would have NO required dependencies on any 3rd party >>>>>>> library. That just feels sexy. But we can still have default >>>>>>> implementations that use our favorite infrastructure. >>>>>>> >>>>>>> Any thoughts or objections? >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >
