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