1. I suppose you are coding a project which does not have a web.xml and are wondering how to initialize Shiro. I have not done this myself without web.xml but assume you must subclass org.apache.shiro.web.env.EnvironmentLoaderListener and attach the annotation @WebListener to this subclass to have it loaded on application startup. Your subclass of EnvironmentLoaderListener can then read its initialization parameters from anywhere you seem fit, thereby removing the need for a shiro.ini file. Also subclass org.apache.shiro.web.servlet.ShiroFilter and attach the annotation @WebFilter to it.
2. Yes, you always need a realm to do the authentication and authorization with Shiro in a production environment. For testing you can get away by hard coding users, roles and permissions into shiro.ini or your equivalent. Since java objects instantiated through Shiro are not CDI beans you cannot use @Inject to inject any CDI / EJB beans into your realm but must resort to one of either: a. use pax shiro https://github.com/ops4j/org.ops4j.pax.shiro or b. use CDI and BeanManager BeanManager bm = CDI.current().getBeanManager(); Bean<your.ejb.dao.className> bean = (Bean<your.ejb.dao.className>) bm.getBeans(your.ejb.dao.className.class).iterator().next(); CreationalContext<your.ejb.dao.className> ctx = bm.createCreationalContext(bean); your.ejb.dao.className dao = (your.ejb.dao.className) bm.getReference(bean, your.ejb.dao.className.class, ctx); 3. You may use interceptors if you want to or alternatively do authorization via explicit coding public Object someMethod(...) { org.apache.shiro.subject.Subject subject = SecurityUtils.getSubject(); or with pax shiro @Inject Subject subject; // without the SecurityUtils.getSubject(); if (!subject.hasRole(...) && !subject.isPermitted(...)) { // deny access to resource } } -- View this message in context: http://shiro-user.582556.n2.nabble.com/Help-with-shiro-and-jEE-JAX-RS-Jersey-EJB-JPA-on-Glassfish-4-1-tp7580321p7580323.html Sent from the Shiro User mailing list archive at Nabble.com.
