On Mon, May 7, 2012 at 9:42 AM, Afkham Azeez <[email protected]> wrote: > The way CarbonContext is created in AS is a bit different. Do you have the > latest code from the trunk?
Yes, I do have. I will check on CompositValve, CarbonContextCreator sources. Thanks AmilaJ Earlier, in the CompositValve or > CarbonContextCreator valve, we used to check whether webapp.mgt is there and > if so, we create the CarbonContext. So, that may be the difference. In the > current trunk, we have removed that check in that valve. > > Senaka mentioned that he will look into CarbonContext API cleanup now that > the Tomcat OSGification is done. > > > On Mon, May 7, 2012 at 7:56 AM, Amila Jayasekara <[email protected]> wrote: >> >> On Sat, May 5, 2012 at 2:25 PM, Kishanthan Thangarajah >> <[email protected]> wrote: >> > >> > >> > 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. >> >> Hi Krishanthan, >> >> The CarbonContext is not there in the session after restarting AS. But >> for other servers there is a CarbonContext object in session, which is >> not valid. If CarbonContext is not there in the session, according to >> code in [1] it will create a new Context with valid parameters. Not >> having CarbonContext in session (After a restart) is also the expected >> behaviour. >> I swiftly did a test on registry UI in AS server. But I didnt see >> "System failed to authorise" error log. I only saw "An unexpected >> error occurred, Please check server logs for more details" error in >> the UI. But didnt see anything in server log. Therefore I am not sure >> the error when accessing registry UI and the error we discussed in >> this thread are same. Need to further debug and see. >> >> Thanks >> AmilaJ >> >> > 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 >> > >> >> >> >> -- >> Mobile : +94773330538 > > > > > -- > Afkham Azeez > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > > email: [email protected] cell: +94 77 3320919 > blog: http://blog.afkham.org > twitter: http://twitter.com/afkham_azeez > linked-in: http://lk.linkedin.com/in/afkhamazeez > > Lean . Enterprise . Middleware > -- Mobile : +94773330538 _______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
