cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: LogBrowser project is on the trunk
Date Fri, 25 Feb 2011 12:19:08 GMT
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
>

Mime
View raw message