are you using OpenID?
Page actions are generally a good way to get this kind of thing done, but in this case I think a plain old servlet filter is going to be the best approach. You can perform whatever checking you need there and pass that information into seam for it to use.
Thanks for your reply Norman,
That's the approach I first tried, or nearly. I used a servlet Filter. But I faced the fact that through an identity injection,
@In Identity, I receive an empty Identity (new one I suppose!?) at the time the servlet Filter is processed.
If I'm doing something wrong, please tell me. It seems (:-)) that the previously existing seam context is not yet available at the time the servlet Filter is processed.
By the way, I managed to get the previous solution (the one I was struggling with in my previous post (using an <action execute> in the page.xml) to work. I still have to put it in the test release to certify it.
But I also think a servlet Filter-like approach would have been a better one. If you can tell me why I don't get the seam components in the servlet Filter ....
Many thanks for your replies.
Did you use ContextualHttpServletRequest?
I'm now (after reading your post) using ContextualHttpServletRequest
- The good news : I can get the Identity Component using:
Identity identity = (Identity) Component.getInstance( Identity.class, false);
- The bad news : when trying to get one custom seam component, using this code
JossoAuthenticator jossoAuth = ((JossoAuthenticator) Component .getInstance(JossoAuthenticator.class, false));
Caused by: java.lang.ClassNotFoundException: myPackage.MySSOAuthenticator at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
As if my components were not in the classload path when the doFilter is called.
But the seam libs are at that time,
as I can get the org.jboss.seam.security.Identity component.
So why wonldn't my embedded libs be available ?
I don't see the difference ?
Did the ContextualHttpServletRequest only restore
Thanks for your support,
The problem is that there are two directories generated by JbossTools in eclipse when creating a new seam project. The "hot" and the "main".
hotone is used for hot deployment enabled component. The other one is merely for the enity stuffs you don't want to hot deploy (because this can impact your existing data and often requires other changes to occur before).
So, the classes you put in the "hot" are not dealt with in the same manner as the one you put in the "main". They are deployed in a sub folder and not in the WEB-INF/lib like your entity stuffs are ("main").
So they are not visible to the container's class loader. I don't understand why they are available otherwise but these are the facts.
----------!!!!!!!!!!!---------- For the impatient:
So the solution is simply to put the servlet in the entity (
main) directory and not in the "hot" deployable one and all will be just fine.
And to use ContextualHttpServletRequest
As a proof of this, If you put the servlet itself in the "hot" dir, and call it in the browser address bar directly, here is the exception :
javax.servlet.ServletException: Wrapper cannot find servlet class be.myspeos.servlet.CheckSSOSessionIdServlet or a class it depends on org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) ...
If I switch it back to the "main" dir, it runs smoothly.
One last word,
If you don't use the ContextualHttpServletRequest as described in one previous post on this topic, you will receive this in the log :
java.lang.IllegalStateException: No application context active at org.jboss.seam.Component.forName(Component.java:1912) at org.jboss.seam.Component.getInstance(Component.java:1972) ...