Oops - meant to post this on the Mutable Realm thread. Sorry!
On Jul 18, 2008, at 9:53 AM, Jeremy Haile 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?
