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... 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 >
