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 Tue, 15 Mar 2011 22:25:14 GMT
Hi Sergey,

On Tue, Mar 15, 2011 at 11:13 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> Hi Tomasz
>>
>> > Can you do a sanity check please and confirm that only those filter
>> > fields
>> > which are selected are added to the URI ?
>> > Example, if the filter becomes empty then the query is set to null/empty
>> > value, if only the 'from'  date field selected then it is
>> >
>> > _s=date=lt=2011-03-07
>> >
>> > only. And yes, the message value should have '*' symbols on both ends of
>> > the
>> > entered value....
>>
>> Done.
>>
>> Some variations from current implementation:
>>
>>
>> /log/logs?_s=phrase==*test%20test*;date=ge=2011-03-17;date=lt=2011-03-07;(level==INFO,level==WARN)
>>
>> /log/logs?_s=phrase==*test*;date=ge=2011-03-17;date=lt=2011-03-07;(level==INFO,level==WARN)
>> /log/logs?_s=level==INFO,level==WARN
>> /log/logs?_s=date=ge=2011-03-23
>>
>
> That is exactly what is needed, nice...A very minor fix is needed - replace
> 'phrase' with 'message' - this is because LogRecord has a property
> 'message', it's really a minor issue...
>

Fixed.

>> > One thing I noticed in your merge email is that it said that storing the
>> > user settings in the local cache was also removed. But we should
>> > actually
>> > keep it ? So that after we start the browser again it remembers the
>> > information about the endpoints ? If you did remove this code then
>> > please
>> > restore it...
>>
>> At the moment it works like:
>>
>> - Start application;
>> - Load settings from BootStrapStorage web service to memory (later we
>> use settings from memory);
>> - There is synchronization with BootStrapStorage when you
>> add/remove/edit endpoint;
>>
>> ...this solution is according to your quote:
>>
>> "
>> 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 :-)
>> "
>>
>> ...I think it's a good idea - users can share settings.
>>
> So you only removed per-user specific settings - that is ok, thanks...
>
>>
>> I don't consider filter options as settings. It's something per user
>> and only during the session.
>>
> Sounds good - lets see if users will want to keep them across restarts, good
> for now...
>
>
> I think we're getting close enough to finalizing the current code on the
> trunk. I still have to trace that Date issue, and play a bit with the
> browser checking the files, but I think things are looking good.
>
> Probably one open issue is to figure out what to do with different .js
> scripts. ? The scripts which are in the rt/management-web module, can they
> be Apache licensed ? Dan - what do you think ?

There are:

* json2.min.js - Public Domain;
* uuid.min.js - Dual licensed under the MIT and GPL licenses;

> The script which is shipped with the log browser demo - should we remove it
> and just use a plain client code to do the invocations for the logs be
> generated ?
>
> thanks, Sergey
>
>>
>>
>> --
>> Best regards,
>> Tomasz Oponowicz
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
>



-- 
Best regards,
Tomasz Oponowicz

Mime
View raw message