Hi Tomasz I'm finishing some work for AtomPullServer be able to connect to the existing file logs, I saw you committing some relevant updates to the LogBrowser code too, thanks. I'll will experiment with the Filter dialog shortly.
What I'd really appreciate if you could help me with the following, hope it will take just a fraction of your time: - Remove the Authentication/SignIn/SignOut related code/resources. We just don't have time now to deal with the authentication/security issues and we'd need to have another discussion later on about it. I believe you agreed to it too. - Explain a bit which code/script deals with processing the dates. I know you spent a lot of time on trying to reproduce the application exception, including testing it on Ubuntu, but I'd like to give it a try and see if I can spot something that causes the issue on my particular OS - if I can trace it to some bad Java or Firefox installation then I'll get relaxed :-)... Thanks, Sergey On Sun, Feb 27, 2011 at 6:20 PM, Sergey Beryozkin <sberyoz...@gmail.com>wrote: > 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 > >> > > > -- Sergey Beryozkin Application Integration Division of Talend <http://www.talend.com> http://sberyozkin.blogspot.com
