Hi Sergey, On Tue, Sep 14, 2010 at 11:33 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > Hi Tomasz > > sorry for a delay > > On Fri, Sep 10, 2010 at 4:01 PM, Tomasz Oponowicz > <tomasz.oponow...@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 >> <tomasz.oponow...@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 >> > > >
