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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > wrote: > > > > > >> These have been merged to master and 1.2.x > > >> > > >> On Wed, Apr 13, 2016 at 10:26 AM, Andreas Kohn < > [email protected]> > > >> 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 < > [email protected] > > > > > >> > wrote: > > >> > > > >> > > It should, though use JDK 1.7, if you are not already > > >> > > > > >> > > -Brian > > >> > > > > >> > > > On Apr 10, 2016, at 7:43 AM, Martin Nielsen <[email protected]> > > >> 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 < > > >> [email protected]> > > >> > > wrote: > > >> > > >> > > >> > > >> Martin, > > >> > > >> Understood, go for it. > > >> > > >> > > >> > > >>> On Thu, Apr 7, 2016 at 10:32 AM, Martin Nielsen < > > [email protected] > > >> > > > >> > > 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 < > > >> [email protected] > > >> > > > > >> > > >>> wrote: > > >> > > >>> > > >> > > >>>> +1 ( including Dan's comments) > > >> > > >>>> > > >> > > >>>> GitHub pull requests are now preferred. > > >> > > >>>> > > >> > > >>>>> On Thu, Apr 7, 2016 at 9:07 AM, Dan Dumont < > > [email protected]> > > >> > > 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" <[email protected] > > > > >> > 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 > > >> > > >>>>>> > > >> > > >>>>> > > >> > > >>>> > > >> > > >>> > > >> > > >> > > >> > > > > >> > > > >> > > > > > > > > >
