Specifically, we are exporting:
<entry key="org.apache.shiro" value="${shiro.version}"/>
<entry key="org.apache.shiro.aop" value="${shiro.version}"/>
<entry key="org.apache.shiro.authc" value="${shiro.version}"/>
<entry key="org.apache.shiro.authc.credential"
value="${shiro.version}"/>
<entry key="org.apache.shiro.authc.pam"
value="${shiro.version}"/>
<entry key="org.apache.shiro.authz" value="${shiro.version}"/>
<entry key="org.apache.shiro.authz.annotation"
value="${shiro.version}"/>
<entry key="org.apache.shiro.authz.aop"
value="${shiro.version}"/>
<entry key="org.apache.shiro.authz.permission"
value="${shiro.version}"/>
<entry key="org.apache.shiro.cache" value="${shiro.version}"/>
<entry key="org.apache.shiro.codec" value="${shiro.version}"/>
<entry key="org.apache.shiro.concurrent"
value="${shiro.version}"/>
<entry key="org.apache.shiro.config" value="${shiro.version}"/>
<entry key="org.apache.shiro.crypto" value="${shiro.version}"/>
<entry key="org.apache.shiro.crypto.hash"
value="${shiro.version}"/>
<entry key="org.apache.shiro.io" value="${shiro.version}"/>
<entry key="org.apache.shiro.jndi" value="${shiro.version}"/>
<entry key="org.apache.shiro.mgt" value="${shiro.version}"/>
<entry key="org.apache.shiro.realm" value="${shiro.version}"/>
<entry key="org.apache.shiro.realm.activedirectory"
value="${shiro.version}"/>
<entry key="org.apache.shiro.realm.jdbc"
value="${shiro.version}"/>
<entry key="org.apache.shiro.realm.jndi"
value="${shiro.version}"/>
<entry key="org.apache.shiro.realm.ldap"
value="${shiro.version}"/>
<entry key="org.apache.shiro.realm.text"
value="${shiro.version}"/>
<entry key="org.apache.shiro.session" value="${shiro.version}"/>
<entry key="org.apache.shiro.session.mgt"
value="${shiro.version}"/>
<entry key="org.apache.shiro.session.mgt.eis"
value="${shiro.version}"/>
<entry key="org.apache.shiro.subject" value="${shiro.version}"/>
<entry key="org.apache.shiro.subject.support"
value="${shiro.version}"/>
<entry key="org.apache.shiro.util" value="${shiro.version}"/>
where ${shiro.version} for us is currently 1.2.0.SNAPSHOT (but would work fine
with 1.1.0 (Felix doesn't like versions like 1.2.0-SNAPSHOT; hence the
.SNAPSHOT instead). You might not need to export all of these, and you may need
to export more. These are all system packages, for us (seed bundles may have
been the wrong term).
From: [email protected]
To: [email protected]
Subject: RE: Cant access subject with Eclipse RAP
Date: Mon, 10 Jan 2011 17:57:32 -0700
Lothar, have you tried adding Shiro into the seed bundles exported by the OSGi
container? Those packages are available in all class loaders, and are the same
instances. That's how we're publishing Shiro in our OSGi application (built on
Felix, but we've also tested it on Equinox) and it appears to work without any
issues.
Best regards,
Bryan Turner
> From: [email protected]
> To: [email protected]
> Subject: Re: Cant access subject with Eclipse RAP
> Date: Mon, 10 Jan 2011 14:31:03 -0800
>
> On Monday, January 10, 2011, Jared Bunting wrote:
> > I'm only just starting to learn about OSGI and I don't know anything about
> > Eclipse RAP so I may be way off the mark here. It looks like shiro is
> > getting loaded twice - once by your webapp (or whatever does the filtering)
> > and once by your RAP application. Seems like both of them (assuming they
> > are both bundles?) should do an Import-Package on shiro (and have a shiro
> > bundle) or one should Export-Package on shiro and the other should import
> > it. From what I've read (ie. take it with a grain of salt), I would think
> > this would allow your original code to work.
>
> Import or export declarations are not the problem here. OSGi uses special
> class loaders and the OSGi class loader is definitely another one than the
> class loader of the web container (tomcat) that executes the initial
> authentication with Shiro.
> So what's needed is a way to transfer the state of the subject (and possibly
> the security manager) to a (probably new) subject that got created with the
> correct class loader.
>
>
> Lothar
