shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Nielsen <mny...@gmail.com>
Subject Re: I would like to help OSGI'fy Shiro, if you will have me.
Date Wed, 13 Apr 2016 07:35:33 GMT
I switched to JDK 1.7 and everything works like a charm.
Now i have another question:
I am currently working on making Shiro core able to handle the
SecurityManager as an OSGi service, and i have run into something i don't
quite understand:
In the normal non-OSGi Shiro setup, why is the securitymanager bound to the
thread state in so many places? Isn't there supposed to be exactly one
SecurityManager set in the static SecurityUtils.securityManager field,
which is used for everything?
Why, for example, does the SubjectCallable and SubjectRunnable classes use
SubjectThreadState to persist the SecurityManager to the current thread, if
it is always available through SecurityUtils?

Thank you in advance (I will try to keep the questions to a minimum)


On Sun, Apr 10, 2016 at 11:02 PM, Brian Demers <brian.demers@gmail.com>
wrote:

> It should, though use JDK 1.7, if you are not already
>
> -Brian
>
> > On Apr 10, 2016, at 7:43 AM, Martin Nielsen <mnybon@gmail.com> wrote:
> >
> > Hi again.
> >
> > I have started ever so slowly, and i have run into the first issue:
> Compile
> > problems:D
> >
> > Either i am missing something, or i have hit the project at a time where
> it
> > doesn't compile. The support/AspectJ project is failing to compile.
> >
> > Should the project just comple directly from the github repo? Or do i
> need
> > some special setup?
> >
> > If not, i guess i will just start spooling backwards until i hit a commit
> > that compiles:D
> >
> >> On Thu, Apr 7, 2016 at 9:25 PM, Brian Demers <brian.demers@gmail.com>
> wrote:
> >>
> >> Martin,
> >> Understood, go for it.
> >>
> >>> On Thu, Apr 7, 2016 at 10:32 AM, Martin Nielsen <mnybon@gmail.com>
> wrote:
> >>>
> >>> That is the problem, i don't think this will be a "small" change
> really.
> >> I
> >>> will be making small knicks in quite a few places. I am up for doing
> the
> >>> work, and i am up for modifying it and taking critique. I wouldn't mind
> >>> helping to support it afterwards either. I just want to make sure i
> don't
> >>> get some answer like "OSGi is not a priority for us, please sod off" :D
> >>>
> >>> On Thu, Apr 7, 2016 at 3:44 PM, Brian Demers <brian.demers@gmail.com>
> >>> wrote:
> >>>
> >>>> +1 ( including Dan's comments)
> >>>>
> >>>> GitHub pull requests are now preferred.
> >>>>
> >>>>> On Thu, Apr 7, 2016 at 9:07 AM, Dan Dumont <ddumont@apache.org>
> wrote:
> >>>>>
> >>>>> I don't want to put words in the shiro committers mouths, but I'm
> >> sure
> >>>> they
> >>>>> would be happy to see the work.  The best way I found to get involved
> >>> in
> >>>>> Apache projects is to start making small, easy to review changes
that
> >>>> were
> >>>>> easy to explain.  (With unit tests of course :)
> >>>>>
> >>>>> Eventually, the community extended a committer invite.
> >>>>>
> >>>>> Good luck!
> >>>>> I use shiro on karaf right now and would like to see some love for
> >> OSGi
> >>>> as
> >>>>> well.
> >>>>>
> >>>>> sent using my nexus 5x
> >>>>>> On Apr 7, 2016 7:29 AM, "Martin Nielsen" <mnybon@gmail.com>
wrote:
> >>>>>>
> >>>>>> Hello Shiro developers.
> >>>>>>
> >>>>>> I have recently been using Shiro for all my security needs,
and I
> >>> adore
> >>>>> the
> >>>>>> framework. Recently though, I have been moving more and more
> >> towards
> >>>> OSGi
> >>>>>> specification, and it feels like Shiro is a little lacking in
that
> >>>> area.
> >>>>> It
> >>>>>> works well enough but it is quite static, and does not really
> >> handle
> >>>> the
> >>>>>> dynamic nature of OSGi.
> >>>>>>
> >>>>>> As far as I can see, all the wiring in Shiro on OSGi is one
at
> >>>>>> initialization time, and remains static while the application
is
> >>>> running.
> >>>>>>
> >>>>>> I think I have a pretty low impact way to create an OSGi based
> >>>>>> SecurityManager that would register Realms, SubjectDAO's,
> >>>> SessionManagers
> >>>>>> et cetera as services, allowing bundles to register their own
> >>>>>> sessionmanagers, cachemanagers, and more importantly realms,
when
> >>> they
> >>>>>> start up.
> >>>>>>
> >>>>>> The result would be an OSGi based SecurityManager that does
not
> >> start
> >>>> up
> >>>>>> statically, for example with an INI file, but uses the OSGi
service
> >>>>>> registry to get its resources at runtime.
> >>>>>>
> >>>>>> The overall plan is to create a few changes in Shiro Core and
Shiro
> >>>> Web,
> >>>>> so
> >>>>>> it is possible to define how the individual parts connects to
each
> >>>> other.
> >>>>>> So, basically i want to change hardwired references to small
> >> adapter
> >>>>>> classes, that can be injected to change how the components finds
> >> each
> >>>>>> other. The existing SecurityManagers should of cause remain
> >>> unaffected
> >>>>> and
> >>>>>> there should be no change to the end user experience.
> >>>>>> I will also create an adapter, that can be used in place of
the
> >>> static
> >>>>>> securitymanager when running OSGi.
> >>>>>>
> >>>>>> When that is done, I will add a number of modules to serve as
> >>> dedicated
> >>>>>> OSGi bundles, using hopefully 95& of the code from Core
and Web, so
> >>> the
> >>>>>> standard components can be started as separate bundles, and
> >> replaced
> >>> by
> >>>>>> custom implementations if necessary.
> >>>>>>
> >>>>>> My hope is that, when done, it will be possible to use a
> >>>> securitymanager
> >>>>>> that doesn't wire anything at startup, and can change at runtime,
> >> as
> >>>>>> bundles are started and stopped.
> >>>>>>
> >>>>>> I am very willing to put in the hours to make this happen, but
it
> >>> would
> >>>>> be
> >>>>>> nice to know that this is something that the maintainers actaully
> >>> want,
> >>>>> so
> >>>>>> I don't end up with something that isn't desired. I also have
not
> >>>> worked
> >>>>>> that much with the Web bundle, so I might have some questions
down
> >>> the
> >>>>>> line.
> >>>>>>
> >>>>>> So: Is this something that that you would consider a pull request
> >>> for?
> >>>> Of
> >>>>>> cause i can't guarantee that it will work, but i am willing
to try,
> >>>>>> provided that i get some assurance that it is actually something
> >> you
> >>>> want
> >>>>>> in the project.
> >>>>>>
> >>>>>> Please let me know
> >>>>>>
> >>>>>> Martin Nielsen
> >>>>>> -Hopeful Apache Committer
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message