Looks like a classic case of exception swallowing from the registry component. Can you debug and check? Most probably an NPE.
On Mon, May 7, 2012 at 11:05 AM, Amila Jayasekara <[email protected]> wrote: > Hi All, > > Issue resolved after removing webappmgmt check in > CarbonContextCreator. Pradeeban has already removed the check (in > r126420). Therefore resolved the issue. But registry accessing issue > is still there. Created L1 for that [4]. > > [4] https://wso2.org/jira/browse/CARBON-13042 > > Thanks > AmilaJ > > On Mon, May 7, 2012 at 9:46 AM, Amila Jayasekara <[email protected]> wrote: > > 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 > > > > -- > Mobile : +94773330538 > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>** email: **[email protected]* <[email protected]>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
