Kalle, I see you already committed this change! Thanks for the prompt action. I agree that very few situations would not specify Spring dependency somewhere else.
Tauren On Mon, Feb 8, 2010 at 8:41 AM, Les Hazlewood <[email protected]> wrote: > 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 > >>>>>>> > >>>>> > >>> > >>> > >> > > >
