Quantcast

Shiro and multiple wars within the same Servlet Container

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Shiro and multiple wars within the same Servlet Container

Mike K
Question for the experts:
How are Realm instances, caches, and the like shared by multiple Shiro-enabled wars running within the same Tomcat Servlet Container?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

armandoxxx
Hey ...

I really don't think they are ... unless you use "outside" caching sistems and/or databases etc...

if your realm in different application connects to the same LDAP or DATABASE, well that speaks for itself..

bye

Armando
PS: I hope I understood your question ...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

slott
I guess you are asking this to achieve SSO between your webapps running on the same Tomcat (Jetty etc).

I have been wondering about the same thing, and find the suggestions on this forum about using Terracotta or similar enterprise distributed caches to be quite an overkill for this situation.

After my 5 min research into the issue, there does not immediately seem like you can share the shiro native session between apps on a single web container out of the box.

But perhaps it is possible (and easier) to share such resources using Redis or Memcached,... etc?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

f a v
If it helps as an example, I've used ehcache and this configuration.

shiro.ini:

# Cache for single sign on
ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
securityManager.cacheManager = $ssoCacheManager

# native for single sign on
securityManager.sessionMode = native

# DAO for single sign on
sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
securityManager.sessionManager.sessionDAO = $sessionDAO

# cookie for single sign on
cookie = org.apache.shiro.web.servlet.SimpleCookie
cookie.name = SSOcookie
cookie.path = /
securityManager.sessionManager.sessionIdCookie = $cookie

# etc...

ehcache.xml:

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"
        monitoring="autodetect" dynamicConfig="true">

        <diskStore path="java.io.tmpdir" />

        <cacheManagerPeerProviderFactory
                class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
                properties="peerDiscovery=automatic,
                        multicastGroupAddress=230.0.0.1,
                        multicastGroupPort=4446, timeToLive=1"
                propertySeparator="," />

        <cacheManagerPeerListenerFactory
                class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" />

        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"
                eternal="true" overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
                <cacheEventListenerFactory
                        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />
        </cache>

        <defaultCache maxElementsInMemory="100" eternal="true"
                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
        </defaultCache>
</ehcache>
On Thu, Sep 23, 2010 at 11:09 AM, slott
<[hidden email]> wrote:

>
> I guess you are asking this to achieve SSO between your webapps running on
> the same Tomcat (Jetty etc).
>
> I have been wondering about the same thing, and find the suggestions on this
> forum about using Terracotta or similar enterprise distributed caches to be
> quite an overkill for this situation.
>
> After my 5 min research into the issue, there does not immediately seem like
> you can share the shiro native session between apps on a single web
> container out of the box.
>
> But perhaps it is possible (and easier) to share such resources using Redis
> or Memcached,... etc?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Les Hazlewood
Administrator
f a v's approach is a good one.

Shiro's Security

On Thu, Sep 23, 2010 at 7:44 AM, f a v <[hidden email]> wrote:

> If it helps as an example, I've used ehcache and this configuration.
>
> shiro.ini:
>
> # Cache for single sign on
> ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
> securityManager.cacheManager = $ssoCacheManager
>
> # native for single sign on
> securityManager.sessionMode = native
>
> # DAO for single sign on
> sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
> securityManager.sessionManager.sessionDAO = $sessionDAO
>
> # cookie for single sign on
> cookie = org.apache.shiro.web.servlet.SimpleCookie
> cookie.name = SSOcookie
> cookie.path = /
> securityManager.sessionManager.sessionIdCookie = $cookie
>
> # etc...
>
> ehcache.xml:
>
> <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"
>        monitoring="autodetect" dynamicConfig="true">
>
>        <diskStore path="java.io.tmpdir" />
>
>        <cacheManagerPeerProviderFactory
>                class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
>                properties="peerDiscovery=automatic,
>                        multicastGroupAddress=230.0.0.1,
>                        multicastGroupPort=4446, timeToLive=1"
>                propertySeparator="," />
>
>        <cacheManagerPeerListenerFactory
>                class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" />
>
>        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"
>                eternal="true" overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>                <cacheEventListenerFactory
>                        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />
>        </cache>
>
>        <defaultCache maxElementsInMemory="100" eternal="true"
>                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>        </defaultCache>
> </ehcache>
> On Thu, Sep 23, 2010 at 11:09 AM, slott
> <[hidden email]> wrote:
>>
>> I guess you are asking this to achieve SSO between your webapps running on
>> the same Tomcat (Jetty etc).
>>
>> I have been wondering about the same thing, and find the suggestions on this
>> forum about using Terracotta or similar enterprise distributed caches to be
>> quite an overkill for this situation.
>>
>> After my 5 min research into the issue, there does not immediately seem like
>> you can share the shiro native session between apps on a single web
>> container out of the box.
>>
>> But perhaps it is possible (and easier) to share such resources using Redis
>> or Memcached,... etc?
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Les Hazlewood-2
In reply to this post by f a v
f a v's approach is a good one.

Shiro's SecurityManager is mostly intended to be an application
singleton - i.e. one instance per application.

However, it is possible to set the SecurityManager as a VM-wide
(container-wide) static singleton via
SecurityUtils.setSecurityManager.  This is almost exclusively used in
standalone apps, say, a Swing desktop application, where it is
expected to have only one application running on the VM.

I suppose one of your apps could set-up/configure the SecurityManager
and all of it's constituent components (realms, CacheManager, DAO's,
etc) and then it could be shared across applications by calling
SecurityUtils.getSecurityManager().

However, I've never tested this approach, and I personally feel it
might be a brittle solution.  f a v's approach of having each app have
its own SecurityManager and sharing a cache is a 'cleaner' approach in
my opinion.  It allows each app to configure their own settings, their
own URL policies (if they're web apps), and whatever else they want.

The shared cache approach with Ehcache + the cookie settings f a v
showed will get you single sign-on for apps hosted on the same
machine, which will work well.  If you want to use this technique for
SSO across applications hosted on multiple machines, only then would
you need to use a distributed cache like Terracotta.

Mike - does this address your original question?

Les

On Thu, Sep 23, 2010 at 7:44 AM, f a v <[hidden email]> wrote:

> If it helps as an example, I've used ehcache and this configuration.
>
> shiro.ini:
>
> # Cache for single sign on
> ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
> securityManager.cacheManager = $ssoCacheManager
>
> # native for single sign on
> securityManager.sessionMode = native
>
> # DAO for single sign on
> sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
> securityManager.sessionManager.sessionDAO = $sessionDAO
>
> # cookie for single sign on
> cookie = org.apache.shiro.web.servlet.SimpleCookie
> cookie.name = SSOcookie
> cookie.path = /
> securityManager.sessionManager.sessionIdCookie = $cookie
>
> # etc...
>
> ehcache.xml:
>
> <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"
>        monitoring="autodetect" dynamicConfig="true">
>
>        <diskStore path="java.io.tmpdir" />
>
>        <cacheManagerPeerProviderFactory
>                class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
>                properties="peerDiscovery=automatic,
>                        multicastGroupAddress=230.0.0.1,
>                        multicastGroupPort=4446, timeToLive=1"
>                propertySeparator="," />
>
>        <cacheManagerPeerListenerFactory
>                class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" />
>
>        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"
>                eternal="true" overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>                <cacheEventListenerFactory
>                        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />
>        </cache>
>
>        <defaultCache maxElementsInMemory="100" eternal="true"
>                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>        </defaultCache>
> </ehcache>
> On Thu, Sep 23, 2010 at 11:09 AM, slott
> <[hidden email]> wrote:
>>
>> I guess you are asking this to achieve SSO between your webapps running on
>> the same Tomcat (Jetty etc).
>>
>> I have been wondering about the same thing, and find the suggestions on this
>> forum about using Terracotta or similar enterprise distributed caches to be
>> quite an overkill for this situation.
>>
>> After my 5 min research into the issue, there does not immediately seem like
>> you can share the shiro native session between apps on a single web
>> container out of the box.
>>
>> But perhaps it is possible (and easier) to share such resources using Redis
>> or Memcached,... etc?
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Les Hazlewood-2
Actually, looking at f a v's ehcache.xml, you don't even need
terracotta if you don't want to use it - apparently it's using
Ehcache's built-in distributed clustering mechanism.  I don't know if
this 'hooks in' to TerraCotta or not though.  Very cool.

Les

On Thu, Sep 23, 2010 at 12:11 PM, Les Hazlewood <[hidden email]> wrote:

> f a v's approach is a good one.
>
> Shiro's SecurityManager is mostly intended to be an application
> singleton - i.e. one instance per application.
>
> However, it is possible to set the SecurityManager as a VM-wide
> (container-wide) static singleton via
> SecurityUtils.setSecurityManager.  This is almost exclusively used in
> standalone apps, say, a Swing desktop application, where it is
> expected to have only one application running on the VM.
>
> I suppose one of your apps could set-up/configure the SecurityManager
> and all of it's constituent components (realms, CacheManager, DAO's,
> etc) and then it could be shared across applications by calling
> SecurityUtils.getSecurityManager().
>
> However, I've never tested this approach, and I personally feel it
> might be a brittle solution.  f a v's approach of having each app have
> its own SecurityManager and sharing a cache is a 'cleaner' approach in
> my opinion.  It allows each app to configure their own settings, their
> own URL policies (if they're web apps), and whatever else they want.
>
> The shared cache approach with Ehcache + the cookie settings f a v
> showed will get you single sign-on for apps hosted on the same
> machine, which will work well.  If you want to use this technique for
> SSO across applications hosted on multiple machines, only then would
> you need to use a distributed cache like Terracotta.
>
> Mike - does this address your original question?
>
> Les
>
> On Thu, Sep 23, 2010 at 7:44 AM, f a v <[hidden email]> wrote:
>> If it helps as an example, I've used ehcache and this configuration.
>>
>> shiro.ini:
>>
>> # Cache for single sign on
>> ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
>> ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml
>> securityManager.cacheManager = $ssoCacheManager
>>
>> # native for single sign on
>> securityManager.sessionMode = native
>>
>> # DAO for single sign on
>> sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
>> securityManager.sessionManager.sessionDAO = $sessionDAO
>>
>> # cookie for single sign on
>> cookie = org.apache.shiro.web.servlet.SimpleCookie
>> cookie.name = SSOcookie
>> cookie.path = /
>> securityManager.sessionManager.sessionIdCookie = $cookie
>>
>> # etc...
>>
>> ehcache.xml:
>>
>> <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>        xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"
>>        monitoring="autodetect" dynamicConfig="true">
>>
>>        <diskStore path="java.io.tmpdir" />
>>
>>        <cacheManagerPeerProviderFactory
>>                class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
>>                properties="peerDiscovery=automatic,
>>                        multicastGroupAddress=230.0.0.1,
>>                        multicastGroupPort=4446, timeToLive=1"
>>                propertySeparator="," />
>>
>>        <cacheManagerPeerListenerFactory
>>                class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" />
>>
>>        <cache name="shiro-activeSessionCache" maxElementsInMemory="600"
>>                eternal="true" overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>>                <cacheEventListenerFactory
>>                        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" />
>>        </cache>
>>
>>        <defaultCache maxElementsInMemory="100" eternal="true"
>>                overflowToDisk="true" memoryStoreEvictionPolicy="LFU">
>>        </defaultCache>
>> </ehcache>
>> On Thu, Sep 23, 2010 at 11:09 AM, slott
>> <[hidden email]> wrote:
>>>
>>> I guess you are asking this to achieve SSO between your webapps running on
>>> the same Tomcat (Jetty etc).
>>>
>>> I have been wondering about the same thing, and find the suggestions on this
>>> forum about using Terracotta or similar enterprise distributed caches to be
>>> quite an overkill for this situation.
>>>
>>> After my 5 min research into the issue, there does not immediately seem like
>>> you can share the shiro native session between apps on a single web
>>> container out of the box.
>>>
>>> But perhaps it is possible (and easier) to share such resources using Redis
>>> or Memcached,... etc?
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Mike K
Thanks everyone.
Yes Les, this answers my question and I agree on the brittleness.
I am using ZooKeeper as the caching/clustering mechanism, but the basic idea from fav is the same.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
Hi,

I've got some problem with sharing Ehcache between two applications within one Tomcat instance.
I've tried f a v's solution but unfortunatelly it doesn't work for me and I am wondering if something changed from the last 2 years.

This is what I am using now:
1. Apache Shiro 1.2.0
2. Ehcache 2.5.2
3. Apache Tomcat 6.0.35

I've put ehcache-core-2.5.2.jar in Tomcat's lib folder and shiro-ehcache-1.2.0.jar in the projects' classpath.

After running the second application f a v's solution gives me such error:

org.apache.shiro.cache.CacheException: net.sf.ehcache.CacheException: Another unnamed CacheManager already exists in the same VM. Please provide unique names for each CacheManager in the config or do one of following:
1. Use one of the CacheManager.create() static factory methods to reuse same CacheManager with same name or create one if necessary
2. Shutdown the earlier cacheManager before creating new one with same name.

Any ideas?
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

jleleu
Hi,

I remember another thread on this EhCache problem : http://shiro-user.582556.n2.nabble.com/EhCache-initialization-exception-Another-unnamed-CacheManager-already-exists-in-the-same-VM-td7577532.html.
Take a look at it.
Best regards,
Jérôme
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
Thank you Jérôme. I appreciate your help but I've seen this topic before.
Jared Bunting-2 is suggesting that the only way to use one shared ehache instance for multiple applications in the same VM is to implement some custom CacheManagerFactory.

Is this the only way to solve my problem?
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Jared Bunting-2

If you want to share the CacheManager across webapps, then yes, you will need a custom factory.  Fortunately this would only be like a one line method.

-Jared

On Jun 29, 2012 2:29 AM, "PPiatkowski" <[hidden email]> wrote:
Thank you Jérôme. I appreciate your help but I've seen this topic before.
Jared Bunting-2 is suggesting that the only way to use one shared ehache
instance for multiple applications in the same VM is to implement some
custom CacheManagerFactory.

Is this the only way to solve my problem?

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577558.html
Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
Jared, could you please give me a little hint how to achieve this "one line method"?

You've told that factory class should implement org.apache.shiro.util.Factory interface. It gives us T getInstance() method to implement in our class.

I think that getInstance() method should return EhCacheManager object but how can I create instance or return from some context for example by given Ehcache name?

Pawel
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Jared Bunting-2
Bear in mind that I haven't done this myself.  But the issue resolves
around the fact that EhCache only allows one CacheManager per name
statically, and Shiro doesn't use EhCache's "create or retrieve"
method.  I personally don't care for the EhCache pattern here - in my
mind passing in a config file and potentially getting back a
CacheManager that is completely unrelated except that it shares the
same name is a fair bit counterintuitive to me.  Seems to open up the
doors to confusing and misleading problems down the road.

However, if you want to share a single CacheManager between multiple
webapps you need to instructor Shiro to use EhCache's create or
retrieve method.

The factory should look something like this:

package com.example.shiro;

import net.sf.ehcache.CacheManager;
import org.apache.shiro.util.Factory;

public class SharedEhCacheManagerFactory implements
Factory<CacheManager>
{
        private String configFile;

        @Override
        public CacheManager getInstance()
        {
                return CacheManager.newInstance(this.configFile);
        }

        public String getConfigFile()
        {
                return configFile;
        }

        public void setConfigFile(final String configFile)
        {
                this.configFile = configFile;
        }
}


And then your shiro.ini would look something like this:

ehCacheManager = com.example.shiro.SharedEhCacheManagerFactory
cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
cacheManager.cacheManager=$ehCacheManager


Hope that helps,
Jared

On Fri 29 Jun 2012 07:17:18 AM CDT, PPiatkowski wrote:

> Jared, could you please give me a little hint how to achieve this "one line
> method"?
>
> You've told that factory class should implement
> org.apache.shiro.util.Factory interface. It gives us T getInstance() method
> to implement in our class.
>
> I think that getInstance() method should return EhCacheManager object but
> how can I create instance or return from some context for example by given
> Ehcache name?
>
> Pawel
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577562.html
> Sent from the Shiro User mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
Hi Jared,

Thank you for your advice.
I've tried something like this:

public class EhCacheManagerFactory implements Factory<CacheManager> {

        public CacheManager getInstance() {
                return CacheManager.create();
        }
}


which should work similar to your solution but when I try to get session with conrete id [sessionIdFromParam]:

Subject currentUser = new Subject.Builder().sessionId(sessionIdFromParam).buildSubject();

passed by GET parameter I get the following exception:

java.lang.ClassCastException: org.apache.shiro.session.mgt.SimpleSession cannot be cast to org.apache.shiro.session.Session
        org.apache.shiro.session.mgt.eis.CachingSessionDAO.getCachedSession(CachingSessionDAO.java:217)
        org.apache.shiro.session.mgt.eis.CachingSessionDAO.getCachedSession(CachingSessionDAO.java:202)
        org.apache.shiro.session.mgt.eis.CachingSessionDAO.readSession(CachingSessionDAO.java:259)
        org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSessionFromDataSource(DefaultSessionManager.java:236)
        org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSession(DefaultSessionManager.java:222)
        org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
        org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105)
        org.apache.shiro.session.mgt.AbstractNativeSessionManager.getSession(AbstractNativeSessionManager.java:97)
        org.apache.shiro.mgt.SessionsSecurityManager.getSession(SessionsSecurityManager.java:125)
        org.apache.shiro.mgt.DefaultSecurityManager.resolveContextSession(DefaultSecurityManager.java:456)
        org.apache.shiro.mgt.DefaultSecurityManager.resolveSession(DefaultSecurityManager.java:442)
        org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:338)
        org.apache.shiro.subject.Subject$Builder.buildSubject(Subject.java:846)
        pl.compugroup.servlet.SessionServlet.doGet(SessionServlet.java:57)
        javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
        org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
        org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
        org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
        org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:380)
        org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
        org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)


It happens only when I try to retrieve session created in application A from application B so it looks that something works here.

I've got such shiro.ini configuration:

ehCacheManager = pl.compugroup.shiro.EhCacheManagerFactory
cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
cacheManager.cacheManager = $ehCacheManager
cacheManager.cacheManagerConfigFile = classpath:ehcache.xml
securityManager.cacheManager = $cacheManager

sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager

sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
sessionManager.sessionDAO = $sessionDAO
securityManager.sessionManager = $sessionManager
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Jared Bunting-2
Looks like a classloader issue.  My guess is that you have the shiro
jars in the war files, rather than at the same level as the ehcache
jar?  In order for this to work, both applications would need to load
the shiro classes from the same classloader.  This probably means
putting the shiro jars at the server level, the same way as you have
done ehcache.  (org.apache.shiro.session.Session loading in application
A != org.apache.shiro.session.Session loaded in application B)

Hope that helps,
Jared

On Fri 06 Jul 2012 07:36:03 AM CDT, Pawel_Piatkowski wrote:

> Hi Jared,
>
> Thank you for your advice.
> I've tried something like this:
>
> /public class EhCacheManagerFactory implements Factory<CacheManager> {
>
> public CacheManager getInstance() {
> return CacheManager.create();
> }
> }/
>
> which should work similar to your solution but when I try to get session
> with conrete id [*sessionIdFromParam*]:
>
> /Subject currentUser = new
> Subject.Builder().sessionId(*sessionIdFromParam*).buildSubject();/
>
> passed by GET parameter I get the following exception:
>
> /java.lang.ClassCastException: org.apache.shiro.session.mgt.SimpleSession
> cannot be cast to org.apache.shiro.session.Session
>
> org.apache.shiro.session.mgt.eis.CachingSessionDAO.getCachedSession(CachingSessionDAO.java:217)
>
> org.apache.shiro.session.mgt.eis.CachingSessionDAO.getCachedSession(CachingSessionDAO.java:202)
>
> org.apache.shiro.session.mgt.eis.CachingSessionDAO.readSession(CachingSessionDAO.java:259)
>
> org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSessionFromDataSource(DefaultSessionManager.java:236)
>
> org.apache.shiro.session.mgt.DefaultSessionManager.retrieveSession(DefaultSessionManager.java:222)
>
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
>
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:105)
>
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.getSession(AbstractNativeSessionManager.java:97)
>
> org.apache.shiro.mgt.SessionsSecurityManager.getSession(SessionsSecurityManager.java:125)
>
> org.apache.shiro.mgt.DefaultSecurityManager.resolveContextSession(DefaultSecurityManager.java:456)
>
> org.apache.shiro.mgt.DefaultSecurityManager.resolveSession(DefaultSecurityManager.java:442)
>
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:338)
> org.apache.shiro.subject.Subject$Builder.buildSubject(Subject.java:846)
> pl.compugroup.servlet.SessionServlet.doGet(SessionServlet.java:57)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>
> org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>
> org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>
> org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>
> org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>
> org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:380)
>
> org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)/
>
> It happens only when I try to retrieve session created in application A from
> application B so it looks that something works here.
>
> I've got such shiro.ini configuration:
>
> /ehCacheManager = pl.compugroup.shiro.EhCacheManagerFactory
> cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> cacheManager.cacheManager = $ehCacheManager
> cacheManager.cacheManagerConfigFile = classpath:ehcache.xml
> securityManager.cacheManager = $cacheManager
>
> sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
>
> sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO
> sessionManager.sessionDAO = $sessionDAO
> securityManager.sessionManager = $sessionManager/
>
> -----
> -----------------------
> Paweł Piątkowski
> http://pl.linkedin.com/in/ppiatkowski
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577572.html
> Sent from the Shiro User mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
It was it! Thanks a lot Jared!

I've thought ehcache-core-2.5.2.jar on the server libs is sufficient.

I think that it should be described somewhere in the documentation in the future.
Running multiple applications with the same cache on one server is very popular case I think.
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
I've got some problems with integrating EhCacheManagerFactory with my Spring application.
As I noticed there is no possibility to use a plain shiro.ini configuration file with Spring Framework.

We can only define [Users] and [Roles] sections in ini file and connect it in xml configuration in this way:

<bean name="iniRealm" class="org.apache.shiro.realm.text.IniRealm">
        <constructor-arg type="java.lang.String" value="classpath:shiro.ini"/>
</bean>


Please let me know if I am wrong.

I was trying to reconstruct my shiro.ini's [Main] section which is:

ehCacheManager = my.package.shiro.EhCacheManagerFactory
cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
cacheManager.cacheManager = $ehCacheManager
securityManager.cacheManager = $cacheManager


to xml form and I've got:

<bean id="ehCacheManager" class="my.package.shiro.EhCacheManagerFactory"/>
   
<bean id="cacheManager" class="org.apache.shiro.cache.ehcache.EhCacheManager">
        <property name="cacheManager" ref="ehCacheManager"/>
</bean>
   
<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
        <property name="cacheManager" ref="cacheManager"/>
</bean>


Unfortunately I have such error during deployment:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shiroFilter' defined in ServletContext resource [/WEB-INF/spring/root-context.xml]: BeanPostProcessor before instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.shiro.spring.security.interceptor.AuthorizationAttributeSourceAdvisor#0' defined in ServletContext resource [/WEB-INF/spring/root-context.xml]: Cannot resolve reference to bean 'securityManager' while setting bean property 'securityManager'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'securityManager' defined in ServletContext resource [/WEB-INF/spring/root-context.xml]: Cannot resolve reference to bean 'cacheManager' while setting bean property 'cacheManager'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cacheManager' defined in ServletContext resource [/WEB-INF/spring/root-context.xml]: Initialization of bean failed; nested exception is org.springframework.beans.ConversionNotSupportedException: Failed to convert property value of type 'my.package.shiro.shiro.EhCacheManagerFactory' to required type 'net.sf.ehcache.CacheManager' for property 'cacheManager'; nested exception is java.lang.IllegalStateException: Cannot convert value of type [my.package.shiro.shiro.EhCacheManagerFactory] to required type [net.sf.ehcache.CacheManager] for property 'cacheManager': no matching editors or conversion strategy found

Does anyone knows what should I do now?
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Les Hazlewood-2
The Shiro Factory interface will resolve to its constructed instance
in Shiro's .ini configuration automatically.

It will not do that in Spring configuration however (Spring has no
knowledge of Shiro's Factory concept and therefore doesn't know how to
automatically resolve the Factory's created instance).

Instead, Spring can support what you want by implementing Spring's
FactoryBean interface.

If your my.package.shiro.EhCacheManagerFactory implementation
implemented FactoryBean (or even better, subclassed
AbstractFactoryBean), I think you will have what you want, but note:

If you're going to do all this in Spring, maybe you should be using
Spring's out-of-the-box EhCacheManagerFactoryBean which already
provides an EhCacheManager in a Spring environment.  I don't know if
it will meet your needs, but it is probably worth checking it out
before you develop your own.

HTH,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk


On Thu, Jul 12, 2012 at 7:09 AM, Paweł Piątkowski
<[hidden email]> wrote:

> I've got some problems with integrating EhCacheManagerFactory with my Spring
> application.
> As I noticed there is no possibility to use a plain shiro.ini configuration
> file with Spring Framework.
>
> We can only define [Users] and [Roles] sections in ini file and connect it
> in xml configuration in this way:
> */
> <bean name="iniRealm" class="org.apache.shiro.realm.text.IniRealm">
>         <constructor-arg type="java.lang.String" value="classpath:shiro.ini"/>
> </bean>/*
>
> Please let me know if I am wrong.
>
> I was trying to reconstruct my shiro.ini's [Main] section which is:
> *
> /ehCacheManager = my.package.shiro.EhCacheManagerFactory
> cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> cacheManager.cacheManager = $ehCacheManager
> securityManager.cacheManager = $cacheManager/*
>
> to xml form and I've got:
> *
> /<bean id="ehCacheManager" class="my.package.shiro.EhCacheManagerFactory"/>
>
> <bean id="cacheManager"
> class="org.apache.shiro.cache.ehcache.EhCacheManager">
>         <property name="cacheManager" ref="ehCacheManager"/>
> </bean>
>
> <bean id="securityManager"
> class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
>         <property name="cacheManager" ref="cacheManager"/>
> </bean>/*
>
> Unfortunately I have such error during deployment:
>
> /org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'shiroFilter' defined in ServletContext resource
> [/WEB-INF/spring/root-context.xml]: BeanPostProcessor before instantiation
> of bean failed; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name
> 'org.apache.shiro.spring.security.interceptor.AuthorizationAttributeSourceAdvisor#0'
> defined in ServletContext resource [/WEB-INF/spring/root-context.xml]:
> Cannot resolve reference to bean 'securityManager' while setting bean
> property 'securityManager'; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'securityManager' defined in ServletContext resource
> [/WEB-INF/spring/root-context.xml]: Cannot resolve reference to bean
> 'cacheManager' while setting bean property 'cacheManager'; nested exception
> is org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'cacheManager' defined in ServletContext resource
> [/WEB-INF/spring/root-context.xml]: Initialization of bean failed; nested
> exception is org.springframework.beans.ConversionNotSupportedException:
> Failed to convert property value of type
> 'my.package.shiro.shiro.EhCacheManagerFactory' to required type
> 'net.sf.ehcache.CacheManager' for property 'cacheManager'; nested exception
> is java.lang.IllegalStateException: *Cannot convert value of type
> [my.package.shiro.shiro.EhCacheManagerFactory] to required type
> [net.sf.ehcache.CacheManager] for property 'cacheManager': no matching
> editors or conversion strategy found/*
>
> Does anyone knows what should I do now?
>
> -----
> -----------------------
> Paweł Piątkowski
> http://pl.linkedin.com/in/ppiatkowski
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577596.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shiro and multiple wars within the same Servlet Container

Paweł Piątkowski
Thank you Les!

<bean id="ehCacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
    <property name="shared" value="true"/>
</bean>


works like a charm :)
-----------------------
Paweł Piątkowski
http://pl.linkedin.com/in/ppiatkowski
12
Loading...