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 >>>>>>>>>>> >>>>>>>>>>> >
