You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Mike K <mk...@semanticresearch.com> on 2010/09/22 22:50:03 UTC
Shiro and multiple wars within the same Servlet Container
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?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p5560737.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Les Hazlewood <lh...@apache.org>.
Glad to help! :)
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk
On Fri, Jul 13, 2012 at 12:45 AM, Paweł Piątkowski
<pi...@gmail.com> wrote:
> 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
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577600.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Paweł Piątkowski <pi...@gmail.com>.
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
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577600.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Les Hazlewood <lh...@apache.org>.
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
<pi...@gmail.com> 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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Paweł Piątkowski <pi...@gmail.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Pawel_Piatkowski <pi...@gmail.com>.
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
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577574.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Jared Bunting <ja...@peachjean.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Pawel_Piatkowski <pi...@gmail.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by PPiatkowski <pi...@gmail.com>.
Thank you Jared.
My final and working solution is even simpler:
public class EhCacheManagerFactory implements Factory<CacheManager> {
public CacheManager getInstance() {
return CacheManager.create();
}
}
It creates a new instance of EhCacheManager when it doesn't exist and
returns the new one when it was created before.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577571.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Jared Bunting <ja...@peachjean.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by PPiatkowski <pi...@gmail.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Jared Bunting <ja...@peachjean.com>.
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" <pi...@gmail.com> 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.
>
Re: Shiro and multiple wars within the same Servlet Container
Posted by PPiatkowski <pi...@gmail.com>.
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.
Re: Shiro and multiple wars within the same Servlet Container
Posted by jleleu <le...@gmail.com>.
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
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577557.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by PPiatkowski <pi...@gmail.com>.
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?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p7577555.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Mike K <mk...@semanticresearch.com>.
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.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p5564527.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org> 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 <fa...@gmail.com> 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
>> <be...@atchik-realtime.com> 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?
>>
>
Re: Shiro and multiple wars within the same Servlet Container
Posted by Les Hazlewood <lh...@apache.org>.
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 <fa...@gmail.com> 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
> <be...@atchik-realtime.com> 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?
>
Re: Shiro and multiple wars within the same Servlet Container
Posted by Les Hazlewood <le...@hazlewood.com>.
f a v's approach is a good one.
Shiro's Security
On Thu, Sep 23, 2010 at 7:44 AM, f a v <fa...@gmail.com> 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
> <be...@atchik-realtime.com> 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?
>
Re: Shiro and multiple wars within the same Servlet Container
Posted by f a v <fa...@gmail.com>.
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
<be...@atchik-realtime.com> 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?
Re: Shiro and multiple wars within the same Servlet Container
Posted by slott <be...@atchik-realtime.com>.
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?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p5563195.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro and multiple wars within the same Servlet Container
Posted by armandoxxx <ar...@dropchop.com>.
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 ...
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-tp5560737p5563111.html
Sent from the Shiro User mailing list archive at Nabble.com.