shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Marev (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SHIRO-389) Fix OSGI Exports for shiro-ehcache
Date Mon, 07 Jan 2013 18:04:14 GMT

    [ https://issues.apache.org/jira/browse/SHIRO-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546104#comment-13546104
] 

Mladen Marev edited comment on SHIRO-389 at 1/7/13 6:03 PM:
------------------------------------------------------------

Hi Les,

Of course not. That someone will create a fragment to shiro core in order to load properly.
This new bundle will be under the control of the implementer and has no role here.
Here we are talking about out-of-the-box behavior of the released shiro bundles, right? Imagine
we are placing shiro bundles in OSGi and want out-of-the-box to start a caching authentication.
We have to be able to do it without modifying original bundles. We have to be able to just
edit shiro.ini. We have several options for succeeding:
1. shiro-ehcache to be a fragment to shiro-core, or
2. shiro-core to have optional import of shiro-ehcache package.
3. use blueprint to initialize defaultsecuritymanager before actually calling shiro functions.
(This is too static and not working for my case)
4. add ClassLoader parameter to IniSecurityManagerFactory constructor (maybe to other factories
too) - as additional class loader for classes. This way user bundle can import everything
it needs and supply the classloader to the factory. This is the best OSGi approach in my opinion,
but I doubt it will be implemented.
As I said earlier, I would prefer optional import as fastest and least intrusive approach.
                
      was (Author: mdmarev):
    Hi Les,

Of course not. That someone will create a fragment to shiro core in order to load properly.
This new bundle will be under the control of the implementer and has no role here.
Here we are talking about out-of-the-box behavior of the released shiro bundles, right? Imagine
we are placing shiro bundles in OSGi and want out-of-the-box to start a caching authentication.
We have to be able to do it without modifying original bundles. We have to be able to just
edit shiro.ini. We have two options for succeeding:
1. shiro-ehcache to be a fragment to shiro-core, or
2. shiro-core to have optional import of shiro-ehcache package.
3. use blueprint to initialize defaultsecuritymanager before actually calling shiro functions.
(This is too static and not working for my case)
4. add ClassLoader parameter to IniSecurityManagerFactory constructor (maybe to other factories
too) - as additional class loader for classes. This way user bundle can import everything
it needs and supply the classloader to the factory. This is the best OSGi approach in my opinion,
but I doubt it will be implemented.
As I said earlier, I would prefer optional import as fastest and least intrusive approach.
                  
> Fix OSGI Exports for shiro-ehcache
> ----------------------------------
>
>                 Key: SHIRO-389
>                 URL: https://issues.apache.org/jira/browse/SHIRO-389
>             Project: Shiro
>          Issue Type: Bug
>          Components: Caching 
>    Affects Versions: 1.2.0, 1.2.1
>            Reporter: Chris Geer
>            Assignee: Les Hazlewood
>             Fix For: 1.2.2, 1.3.0
>
>         Attachments: SHIRO_389_core.patch, SHIRO-389.patch
>
>
> Currently the osgi-export in the pom file is org.apache.shiro.ehcache which isn't a valid
package. It should be changed to org.apache.shiro.cache.ehcache

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message