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 <sberyoz...@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 <sberyoz...@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.oponow...@gmail.com> wrote: >>> >>> 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 >>> >> > >>> > >>> > >> > >
