Hi, Just want to check whether there will be any implication if I use Shiro in EJB3.1 environment. We are planning to migrate our EJB3 application to 3.1(JEE6). Will you be releasing a new version for JEE6?
Thanks Narcom wrote: > > 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-tp3773528p3990469.html Sent from the Shiro User mailing list archive at Nabble.com.
