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 Thu, 14 Apr 2016 13:53:08 GMT
I am going to implement on master first, and look into applying the same
logic on the 1.2 branch afterwards. I think i will need room to maneuver at
first, i am still making heads and tails of everything.

When you say "Pretty locked" then what exactly does that mean? Are all
interfaces hands off? Can i add new methods to interfaces? What exactly are
my range of freedom? And don't worry, i will try my very best to make it
work on both branches, even if the implementation won't be entirely
identical.

On Thu, Apr 14, 2016 at 3:41 PM, Brian Demers <brian.demers@gmail.com>
wrote:

> For 1.2, the API is pretty locked, but if you can do it in a backwards
> compatible way, that should be fine.
>
> For master, you have a lot more room to play
>
> On Thu, Apr 14, 2016 at 2:49 AM, Martin Nielsen <mnybon@gmail.com> wrote:
>
> > Brian: To what extend would you be ok with me adding extra methods to
> > established interfaces?
> >
> > Current example is that i need to be able to distinguish between what is
> > saved on ThreadLocal when running "normally" and in OSGi.
> > It seems the smallest change would be to make SubjectThreadState into an
> > interface and allow the Subject class to either return its own
> > SubjectThreadState, or maybe even build the bind method directly into the
> > Subject.
> > Its a fix that is quite small, but i am not sure about adding such
> > functionality to Subject, as it currently only contains developer-focused
> > methods, and next to none focused on the backing framework.
> >
> > On Thu, Apr 14, 2016 at 8:33 AM, Martin Nielsen <mnybon@gmail.com>
> wrote:
> >
> > > Cristiano, i will see if i can find your work a little later on. Right
> > now
> > > my main concern is finding the "least impact" solution for
> circumventing
> > > the initialization wiring and threadlocal functionality (Ironically,
> > these
> > > are some of the things that make Shiro so nice to use, and now i am
> > working
> > > on getting around them).
> > >
> > > The main problem i am having right now is that i must not bind anything
> > to
> > > a threadlocal, that will be exposed as a service (Considering what
> would
> > > happen if the corresponding securitymanager bundle is suddenly stopped,
> > > what about the service instance in the threadlocal?)
> > >
> > > Did you do any work along those lines? I would very much like to not
> > > reinvent the wheel if someone else already did the work.
> > >
> > > Right now my thought is to expand the SubjectThreadState, letting the
> > > subject itself define how it is stored, but i am very much open to
> other,
> > > and potentially better, ideas:)
> > >
> > > More regards
> > > -Martin
> > >
> > > On Wed, Apr 13, 2016 at 9:11 PM, Brian Demers <brian.demers@gmail.com>
> > > wrote:
> > >
> > >> These have been merged to master and 1.2.x
> > >>
> > >> On Wed, Apr 13, 2016 at 10:26 AM, Andreas Kohn <
> andreas.kohn@gmail.com>
> > >> wrote:
> > >>
> > >> > Brian,
> > >> >
> > >> > We needed[*] to get Shiro 1.2 building with JDK 8, these commits
> could
> > >> be
> > >> > helpful to pull into the main repository:
> > >> >
> > >> >
> > >> >
> > >>
> >
> https://github.com/Collaborne/shiro/commit/e83d73f858bc48cbc7c7123fada099eff044aa43
> > >> > (SHIRO-516)
> > >> >
> > >> >
> > >> >
> > >>
> >
> https://github.com/Collaborne/shiro/commit/631847d3a2754244ad0ab2f87bd581fe7b8e60f7
> > >> >
> > >> >
> > >>
> >
> https://github.com/Collaborne/shiro/commit/831b90c9255ce81994accef5a94ddfa31a85d8cf
> > >> >
> > >> >
> > >>
> >
> https://github.com/Collaborne/shiro/commit/be75d27d9439585308ea48420a36d42b53fe7cb2
> > >> > (no issue/PR yet)
> > >> >
> > >> > Should I create a new issue for that, or would that only be relevant
> > for
> > >> > the mythical Shiro 2.x?
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Andreas
> > >> >
> > >> > [*] JDK 7 is EOL'd, so I simply didn't want to have to bother with
> > that
> > >> > anymore.
> > >> >
> > >> > 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