Hi Bruce, Thanks very much for pointing out your frustration. PLEASE enter a Jira issue for this for us to clear up the Filter documentation. That JavaDoc has evolved over time and you're absolutely right - it has not been updated properly to explain the 'poor man's dependency injection' that it is capable of. Come hell or high water, I will absolutely work on that this weekend - I definitely recognize that it needs to be much clearer than what the existing JavaDoc provides.
That aside, what you've done is correct. Simply defining the fully qualified class name is enought to instantiate it (as long as there is a default, no-arg constructor). Any Realms that are defined are automatically injected into the SecurityManager instance created by the Filter at startup. Also, if a default,no-arg constructor isn't good enough, you can implement a RealmFactory ( http://www.jsecurity.org/api/org/jsecurity/realm/RealmFactory.html) and define it in the same way. Any Realm instances created by it, combined with any other directly defined Realms, will be injected into the SecurityManager the same way. Part of the difficulty with configuration is that Ki's configuration is what I call, as mentioned before, 'poor man's dependency injection'. It basically creates instances and injects them based on a simple reference syntax: beanA = some.pkg.ClassName beanA.intProperty = 42 beanA.doubleProperty = 3.122 beanA.stringProperty = Hello World beanB = some.other.pkg.ClassName beanB.propertyOfTypeBeanA = $beanA ... etc. It is basically as robust as what org.apache.commons.beanutils.PropertyUtils is capable of as far as setting properties based on reflection. It is not as powerful as say, Spring or Guice configuration, which is why many folks use these frameworks for more complicated set ups like Jdbc DataSources that back the Realms. Thanks very much for the feedback - please feel free to ask any more questions. I'll also update all of this in the docs this weekend - either on the wiki or in DocBook, or somewhere. Best, Les On Fri, Apr 3, 2009 at 10:28 AM, Bruce Phillips <[email protected]> wrote: > > I think I've figured out my issue. I was not configuring the realm in the > web.xml file so the SecurityManager didn't know what realm to use. > Everything worked fine in my LoginUser servlet because there I specifically > set the realm for the SecurityManager. > > Here is what I'm now doing in web.xml: > > <filter> > <filter-name>JSecurityFilter</filter-name> > > <filter-class>org.jsecurity.web.servlet.JSecurityFilter</filter-class> > <init-param> > <param-name>config</param-name> > <param-value> > #See JSecurity API http://jsecurity.org/api/index.html > # and > http://www.jsecurity.org/api/org/jsecurity/web/servlet/JSecurityFilter.html > > #create an object of the RoleSecurityJdbcRealm > #inject that object into the SecurityManager > [main] > realmA = > name.brucephillips.rolesecurity.dao.RoleSecurityJdbcRealm > > #this application will use all the default > #filters (see link above) > #for example the default login page is /login.jsp > #users who try to access a page protected by JSecurity > #will be sent to /login.jsp > [filters] > > > #only let authenticated users > #with the appropriate role > #view the web pages in the secure > #and admin areas > [urls] > /secure/** = authc, roles[user] > /admin/** = authc, roles[admin] > > </param-value> > </init-param> > </filter> > > Here is class RoleSecurityJdbcRealm > > public class RoleSecurityJdbcRealm extends JdbcRealm { > > public RoleSecurityJdbcRealm() { > super(); > > //get the DataSource that JSecurity's JdbcRealm > //should use to find the user's password > //using the provided username > //see context.xml for this DataSource's properties > InitialContext ic; > DataSource dataSource; > try { > > ic = new InitialContext(); > dataSource = (DataSource) > ic.lookup("java:/comp/env/jdbc/security"); > this.setDataSource(dataSource); > > } catch (NamingException e) { > > e.printStackTrace(); > } > > } > > } > > PLEASE note that the JavaDoc for JSecurityFilter WAS NOT helpful. No where > in that JavaDoc does it mention specifying the realm that should be created > and that will then be injected into SecurityManager. > > If someone could let me know if I'm doing this correclty that would be > helpful. There just are not any good examples for setting up JSecurity > using the JdbcRealm in a standard web application (one that is not using > Spring, Hibernate, Ivy, etc). Before I can apply JSecurity to my own > projects (and perhaps use Spring with it) I need to understand how to get > the basics to work. > > The code for my latest example that uses role security is at: > http://www.brucephillips.name/jsecurity_examples/rolesecurity_mod_1.zip > > Once I get all this working and I understand somewhat why/how it works, > I'll be writing up a series of tutorials for others. > > -- > View this message in context: > http://n2.nabble.com/Call-to-Subject-class-hasRoles-method-causes-NoSuchElementException-tp2578639p2581031.html > Sent from the JSecurity User mailing list archive at Nabble.com. > >
