Hi Kalle, +1
I think this is a good idea - I must be "having a case of the Mondays" ;). Yes, almost everyone who uses shiro-spring integration will most certainly specify their Spring dependency elsewhere. Cheers, Les On Mon, Feb 8, 2010 at 11:30 AM, Kalle Korhonen <[email protected]> wrote: > 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 >>>>>>> >>>>> >>> >>> >> >
