It's no problem, i have every intention of using the finished product myself :)
I have created the pull request. Looking forward to your comments. On Mon, May 23, 2016 at 3:49 PM, Brian Demers <[email protected]> wrote: > 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 > > >
