[
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
