I'm wondering - shouldn't we do this for all of our support modules then?
On Mon, Feb 8, 2010 at 12:32 PM, Tauren Mills <[email protected]> wrote: > 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 >> >>>>>>> >> >>>>> >> >>> >> >>> >> >> >> > > >
