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...
> > > 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 ? 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://www.talend.com> http://sberyozkin.blogspot.com
