You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Tomasz Oponowicz <to...@gmail.com> on 2010/08/30 13:11:15 UTC
[CXF-2736] LogBrowser - future plans
Hi,
GSOC has just ended. During this time LogBrowser was created. At the
moment the project has all basic features like authentication,
settings manager and browse layout which includes navigation links
(first, previous, refresh, next and last page). I would really like to
continue working with Apache CXF community. Together with Sergey, we
think about how to extend the project to make it even more useful.
We consider two crucial features right now:
1. search capabilities;
2. removing authentication when connection is not secure (it is not HTTPS);
Below our discussion about that (we have some spam filter difficulties
and this is why it looks so weird).
=According to search capabilities=
[Sergey]
Offer some basic search options first, I think they should be global
for a start, i.e, they'd apply to all the endpoints. Ex : a user is
offered a list of level options (level: INFO or DEBUG), just this
would do, so the user would select : I'd like to see INFOS only, and
then a FIQL expression is sent to AtomPullServer and it would just
return the list of matching records.
[Tomasz]
I agree that search option is crucial feature right now. I think there
should be available search criteria as follows:
1) specified phrase;
2) datetime range: begin and end datetime;
3) log entry level: INFO, etc;
...all parameters will be sent to AtomPullServer as FIQL expression
(as you mentioned).
Although I think it's better to have search only within current
selected endpoint. We give an user an ability to divide all logs into
plenty of endpoints for clean browsing but now we will search through
all endpoint at once. I think it breaks basic assumption. However
searching within selected endpoint isn't a problem, because
AtomPullServer has powerful configuration capabilities and user can
easily combine many loggers into one instance through "setLoggers"
method.
What do you think about that? I think searching within current
selected endpoint is good enough.
[Sergey]
Sounds ok, not sure about phrases but I guess it can be useful, I
thought users would really would like to see all the error messages or
indeed all the messages logged during some specific limited period of
time, but phrases may probably help those who know what sort of log
messages can be expected to narrow down the set to virtually a single
message or just few of them...
[Sergey]
May be you're right that it's better to have individual endpoint
having specific search conditions. But I'd really like to enter the
common search conditions, say, say show me the message with INFO level
only only, and then start clicking between multiple endpoints and see
the INFO logs only. However, I'd likely want to customize the way the
search conditions get applied to a given endpoint
So how about being able to specify the search condition that applies
to all the endpoints first and once it all works ok, add the
capability to override it on per-endpoint basis ? Or the other way
around. I'd not be concerned about making both options work before the
merge to the trunk, just
--
Best regards,
Tomasz Oponowicz
Re: @Produces programmatically
Posted by Sheraz Attari <ms...@folio3.com>.
Oh is there any separate list for these type of questions.
Yes you are right, I am using JAX-RS. If you can look at the
pseudo code below, there is an argument “output” I will decide based on its
value whether to return XML or JSON.
Any clues ?
Thanks
--- On Tue, 8/31/10, Sergey Beryozkin <sb...@gmail.com> wrote:
From: Sergey Beryozkin <sb...@gmail.com>
Subject: Re: @Produces programmatically
To: users@cxf.apache.org
Cc: msheraz@folio3.com
Date: Tuesday, August 31, 2010, 10:45 AM
Hi this is a question for the users list...
On Tue, Aug 31, 2010 at 11:38 AM, Muhammad Sheraz Siddiqi <ms...@folio3.com> wrote:
Hi,
I want to expose a webmethod like this:
@WebMethod
public List<CustonBean> test(String output)
{
If(output == "xml")
{
//use XML Provider i.e. output XML
}
Else if(output == "json")
{
//use JSON Provider i.e. output JSON
}
}
I do not want to use @Produces or rely on "Accept" request header.
Any help please ?
I'm presuming you're using JAXRS. So how are you going to decide if it's JSON or XML that needs to be returned ?
cheers, Sergey
Re: @Produces programmatically
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi this is a question for the users list...
On Tue, Aug 31, 2010 at 11:38 AM, Muhammad Sheraz Siddiqi <
msheraz@folio3.com> wrote:
> Hi,
>
> I want to expose a webmethod like this:
>
> @WebMethod
> public List<CustonBean> test(String output)
> {
> If(output == "xml")
> {
> //use XML Provider i.e. output XML
> }
> Else if(output == "json")
> {
> //use JSON Provider i.e. output JSON
> }
> }
>
> I do not want to use @Produces or rely on "Accept" request header.
>
> Any help please ?
>
>
>
I'm presuming you're using JAXRS. So how are you going to decide if it's
JSON or XML that needs to be returned ?
cheers, Sergey
@Produces programmatically
Posted by Muhammad Sheraz Siddiqi <ms...@folio3.com>.
Hi,
I want to expose a webmethod like this:
@WebMethod
public List<CustonBean> test(String output)
{
If(output == "xml")
{
//use XML Provider i.e. output XML
}
Else if(output == "json")
{
//use JSON Provider i.e. output JSON
}
}
I do not want to use @Produces or rely on "Accept" request header.
Any help please ?
Re: [CXF-2736] LogBrowser - future plans
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
It's wonderful idea - It will really help because I go through rough
time now. I'm going to contribute more frequently in next few weeks.
--
Best regards,
Tomasz Oponowicz
On Wed, Oct 27, 2010 at 1:54 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Tomasz
>
> I've seen you committing the UI-related updates to do with supporting the
> search options. I'll work during the next few weeks on supporting the search
> conditions on the AtomPullServer side and then we will start moving your
> code to the trunk
>
> thanks, Sergey
>
> On Sun, Sep 19, 2010 at 11:28 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
>>
>> Hi Tomasz
>>
>> I think it looks really nice. I'd just prefer to rename "Fiter" to
>> "Settings" and "Edit details" to "Filter" - because "Filter" settings are
>> just some of the settings which users will want to change. But I'm OK with
>> Filter/EditSettings as well for now...
>>
>> Please go ahead with implementing the search feature :-)
>>
>> thanks, Sergey
>>
>> On Sun, Sep 19, 2010 at 10:06 PM, Tomasz Oponowicz
>> <to...@gmail.com> wrote:
>>>
>>> Hi Sergey,
>>>
>>> On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sb...@gmail.com>
>>> wrote:
>>> > Hi Tomasz
>>> >
>>> > sorry for a delay
>>> >
>>> > On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz
>>> > <to...@gmail.com> wrote:
>>> >>
>>> >> Hi Sergey,
>>> >>
>>> >> Welcome everyone after quite long break.
>>> >>
>>> >> I've prepared sample user interface for "search capabilities" feature.
>>> >>
>>> >
>>> > Great :-)
>>> >
>>> >>
>>> >> Legend:
>>> >>
>>> >> * File [0]:
>>> >>
>>> >> 1) "All endpoints" entry is added after moving to "search" mode
>>> >> (this entry isn't shown during "browsing mode").
>>> >> If user choose particular endpoint, the application will
>>> >> search log entries only within chosen endpoint;
>>> >>
>>> >> 2) User is informed that he is currently at "search mode".
>>> >> He can return to "browsing mode" by clicking "reset" link;
>>> >>
>>> >> 3) "Advanced" checkbox shows or hides additional inputs like: from
>>> >> date, to date and levels;
>>> >>
>>> >> 4) This button has two functions. First of all it shows what
>>> >> levels are enabled.
>>> >> For example when only INFO and ERROR levels are enabled then
>>> >> label of the button has value "I/E".
>>> >> Second of all popup is showed after clicking button (more info
>>> >> in next section);
>>> >>
>>> >> * File [1]
>>> >>
>>> >> 1) Popup contains all possible log levels. Click on specified
>>> >> level to enable or disable level.
>>> >> If user click outside the popup, popup will disappear and new
>>> >> configuration will be saved.
>>> >>
>>> >> Of course it's only a concept - all improvements are welcome.
>>> >>
>>> >
>>> > I'm not quite sure I'd like, as a user, to switch between 'browsing'
>>> > and
>>> > 'searching' modes.
>>> > I'd like to work in a single mode, the way I can do it right now by
>>> > adding
>>> > endpoints, clicking between them and looking at corresponding log
>>> > entries.
>>> >
>>> > As I suggested earlier on, it would be nice for a start to have global
>>> > search properties which apply to all the endpoints, just making it easy
>>> > to
>>> > configure in a very non intrusive way would be something which will let
>>> > us
>>> > move the code to the trunk.
>>> >
>>> > Thinking ahead, perhaps we can have what is the log browser now turning
>>> > into
>>> > a management UI where another tab would probably show the statistics
>>> > (exchanges, etc) collected with the help of persisting interceptors.
>>> > Thus
>>> > I'm not sure if we can have a *menu* right now.
>>> >
>>> > Perhaps a pop-up window allowing to set search properties would do.
>>> > Have a look please at Google Mail 'More Actions' which shows a number
>>> > of
>>> > menu items, one of them is "Create Event" which allows to set the event
>>> > properties. So if we could have a button in the top right cotton
>>> > "Settings"
>>> > which, once pressed, would show only "Filter..." or "Search..." which
>>> > in
>>> > turn would lead to a pop-up window where a user would select how to
>>> > search
>>> > and press OK. From then on every endpoint will use this filter/search
>>> > conditions.
>>> >
>>>
>>> I've prepared new interface by taking all good ideas into consideration.
>>>
>>> At the [0] screenshot there is "explore" mode. I modified left sidebar
>>> by adding stack panel. In the future we can add more children (for
>>> example "statistics" header etc.). I think this solution is very
>>> flexible. At the [1] screenshot there is "filter" mode. It looks
>>> almost the same but there is additional "Edit criteria" link. User can
>>> easily swap between this two modes. After pressing "Edit criteria"
>>> link, dialog box is shown for modifying criteria [2].
>>>
>>> I think this solution is good enough, so if you approve it I will begin
>>> coding.
>>>
>>> What do you think?
>>>
>>> > Additionally, if really needed, users could override the settings on a
>>> > per-endpoint basis. Possibly by right-clicking on a specific endpoint
>>> > and
>>> > selecting "Filter..." or "Search..." from a popup menu.
>>> >
>>> > Do you think it's doable ?
>>>
>>> Yes, no problem at all. I think it's good feature for future.
>>>
>>> >>
>>> >> I have got some technical question. How do you consider paging for
>>> >> "All endpoints"? Because every endpoint is independent the only
>>> >> solution would be gathered page from all endpoints and combine into
>>> >> one huge page. Unfortunately I don't like this solution. Have you got
>>> >> any idea?
>>> >>
>>> > Perhaps we should not introduce such a composite endpoint at this stage
>>> > ?
>>> > This would just make things much more complicated. AtomPullServer
>>> > allows one
>>> > to search from the external file but I'm not sure yet how to deal with
>>> > that
>>> > in the browser. You are right in that all the logs should be shown, but
>>> > lets
>>> > discuss it once we have the code on the trunk :-)
>>>
>>> I introduce "composite endpoint" because of my misunderstanding. I
>>> also agree that it would be problematic.
>>>
>>>
>>> [0]
>>> https://issues.apache.org/jira/secure/attachment/12454988/searching_layout_explore_v2.png
>>> [1]
>>> https://issues.apache.org/jira/secure/attachment/12454987/searching_layout_filter_v2.png
>>> [2]
>>> https://issues.apache.org/jira/secure/attachment/12454989/searching_layout_edit_criteria_v2.png
>>>
>>> --
>>> Best regards,
>>> Tomasz Oponowicz
>>>
>>> > thanks, Sergey
>>> >
>>> >> [0]
>>> >>
>>> >> https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
>>> >> [1]
>>> >>
>>> >> https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
>>> >>
>>> >> --
>>> >> Best regards,
>>> >> Tomasz Oponowicz
>>> >>
>>> >> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
>>> >> <to...@gmail.com> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > GSOC has just ended. During this time LogBrowser was created. At the
>>> >> > moment the project has all basic features like authentication,
>>> >> > settings manager and browse layout which includes navigation links
>>> >> > (first, previous, refresh, next and last page). I would really like
>>> >> > to
>>> >> > continue working with Apache CXF community. Together with Sergey, we
>>> >> > think about how to extend the project to make it even more useful.
>>> >> >
>>> >> > We consider two crucial features right now:
>>> >> >
>>> >> > 1. search capabilities;
>>> >> > 2. removing authentication when connection is not secure (it is not
>>> >> > HTTPS);
>>> >> >
>>> >> > Below our discussion about that (we have some spam filter
>>> >> > difficulties
>>> >> > and this is why it looks so weird).
>>> >> >
>>> >> > =According to search capabilities=
>>> >> >
>>> >> > [Sergey]
>>> >> >
>>> >> > Offer some basic search options first, I think they should be global
>>> >> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is
>>> >> > offered a list of level options (level: INFO or DEBUG), just this
>>> >> > would do, so the user would select : I'd like to see INFOS only, and
>>> >> > then a FIQL expression is sent to AtomPullServer and it would just
>>> >> > return the list of matching records.
>>> >> >
>>> >> > [Tomasz]
>>> >> >
>>> >> > I agree that search option is crucial feature right now. I think
>>> >> > there
>>> >> > should be available search criteria as follows:
>>> >> >
>>> >> > 1) specified phrase;
>>> >> > 2) datetime range: begin and end datetime;
>>> >> > 3) log entry level: INFO, etc;
>>> >> >
>>> >> > ...all parameters will be sent to AtomPullServer as FIQL expression
>>> >> > (as you mentioned).
>>> >> >
>>> >> > Although I think it's better to have search only within current
>>> >> > selected endpoint. We give an user an ability to divide all logs
>>> >> > into
>>> >> > plenty of endpoints for clean browsing but now we will search
>>> >> > through
>>> >> > all endpoint at once. I think it breaks basic assumption. However
>>> >> > searching within selected endpoint isn't a problem, because
>>> >> > AtomPullServer has powerful configuration capabilities and user can
>>> >> > easily combine many loggers into one instance through "setLoggers"
>>> >> > method.
>>> >> >
>>> >> > What do you think about that? I think searching within current
>>> >> > selected endpoint is good enough.
>>> >> >
>>> >> > [Sergey]
>>> >> >
>>> >> > Sounds ok, not sure about phrases but I guess it can be useful, I
>>> >> > thought users would really would like to see all the error messages
>>> >> > or
>>> >> > indeed all the messages logged during some specific limited period
>>> >> > of
>>> >> > time, but phrases may probably help those who know what sort of log
>>> >> > messages can be expected to narrow down the set to virtually a
>>> >> > single
>>> >> > message or just few of them...
>>> >> >
>>> >> > [Sergey]
>>> >> >
>>> >> > May be you're right that it's better to have individual endpoint
>>> >> > having specific search conditions. But I'd really like to enter the
>>> >> > common search conditions, say, say show me the message with INFO
>>> >> > level
>>> >> > only only, and then start clicking between multiple endpoints and
>>> >> > see
>>> >> > the INFO logs only. However, I'd likely want to customize the way
>>> >> > the
>>> >> > search conditions get applied to a given endpoint
>>> >> >
>>> >> > So how about being able to specify the search condition that applies
>>> >> > to all the endpoints first and once it all works ok, add the
>>> >> > capability to override it on per-endpoint basis ? Or the other way
>>> >> > around. I'd not be concerned about making both options work before
>>> >> > the
>>> >> > merge to the trunk, just
>>> >> >
>>> >> > --
>>> >> > Best regards,
>>> >> > Tomasz Oponowicz
>>> >> >
>>> >
>>> >
>>
>
>
Re: [CXF-2736] LogBrowser - future plans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
I've seen you committing the UI-related updates to do with supporting the
search options. I'll work during the next few weeks on supporting the search
conditions on the AtomPullServer side and then we will start moving your
code to the trunk
thanks, Sergey
On Sun, Sep 19, 2010 at 11:28 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Tomasz
>
> I think it looks really nice. I'd just prefer to rename "Fiter" to
> "Settings" and "Edit details" to "Filter" - because "Filter" settings are
> just some of the settings which users will want to change. But I'm OK with
> Filter/EditSettings as well for now...
>
> Please go ahead with implementing the search feature :-)
>
> thanks, Sergey
>
> On Sun, Sep 19, 2010 at 10:06 PM, Tomasz Oponowicz <
> tomasz.oponowicz@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sb...@gmail.com>
>> wrote:
>> > Hi Tomasz
>> >
>> > sorry for a delay
>> >
>> > On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz
>> > <to...@gmail.com> wrote:
>> >>
>> >> Hi Sergey,
>> >>
>> >> Welcome everyone after quite long break.
>> >>
>> >> I've prepared sample user interface for "search capabilities" feature.
>> >>
>> >
>> > Great :-)
>> >
>> >>
>> >> Legend:
>> >>
>> >> * File [0]:
>> >>
>> >> 1) "All endpoints" entry is added after moving to "search" mode
>> >> (this entry isn't shown during "browsing mode").
>> >> If user choose particular endpoint, the application will
>> >> search log entries only within chosen endpoint;
>> >>
>> >> 2) User is informed that he is currently at "search mode".
>> >> He can return to "browsing mode" by clicking "reset" link;
>> >>
>> >> 3) "Advanced" checkbox shows or hides additional inputs like: from
>> >> date, to date and levels;
>> >>
>> >> 4) This button has two functions. First of all it shows what
>> >> levels are enabled.
>> >> For example when only INFO and ERROR levels are enabled then
>> >> label of the button has value "I/E".
>> >> Second of all popup is showed after clicking button (more info
>> >> in next section);
>> >>
>> >> * File [1]
>> >>
>> >> 1) Popup contains all possible log levels. Click on specified
>> >> level to enable or disable level.
>> >> If user click outside the popup, popup will disappear and new
>> >> configuration will be saved.
>> >>
>> >> Of course it's only a concept - all improvements are welcome.
>> >>
>> >
>> > I'm not quite sure I'd like, as a user, to switch between 'browsing' and
>> > 'searching' modes.
>> > I'd like to work in a single mode, the way I can do it right now by
>> adding
>> > endpoints, clicking between them and looking at corresponding log
>> entries.
>> >
>> > As I suggested earlier on, it would be nice for a start to have global
>> > search properties which apply to all the endpoints, just making it easy
>> to
>> > configure in a very non intrusive way would be something which will let
>> us
>> > move the code to the trunk.
>> >
>> > Thinking ahead, perhaps we can have what is the log browser now turning
>> into
>> > a management UI where another tab would probably show the statistics
>> > (exchanges, etc) collected with the help of persisting interceptors.
>> Thus
>> > I'm not sure if we can have a *menu* right now.
>> >
>> > Perhaps a pop-up window allowing to set search properties would do.
>> > Have a look please at Google Mail 'More Actions' which shows a number of
>> > menu items, one of them is "Create Event" which allows to set the event
>> > properties. So if we could have a button in the top right cotton
>> "Settings"
>> > which, once pressed, would show only "Filter..." or "Search..." which in
>> > turn would lead to a pop-up window where a user would select how to
>> search
>> > and press OK. From then on every endpoint will use this filter/search
>> > conditions.
>> >
>>
>> I've prepared new interface by taking all good ideas into consideration.
>>
>> At the [0] screenshot there is "explore" mode. I modified left sidebar
>> by adding stack panel. In the future we can add more children (for
>> example "statistics" header etc.). I think this solution is very
>> flexible. At the [1] screenshot there is "filter" mode. It looks
>> almost the same but there is additional "Edit criteria" link. User can
>> easily swap between this two modes. After pressing "Edit criteria"
>> link, dialog box is shown for modifying criteria [2].
>>
>> I think this solution is good enough, so if you approve it I will begin
>> coding.
>>
>> What do you think?
>>
>> > Additionally, if really needed, users could override the settings on a
>> > per-endpoint basis. Possibly by right-clicking on a specific endpoint
>> and
>> > selecting "Filter..." or "Search..." from a popup menu.
>> >
>> > Do you think it's doable ?
>>
>> Yes, no problem at all. I think it's good feature for future.
>>
>> >>
>> >> I have got some technical question. How do you consider paging for
>> >> "All endpoints"? Because every endpoint is independent the only
>> >> solution would be gathered page from all endpoints and combine into
>> >> one huge page. Unfortunately I don't like this solution. Have you got
>> >> any idea?
>> >>
>> > Perhaps we should not introduce such a composite endpoint at this stage
>> ?
>> > This would just make things much more complicated. AtomPullServer allows
>> one
>> > to search from the external file but I'm not sure yet how to deal with
>> that
>> > in the browser. You are right in that all the logs should be shown, but
>> lets
>> > discuss it once we have the code on the trunk :-)
>>
>> I introduce "composite endpoint" because of my misunderstanding. I
>> also agree that it would be problematic.
>>
>>
>> [0]
>> https://issues.apache.org/jira/secure/attachment/12454988/searching_layout_explore_v2.png
>> [1]
>> https://issues.apache.org/jira/secure/attachment/12454987/searching_layout_filter_v2.png
>> [2]
>> https://issues.apache.org/jira/secure/attachment/12454989/searching_layout_edit_criteria_v2.png
>>
>> --
>> Best regards,
>> Tomasz Oponowicz
>>
>> > thanks, Sergey
>> >
>> >> [0]
>> >>
>> https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
>> >> [1]
>> >>
>> https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
>> >>
>> >> --
>> >> Best regards,
>> >> Tomasz Oponowicz
>> >>
>> >> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
>> >> <to...@gmail.com> wrote:
>> >> > Hi,
>> >> >
>> >> > GSOC has just ended. During this time LogBrowser was created. At the
>> >> > moment the project has all basic features like authentication,
>> >> > settings manager and browse layout which includes navigation links
>> >> > (first, previous, refresh, next and last page). I would really like
>> to
>> >> > continue working with Apache CXF community. Together with Sergey, we
>> >> > think about how to extend the project to make it even more useful.
>> >> >
>> >> > We consider two crucial features right now:
>> >> >
>> >> > 1. search capabilities;
>> >> > 2. removing authentication when connection is not secure (it is not
>> >> > HTTPS);
>> >> >
>> >> > Below our discussion about that (we have some spam filter
>> difficulties
>> >> > and this is why it looks so weird).
>> >> >
>> >> > =According to search capabilities=
>> >> >
>> >> > [Sergey]
>> >> >
>> >> > Offer some basic search options first, I think they should be global
>> >> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is
>> >> > offered a list of level options (level: INFO or DEBUG), just this
>> >> > would do, so the user would select : I'd like to see INFOS only, and
>> >> > then a FIQL expression is sent to AtomPullServer and it would just
>> >> > return the list of matching records.
>> >> >
>> >> > [Tomasz]
>> >> >
>> >> > I agree that search option is crucial feature right now. I think
>> there
>> >> > should be available search criteria as follows:
>> >> >
>> >> > 1) specified phrase;
>> >> > 2) datetime range: begin and end datetime;
>> >> > 3) log entry level: INFO, etc;
>> >> >
>> >> > ...all parameters will be sent to AtomPullServer as FIQL expression
>> >> > (as you mentioned).
>> >> >
>> >> > Although I think it's better to have search only within current
>> >> > selected endpoint. We give an user an ability to divide all logs into
>> >> > plenty of endpoints for clean browsing but now we will search through
>> >> > all endpoint at once. I think it breaks basic assumption. However
>> >> > searching within selected endpoint isn't a problem, because
>> >> > AtomPullServer has powerful configuration capabilities and user can
>> >> > easily combine many loggers into one instance through "setLoggers"
>> >> > method.
>> >> >
>> >> > What do you think about that? I think searching within current
>> >> > selected endpoint is good enough.
>> >> >
>> >> > [Sergey]
>> >> >
>> >> > Sounds ok, not sure about phrases but I guess it can be useful, I
>> >> > thought users would really would like to see all the error messages
>> or
>> >> > indeed all the messages logged during some specific limited period of
>> >> > time, but phrases may probably help those who know what sort of log
>> >> > messages can be expected to narrow down the set to virtually a single
>> >> > message or just few of them...
>> >> >
>> >> > [Sergey]
>> >> >
>> >> > May be you're right that it's better to have individual endpoint
>> >> > having specific search conditions. But I'd really like to enter the
>> >> > common search conditions, say, say show me the message with INFO
>> level
>> >> > only only, and then start clicking between multiple endpoints and see
>> >> > the INFO logs only. However, I'd likely want to customize the way the
>> >> > search conditions get applied to a given endpoint
>> >> >
>> >> > So how about being able to specify the search condition that applies
>> >> > to all the endpoints first and once it all works ok, add the
>> >> > capability to override it on per-endpoint basis ? Or the other way
>> >> > around. I'd not be concerned about making both options work before
>> the
>> >> > merge to the trunk, just
>> >> >
>> >> > --
>> >> > Best regards,
>> >> > Tomasz Oponowicz
>> >> >
>> >
>> >
>>
>
>
Re: [CXF-2736] LogBrowser - future plans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
I think it looks really nice. I'd just prefer to rename "Fiter" to
"Settings" and "Edit details" to "Filter" - because "Filter" settings are
just some of the settings which users will want to change. But I'm OK with
Filter/EditSettings as well for now...
Please go ahead with implementing the search feature :-)
thanks, Sergey
On Sun, Sep 19, 2010 at 10:06 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Sergey,
>
> On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > Hi Tomasz
> >
> > sorry for a delay
> >
> > On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz
> > <to...@gmail.com> wrote:
> >>
> >> Hi Sergey,
> >>
> >> Welcome everyone after quite long break.
> >>
> >> I've prepared sample user interface for "search capabilities" feature.
> >>
> >
> > Great :-)
> >
> >>
> >> Legend:
> >>
> >> * File [0]:
> >>
> >> 1) "All endpoints" entry is added after moving to "search" mode
> >> (this entry isn't shown during "browsing mode").
> >> If user choose particular endpoint, the application will
> >> search log entries only within chosen endpoint;
> >>
> >> 2) User is informed that he is currently at "search mode".
> >> He can return to "browsing mode" by clicking "reset" link;
> >>
> >> 3) "Advanced" checkbox shows or hides additional inputs like: from
> >> date, to date and levels;
> >>
> >> 4) This button has two functions. First of all it shows what
> >> levels are enabled.
> >> For example when only INFO and ERROR levels are enabled then
> >> label of the button has value "I/E".
> >> Second of all popup is showed after clicking button (more info
> >> in next section);
> >>
> >> * File [1]
> >>
> >> 1) Popup contains all possible log levels. Click on specified
> >> level to enable or disable level.
> >> If user click outside the popup, popup will disappear and new
> >> configuration will be saved.
> >>
> >> Of course it's only a concept - all improvements are welcome.
> >>
> >
> > I'm not quite sure I'd like, as a user, to switch between 'browsing' and
> > 'searching' modes.
> > I'd like to work in a single mode, the way I can do it right now by
> adding
> > endpoints, clicking between them and looking at corresponding log
> entries.
> >
> > As I suggested earlier on, it would be nice for a start to have global
> > search properties which apply to all the endpoints, just making it easy
> to
> > configure in a very non intrusive way would be something which will let
> us
> > move the code to the trunk.
> >
> > Thinking ahead, perhaps we can have what is the log browser now turning
> into
> > a management UI where another tab would probably show the statistics
> > (exchanges, etc) collected with the help of persisting interceptors. Thus
> > I'm not sure if we can have a *menu* right now.
> >
> > Perhaps a pop-up window allowing to set search properties would do.
> > Have a look please at Google Mail 'More Actions' which shows a number of
> > menu items, one of them is "Create Event" which allows to set the event
> > properties. So if we could have a button in the top right cotton
> "Settings"
> > which, once pressed, would show only "Filter..." or "Search..." which in
> > turn would lead to a pop-up window where a user would select how to
> search
> > and press OK. From then on every endpoint will use this filter/search
> > conditions.
> >
>
> I've prepared new interface by taking all good ideas into consideration.
>
> At the [0] screenshot there is "explore" mode. I modified left sidebar
> by adding stack panel. In the future we can add more children (for
> example "statistics" header etc.). I think this solution is very
> flexible. At the [1] screenshot there is "filter" mode. It looks
> almost the same but there is additional "Edit criteria" link. User can
> easily swap between this two modes. After pressing "Edit criteria"
> link, dialog box is shown for modifying criteria [2].
>
> I think this solution is good enough, so if you approve it I will begin
> coding.
>
> What do you think?
>
> > Additionally, if really needed, users could override the settings on a
> > per-endpoint basis. Possibly by right-clicking on a specific endpoint and
> > selecting "Filter..." or "Search..." from a popup menu.
> >
> > Do you think it's doable ?
>
> Yes, no problem at all. I think it's good feature for future.
>
> >>
> >> I have got some technical question. How do you consider paging for
> >> "All endpoints"? Because every endpoint is independent the only
> >> solution would be gathered page from all endpoints and combine into
> >> one huge page. Unfortunately I don't like this solution. Have you got
> >> any idea?
> >>
> > Perhaps we should not introduce such a composite endpoint at this stage ?
> > This would just make things much more complicated. AtomPullServer allows
> one
> > to search from the external file but I'm not sure yet how to deal with
> that
> > in the browser. You are right in that all the logs should be shown, but
> lets
> > discuss it once we have the code on the trunk :-)
>
> I introduce "composite endpoint" because of my misunderstanding. I
> also agree that it would be problematic.
>
>
> [0]
> https://issues.apache.org/jira/secure/attachment/12454988/searching_layout_explore_v2.png
> [1]
> https://issues.apache.org/jira/secure/attachment/12454987/searching_layout_filter_v2.png
> [2]
> https://issues.apache.org/jira/secure/attachment/12454989/searching_layout_edit_criteria_v2.png
>
> --
> Best regards,
> Tomasz Oponowicz
>
> > thanks, Sergey
> >
> >> [0]
> >>
> https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
> >> [1]
> >>
> https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
> >>
> >> --
> >> Best regards,
> >> Tomasz Oponowicz
> >>
> >> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
> >> <to...@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > GSOC has just ended. During this time LogBrowser was created. At the
> >> > moment the project has all basic features like authentication,
> >> > settings manager and browse layout which includes navigation links
> >> > (first, previous, refresh, next and last page). I would really like to
> >> > continue working with Apache CXF community. Together with Sergey, we
> >> > think about how to extend the project to make it even more useful.
> >> >
> >> > We consider two crucial features right now:
> >> >
> >> > 1. search capabilities;
> >> > 2. removing authentication when connection is not secure (it is not
> >> > HTTPS);
> >> >
> >> > Below our discussion about that (we have some spam filter difficulties
> >> > and this is why it looks so weird).
> >> >
> >> > =According to search capabilities=
> >> >
> >> > [Sergey]
> >> >
> >> > Offer some basic search options first, I think they should be global
> >> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is
> >> > offered a list of level options (level: INFO or DEBUG), just this
> >> > would do, so the user would select : I'd like to see INFOS only, and
> >> > then a FIQL expression is sent to AtomPullServer and it would just
> >> > return the list of matching records.
> >> >
> >> > [Tomasz]
> >> >
> >> > I agree that search option is crucial feature right now. I think there
> >> > should be available search criteria as follows:
> >> >
> >> > 1) specified phrase;
> >> > 2) datetime range: begin and end datetime;
> >> > 3) log entry level: INFO, etc;
> >> >
> >> > ...all parameters will be sent to AtomPullServer as FIQL expression
> >> > (as you mentioned).
> >> >
> >> > Although I think it's better to have search only within current
> >> > selected endpoint. We give an user an ability to divide all logs into
> >> > plenty of endpoints for clean browsing but now we will search through
> >> > all endpoint at once. I think it breaks basic assumption. However
> >> > searching within selected endpoint isn't a problem, because
> >> > AtomPullServer has powerful configuration capabilities and user can
> >> > easily combine many loggers into one instance through "setLoggers"
> >> > method.
> >> >
> >> > What do you think about that? I think searching within current
> >> > selected endpoint is good enough.
> >> >
> >> > [Sergey]
> >> >
> >> > Sounds ok, not sure about phrases but I guess it can be useful, I
> >> > thought users would really would like to see all the error messages or
> >> > indeed all the messages logged during some specific limited period of
> >> > time, but phrases may probably help those who know what sort of log
> >> > messages can be expected to narrow down the set to virtually a single
> >> > message or just few of them...
> >> >
> >> > [Sergey]
> >> >
> >> > May be you're right that it's better to have individual endpoint
> >> > having specific search conditions. But I'd really like to enter the
> >> > common search conditions, say, say show me the message with INFO level
> >> > only only, and then start clicking between multiple endpoints and see
> >> > the INFO logs only. However, I'd likely want to customize the way the
> >> > search conditions get applied to a given endpoint
> >> >
> >> > So how about being able to specify the search condition that applies
> >> > to all the endpoints first and once it all works ok, add the
> >> > capability to override it on per-endpoint basis ? Or the other way
> >> > around. I'd not be concerned about making both options work before the
> >> > merge to the trunk, just
> >> >
> >> > --
> >> > Best regards,
> >> > Tomasz Oponowicz
> >> >
> >
> >
>
Re: [CXF-2736] LogBrowser - future plans
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Tomasz
>
> sorry for a delay
>
> On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz
> <to...@gmail.com> wrote:
>>
>> Hi Sergey,
>>
>> Welcome everyone after quite long break.
>>
>> I've prepared sample user interface for "search capabilities" feature.
>>
>
> Great :-)
>
>>
>> Legend:
>>
>> * File [0]:
>>
>> 1) "All endpoints" entry is added after moving to "search" mode
>> (this entry isn't shown during "browsing mode").
>> If user choose particular endpoint, the application will
>> search log entries only within chosen endpoint;
>>
>> 2) User is informed that he is currently at "search mode".
>> He can return to "browsing mode" by clicking "reset" link;
>>
>> 3) "Advanced" checkbox shows or hides additional inputs like: from
>> date, to date and levels;
>>
>> 4) This button has two functions. First of all it shows what
>> levels are enabled.
>> For example when only INFO and ERROR levels are enabled then
>> label of the button has value "I/E".
>> Second of all popup is showed after clicking button (more info
>> in next section);
>>
>> * File [1]
>>
>> 1) Popup contains all possible log levels. Click on specified
>> level to enable or disable level.
>> If user click outside the popup, popup will disappear and new
>> configuration will be saved.
>>
>> Of course it's only a concept - all improvements are welcome.
>>
>
> I'm not quite sure I'd like, as a user, to switch between 'browsing' and
> 'searching' modes.
> I'd like to work in a single mode, the way I can do it right now by adding
> endpoints, clicking between them and looking at corresponding log entries.
>
> As I suggested earlier on, it would be nice for a start to have global
> search properties which apply to all the endpoints, just making it easy to
> configure in a very non intrusive way would be something which will let us
> move the code to the trunk.
>
> Thinking ahead, perhaps we can have what is the log browser now turning into
> a management UI where another tab would probably show the statistics
> (exchanges, etc) collected with the help of persisting interceptors. Thus
> I'm not sure if we can have a *menu* right now.
>
> Perhaps a pop-up window allowing to set search properties would do.
> Have a look please at Google Mail 'More Actions' which shows a number of
> menu items, one of them is "Create Event" which allows to set the event
> properties. So if we could have a button in the top right cotton "Settings"
> which, once pressed, would show only "Filter..." or "Search..." which in
> turn would lead to a pop-up window where a user would select how to search
> and press OK. From then on every endpoint will use this filter/search
> conditions.
>
I've prepared new interface by taking all good ideas into consideration.
At the [0] screenshot there is "explore" mode. I modified left sidebar
by adding stack panel. In the future we can add more children (for
example "statistics" header etc.). I think this solution is very
flexible. At the [1] screenshot there is "filter" mode. It looks
almost the same but there is additional "Edit criteria" link. User can
easily swap between this two modes. After pressing "Edit criteria"
link, dialog box is shown for modifying criteria [2].
I think this solution is good enough, so if you approve it I will begin coding.
What do you think?
> Additionally, if really needed, users could override the settings on a
> per-endpoint basis. Possibly by right-clicking on a specific endpoint and
> selecting "Filter..." or "Search..." from a popup menu.
>
> Do you think it's doable ?
Yes, no problem at all. I think it's good feature for future.
>>
>> I have got some technical question. How do you consider paging for
>> "All endpoints"? Because every endpoint is independent the only
>> solution would be gathered page from all endpoints and combine into
>> one huge page. Unfortunately I don't like this solution. Have you got
>> any idea?
>>
> Perhaps we should not introduce such a composite endpoint at this stage ?
> This would just make things much more complicated. AtomPullServer allows one
> to search from the external file but I'm not sure yet how to deal with that
> in the browser. You are right in that all the logs should be shown, but lets
> discuss it once we have the code on the trunk :-)
I introduce "composite endpoint" because of my misunderstanding. I
also agree that it would be problematic.
[0] https://issues.apache.org/jira/secure/attachment/12454988/searching_layout_explore_v2.png
[1] https://issues.apache.org/jira/secure/attachment/12454987/searching_layout_filter_v2.png
[2] https://issues.apache.org/jira/secure/attachment/12454989/searching_layout_edit_criteria_v2.png
--
Best regards,
Tomasz Oponowicz
> thanks, Sergey
>
>> [0]
>> https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
>> [1]
>> https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
>>
>> --
>> Best regards,
>> Tomasz Oponowicz
>>
>> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
>> <to...@gmail.com> wrote:
>> > Hi,
>> >
>> > GSOC has just ended. During this time LogBrowser was created. At the
>> > moment the project has all basic features like authentication,
>> > settings manager and browse layout which includes navigation links
>> > (first, previous, refresh, next and last page). I would really like to
>> > continue working with Apache CXF community. Together with Sergey, we
>> > think about how to extend the project to make it even more useful.
>> >
>> > We consider two crucial features right now:
>> >
>> > 1. search capabilities;
>> > 2. removing authentication when connection is not secure (it is not
>> > HTTPS);
>> >
>> > Below our discussion about that (we have some spam filter difficulties
>> > and this is why it looks so weird).
>> >
>> > =According to search capabilities=
>> >
>> > [Sergey]
>> >
>> > Offer some basic search options first, I think they should be global
>> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is
>> > offered a list of level options (level: INFO or DEBUG), just this
>> > would do, so the user would select : I'd like to see INFOS only, and
>> > then a FIQL expression is sent to AtomPullServer and it would just
>> > return the list of matching records.
>> >
>> > [Tomasz]
>> >
>> > I agree that search option is crucial feature right now. I think there
>> > should be available search criteria as follows:
>> >
>> > 1) specified phrase;
>> > 2) datetime range: begin and end datetime;
>> > 3) log entry level: INFO, etc;
>> >
>> > ...all parameters will be sent to AtomPullServer as FIQL expression
>> > (as you mentioned).
>> >
>> > Although I think it's better to have search only within current
>> > selected endpoint. We give an user an ability to divide all logs into
>> > plenty of endpoints for clean browsing but now we will search through
>> > all endpoint at once. I think it breaks basic assumption. However
>> > searching within selected endpoint isn't a problem, because
>> > AtomPullServer has powerful configuration capabilities and user can
>> > easily combine many loggers into one instance through "setLoggers"
>> > method.
>> >
>> > What do you think about that? I think searching within current
>> > selected endpoint is good enough.
>> >
>> > [Sergey]
>> >
>> > Sounds ok, not sure about phrases but I guess it can be useful, I
>> > thought users would really would like to see all the error messages or
>> > indeed all the messages logged during some specific limited period of
>> > time, but phrases may probably help those who know what sort of log
>> > messages can be expected to narrow down the set to virtually a single
>> > message or just few of them...
>> >
>> > [Sergey]
>> >
>> > May be you're right that it's better to have individual endpoint
>> > having specific search conditions. But I'd really like to enter the
>> > common search conditions, say, say show me the message with INFO level
>> > only only, and then start clicking between multiple endpoints and see
>> > the INFO logs only. However, I'd likely want to customize the way the
>> > search conditions get applied to a given endpoint
>> >
>> > So how about being able to specify the search condition that applies
>> > to all the endpoints first and once it all works ok, add the
>> > capability to override it on per-endpoint basis ? Or the other way
>> > around. I'd not be concerned about making both options work before the
>> > merge to the trunk, just
>> >
>> > --
>> > Best regards,
>> > Tomasz Oponowicz
>> >
>
>
Re: [CXF-2736] LogBrowser - future plans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Tomasz
sorry for a delay
On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:
> Hi Sergey,
>
> Welcome everyone after quite long break.
>
> I've prepared sample user interface for "search capabilities" feature.
>
>
Great :-)
> Legend:
>
> * File [0]:
>
> 1) "All endpoints" entry is added after moving to "search" mode
> (this entry isn't shown during "browsing mode").
> If user choose particular endpoint, the application will
> search log entries only within chosen endpoint;
>
> 2) User is informed that he is currently at "search mode".
> He can return to "browsing mode" by clicking "reset" link;
>
> 3) "Advanced" checkbox shows or hides additional inputs like: from
> date, to date and levels;
>
> 4) This button has two functions. First of all it shows what
> levels are enabled.
> For example when only INFO and ERROR levels are enabled then
> label of the button has value "I/E".
> Second of all popup is showed after clicking button (more info
> in next section);
>
> * File [1]
>
> 1) Popup contains all possible log levels. Click on specified
> level to enable or disable level.
> If user click outside the popup, popup will disappear and new
> configuration will be saved.
>
> Of course it's only a concept - all improvements are welcome.
>
>
I'm not quite sure I'd like, as a user, to switch between 'browsing' and
'searching' modes.
I'd like to work in a single mode, the way I can do it right now by adding
endpoints, clicking between them and looking at corresponding log entries.
As I suggested earlier on, it would be nice for a start to have global
search properties which apply to all the endpoints, just making it easy to
configure in a very non intrusive way would be something which will let us
move the code to the trunk.
Thinking ahead, perhaps we can have what is the log browser now turning into
a management UI where another tab would probably show the statistics
(exchanges, etc) collected with the help of persisting interceptors. Thus
I'm not sure if we can have a *menu* right now.
Perhaps a pop-up window allowing to set search properties would do.
Have a look please at Google Mail 'More Actions' which shows a number of
menu items, one of them is "Create Event" which allows to set the event
properties. So if we could have a button in the top right cotton "Settings"
which, once pressed, would show only "Filter..." or "Search..." which in
turn would lead to a pop-up window where a user would select how to search
and press OK. From then on every endpoint will use this filter/search
conditions.
Additionally, if really needed, users could override the settings on a
per-endpoint basis. Possibly by right-clicking on a specific endpoint and
selecting "Filter..." or "Search..." from a popup menu.
Do you think it's doable ?
> I have got some technical question. How do you consider paging for
> "All endpoints"? Because every endpoint is independent the only
> solution would be gathered page from all endpoints and combine into
> one huge page. Unfortunately I don't like this solution. Have you got
> any idea?
>
> Perhaps we should not introduce such a composite endpoint at this stage ?
This would just make things much more complicated. AtomPullServer allows one
to search from the external file but I'm not sure yet how to deal with that
in the browser. You are right in that all the logs should be shown, but lets
discuss it once we have the code on the trunk :-)
thanks, Sergey
[0]
> https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
> [1]
> https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
>
> --
> Best regards,
> Tomasz Oponowicz
>
> On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
> <to...@gmail.com> wrote:
> > Hi,
> >
> > GSOC has just ended. During this time LogBrowser was created. At the
> > moment the project has all basic features like authentication,
> > settings manager and browse layout which includes navigation links
> > (first, previous, refresh, next and last page). I would really like to
> > continue working with Apache CXF community. Together with Sergey, we
> > think about how to extend the project to make it even more useful.
> >
> > We consider two crucial features right now:
> >
> > 1. search capabilities;
> > 2. removing authentication when connection is not secure (it is not
> HTTPS);
> >
> > Below our discussion about that (we have some spam filter difficulties
> > and this is why it looks so weird).
> >
> > =According to search capabilities=
> >
> > [Sergey]
> >
> > Offer some basic search options first, I think they should be global
> > for a start, i.e, they'd apply to all the endpoints. Ex : a user is
> > offered a list of level options (level: INFO or DEBUG), just this
> > would do, so the user would select : I'd like to see INFOS only, and
> > then a FIQL expression is sent to AtomPullServer and it would just
> > return the list of matching records.
> >
> > [Tomasz]
> >
> > I agree that search option is crucial feature right now. I think there
> > should be available search criteria as follows:
> >
> > 1) specified phrase;
> > 2) datetime range: begin and end datetime;
> > 3) log entry level: INFO, etc;
> >
> > ...all parameters will be sent to AtomPullServer as FIQL expression
> > (as you mentioned).
> >
> > Although I think it's better to have search only within current
> > selected endpoint. We give an user an ability to divide all logs into
> > plenty of endpoints for clean browsing but now we will search through
> > all endpoint at once. I think it breaks basic assumption. However
> > searching within selected endpoint isn't a problem, because
> > AtomPullServer has powerful configuration capabilities and user can
> > easily combine many loggers into one instance through "setLoggers"
> > method.
> >
> > What do you think about that? I think searching within current
> > selected endpoint is good enough.
> >
> > [Sergey]
> >
> > Sounds ok, not sure about phrases but I guess it can be useful, I
> > thought users would really would like to see all the error messages or
> > indeed all the messages logged during some specific limited period of
> > time, but phrases may probably help those who know what sort of log
> > messages can be expected to narrow down the set to virtually a single
> > message or just few of them...
> >
> > [Sergey]
> >
> > May be you're right that it's better to have individual endpoint
> > having specific search conditions. But I'd really like to enter the
> > common search conditions, say, say show me the message with INFO level
> > only only, and then start clicking between multiple endpoints and see
> > the INFO logs only. However, I'd likely want to customize the way the
> > search conditions get applied to a given endpoint
> >
> > So how about being able to specify the search condition that applies
> > to all the endpoints first and once it all works ok, add the
> > capability to override it on per-endpoint basis ? Or the other way
> > around. I'd not be concerned about making both options work before the
> > merge to the trunk, just
> >
> > --
> > Best regards,
> > Tomasz Oponowicz
> >
>
Re: [CXF-2736] LogBrowser - future plans
Posted by Tomasz Oponowicz <to...@gmail.com>.
Hi Sergey,
Welcome everyone after quite long break.
I've prepared sample user interface for "search capabilities" feature.
Legend:
* File [0]:
1) "All endpoints" entry is added after moving to "search" mode
(this entry isn't shown during "browsing mode").
If user choose particular endpoint, the application will
search log entries only within chosen endpoint;
2) User is informed that he is currently at "search mode".
He can return to "browsing mode" by clicking "reset" link;
3) "Advanced" checkbox shows or hides additional inputs like: from
date, to date and levels;
4) This button has two functions. First of all it shows what
levels are enabled.
For example when only INFO and ERROR levels are enabled then
label of the button has value "I/E".
Second of all popup is showed after clicking button (more info
in next section);
* File [1]
1) Popup contains all possible log levels. Click on specified
level to enable or disable level.
If user click outside the popup, popup will disappear and new
configuration will be saved.
Of course it's only a concept - all improvements are welcome.
I have got some technical question. How do you consider paging for
"All endpoints"? Because every endpoint is independent the only
solution would be gathered page from all endpoints and combine into
one huge page. Unfortunately I don't like this solution. Have you got
any idea?
[0] https://issues.apache.org/jira/secure/attachment/12454295/searching_layout_v1.png
[1] https://issues.apache.org/jira/secure/attachment/12454296/searching_layout_with_popup_v1.png
--
Best regards,
Tomasz Oponowicz
On Mon, Aug 30, 2010 at 1:11 PM, Tomasz Oponowicz
<to...@gmail.com> wrote:
> Hi,
>
> GSOC has just ended. During this time LogBrowser was created. At the
> moment the project has all basic features like authentication,
> settings manager and browse layout which includes navigation links
> (first, previous, refresh, next and last page). I would really like to
> continue working with Apache CXF community. Together with Sergey, we
> think about how to extend the project to make it even more useful.
>
> We consider two crucial features right now:
>
> 1. search capabilities;
> 2. removing authentication when connection is not secure (it is not HTTPS);
>
> Below our discussion about that (we have some spam filter difficulties
> and this is why it looks so weird).
>
> =According to search capabilities=
>
> [Sergey]
>
> Offer some basic search options first, I think they should be global
> for a start, i.e, they'd apply to all the endpoints. Ex : a user is
> offered a list of level options (level: INFO or DEBUG), just this
> would do, so the user would select : I'd like to see INFOS only, and
> then a FIQL expression is sent to AtomPullServer and it would just
> return the list of matching records.
>
> [Tomasz]
>
> I agree that search option is crucial feature right now. I think there
> should be available search criteria as follows:
>
> 1) specified phrase;
> 2) datetime range: begin and end datetime;
> 3) log entry level: INFO, etc;
>
> ...all parameters will be sent to AtomPullServer as FIQL expression
> (as you mentioned).
>
> Although I think it's better to have search only within current
> selected endpoint. We give an user an ability to divide all logs into
> plenty of endpoints for clean browsing but now we will search through
> all endpoint at once. I think it breaks basic assumption. However
> searching within selected endpoint isn't a problem, because
> AtomPullServer has powerful configuration capabilities and user can
> easily combine many loggers into one instance through "setLoggers"
> method.
>
> What do you think about that? I think searching within current
> selected endpoint is good enough.
>
> [Sergey]
>
> Sounds ok, not sure about phrases but I guess it can be useful, I
> thought users would really would like to see all the error messages or
> indeed all the messages logged during some specific limited period of
> time, but phrases may probably help those who know what sort of log
> messages can be expected to narrow down the set to virtually a single
> message or just few of them...
>
> [Sergey]
>
> May be you're right that it's better to have individual endpoint
> having specific search conditions. But I'd really like to enter the
> common search conditions, say, say show me the message with INFO level
> only only, and then start clicking between multiple endpoints and see
> the INFO logs only. However, I'd likely want to customize the way the
> search conditions get applied to a given endpoint
>
> So how about being able to specify the search condition that applies
> to all the endpoints first and once it all works ok, add the
> capability to override it on per-endpoint basis ? Or the other way
> around. I'd not be concerned about making both options work before the
> merge to the trunk, just
>
> --
> Best regards,
> Tomasz Oponowicz
>