On 08/17/2011 10:11 AM, manitas wrote: > Great investigation ! I hope this will solve the "deprecated api" issue. Well, the fact remains that we need access to the ServletContext in singletons, and guice-servlet doesn't provide a ServletContext (w/o the warning) until after singletons are instantiated. So we have to provide one.
That being said, I consider the "deprecated api" issue to be resolved - there is a solution for it in svn and the warnings don't appear anymore. > I've another issue due to the fact that ShiroModule is a private module. I > do not know how to expose one of my custom realm. I need to inject some > elements in it from another module. Does expose(MyCustomRealm1.class) not work for you? In addition, if you need to inject elements into it, then it doesn't need to be exposed at all - it has full access to anything outside of ShiroModule (provided those things aren't also in a PrivateModule). The dependency is what needs to be exposed. > I've seen that there is a work around but I'm sure to know how to use it in > that case : > http://markmail.org/message/pvjcz5akerw3ynae#query:+page:1+mid:pvjcz5akerw3ynae+state:results > maybe you can help me on that point. Do you need the list? Or do you need specific realms? > Another point I've seen in the ShiroModule code is that you encapsulate > guice multibinding mechanism in the bindRealm() function. IMHO, I'm not sure > this is a good idea because end users need to know which mechanism is used > behind. I think that the main goal of the shiro-guice library is to > encapsulate internal configuration of shiro but not guice mechanisms and > particularly on this part directly used by the end users. The bindRealm method encapsulates how realms are provided to the SecurityManager. The fact that it uses Multibinder is an implementation detail that I'd rather not expose. If you really need access to the collection of realms, I recommend binding to: Collection<Realm> You would also need to expose that key if you needed access to it outside of Shiro. Just so that you know, this is what I meant by encouraging good practices. The Realm is an interface whose primary purpose is to be implemented by the end user and consumed by the framework. The intended manner of interacting with the framework is through the SecurityManager. That being said, I fully understand that some situations call for using the framework slightly different than intended and that good practices rightfully fall victim to the realities of a situation. That's why I am more than happy to help you figure out what you need to get your application working but I don't feel it is how we should set things up by default. Thanks, Jared
