On Sat, May 5, 2012 at 7:18 AM, Amila Jayasekara <[email protected]> wrote:
> Hi All,
>
> Guess I need some help in understanding the real cause for issue
> CARBON-12902 [3]. The issue can be easily re-producible in IS, Carbon
> and ESB with following steps,
>
> 1. Start server
> 2. Login to management console
> 3. Restart the server without closing browser
> 4. Try to access a link in management console.
>
> In back-end logs you will see "System failed to authorise" error log.
> But this error is not re-producible in AS. The cause for "System
> failed to authorise" error log is server not able to retrieve the
> realm for user. The realm is retrieved from the CarbonContext. Thus
> the code which retrieves CarbonContext is in [1].
>
> According to [1] once we received the CarbonContext, it is stored in
> the session. But we do not expect CarbonContext to be persisted as a
> session property. Also CarbonContext and other relevant classes are
> not serializable. After a server restart the CarbonContext is found in
> the session for IS, Carbon and ESB servers. But the CarbonContext
> object is not valid (In the sense it does not contain required
> attributes etc ... hence it leads to issue in [3]). Thus CarbonContext
> is not there in the session for AS server (after a restart).
>
> Therefore above mentioned issue does not occur for AS server but can
> experience for other servers.
>
I think the issue is there in AS in a different form. This may be because
CarbonContext is not there in the session after server is restarted. Have
to debug and see. Only difference is that the error is not being logged at
BE. For example, after following the same steps as above, if you try to
access registry UI, you will see a popped up error message in the UI,
rather than redirected to the login page, which was the earlier case. You
have to manually log-in again to overcome this. I believe the error here is
same for all servers.
Thanks,
Kishanthan.
>
> First of all I cant find a proper reason why this behaviour is
> appearing in other server but not in AS. Isusru/Azeez any feedback on
> this ?
>
> Ideally we do not expect CarbonContext to be persisted during session
> persistence. Is there a tomcat specific configuration where we can set
> so that non-serializable classes are not persisted during session
> persistence ? I found "<distributable />" configuration in web.xml,
> but it didnt work for me [2].
>
> Thank you
> AmilaJ
>
>
> [1]
> private static CarbonContextHolder
> getCurrentCarbonContextHolder(HttpSession httpSession,
>
> boolean addToSession) {
> Object contextObject =
> httpSession.getAttribute(CARBON_CONTEXT_HOLDER);
> if (contextObject != null) {
> return (CarbonContextHolder) contextObject;
> } else if (!addToSession) {
> return null;
> }
> CarbonContextHolder context = getClone();
> log.debug("Added CarbonContext to the HTTP Session");
> httpSession.setAttribute(CARBON_CONTEXT_HOLDER, context);
> return context;
> }
>
> [2]
> http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html#Persistence_Across_Restarts
> [3] https://wso2.org/jira/browse/CARBON-12902
>
> --
> Mobile : +94773330538
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
--
*Kishanthan Thangarajah*
Software Engineer,
Development Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com*
Twitter - *http://twitter.com/kishanthan*
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
