We need to be able to parse the identifier, which either requires everything to be separated by spaces (like the expressionrule requires) or we need to delimit keywords with some character, like single quote.
Examples: Both would resolve to something like 'mybox-appname': (spaces are removed after the event's values are retrieved) PROP.log4jmachinename - PROP.log4japp Or (single quotes are removed after the event's valus are retrieved) 'PROP.log4japp'-'MDC.userID' If we used the former, we could just use a stringtokenizer, do an 'iskeyword' check on the resolver, and if it is, get the value using the resolver. Everything is appended until there are no more tokens and that's the identifier. For the latter, we walk the string, turning everything between ticks into resolver lookups, everything else is appended similar to the stringtokenizer version. We could be smarter about it but that would require more complicated scanner logic. Thoughts? -----Original Message----- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 3:14 PM To: Log4J Developers List Subject: RE: [chainsaw] chainsaw with multiple tabs... > For example, for the way Chainsaw currently works, the only expression > it's supporting is: PROP.log4jmachinename-PROP.log4japp At a minimum we should at least convert over the ChainsawAppenderHandler code so that it is configurable, rather than how we have it now (it's a bunch of if()'s with some logic). Given that the current structure of the tab routing mechanism requires ChainsawAppenderHandler to create an 'identifier' object (string), could you show how the Expression stuff could create an identifier? (This is probably easy...) I can see a way we could use a PatternLayout instance that outputs an identifier string? So the current mechanism would as a pattern layout: %properties{hostName}-%properties{application} As you said, we could open this up via an application Preferences dialog so that those people that ALWAYS want new tabs spawned a particular way could do so. I would however prefer this to be expression-based so that it is consistent with what I describe below, but I am not familiar enough with the expression stuff to really know. Could you describe it Scott? > Paul mentioned he's interested in the ability of deriving views of an > existing LogPanel, which is a great idea, and can use the same > mechanism. Sub-views would generally be a temporary thing, sort of like "What IS that Thread/User/App/Host doing?.....". The user could then temporarily create a sub-view based on an expression. The _original_ Tab would continue to receive and display all the events including those matching the sub-view expression, just the new tab would only display the events based on the expression. The sub-view is just a new (filtered) window into the data model. The sub-view would then fill the gap between the more 'permanent' tab-routing mechanism, and the general filtering/focus-on mechanism you have within a LogPanel at the moment. cheers, Paul Smith --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
