cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomasz Oponowicz <tomasz.oponow...@gmail.com>
Subject Re: LogBrowser project is on the trunk
Date Sat, 26 Feb 2011 13:23:32 GMT
Hi Sergey,

On Fri, Feb 25, 2011 at 1:19 PM, Sergey Beryozkin <sberyozkin@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

Mime
View raw message