|
Hello,
I would like to use Shiro within my JavaEE based web application. User and credential data is stored inside a database. So I wrote my own Realm, extending org.apache.shiro.realm.AuthorizingRealm. This realm makes use of EJBs/JPA to read the data from the database. An instance of this realm has to be placed in a DefaultWebSecurityManager. To put all togehter, I would like to use the CDI/EJB facilities of the JEE container. For this I added CDI annotations to my realm and to a SecurityManagerFactory. But trying to deploy this, I get an exception: Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437 Normal scoped bean class org.apache.shiro.realm.AuthenticatingRealm is not proxyable because the type is final or it contains a final method public final void org.apache.shiro.realm.AuthenticatingRealm.init() - Managed Bean [class de.reschif.security.ShiroRealm] with qualifiers [@Any @Default]. The final method comes from org.apache.shiro.realm.AuthenticatingRealm. How can I solve this problem to get my realm/its resources managed by the container? Regards, Lars |
|
Delegate ?
On 26 April 2012 10:01, Lars Fischer <[hidden email]> wrote: Hello, |
|
In reply to this post by Lars Fischer
Hello Lars, A patch is posted here :
https://issues.apache.org/jira/browse/SHIRO-337 Regards, Thibault
2012/4/26 Lars Fischer <[hidden email]> Hello, |
|
Hello,
I'm sorry, I don't see, how this patch belongs to my problem. I changed my CDI configuration to use my own producer method for my realm and set this realm into a SecurityManager. But when I try to run subject.login(token); then the securityManager has no realm set. Looks like there are two different instances of SecurityManagers. One created by me and one created by the EnvironmentLoaderListener? Is it possible to add a realm lately to a SecurityManager? How can this be done. The SecurityManager interface has no such method. Can I cast it? Regards, Lars |
|
Shiro 1.2 introduced a mechanism to allow this to be configurable for any web application configuration mechanism you desire: By default, the WebEnvironment created at startup is an IniWebEnvironment, which assumes shiro.ini configuration. However, if you have another configuration mechanism, e.g. JEE CDI, you could create your own WebEnvironment implementation, e.g. JeeCdiWebEnvironment that knows how to interact with the JEE CDI infrastructure and set up Shiro that way.
The custom WebEnvironment technique is covered here: http://shiro.apache.org/web.html#Web-Custom%257B%257BWebEnvironment%257D%257DClass
Thibault, forgive me if this technique is used in the SHIRO-337 patch - I haven't looked at it in-depth yet. I'm checking it out right now...
HTH, -- Les Hazlewood CTO, Stormpath | http://stormpath.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood
blog: http://leshazlewood.com stormpath blog: http://www.stormpath.com/blog On Thu, Apr 26, 2012 at 7:26 AM, Lars Fischer <[hidden email]> wrote: Hello, |
|
Hello,
>The custom WebEnvironment technique is covered here: http://shiro.apache.org/web.html#Web-Custom%257B%257BWebEnvironment%257D%257DClass As I understand it, the mentioned technique implies "manual" injection (by new InitialContext().getBean...) of e.g. jpa-based realm into WebEnvironment. This thread: http://shiro-user.582556.n2.nabble.com/Shiro-in-CDI-JPA2-JSF2-project-td7577437.html attempts to introduce CDI-support in a an more elegant(???) way by implementing own EnvironmentLoaderListener. I tried to implement this, but since AuthorizingRealm, extended by JpaRealm in the given solution, has public final method, CDI still fails to initialize with the very same error message mentioned by Lars. Both threads (this one and the http://shiro-user.582556.n2.nabble.com/Shiro-in-CDI-JPA2-JSF2-project-td7577437.html) haven't been commented on since April so I assume everyone sees this topic as solved. My question is this - so what is the good practice to enable CDI-support in shiro nowadays? thanks and kind regards Reinis. |
|
The custom EnvironmentLoaderListener approach works fine as long as the bean doesn't have a normal scope. If you really need to use a normal scope, define an intermediary bean with the scope you need, declare the realm bean as @Dependent, and inject the latter into the former. If you're using alternatives for configuration beans, this approach dovetails quite nicely.
|
|
I don't know if this will help this thread, but this was posted two days ago:
How to integrate Apache Shiro with JEE6:
P.S. If someone wants to contribute a JEE support module, I personally would be in favor of the Shiro dev team supporting it. -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk |
|
This patch (https://issues.apache.org/jira/browse/SHIRO-337 ) works fine for me.
regards Thibault
2012/10/13 Les Hazlewood <[hidden email]> I don't know if this will help this thread, but this was posted two days ago: |
|
It's important to note that there are two different sets of issues here. The first is with regard to exposing Shiro components to client applications - this is addressed by the patches for SHIRO-337 as well as the code in the blog entry referenced by Les. The second is with regard to configuring the Shiro system to integrate with other JEE components (e.g. a Realm implementation backed by JPA) - this has not been addressed except as one-off responses to queries posted to the list. The code in the referenced blog entry does perform some configuration, though it assumes that the default INI-based configuration is sufficient (which is probably not sufficiently general and deviates from the recommended approach of using @Alternatives for type-safe configuration).
|
| Powered by Nabble | Edit this page |
