Yea, the problem originates from us depending on spring-all but many users likely depending on only those specific Spring libs they need, in which case artifact ids don't match and you end with duplicate libs in your classpath. We should mark Spring as scope provided, presumably people don't use shiro-spring as the end dependency to get Spring. If I don't hear otherwise, I'll create a JIRA and fix it.
Kalle PS. Les, for commons-logging the situation is much the same. The proper way is to lobby the projects to mark common-logging as provided, but it's a more difficult problem to solve since there may not be any other end dependency for commons logging unless you provided one (either slf or commons-logging). We should evaluate all of our third-party dependencies and mark them as provided if at all possible - it's more difficult to go from compiled to provided than the other way around. On Mon, Feb 8, 2010 at 8:03 AM, Les Hazlewood <[email protected]> wrote: > Hi Tauren, > > Yep, this is pretty customary in Maven poms as I understand it, but > I'd love to hear if there is a better way. I have to do this > regularly for any dependency that pulls in commons-logging - I have to > manually exclude it since I use SLF4J's version instead. > > If there's a better way, I'm all ears! > > Cheers, > > Les > > On Mon, Feb 8, 2010 at 7:01 AM, Tauren Mills <[email protected]> wrote: >> Can something be done to make Shiro support either Spring 2.5.6 or Spring >> 3.0 more seamlessly? I recently upgraded from 2.5.6 to 3.0 and found that >> Shiro was including spring 2.5.6 as a dependency. I had to manually exclude >> it in my pom. >> <dependency> >> <groupId>org.apache.shiro</groupId> >> <artifactId>shiro-spring</artifactId> >> <version>${shiro.version}</version> >> <exclusions> >> <exclusion> >> <groupId>org.springframework</groupId> >> <artifactId>spring</artifactId> >> </exclusion> >> </exclusions> >> </dependency> >> The good news is that this doesn't seem to have caused any problems for my >> application. I saw another project that manages to support both versions in >> their pom, but can't remember which project it was or how they did it. I'll >> try to find it if it would help. >> Of course I'm open to suggestions if there is a better way to deal with >> this. >> Thanks, >> Tauren >> >> On Fri, Jan 22, 2010 at 5:59 PM, Jason <[email protected]> wrote: >>> >>> ah, the question wasnt how to check, but how to configure. >>> I mean how do u abandon the shiro.ini roles & permissions mechanism for >>> TextConfigurationRealm etc and model it in spring instead. >>> I thought in a previous post you mentioned this should be done. >>> >>> re the useage though I'm really keen for an aop solution, and an xml >>> element something like this: >>> <shiro:requires permissions="user:edit"/> >>> that I could just drop into any spring bean would be great. far better for >>> me than annotations. >>> >>> Cheers >>> Jason. >>> >>> >>> Les Hazlewood wrote: >>>> >>>> Hi Jason, >>>> >>>> What do you mean by 'configure permissions' exactly? Typically >>>> permission checks in standalone applications are done by explicitly >>>> checking (subject.isPermitted(blah)) or using Shiro's >>>> @RequiresPermissions annotation. >>>> >>>> Regards, >>>> >>>> Les >>>> >>>> On Thu, Jan 21, 2010 at 8:13 PM, Jason Eacott <[email protected]> >>>> wrote: >>>>> >>>>> thanks! >>>>> now how do I configure permissions etc in spring for a standalone app? >>>>> >>>>> >>>>> Les Hazlewood wrote: >>>>>> >>>>>> The upcoming Shiro 1.0 release will have improved Spring application >>>>>> support, especially for Spring web applications. >>>>>> >>>>>> In Shiro-enabled Spring web apps today, there was often a hybrid >>>>>> configuration - you would usually define an INI-based Shiro Filter in >>>>>> web.xml and configure it via INI mechanisms. But often you would >>>>>> configure the SecurityManager and its dependencies (Realms, etc) in >>>>>> applicationContext.xml. In Shiro 1.0, you will be able to configure >>>>>> all of Shiro in your Spring files and only touch web.xml only when >>>>>> setting up Shiro for the first time. >>>>>> >>>>>> There are many benefits for Spring users when configuring Shiro >>>>>> entirely in Spring instead of in web.xml: >>>>>> >>>>>> 1) Shiro configuration can live along side where you configure the >>>>>> rest of your application - no need to flip back between web.xml and >>>>>> spring files when making configuration changes. >>>>>> 2) Shiro configuration can leverage Spring-specific configuration >>>>>> benefits, such as PropertyPlaceholderConfigurer for properties based >>>>>> configuration at startup, spring-managed lifecycles (init-method, >>>>>> destroy-method), circular dependency checks, and more. >>>>>> 3) Custom javax.servlet.Filters that you could use in Shiro's powerful >>>>>> url-pattern-based filter chain definitions can also be defined in >>>>>> Spring and acquired automatically at startup. >>>>>> >>>>>> The current documentation for all of this is located here: >>>>>> >>>>>> http://cwiki.apache.org/confluence/display/SHIRO/Spring >>>>>> >>>>>> Please feel free to review and offer suggestions/improvements. The >>>>>> mechanisms documented (using Spring's DelegatingFilterProxy and the >>>>>> new ShiroFilterFactoryBean) have been tested and the two spring web >>>>>> sample applications have been updated to use this approach. >>>>>> >>>>>> Early adopters are encouraged to use this newer support before 1.0 is >>>>>> released as there probably won't be any significant changes to this >>>>>> mechanism before then. (SecurityManager configuration might be >>>>>> simplified via a Spring FactoryBean as well, but that won't affect web >>>>>> configuration). >>>>>> >>>>>> Please give it a try and let us know what you think! >>>>>> >>>>>> Best, >>>>>> >>>>>> Les >>>>>> >>>> >> >> >
