Thanks for taking this on Martin!

I suggest you create the pull request, (just prefix the title with a 'WIP:'
to avoid any confusion) this way we can move any comments/suggestions
closer to the code.

On Mon, May 23, 2016 at 3:15 AM, Martin Nielsen <[email protected]> wrote:

> Hi all.
> I decided to start up a new thread for my attempt at making Shiro OSGi
> compatible. This is mostly because i was not exactly clear in the last few
> mails i sent. Sorry about that. I tried to jam it into my schedule, and
> didn't take the time needed do a proper description of the work.
> What i would very much like from you devs, is a yay-or-nay on the current
> direction, before i sink my teeth into finishing:)
>
> Overall
> I have forked the Shiro Github repository into
> https://github.com/mnybon/shiro, and created a branch called OSGification.
> The branch is currently a proof of concept, and is missing some java-doc,
> and a second revision of the POM's and whatnot, but i have stopped here to
> give the devs a chance to weigh in on the direction i'm going in. I have
> not created a pull request yet. I would love to hear your toughts on the
> direction first. I have made a functioning Shiro-Core OSGi package, but
> have yet to finish Shiro-Web
>
> Design Choice:
> The mission was to create a "Pure OSGi" approach for configuring Shiro. The
> idea is that each component (SecurityManager, SessionManager, Cache and so
> on) exists as seperate bundles. Configuring Shiro in OSGi is therefore not
> done via Shiro.ini, but is instead done by installing the bundles that make
> up the desired Shiro runtime. Any configuration needed by the components is
> done through the ConfigurationAdmin, or through container specific
> deployment methods, such as the Karaf Feature. Besides being a very
> "OSGi-like" way of configuring applications, it also allows us to run Shiro
> in for example, a Karaf Cellar Cluster, as the SecurityManager can actually
> exist in several Karafs at once, as long as the cache and session managers
> are synchronized.
>
> Steps i have taken:
> A few changes has been made to the existing Shiro code. I have really tired
> to keep it to an absolute minimum, to illustrate how few changes to the
> existing code is actually needed. I even opted to create my own
> Karaf-Feature file (which will be merged with the existing one later)
> Here is a quick summary:
> Shiro Core is now a Declarative Service, which injects the
> SecurityUtils.SecurityManager, ensuring that "Normal" shiro applications
> will also work in the OSGi-based Shiro.
> Delegating subject now has a SecurityManagerSource, instead of a reference
> to an actual SecurityManager, to allow the SubjectFactory control over
> where to find the SecurityManager for its subjects.
> ThreadState now has more control over what exactly is saved in ThreadLocal,
> allowing the SubjectFactory control over what to save and what NOT to save.
> I updated a few tests, as the mocks needed to refresh the new reality.
> I changed and added dependencies in the root-POM (only related to OSGi)
>
> New additions:
> The support module now contains a new OSGi submodule, which contains
> DeclarativeService enabled versions of the normal Shiro-Core components.
> A new Realm has also been created, allowing subjects and roles to be
> configured via the ConfigurationAdmin.
> I have added a new Feature File and an Integration Test. (Also in
> support/OSGi)
>
> So, tell me what you think, i look forward to getting (i hope) a yay, so i
> can finish the rest, and do something similar for the v1 branch, if you
> feel that is necessary.
>
> Thanks in advance
> -Martin
>

Reply via email to