Hi Chris, The best thing to do in this case (in my opinion) is create the barebones example on GitHub so one of us can clone it and see and/or build/run it.
Cheers, Les On Tue, Jan 24, 2012 at 6:19 AM, Chris Richmond <[email protected]> wrote: > Les, > > I am a little lost now and I want to put together a bare bones example of > what I am trying to do. What is the best format for me to post an entire > barebones embedded Jetty application to this forum? Required .jars? > > Thanks, > Chris > > > On 1/23/2012 3:09 PM, Les Hazlewood wrote: >> >> Hi Chris, >> >> The WebEnvironment stuff is available in Shiro 1.2 only. The Factory >> approach should work in 1.1. >> >> Cheers, >> >> Les >> >> P.S. Although we haven't made our formal announcement yet, it appears >> that the Shiro 1.2.0 release .jars have propagated to Maven central. >> You should be able to try it out now. >> >> On Tue, Jan 24, 2012 at 4:52 AM, Chris Richmond >> <[email protected]> wrote: >>> >>> Should specify we're using 1.1 but might be able to upgrade to later >>> version >>> if it would help this along. >>> >>> Thanks, >>> Chris >>> >>> >>> On 1/23/2012 1:46 PM, Les Hazlewood wrote: >>>> >>>> Hi Chris, >>>> >>>> I just read your other email, but let me clarify in case I'm >>>> interpreting this incorrectly: you've set up a Shiro SecurityManager >>>> with a Realm in your app (outside of web.xml) and now you want the >>>> realm accessible to the web tier via web.xml. >>>> >>>> If that's the case, you will have two SecurityManagers created and >>>> running - one for the non-web code and one for the web code. This is >>>> perfectly ok by the way, but I clarify because in a web environment, >>>> you definitely want a WebSecurityManager and corresponding web-related >>>> code to execute (WebSubject creation, etc). >>>> >>>> One of the easiest ways to do this is to create a >>>> org.apache.shiro.util.Factory implementation that looks up your Realm >>>> from a known location and returns it when getInstance() is invoked. >>>> >>>> For example: >>>> >>>> [main] >>>> >>>> lookedUpRealm = com.foo.my.shiro.RealmFactory >>>> >>>> securityManager.realms = $lookedUpRealm >>>> #end .ini >>>> >>>> Your com.foo.my.shiro.RealmFactory implementation's getInstance() call >>>> would return your Realm based on that known location. >>>> >>>> Another approach is to create a custom MutableWebEnvironment class >>>> that looks up things based on a ServletContext. For example, you >>>> could subclass the IniWebEnvironment implementation and override the >>>> 'createWebSecurityManager' to create a new WebSecurityManager instance >>>> with the objects you acquired based on the ServletContext. You would >>>> specify that custom class in web.xml as described here: >>>> >>>> >>>> http://shiro.apache.org/web.html#Web-Custom%257B%257BWebEnvironment%257D%257DClass >>>> >>>> The Filter approach is easier, so I'd go with that barring any >>>> problems. If, along the way, you see a way to make this even easier, >>>> let us know and we can try to add an improvement for 1.3.x. >>>> >>>> HTH
