Yeah, agree. That's why I think it makes more sense to embed shiro as private. We just have to document and provide an example.
Regards JB Le 23 juil. 2019 à 23:49, à 23:49, Brian Demers <brian.dem...@gmail.com> a écrit: >IMHO in web environment, you typically do NOT want to set the static >instance of the SecurityManager. But instead, bind it to the request >(or >similar context). > >In our Spring integration (and I assume Guice) we expose the >SecurityManger >as a bean, can you do something similar? > >I'm not sure if this helps much, as you still might have a problem >between >classloaders (depending on the structure). > >On Tue, Jul 23, 2019 at 5:13 PM j...@nanthrax.net <j...@nanthrax.net> >wrote: > >> >> Hi, >> >> Actually, I think it's not a good idea to provide a Shiro Karaf >feature as >> it is, without details. As we are using singleton and configuration >loaded >> by TCCL, it means that all will be in an unique classloader and >doesn't >> work as expected. >> >> I think it makes more sense to embed Shiro as private package in >"client" >> bundles. It will work directly without any pain. >> >> I would like to submit a PR with the following: >> >> - add a Karaf/OSGi Shiro global approach (via Karaf feature) with a >Shiro >> "service". It means we will have an unique security manager and >unique >> configuration. >> - add a Karaf/OSGi example to use "multiple" Shiro manager, as >private >> package on the "client" bundles. >> >> I would like to add this in examples folder with some details and use >> cases. >> >> If you agree, I will create the PR tomorrow. >> >> I have also other OSGi improvements on the way. >> >> Regards >> JB >> >> On Tuesday, July 23, 2019 23:00 CEST, Francois Papon < >> francois.pa...@openobject.fr> wrote: >> Hi guys, >> >> After many brainstorming with JB and make some tests on the >integration >> of Shiro in OSGi and especially with Karaf, I noticed that we have >some >> classloader issues that we have to deal with. >> >> A good example is the SecurityUtils class that is a singleton and if >we >> want to configure multiple SecurityManager, we can't do that as is. >> >> We have one singleton per classloader and if we install the >shiro-core >> feature, the configuration is the same for all the services. >> >> So it would be great if we can choose how to configure the security >> manager: >> >> - on each services (with one configuration file per service and >> declaring shiro bundles as private package) >> >> - global to the runtime (with only one configuration file and >installing >> shiro features) >> >> Another things is the instanciation of the class that is defined in >the >> shiro.ini and the usage of the ReflectionBuilder with Apache Commons >> BeanUtils. >> >> We have some classNotFound issues that is related to the classloader >> design of OSGi. We can also deal with some private package to fix >that. >> >> We have some tutorials and we could add them to the Shiro website :) >> >> Thoughts? >> >> regards, >> >> -- >> François >> fpa...@apache.org >> >> >> >> >> >>
