I have moved this thread to http://shiro-developer.582600.n2.nabble.com/OSGi-fication-of-Shiro-td7578996.html
Please use that instead, I think this current thread has become too messy, mostly because of myself. On Fri, May 20, 2016 at 2:34 PM, Martin Nielsen <[email protected]> wrote: > I completely forgot to add that the branch is called OSGification. > > That seems like important information. Sorry. > > I should also add that the plan is to not use INI configurations for > OSGibased Shiro, but instead control the runtime by applying the different > bundles, and controlling them through the ConfigurationAdmin. So if you > don't see an INI configuration anywhere, it is completely intended. > > On Wed, May 18, 2016 at 6:23 PM, Martin Nielsen <[email protected]> wrote: > >> I have now made some (Very) slow and (Kind of) steady progress. Sorry >> about the long wait time. >> >> https://github.com/mnybon/shiro >> >> Please note: This is only for the Shiro 2-Alpha version. It was a lot >> easier for me to start there. If Shiro-2 is not released within the >> foreseeable future, i will attempt to make the same changes to the current >> Shiro branch, which should be a lot faster and easier with my newfound >> practice. >> >> I have made the first push and created a number of OSGi bundles for the >> common Shiro-Core components. I have also created a Realm that integrates >> with the Felix ConfigurationAdmin. Lastly i have added a Pax-Exam >> integration test which, at the moment, only has a single test worth >> mentioning. I have tried to keep my fingers out of the base Shiro code as >> much as i could, and i think it has worked reasonably well. >> >> I still have some work to do, going thorough the new bundles and checking >> imports and especially exports, updating javadoc and clearning imports, but >> the current state of the project should at least give you a pretty good >> idea of my direction. >> >> I have not created a pull request yet, as that should probably be >> postponed until Shiro-Web has recieved the same attention as Shiro-Core. >> But could i convince some of you very wise and skilled Shiro contributors >> to take a look at the work and see if you can agree with the direction I'm >> going in, or if i am completely insane? >> >> I will wait a little with continuing, until i hear a verdict:) >> >> Another thing to consider: Right now I have created seperate bundle >> projects that pretty much just extend the different Shiro-Core components, >> but it would be simpler (i think) to just seperate the components out into >> seperate modules, and use an aggregation project to collect them all into >> the "Shiro-Core" and "Shiro-Web" Jars. It would be a lot easier for the >> OSGi implementation, as it would remove the need for what is essentially >> shadow-bundles, but it would introduce at least two new aggregations >> projects. What are your thoughts there? >> >> Changes i have made to the Shiro we all know and love (Excluding new >> classes). >> I have made Shiro Core into a Declarative Services component. This has >> allowed me to inject the SecurityManager into SecurityUtils, which should >> ensure that all the shiro-based applications that use >> SecurityUtils.getSubject will still work in an OSGi context. >> I made a slight addition to DelegatingSubject, by allowing the >> constructor to inject a SecurityManager Source. This is needed in order to >> seperate out the SecurityManager retrieval logic, so it can be replaced >> with the OSGi Service Registry when needed. >> I delegated the choice of what exactly gets saved to the Thread, to >> ThreadState, allowing SecurityManagers and DelegatingSubjects greater >> control over what gets saved to the Thread. I needed this in order to make >> SecurityUtils work with OSGi, without actually touching the class. >> I tweaked a few ThreadState tests, as i needed to reprogram a few of the >> Mocks. >> Lastly, i have made select changes to the Shiro-Root POM. >> >> Additions i have made (New stuff that doesn't impact the normal >> application: >> I created OSGi-enabled Declarative Service bundles of the most common >> Shiro Core classes (SecurityManager, SessionManager, SessionDAO and so >> forth) >> A new Realm has joined the family as well, It is similar to the >> Configuration Realms, but uses the Felix Configuration Admin instead of >> config files. >> Shiro now has an OSGi Integration Test >> >> (And now I think that I have used my allowance of the word "I", I >> apologize:) ) >> >> Thanks in advance >> -Martin >> >> On Fri, Apr 15, 2016 at 2:57 PM, Martin Nielsen <[email protected]> wrote: >> >>> Christiano: >>> I am looking into the Coordinator now, and it seems that it would indeed >>> be a good substitute for the ThreadLocal approach for the >>> "single-classloader" implementation. But have you had any thought about how >>> (or if) to make the two ways compatible? I would very much like if existing >>> shiro-enabled applications could simply be dropped into an OSGi container, >>> and still work using SecurityUtils.getSubject and the like, not to mention >>> that most of the filters and existing code frequently use the same >>> approach. I am looking into using DeclarativeServices to make sure that the >>> static SecurityManager is always set to a real functioning instance of the >>> SecurityManager service, for this purpose. >>> Any thoughts? >>> >>> Taking all the help i can get! >>> -Martin >>> >>> On Thu, Apr 14, 2016 at 4:40 PM, Brian Demers <[email protected]> >>> wrote: >>> >>>> Adding new methods to interfaces breaks backwards compatibility. >>>> >>>> >>>> On Thu, Apr 14, 2016 at 10:00 AM, Cristiano Gavião <[email protected]> >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > I was not able to find the code that I did... I've bought a new >>>> notebook >>>> > and seems that I left it on the old one... >>>> > >>>> > Well, one of the main goals of the Coordinator Service was to deal >>>> with >>>> > the problem of holding things on the ThreadLocal while calling a >>>> > sequence/chain flowing by different bundles providing OSGi services >>>> due to >>>> > the bundles isolation characteristic. take a look on the spec. >>>> > >>>> > If I remember well, my experiments was madden in order to integrate >>>> the >>>> > ServiceManager with the Coordinator. the path I took was..: >>>> > >>>> > When the first service in the call chain is reached (started by means >>>> of a >>>> > direct call or a remote service call or by a http call) one >>>> *coordination* >>>> > is created/started (from the coordinator service object)... Then >>>> inside its >>>> > bootstrap method the securitymanager is used to get a subject/ >>>> session (and >>>> > any other shiro related object). So, all those objects should be hold >>>> > within this unique coordination... >>>> > >>>> > The coordination object can be passed explicitly or implicitly (using >>>> the >>>> > call stack) to other bundles that will be followed in the call >>>> chain... >>>> > >>>> > at the end of the call chain the coordination can be stopped (in case >>>> of >>>> > stateless use), what will trigger the release of every shiro object >>>> created >>>> > for that coordination. >>>> > >>>> > You can turn the securitymanager service (or any other class) a >>>> > /participant /of the coordination, what can be useful if you need to >>>> stop >>>> > the current coordination before it reach its end. >>>> > >>>> > This OSGi model would fit well currently in order to implement the >>>> > Environment interface also, which would use the OSGi service register >>>> > instead a map to hold the current securitymanager object... and also >>>> some >>>> > others default implementations... >>>> > >>>> > but certainly they will fit better for proposed v2 interfaces that >>>> seems >>>> > to be much clean and less coupled for service based approach... >>>> > >>>> > hope it help you. >>>> > >>>> > regards, >>>> > >>>> > Cristiano >>>> > >>>> > >>>> > On 14/04/2016 03:33, Martin Nielsen 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 >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> > >>>> >>> >>> >> >
