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
