I also need Web + EJB + Standalone client integration. is there any example available how to use CacheManager?
Les Hazlewood-2 wrote: > > On Tue, Oct 6, 2009 at 2:07 PM, Jaco <[email protected]> wrote: >> Not having access to the annotations isn't a train wreck (I guess I could >> always write my own Interceptor), as long as I can still do everything >> programmatically. The part that I'm missing is how to configure Shiro in >> my >> EJB project (specifically the realm). For comparison in order to >> configure >> Shiro in my Web application I'd register the ShiroFilter and set the >> config >> param. > > That hasn't been worked out to a 'standard way', so to speak. > > The absolutely minimal thing required to work is that a > SecurityManager instance has been created and that it has been > configured with 1 or more realms. In simple Java code (non-web > environment): > > DefaultSecurityManager securityManager = new > org.apache.shiro.mgt.DefaultSecurityManager(); > Collection<Realm> myRealms = acquireOrInitOneOrMoreRealms(); > securityManager.setRealms(myRealms); > > Then this securityManager instance must be made available to the > application, both to any components that need to access it directly as > well as to SecurityUtils so the methods on that class function > properly. > > So, I guess that could mean wrapping up the securityManager instance > in an SLSB (or subclass DefaultSecurityManager and create, say, > Ejb3SecurityManager, and use annotations where necessary). > > Also, there needs to be an interceptor for every method invocation > and/or request that binds the securityManager and a Subject instance > to the currently running thread. That is essentially what the > ShiroFilter does in the web environment - it just triggers this logic > based on a ServletRequest instead of a method invocation. The code > that does this creation/binding has been greatly simplified this past > month, so it should be very easy to enable it in an EJB interceptor - > just look at the ShiroFilter source code as an example. > >> I see what you're saying and I can imagine that the number of remote >> invocations would be prohibitively large in most non-trivial cases. As a >> (hopefully) quick aside, how does Shiro store session values on the >> EJB-tier? > > When not using the Servlet container for session management (i.e. any > app that is not web-based or web-based apps where the business tier > and web tier must access the same session), all Session state is done > via a SessionDAO, so the implementation of that interface is entirely > up to you to do persistence however you want. > > By default, Shiro uses a CachingSessionDAO which uses a CacheManager > to store the sessions in a Cache. In practice, people in enterprise > environments are expected to configure a CacheManager that is backed > by an enterprise caching product like > TerraCotta/Coherence/GigaSpaces/etc, as this is without question the > most efficient way to store sessions, especially for larger > applications. People sometimes write their own (e.g. JdbcSessionDAO), > but of course this is much less efficient than the enterprise caching > approach. > >>> You could always post your needs in a Jira issue if you can't foresee >>> doing this yourself and we'll see if we can accommodate, but I >>> personally am hoping the community will step up and contribute to this >>> cause. >>> >> >> Thanks, but like I mentioned earlier, due to timelines this probably >> won't >> work for me (waiting for updates which, given the complexity, might take >> quite a while). But hey, thanks for the good work done on Shiro thus far. >> I >> really like the concept behind it and I feel that there is a definite >> need >> for such a solution, as container-managed security just doesn't cut it in >> some cases. > > Thanks for the encouragement! We'll be here if you find the time to > contribute :) > > Best, > > Les > > -- View this message in context: http://n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-tp3773528p3937327.html Sent from the Shiro User mailing list archive at Nabble.com.
