String text = columnDefinition.getContent(entry); in SelectableTable.setData
is causing it, and it's only happening when the Date column is filled in, the Level and Message are fine. Looks like the code co0nverting the Atom/http-format date is brittle a bit cheers, Sergey On Sun, Feb 27, 2011 at 5:10 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > 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 >> >
