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
