Hi Tomasz I've spent some time and it is some sort of the asynchronous exception which when captured shows the Date of the log entry. It is thrown when the ViewerViewImpl.setEntries(List<Entry> entries) is called. We'll track it down soon :-)
Sergey On Sat, Feb 26, 2011 at 1:23 PM, Tomasz Oponowicz <tomasz.oponow...@gmail.com> wrote: > Hi Sergey, > > On Fri, Feb 25, 2011 at 1:19 PM, Sergey Beryozkin <sberyoz...@gmail.com> > wrote: >> Hi Tomasz >> >> I've rerun the demo. >> First of all, the changes you've made recently have definitely made it >> look much better, thanks. >> Unfortunately, I'm still hitting this GWT ApplicationException when >> refreshing the endpoint : >> " >> Application Error >> Class$jcb >> 2011-02-25T11:46:55.078Z >> " >> >> Can this message, particularly Class$jcb, help somehow to identify the >> problem ? It does look like it's a platform/browser specific issue, >> I'm on Ubuntu 9, Firefox 3.6.13, but it would be good to get rid of it >> somehow. >> Just tried Chrome and it showed the same error but with the >> "Class$kbc" - it's probably the some gwt proxy... >> >> Can you please point to the code in the logbrowser project where the >> response from the remote endpoint is processed ? I will investigate... > > I will install similar environment as a virtual machine - I hope I > will reproduce this issue... > >> Few more comments. I agree, the way Tasks and Endpoints are currently >> shown is nice. >> >> - Can you please consider having both ManageEndpoints and Filter links >> located under the "Tasks" ? And have Endpoints shown first, with the >> "Tasks" in the bottom of the pane ? Ultimately, the user just wants to >> see the list of endpoints. Creating/deleting the endpoints and >> applying filters is critical but I'd just prefer the "Tasks" not to >> feature as the main activity of the LogBrowser users... >> - Filter dialog can not be closed at the moment, after it has been opened... >> - Probably makes sense to rename "Explore" to "Explorer" given that >> the "ManageEndpoints" panel has the "Back to Explorer" link... >> >> More comments inline... >> >> >>>> - Authentication: I've noticed there's AuthenticationRequired >>>> annotation attached to some of the BootstrapStorage methods - we >>>> really need to remove this annotation and for now just pop-up a login >>>> window on the browser start-up. >>>> Users will be configuring the LogBrowser application as part of the >>>> real deployments. So what would be good is to write the GWT client >>>> code such that it only pops up a window when the initial GET returns >>>> 401 - can you use CXF WebClient there and do 'Response r = >>>> webClient.get()' and if r.getStatus() == 401 then pop-up a login >>>> dialog ? We can deal with this issue later, when we have more time, >>>> and then we'll also decide whether to support https in cases when the >>>> authentication is needed or may be do the UT profile, we'll see... >>> >>> According to your list of tasks please consider also fallowing tasks: >> >> Thanks for this analysis... >> >>> >>> - Removing "Sign in" feature; >>> - Pros: >>> - Simplify implementation; >>> - Easy configuration for end user; >>> - Every company has got their own internal user >>> authentication system (LDAP, OpenID, internal SSO etc.); >>> - Even if LogBrowser doesn't contain any user authentication >>> system, it's still very easy to add integration with some >>> authentication system: >>> - Simply interceptor before request rich controller; >>> - Apache directives (of course if user use Apache >>> before Tomcat); >>> - Cons: >>> - I understand that feeds should be secured, but I think we >>> should rather concentrate on: >>> - HTTPS connection; >>> - password per feed (optional); >>> >> >> I think we are in agreement here. I'd like to propose: >> - remove the initial Sign-In dialog altogether >> - Remove SighIn and SignOut buttons >> - Remove AuthenticationRequired annotation from the coode >> - postpone dealing with the authentication issues - at the moment we >> just need to focus on making sure >> the browser is operational. >> >> After 2.4.0, we can enhance it for the authentication+HTTPS be supported. >> >> If you agree then please remove all the authentication-related >> code/settings... >> >>> - Removing storing user settings remotely on the servers; >>> - Pros: >>> - Simplify implementation; >>> - Easy configuration for end user; >>> - Very clear message - all settings are stored in browser >>> local storage. At the moment the logic it's to complicated. It depend >>> on situation we keep settings in memory, browser local storage or >>> bootstrap settings; >>> - Cons: >>> - When end user clear cache all settings will be removed; >>> - Settings are stored per browser. When you add something in >>> Firefox it won't be available in Chrome; >>> >> >> I think it makes sense to keep the list of endpoints and the filter >> properties the current user has created. >> *But*, these settings just need to shared across multiple restarts of >> the browser between all the users. >> This is because I don't really think it is realistic that one user >> will want to see EndpointA only, the other one, EndpointB, etc. >> So lets keep it - I'm not worried about many users using different >> browsers for checking the logs of the single server :-) >> >>> What do you think about these tasks? I'd like to keep LogBrowser >>> minimalistic. >>> >> makes sense :-) >> >> Cheers, Sergey >> >>> -- >>> Best regards, >>> Tomasz Oponowicz >>> >> > > -- > Best regards, > Tomasz Oponowicz >
