[gatein-dev] PortalClusteredSSOSupportValve issue in Tomcat

[Nick Scavelli]

What happens if you use a newer version of tomcat ?

On 03/19/2013 03:22 AM, Julien Viet wrote:
> http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch04s12.html 
>
>
> On Mar 19, 2013, at 4:29 AM, Trong Tran <trongtt at gmail.com> wrote:
>
>> Yes, that was just a way to reproduce the issue.
>>
>> About the real usecase that Hoang has reported, it is a Spring 3.x 
>> web app. For a certain reason, Spring auto scans all Valves which 
>> causes the issue.
>>
>> On 18 March 2013 23:28, Julien Viet <julien at julienviet.com 
>> <mailto:julien at julienviet.com>> wrote:
>>
>>     I think it was just a way to reproduce the issue and Trong does
>>     not want to use the PortalClusteredSSOSupportValve in Tomcat :-)
>>
>>     On Mar 18, 2013, at 5:14 PM, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>>     Hi Trong,
>>>
>>>     Notes inline.
>>>
>>>     On 18/03/13 12:25, Trong Tran wrote:
>>>>     Hi,
>>>>
>>>>     We can easily reproduce the problem in Tomcat by just reference
>>>>     the PortalClusteredSSOSupportValve class in a Servlet Context
>>>>     listener of a web app, to load it.
>>>     yes, I am able to reproduce it with Servlet Context listener.
>>>     But I am still not sure if I understand the usecase. Why you
>>>     need to access PortalClusteredSSOSupportValve from some Servlet
>>>     Context listener on Tomcat? Thing is that
>>>     PortalClusteredSSOSupportValve is meant to be used only in JBoss
>>>     because it uses JBoss specific clustered SSO valve. It does not
>>>     makes sense to use it in Tomcat.
>>>
>>>     And it seems that moving PortalClusteredSSOSupportValve to
>>>     packaging/jboss7 won't solve your issue, because than you won't
>>>     be able to compile your listener anyway because
>>>     PortalClusteredSSOSupportValve won't be available. But maybe I
>>>     still don't uderstand the usecase...
>>>
>>>
>>>
>>>     I am able to have listener on Tomcat with code like this and it
>>>     works without throwing error:
>>>
>>>     public class PortalSSOValveListener implements
>>>     ServletContextListener {
>>>
>>>         ValveBase portalClusteredSSOSupportValve;
>>>
>>>         public void contextInitialized(ServletContextEvent sce) {
>>>
>>>             if (new J2EEServerInfo().isJBoss()) {
>>>                 PortalClusteredSSOSupportValve casted =
>>>     (PortalClusteredSSOSupportValve)portalClusteredSSOSupportValve;
>>>                 // Do something with the valve
>>>             }
>>>         }
>>>
>>>         public void contextDestroyed(ServletContextEvent sce) {
>>>         }
>>>
>>>         private ValveBase findValve() {
>>>             // TODO: Find valve somehow...
>>>             return null;
>>>         }
>>>     }
>>>
>>>>
>>>>     I can see that it has been changed in
>>>>     org.apache.catalina.valves.ValveBase since Tomcat API 7.0 which
>>>>     already defined a final *start()* method from its indirect
>>>>     parent class org.apache.catalina.util.LifecycleBase
>>>>     http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/ValveBase.html
>>>>
>>>>     I confirmed that the problem doesn't happen in JBoss, so I
>>>>     guess this api part is not consistent between Tomcat and JBossWeb.
>>>     yes, It sucks that this api is changed...
>>>>
>>>>     In addition, there is no error in compile time as it is using
>>>>     tomcat catalina version 6.0.29 declared in gatein-dep.
>>>     Hmm... I tried to run "mvn dependency:tree" in module
>>>     component/web/security where PortalClusteredSSOSupportValve
>>>     currently is. And I am seeing that it's using
>>>     jboss.web:jbossweb:jar:2.1.3.GA:provided for compilation.
>>>
>>>     Marek
>>>>
>>>>     Thanks,
>>>
>>
>>
>>
>>
>> -- 
>> *Trong Tran*
>> /(+84) 983841909 | /trongtt at gmail.com <mailto:trongtt at gmail.com>
>> Twitter: http://twitter.com/trongtt//
>
>
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20130321/d63683d7/attachment.html