JBoss integration spring-context destroy/load

[Sergio]

Hey, i have been playing with jaas and JBoss container integration using your framework (btw, nice piece of work) and have found a problem regarding the spring context used inside the container authorization process.

Finally after some tests with the JBoss class loader and the bean definition file i have been able to create a JBoss realm and succesfully authenticate a username/password token. The username token is encoded in SHA1 on a database table and i use hibernate+spring to access the data.

Everything works perfectly, the only problem is that the spring context is closed and opened on every request forcing hibernate session and the rest of beans to initialize on every request.

is there any way to keep spring context open through requests?

[Alef Arendsen]

If you keep a reference to the context in your realm implementation (you're using your own?), you should be fine (you've put the realm in a jar in server/default/lib?). If that doesn't work, JBoss creates a new realm instance for every request (I wouldn't be surprised) and you have to figure out another way to keep the context open.

One solution would be to develop a JBoss service archive (SAR) containing your context and work from there.

[Sergio]

Right now im using acegi implementation for the realm implementation.

<application-policy name = "SpringPoweredRealm">
<authentication>
<login-module code "net.sf.acegisecurity.adapters.jboss.JbossAcegiLog inModule"
flag = "required">
<module-option name = "appContextLocation">jbossSecurity.xml</module-option>
<module-option name = "key">the_password</module-option>
</login-module>
</authentication>
</application-policy>

The only way i have to reference a singleton bean context is through direct code modification since i have no way of passing the referenced instance to the acegi login module.

I suppose i could use a mixed solution using the SAR to declare hibernate session factory and bind it to a JNDI context. Then i could use this hibernate factory (which is the most expensive to initialize time after time) inside the bean context.

Are there any plans to support singleton bean factories declaration inside login modules?

[Ben Alex]

I'm not a JBoss user so I can't really offer much on this aside from if you wish to change the JbossAcegiLoginModule to operate more effectively I would be happy to add patches to CVS.

[Sergio]

Sure no problem in contributing the code once it is finished.

Ill get back on you once it is over.

[spring04]

Sergio,

I see that you are using the JBoss/Spring/Hibernate combination. May i ask you the reason for using JBoss as Spring provides most of J2EE features except may be clustering? In other words, what features of JBoss are you using?

We are also thinking of using JBoss/Spring/Hibernate and i'm trying to find the reason why i need JBoss. Of couse, we are NOT developing web application.

As spring provides most of the features required, isn't JBoss a overhead? Can you please share your experience on what features are you using from JBoss and those from Spring and how does it perform?

I'm also exploring the possibility of using acegi security framework.

I'm new to all of these

Thanks in advance!

[Sergio]

First of all sorry for answering so late but last week was a hell of a week,

Well, it is true that using spring, acegi and the rest you can replicate almost the same functionality that the one found in a J2EE container.

I mean almost the same because neither spring, not acegi attempt to be an application container. Both approach a problem (or a set of problems) that arise on the common development of J2EE applications. And from my point of view they can be used to ease the pain of a full flexed J2EE architecture.

The main parameter to decide would be wheter you use a servlet container or not. In that case i would fully recommend to use JBoss instead of tomcat alone. Spring and acegi both integrate quite well in the container but they themselves are not servlets container.

The next point would be wheter you use remote services or not. This also applies to RMI, CORBA or SOAP services. From the point of RMI and EJB using spring to help developing the EJB is Win-Win strategy for us, joining together the benefits of a container and the ease of deployment and development of spring applications. Fom the point of SOAP you face again the need of a servlet container which is in time solved by the same JBoss container (not to mention RMI is heavier than jnp, and JMX is really handy, a JMX console for spring would be a master touch).

Just to give you a full example. In our current deployment we have JBoss as application container (web and ejb). The login realm is implemented using JBoss JAAS acegi integration for both user/password,session and certificates.

On the client side you can authenticate through LoginContext (JAAS) or accesing through web application (acegi container integration again). As a result, inner code can be accesed from the web, or from a standalone java client and the code below doesnt even realize. Acl, permissions and the rest of security stuff are transparently integrated through security proxys and a newly developed jboss SecurityProxy is placed before any ejb call with the task of binding the gap between JBoss container identification and acegi authentication (just like the web filter).

The net result from my point of view can be described as beautiful transparently integrating the security concept with code that is not even aware wheter it has been remotely invocated by a client or through a web application or a SOAP service, and absolutely abstracted of the authentication mechanism.

Hope this helps

Sergio.

[Ben Alex]

Sorry guys, I still don't see what value JBoss adds. Are you using distributed transactions? Or you have a mandatory need for RMI clustering? Or using existing EJBs that simply cannot be refactored to POJOs? JBoss helps in those sort of occasional situations.

Acegi Security has in CVS even better transparent propagation of security identity from server-to-server. If using HttpInvoker or the RMI client proxy, it will automatically populate the request with a relevant username/password BASIC authentication header or the ContextHolder respectively. There has been good support for rich client validation of username, passwords and listing of GrantedAuthority[]s since 0.5 from memory. I also intend to introduce a new interceptor for the remaining proxies like Hessian and Burlap so they auto populated at each invocation from the ContextHolder. This will mean the run-as replacement is a really useful feature in applications requiring it.

I've never really like container adapters as they lock you into the container. Some people think application servers are like database servers, in that they'll outlive the application. They rarely do, and so container portability - if you can get it for free such as via Spring + Acegi Security - seems a strange thing to sacrifice without strong reason.

[Sergio]

Well,

In general terms i agree with you that a container is an overkill in several situations. But for the web.

What would be your preferred war deployment container, tomcat standalone or an application server such us JBoss or weblogic?

As for pure RMI, right now it is also a considerable overweight and i would recomend avoiding it whenever possible. In those situations that you simply cant provide local services to each of the client virtual machines then EJB comes in handy, but only for the part of easy deployment/redeployment and encapsulation of code (not the rest of stuff such as distributed transactions and so on, in fact i use spring ones and acegi ones for security), not to mention the availability of intelligent contexts able to transparently provide you the local stub instead of the remote one when available.

To be frank i would choose EJB over standalone RMI server because i dont really trust standard JDK RMI registry (too basic) and prefer a full flexed JNDI context. And because it allows me logic encapsulation and deployment/redeployment control.

In my current deployment the EJBs deployed are just a facade for the logic bean directly extracted from spring context. Using Xdoclet and ant tasks i can obtain a deployment package that directly registers itself on context and checks its correct deployment.

The remoting is just there with no extra development time spent just in case i need it. And the local bean can work in an absolutely independent way without it been included in an EJB (testing, single client deployment, etc).

To be frank even the decision of wheter to use a container or not is secondary thanks to spring and acegi. "a good design requires some concesions" but if possible do them at the last point of the chain.