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 >>> >>>>>>> >>> >>>>> >>> >>> >>> >>> >>> >> >>> > >> >> >
