Sounds good!
On Mon, Feb 8, 2010 at 12:59 PM, Kalle Korhonen <[email protected]> wrote: > Yeah we should, that's what I implied in the PS. I can take a look - > I'll open another jira for it. > > Kalle > > > On Mon, Feb 8, 2010 at 9:46 AM, Les Hazlewood <[email protected]> wrote: >> 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 >>>> >>>>>>> >>>> >>>>> >>>> >>> >>>> >>> >>>> >> >>>> > >>> >>> >> >
