Hi Sergey, On Tue, Mar 15, 2011 at 11:13 PM, Sergey Beryozkin <[email protected]> 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
