Question/suggestion regarding use of assertions in unit tests.

quot;patches welcome", I'd be glad to help update unit tests for such a thing. :) -- Matt Sicker

Re: Question/suggestion regarding use of assertions in unit tests.

today I was unaware of > directly using Hamcrest. Since junit uses it I really have no problem if we > do if it makes the tests more readable. > > Ralph > > On Jan 5, 2014, at 12:38 AM, Matt Sicker wrote: > > Hi all, newcomer here. I'm wondering what your opinions

Re: GA Release Date for log4j2

> On Jan 11, 2014, at 4:14, Peter McCarthy > wrote: > > I am wondering if there is a GA date decided for log4j2? > > Is patch 9 the last beta release, or are there many more beta loads planned ? The next release will be an RC release. > > The reason I ask is we currently use log4j, howev

Re: GA Release Date for log4j2

some latitude. > > Ralph > > On Jan 11, 2014, at 10:52 AM, Matt Sicker wrote: > > > > > > >> On Jan 11, 2014, at 4:14, Peter McCarthy > wrote: > >> > >> I am wondering if there is a GA date decided for log4j2? > >> > >&

Question about Log4jServletFilter in core.

Now I'm not sure if I'm interpreting this correctly, but init() clears the current thread's logger context, and destroy() sets it. What's up with this? Especially since it just gets set and cleared in the doFilter() bit. -- Matt Sicker

Re: Question about Log4jServletFilter in core.

;> startup. The ServletContainerInitializer sets the threads logger context so >> that web app startup procedures can use it. The filter's init() method >> clears it near the end of startup so that it doesn't bleed into another web >> app. >> >> Then, on

Re: Web Issues, Logging Levels, and GA

e a drop-in replacement for and binary compatible >>>> with the current Level enum) is not going to be accepted. Absent any other >>>> proposals, I suggest we add the following new levels before GA: >>>> >>>> CONFIG - Between INFO and WARN, mapped to INFO for bridges to other >>>> frameworks that don't have an equivalent level >>>> >>>> FINE - Between DEBUG and TRACE, mapped to TRACE for bridges to other >>>> frameworks that don't have an equivalent level >>>> >>>> I'll let y'all chat about that over the next week. ;-) >>>> >>>> Be back soon, >>>> >>>> Nick >>>> - >>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- Matt Sicker

Re: Web Issues, Logging Levels, and GA

baggage claim, so please forgive brief > replies and frequent typos > > On Jan 18, 2014, at 14:01, Matt Sicker wrote: > > Markers all around! No logging levels, just allow markers to have ordinals > or bit-flags to allow more flexible filtering. > > Sorry, nothing usefu

Re: Question about Log4jServletFilter in core.

only does this issue only affect devs using async > requests, but also of THOSE situations it only really makes an impact with > non-standard configurations. Typical "out of the box" configurations don't > really NEED the logging context set up on each request. > > N >

Re: Web Issues, Logging Levels, and GA

; On Jan 18, 2014, at 2:29 PM, Ralph Goers > wrote: > > Hmm. I actually like LIFECYCLE much better than CONFIG. However, QUIET > seems like a very odd name. > > Ralph > > On Jan 18, 2014, at 2:16 PM, Matt Sicker wrote: > > For a more constructive answer, I would like to

Re: Question about Log4jServletFilter in core.

4J2-452 as I've also addressed some abuse of the synchronization keyword issues as well. I should be done with this patch within the next few hours. On 18 January 2014 17:13, Nick Williams wrote: > > On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote: > > I somewhat figured that any

Re: Question about Log4jServletFilter in core.

r context definitely is already > added to the Servlet context attributes. It's adding it to each request's > attributes in the filter that's needed, if I remember the code correctly. > I'm not in a position to look at it right now. > > N > > > On Jan 18,

Re: [jira] [Commented] (LOG4J2-501) Issue on config log4j2 with JSON

}, > > "loggers": { > > "root": { "level": "trace", > > "AppenderRef": { "ref": "STDOUT" }, > > "AppenderRef": { "ref": "FILE" } > > } > > } > > } > > } > > {code} > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: Web Issues, Logging Levels, and GA

> I'm much in favor of keeping the existing levels. We can make markers easier > to use and document how people can use them to create whatever custom level > they want. I think this is a much more powerful solution than modifying the > existing levels. How about making it as easy to filter by

Re: Web Issues, Logging Levels, and GA

;>>>> On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers < >>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> I tend to agree that there is ambiguity between TRACE and VERBOSE, >>>>>>>> but I have no problem adding it if it means end users will have more >>>>>>>> flexibility with little cost. >>>>>>>> >>>>>>>> >>>>>>> I think this is meaningless flexibility. It smells of adding a >>>>>>> feature without a good reason. Imagine the conversations people will >>>>>>> have >>>>>>> to explain the difference between TRACE and VERBOSE. I can't think of >>>>>>> any >>>>>>> good universal justification for its use that demands an addition to >>>>>>> log4j. >>>>>>> >>>>>> >>>>>> If you do not like it, do not use it ;) >>>>>> >>>>>> This is best reserved for a personal extension. >>>>>>> >>>>>> >>>>>> Which is not possible since Level is an enum, hence this discussion >>>>>> before the API freezes. >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second >>>>>> Edition<http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Paul >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Paul >>>> >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> Paul >>> >>> >>> >> >> >> -- >> Cheers, >> Paul >> > > -- Matt Sicker

Re: Enums and Custom Levels

Neat idea. I'd update it for proper concurrency, though. I could write a mock version of this to show what I mean. Matt Sicker > On Jan 23, 2014, at 2:42, Nick Williams wrote: > > Okay, I finally got a minute to read all of these emails, and... > > EVERYBODY FREEZE! >

Re: Enums and Custom Levels

dd new methods for them > to AbstractLogger. > > Ralph > > On Jan 23, 2014, at 7:49 AM, Paul Benedict wrote: > > It's a neat idea but it's not a Java enum. I think one of Ralph's goal was > to allow client code to use enums. I still think we should continue th

Re: Enums and Custom Levels

t;>> the feature of getting enums to represent custom levels. That's pretty >>>>> cool, IMO. I don't know if any other logging framework has that and that >>>>> would probably get some positive attention. It shouldn't be so hard to do >>>>> a >>>>> find+replace on the code that accepts Level and replace it with another >>>>> name. Yes, there will be some minor refactoring that goes with it, but >>>>> hard? It shouldn't be. >>>>> >>>>> A name I propose for the interface is LevelDefinition. >>>>> >>>>> Paul >>>>> >>>>> >>>>> On Wed, Jan 22, 2014 at 6:48 PM, Gary Gregory >>>>> wrote: >>>>> >>>>> Hi, I do not see this as an engineering problem but more a feature set >>>>> definition issue. So while there may be lots of more or less internally >>>>> complicated ways of solving this with interfaces, makers and whatnots, the >>>>> built in levels are the most user friendly. >>>>> >>>>> I have have lots of buttons, knobs and settings on my sound system >>>>> that I do not use, just like I do not use all the methods in all the >>>>> classes in the JRE... >>>>> >>>>> Gary >>>>> >>>>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > -- Matt Sicker

Re: Enums and Custom Levels

That sounds like a pretty good idea. Matt Sicker > On Jan 25, 2014, at 15:18, Ralph Goers wrote: > > Here is what I am implementing: > > 1. Level is now an Interface. This allows the vast amount of code to > continue to work. > 2. The current Level enum has been re

Re: logging to solr/elasticsearch

er i had a lot of optional field mapping whicht made the > configuration within the log4j.xml quite big > > would be great to get some feedback. > this could be a good way to connect log events directly to a tool like > kibana > > regards > Markus Klose > > > -- Matt Sicker

Re: Enums and Custom Levels - completed.

is > potential usage in mind. > >>>>>> > >>>>>> Remko > >>>>>> > >>>>>> > >>>>>> On Friday, January 24, 2014, Gary Gregory > wrote: > >>>>>> I am discussing custom levels here with the understanding that this > is a separate topic from what the built-in levels are. Here is how I > convinced myself that custom levels are a “good thing”. > >>>>>> > >>>>>> No matter which built-in levels exits, I may want custom levels. > For example, I want my app to use the following levels DEFCON1, DEFCON2, > DEFCON3, DEFCON4, and DEFCON5. This might be for one part of my app or a > whole subsystem, no matter, I want to use the built-in levels in addition > to the DEFCON levels. It is worth mentioning that if I want that feature > only as a user, I can “skin” levels in a layout and assign any label to the > built-in levels. If I am also a developer, I want to use DEFCON levels in > the source code. > >>>>>> > >>>>>> > >>>>>> > >>>>>> At first, my code might look like: > >>>>>> > >>>>>> > >>>>>> > >>>>>> logger.log(DefconLevels.DEFCON5, “All is quiet”); > >>>>>> > >>>>>> > >>>>>> > >>>>>> Let’s put aside for now the type of DefconLevels.DEFCON* objects. I > am a user, and I care about my call sites. > >>>>>> > >>>>>> > >>>>>> > >>>>>> What I really want of course is to write: > >>>>>> > >>>>>> > >>>>>> > >>>>>> defconLogger.defcon5(“All is quiet”) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Therefore, I argue that for any “serious” use of a custom level, I > will wrap a Logger in a custom logger class providing call-site friendly > methods like defcon5(String). > >>>>>> > >>>>>> > >>>>>> > >>>>>> So now, as a developer, all I care about is DefConLogger. It might > wrap (or subclass) the Log4J Logger, who knows. The implementation of > DefConLogger is not important to the developer (all I care is that the > class has ‘defconN’ method) but it is important to the configuration > author. This tells me that as a developer I do not care how DefConLogger is > implemented, with custom levels, markers, or elves. However, as > configuration author, I also want to use DEFCON level just like the > built-in levels. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The configuration code co > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >>>>>> Java Persistence with Hibernate, Second Edition > >>>>>> JUnit in Action, Second Edition > >>>>>> Spring Batch in Action > >>>>>> Blog: http://garygregory.wordpress.com > >>>>>> Home: http://garygregory.com/ > >>>>>> Tweet! http://twitter.com/GaryGregory > >>>>> > >>>> > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org > >> > > > > > > - > > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: Enums and Custom Levels - completed.

>>>>>> understanding that this is a separate topic from what the >>> built-in >>> >> >>>>>> levels are." >>> >> >>>>>> >>> >> >>>>>> I'm not sure why you want to make the features mutually >>> exclusive. >>> >> >>>>>> (Some) others agree that these are different features. >>> >> >>>>>> >>> >> >>>>>> I see two topics: >>> >> >>>>>> >>> >> >>>>>> - What are the default levels for a 21st century logging >>> framework. >>> >> >>>>>> Do we simply blindly copy Log4j 1? Or do we look at frameworks >>> from >>> >> >>>>>> different languages and platforms for inspiration? >>> >> >>>>>> - How (not if, I think we all agree) should we allow for custom >>> >> >>>>>> levels. >>> >> >>>>>> >>> >> >>>>>> Gary >>> >> >>>>>> >>> >> >>>>>>> It definitely makes sense to design the extensible enum with >>> this >>> >> >>>>>>> potential usage in mind. >>> >> >>>>>>> >>> >> >>>>>>> Remko >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> On Friday, January 24, 2014, Gary Gregory < >>> garydgreg...@gmail.com> >>> >> >>>>>>> wrote: >>> >> >>>>>>>> >>> >> >>>>>>>> I am discussing custom levels here with the understanding >>> that >>> >> >>>>>>>> this is a separate topic from what the built-in levels are. >>> Here >>> >> >>>>>>>> is how I convinced myself that custom levels are a “good >>> thing”. >>> >> >>>>>>>> >>> >> >>>>>>>> No matter which built-in levels exits, I may want custom >>> levels. >>> >> >>>>>>>> For example, I want my app to use the following levels >>> DEFCON1, >>> >> >>>>>>>> DEFCON2, DEFCON3, DEFCON4, and DEFCON5. This might be for one >>> >> >>>>>>>> part of my app or a whole subsystem, no matter, I want to >>> use the >>> >> >>>>>>>> built-in levels in addition to the DEFCON levels. It is worth >>> >> >>>>>>>> mentioning that if I want that feature only as a user, I can >>> >> >>>>>>>> “skin” levels in a layout and assign any label to the >>> built-in >>> >> >>>>>>>> levels. If I am also a developer, I want to use DEFCON >>> levels in >>> >> >>>>>>>> the source code. >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> At first, my code might look like: >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> logger.log(DefconLevels.DEFCON5, “All is quiet”); >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> Let’s put aside for now the type of DefconLevels.DEFCON* >>> objects. >>> >> >>>>>>>> I am a user, and I care about my call sites. >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> What I really want of course is to write: >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> defconLogger.defcon5(“All is quiet”) >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> Therefore, I argue that for any “serious” use of a custom >>> level, >>> >> >>>>>>>> I will wrap a Logger in a custom logger class providing >>> call-site >>> >> >>>>>>>> friendly methods like defcon5(String). >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> So now, as a developer, all I care about is DefConLogger. It >>> >> >>>>>>>> might wrap (or subclass) the Log4J Logger, who knows. The >>> >> >>>>>>>> implementation of DefConLogger is not important to the >>> developer >>> >> >>>>>>>> (all I care is that the class has ‘defconN’ method) but it is >>> >> >>>>>>>> important to the configuration author. This tells me that as >>> a >>> >> >>>>>>>> developer I do not care how DefConLogger is implemented, with >>> >> >>>>>>>> custom levels, markers, or elves. However, as configuration >>> >> >>>>>>>> author, I also want to use DEFCON level just like the >>> built-in >>> >> >>>>>>>> levels. >>> >> >>>>>>>> >>> >> >>>>>>>> >>> >> >>>>>>>> The configuration code co >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> -- >>> >> >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> >> >>>> Java Persistence with Hibernate, Second Edition >>> >> >>>> JUnit in Action, Second Edition >>> >> >>>> Spring Batch in Action >>> >> >>>> Blog: http://garygregory.wordpress.com >>> >> >>>> Home: http://garygregory.com/ >>> >> >>>> Tweet! http://twitter.com/GaryGregory >>> >> >> >>> >> >> >>> >> > >>> > >>> > >>> >>> - >>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> >>> >> > -- Matt Sicker

Re: Enums and Custom Levels - completed.

t. > > Ralph > > On Jan 26, 2014, at 4:10 PM, Ralph Goers > wrote: > > My first implementation used a real enum that implemented a Level > interface. I have to agree with Nick that what is currently committed is > simpler. > > Ralph > > On Jan 26, 2014, at 4:

Re: Enums and Custom Levels - completed.

ined strictly via configuration. I agree there may be >> some hurdles but that's my goal. >> >> I'd like to avoid the requirement that users provide their own level >> implementation or use a different API. >> >> Scott >> >>> >>> >> > -- Matt Sicker

Re: Enums and Custom Levels - completed.

larify... Is the custom > logging interface a nice-to-have or a requirement of the system? > > I was hoping simply someone could write this (pseudocode below): > logger.log(MyCustomLevels.LEVEL1, "message"); > > ...so no different interface should be required, right? Can

Re: Enums and Custom Levels - completed.

e current > name. > > Any other thoughts or opinions? > > Ralph > > > On Jan 26, 2014, at 7:28 PM, Matt Sicker wrote: > > How about Level.forName()? > > > On 26 January 2014 21:06, Ralph Goers wrote: > >> No objections on spawning a separate thre

Re: Using Custom Levels with a Custom/Wrapper Interface

gerClass, String, >> MessageFactory) >> > >> > The user can then obtain such a logger like so, etc.: >> > >> > MyLogger logger = LogManager.getCustomLogger(MyLogger.class); >> > >> > Log4j will generate an implementation of MyLogger that exten

Re: Enums and Custom Levels - completed.

ut it must be unique by the name. > > For that matter, what are we to do in the following situation? > > Level.getOrCreate("DIAG", 150); > ... > Level.getOrCreate("DIAG", 250); > > They're not going to get what they expect in both ca

Re: Using Custom Levels with a Custom/Wrapper Interface

: > >>>>>>> > >>>>>>> logger.note("message"); > >>>>>>> logger.diag("message"); > >>>>>>> etc. > >>>>>>> > >>>>>>> We're to discuss h

Re: GA?

onal commands, e-mail: log4j-dev-h...@logging.apache.org >>> >>> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: GA?

s, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Logger isLevelEnabled()

econd Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Logger isLevelEnabled()

logic is only needed is your method > call is doing preformatting or some other heavy calculation. There is no > need to incur the expense if the log level is disabled. > On Jan 27, 2014 8:06 PM, "Matt Sicker" wrote: > >> I like the shorter version better. Is it always

Re: Using Custom Levels with a Custom/Wrapper Interface

was overcomplicating things... >> Why don't we generate source for a concrete class instead of an >> interface+implementation? >> >> If users want to /extend/ Logger, this class would extend >> AbstractLoggerWrapper (which has the standard debug(), info(), warn(), ... >> methods). >> >> If users want to hide the standard methods, the generated class would >> simply not extend AbstractLoggerWrapper, so the only public methods would >> be the generated methods for the custom log levels. >> >> This allows users to generate both extended loggers (with extra methods) >> and custom domain specific Loggers (like a logger that only has defcon1(), >> defcon2(), defcon3() methods). >> >> -- Matt Sicker

Re: [jira] [Commented] (LOG4J2-518) Logging of nested list uses incorrect charset

; %p %C{1.} [%t] %m%n > > UTF-8 > > > > > > {code} > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: ApacheCon CFP

already implemented, creating additional components (I.e., appenders, filters, layouts, etc.), and many other ideas. Obviously that's too much to cover in one talk, but it's a good place to start examining what topics to cover and at what levels of expertise. Matt Sicker > On Jan

Re: ApacheCon CFP

d this > deadline. > > > > However you talk sounds good. Just from experience, people are sometimes > setup > > when they hear they should move their facade from slf4j to log4j2 again. > Be prepared > > to have good arguments > > > > Any great if you could

Re: ApacheCon CFP

r CFPs, lets coordinate and come to a consensus on > which of us is doing which CFP. Having two people there covering Log4j > would be great! > > I've only drafted out a couple ideas so far, but they match up with one as your first one, and the other a union of the remaining.

Re: ApacheCon CFP

Yeah that would work. Nashville huh? My co-worker is from there too, neat. In regard to the async and such, I think that'd be a great idea. One of the selling points of log4j over logback is performance, right? Matt Sicker > On Jan 31, 2014, at 0:52, Nick Williams wrote: > >

Re: Logo contest: nominate your favorite logo

- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> -- Matt Sicker

Re: What will the GA version number be?

> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > --- > http://www.grobmeier.de > The Zen Programmer: http://bit.ly/12lC6DL > @grobmeier > GPG: 0xA5CC90DB > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: What will the GA version number be?

On 3 February 2014 15:41, Christian Grobmeier wrote: > On 3 Feb 2014, at 22:14, Matt Sicker wrote: > > > I like 2.0.0 because semver.org etc., although as long as it's not a > dumb > > version number like GA or RELEASE or Final, I'm happy with it. > > Sticking with s

Re: Logo contest: nominate your favorite logo

gt;>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning. >>>>>>> com/bauer3/> >>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>> >>>>>>> Blog: http://garygregory.wordpress.com >>>>>>> Home: http://garygregory.com/ >>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>> >>>>>>> >>>>>> >>>>>> --- >>>>>> http://www.grobmeier.de >>>>>> The Zen Programmer: http://bit.ly/12lC6DL >>>>>> @grobmeier >>>>>> GPG: 0xA5CC90DB >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>> Java Persistence with Hibernate, Second Edition<http://www.manning. >>>>> com/bauer3/> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>> Blog: http://garygregory.wordpress.com >>>>> Home: http://garygregory.com/ >>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>> >>>> >>>> --- >>>> http://www.grobmeier.de >>>> The Zen Programmer: http://bit.ly/12lC6DL >>>> @grobmeier >>>> GPG: 0xA5CC90DB >>>> >>>> - >>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>> >>> >> >> >> -- >> Cheers, >> Paul >> >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: What will the GA version number be?

: >> >>> Well well well. I'm sensing a lot of disagreement. Too bad my book goes >>> to the printers Wednesday. I have a feeling no matter what I put in it >>> there's a good chance it'll change. :-P >>> >>> Any way we can come to a

Re: [jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers

.apache.logging.log4j.Logger; > > final Logger logger = LogManager.getLogger(MyClass.class); // standard > log4j logger > > final Level VERBOSE = Level.forName("VERBOSE", 550); > > logger.log(VERBOSE, "a verbose message"); > > {code} > > users would instead write: > > {code} > > // MyLogger is a generated customized logger wrapper > > import com.mycompany.myproject.MyLogger; > > final MyLogger logger = MyLogger.create(MyClass.class); > > logger.verbose("a verbose message"); > > {code} > > Creating an extended or customized Logger is as easy as creating a > standard Logger (one line of code). Extended Loggers are drop-in > replacements for standard Loggers - they only add more convenience methods. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: About the DriverManagerConnectionSource

king for some input from the rest of y'all on which direction we > should take, or if you can think of any other options. > > Thanks, > > Nick > --------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Re: About the DriverManagerConnectionSource

gt;> One other option (or perhaps this is more a migration path issue) is to >> leave the DriverManagerConnectionSource there but mark it as >> deprecated/dangerous/broken. Emit an ominous warn status logger message for >> existing users, and in the docs clarify that this will be removed in a >> subsequent release because we can't support it. >> >> >> It would be rather illogical to deprecate a class and say it will be >> remove "later" when we haven't even gone GA yet. >> > > Some people are using beta-9 in production, and I was thinking to provide > a migration path for them. But on second thought, simply removing is > cleaner. If people want to upgrade they should use a pooled > connection source. I'm fine with that. > > >> Nick >> > -- Matt Sicker

On OSGi and class loading.

e experience with at my job thanks to other programmers not spending any time in updating their own code to use 4.3), this could also be a bit of a disaster. I wouldn't want a huge split in the versions people use because of API changes like that. The custom Felix SCR processor idea would probably be the most backward-compatible way to do this in that regard. -- Matt Sicker

Good news about Reflection.getCallerClass(int) in JDK8.

elper class in log4j-api instead of duplicating this functionality in at least 2 or 3 separate locations as it is now. -- Matt Sicker

Re: Good news about Reflection.getCallerClass(int) in JDK8.

In very abbreviated form, only privileged, JDK code can > call getCallerClass(). They initially removed getCallerClass(int), but we > convinced them to restore it until they could come up with a public API > replacement in Java 9. > > We cannot do as you suggest. > > Nick >

Re: Good news about Reflection.getCallerClass(int) in JDK8.

So does JDK8 add that security restriction to getCallerClass(int) as well? On 9 February 2014 13:57, Nick Williams wrote: > Yes. The C++ code enforces the restriction. I've edited it, so I know it > first hand. :-) > > Nick > > On Feb 9, 2014, at 1:51 PM, Matt Sic

Re: Good news about Reflection.getCallerClass(int) in JDK8.

ey did, however, agree to restore > getCallerClass(int) in a deprecated but unrestricted state in 1.7.0_40+ and > 1.8.0_+ until they could create a public API to replace it in Java 9. > > Like I said ... go through the archives. :-) > > N > > > On Feb 9, 2014, at 1:58 PM, Ma

Re: [ANNOUNCEMENT] Nick Williams joins the Apache Logging PMC

j-dev-h...@logging.apache.org > > > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

OSGi version numbering.

rom common practices for versioning, but it's nice to keep in mind if you guys don't like increasing the minor version very often. -- Matt Sicker

Re: OSGi version numbering.

r at the manifest for version > info? > > Sent from my iPhone > > On 2014/02/20, at 1:31, Matt Sicker wrote: > > Just a quick follow-up to making things nice for the bundles. Version > numbers in OSGi are in the format: "major.minor.micro.thing" where the > major

Re: OSGi version numbering.

ugin API that exists with the Felix SCR annotation processor plugin to automate the declarative services stuff. Overall, I don't think true OSGi support will be ready for 2.0, but we should take care of any necessary API changes before GA. Matt Sicker > On Feb 20, 2014, at 0:41, Remk

Re: Health

Glad to hear you're doing better! Matt Sicker > On Feb 20, 2014, at 23:19, Ralph Goers wrote: > > I just wanted to let you all know that I am out of the hospital and am now > continuing to get better at home. I still require oxygen so I have a bit of a > ways to go, but

Re: [jira] [Created] (LOG4J2-552) Logic of isInstanceOf are not consistent in log4j-api's Log4jMarker and log4j-slf4j-impl's MarkerWrapper

That reminds me. I think a lot of the interfaces could use abstract base classes, too. At least the main ones like LoggerContext, Marker, the Manager classes, etc. It does help with implementations. Matt Sicker > On Feb 26, 2014, at 4:19, "RainJ (JIRA)" wrote: > > RainJ

Re: Config styles

lier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: [jira] [Created] (LOG4J2-552) Logic of isInstanceOf are not consistent in log4j-api's Log4jMarker and log4j-slf4j-impl's MarkerWrapper

I'd want to see what you are proposing before I would go along with that. > > Ralph > > > On Feb 26, 2014, at 1:36 PM, Matt Sicker wrote: > > > > That reminds me. I think a lot of the interfaces could use abstract base > classes, too. At least the main ones lik

Re: 2.0 release triage

en create new versions (e.g. 2.1, ...). I could >> always comment my reasoning if I pushed something off to 2.1. >> > >> > What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the >> bucket for everything that needs to be fixed before GA and we pull those >> issues into -rcX as we have time? >> > >> > I just would like the project to keep focused on release 2.0 and not >> being distracted by stuff that should really wait for 2.1. >> > >> > Is there any interest in having me (or someone else) do this? >> > >> > -- >> > >> > Bruce Brouwer >> >> - >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> > > > -- > > Bruce Brouwer > > > -- Matt Sicker

Re: What will the GA version number be?

Just a quick follow up to this: 2.0 works perfectly fine in OSGi. Even the version number 2 would work. Either one gets automatically expanded to 2.0.0, or they're interpreted as the same version number regardless. On 4 February 2014 17:48, Matt Sicker wrote: > I prefer the aesthetic

Found an oddly named class in log4j-core.

this class "AbstractServer", while demonstrating its usage, is a poor name for what it actually does. -- Matt Sicker

We need to discuss version names for OSGi one last time.

s 2.0.0-rc1. This can lead to some unexpected results if you specify, let's say, log4j-api version [2.0,3.0), if your repository has non-release versions in the releases section. NB: I'm a bit of a nerd about versioning. -- Matt Sicker

Re: Found an oddly named class in log4j-core.

all the Receivers share the log method implementation. > > While the name may not be accurate, several of us dislike naming classes > “Base”X or XBase (i.e. ServerBase, ReceiverBase, etc). If you can > suggest a better name I’d be OK with changing it. > > Ralph > >

Re: We need to discuss version names for OSGi one last time.

ts the value for an OSGi-specific attribute in the manifest, right? > (Not sure if this attribute exists in the manifest for all jar files or > only for the OSGi ones.) > > So it doesn't affect the jar/zip file names. Correct? > > Sent from my iPhone > > On 2014/03/03

Re: We need to discuss version names for OSGi one last time.

PM, Remko Popma wrote: > >> In that case I'd be fine with 2.0.0.RELEASE for the reasons you >> mentioned. >> > > This is only for OSGi right? I'd hate to have to use that as Maven coords. > > Gary > > >> >> Sent from my iPhone >>

Re: Found an oddly named class in log4j-core.

I don't believe I've received any follow-up yet on the account. On 2 March 2014 19:30, Ralph Goers wrote: > Fine by me. If you have gotten your account set up go ahead and make the > change. > > Sent from my iPad > > On Mar 2, 2014, at 2:01 PM, Matt Sicker wrote:

Re: [ANNOUNCEMENT] Welcome Matt Sicker

Thanks guys! I'm looking forward to making more direct contributions now! In fact, cleaning up some unit tests was something that's been itching me for a while :) Matt Sicker > On Mar 3, 2014, at 7:51, Gary Gregory wrote: > > Welcome aboard Matt. I'm looking forward t

Re: trunk unit test failure

18060ipAddress="192.168.0.120" > loginId="JohnDoe"][Transfer@18060Amount="200.00" FromAccount="123457" > ToAccount="123456"] Transfer Complete > > RFC5424LayoutTest.testLoggerFields:334 Not expected message received > > Tests run: 539, Failures: 7, Errors: 0, Skipped: 12 > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Extending loggers

I could create one for this if you like. Any particular name you want? Or is "feature/caller-info" good? Matt Sicker > On Mar 4, 2014, at 8:13, Bruce Brouwer wrote: > > I can create a JIRA. I don't think I have rights to create a branch, do I? > >> On M

Re: Extending loggers

ges only to this branch? That way I cannot mess up the trunk. >> On Mar 4, 2014 9:18 AM, "Matt Sicker" wrote: >> >>> I could create one for this if you like. Any particular name you want? >>> Or is "feature/caller-info" good? >>> >>>

Re: Found an oddly named class in log4j-core.

Done in r1574222. On 2 March 2014 20:16, Matt Sicker wrote: > I don't believe I've received any follow-up yet on the account. > > > On 2 March 2014 19:30, Ralph Goers wrote: > >> Fine by me. If you have gotten your account set up go ahead and make the >

Should we emphasize the usage of our Bill of Material pom?

and support might be rather useful as well. I'll make the changes in a branch to show what I mean. -- Matt Sicker

Re: JDK 8 : Third Release Candidate - Build 132 is available on java.net

& test. > Please log all show stopper issues as soon as possible. > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- Matt Sicker

Re: Should we emphasize the usage of our Bill of Material pom?

Haha that's awesome! Small world. I already added documentation about the BOM to the maven page. Matt Sicker > On Mar 7, 2014, at 6:09, Ralph Goers wrote: > > Just for grins, do you know who added "import" scope (and hence, support for > BOM poms) to Maven? >

Re: Should we emphasize the usage of our Bill of Material pom?

handy concept. Matt Sicker > On Mar 7, 2014, at 6:09, Ralph Goers wrote: > > Just for grins, do you know who added "import" scope (and hence, support for > BOM poms) to Maven? > > BOM poms are quite useful when you have a set of projects that are > independent

Looks like the BOM is failing.

Anyone got any idea why? I didn't think it would really be that complicated. -- Matt Sicker

Re: Looks like the BOM is failing.

https://builds.apache.org/job/Log4j%202.x/ Just that module was failing. It was mainly because I forgot to mark it as a pom packaging. On 7 March 2014 18:46, Ralph Goers wrote: > Failing how? > > Ralph > > On Mar 7, 2014, at 4:03 PM, Matt Sicker wrote: > > Anyone got a

Re: [jira] [Commented] (LOG4J2-400) Provide Appender-Bundles

> > > > > ${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml > > > > > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- Matt Sicker

Wondering what we'd like to do about bundles

be alright to also make a bunch of bundles available? -- Matt Sicker

Re: BOM module?

g Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: BOM module?

; dependencies, that is fun because there are 3 flavors so a bunch of its > dependencies are optional. > > Ralph > > > > On Mar 13, 2014, at 1:36 PM, Matt Sicker wrote: > > I think the BOM module might be more useful for the Flume appender. I'm > playing wi

Re: BOM module?

> dependencies are optional. > > Ralph > > > On Mar 13, 2014, at 1:36 PM, Matt Sicker wrote: > > I think the BOM module might be more useful for the Flume appender. I'm > playing with that right now, and my dependencies section is already > ridiculous without addi

Are there any plans to add more log4languages?

I see we have log4j, log4net, log4php, and log4cxx. How about Python, Ruby, Perl, etc.? Anything incubating? Anyone interested in working on one? -- Matt Sicker

Re: Are there any plans to add more log4languages?

Yeah, I started googling for them and found a bunch. Ah well. On 14 March 2014 16:33, Scott Deboy wrote: > Many of those already exist outside of Apache. > > Scott > On Mar 14, 2014 2:29 PM, "Matt Sicker" wrote: > >> I see we have log4j, log4net, log4php

Is it ok to update log4j 1?

Like for bug fixes. Make a new patch release perhaps. Just curious; I haven't even looked at the old codebase. -- Matt Sicker

Re: Is it ok to update log4j 1?

, there is nothing stopping you from doing that except for time. Most >> of us would just prefer to get 2.0 to GA and don’t have time to work on >> both. >> >> Ralph >> >> >> On Mar 20, 2014, at 6:06 AM, Matt Sicker >> > >> wrote: >> >

Re: Are these startup warnings normal?

ang.NoClassDefFoundError with message: javax/jms/MessageListener > 2014-03-24 06:48:31,845 WARN Could not examine class > 'org/apache/logging/log4j/core/net/JMSTopicReceiver.class' due to a > java.lang.NoClassDefFoundError with message: javax/jms/MessageListener > 2014-03-24 06:48:31,849 WARN Could not examine class > 'org/apache/logging/log4j/core/net/SMTPManager$SMTPManagerFactory$1.class' > due to a java.lang.NoClassDefFoundError with message: > javax/mail/Authenticator > 2014-03-24 06:48:31,865 WARN Could not examine class > 'org/apache/logging/log4j/core/web/Log4jServletContainerInitializer.class' > due to a java.lang.NoClassDefFoundError with message: > javax/servlet/ServletContainerInitializer > 2014-03-24 06:48:31,866 WARN Could not examine class > 'org/apache/logging/log4j/core/web/Log4jServletContextListener.class' due > to a java.lang.NoClassDefFoundError with message: > javax/servlet/ServletContextListener > 2014-03-24 06:48:31,868 WARN Could not examine class > 'org/apache/logging/log4j/core/web/Log4jServletFilter.class' due to a > java.lang.NoClassDefFoundError with message: javax/servlet/Filter > 06:48:31.945 INFO LOG4J2_537.HelloWorld 28 main - Hello, World! > C:\Users\remko\workspace\log4j-perf\bin> > -- Matt Sicker

Would like to change a bit of the SimpleLogger API. Feedback requested.

Would it be alright to migrate to using PrintWriter instead of PrintStream? This improves charset handling, plus Java recommends using Writers over OutputStreams for textual content. -- Matt Sicker

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

sistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Would like to change a bit of the SimpleLogger API. Feedback requested.

ntWriter.html> class should be used in situations that require writing characters rather than bytes. On 23 March 2014 18:54, Ralph Goers wrote: > How will it improve charset handling? Currently a charset isn’t > configured. > > Ralph > > On Mar 23, 2014, at 3:58 PM, Matt Sicker

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

Interesting. There's already an AbstractConfigurationTest that's an abstract ConfigurationTest, but there's also a BaseConfigurationTest. On 23 March 2014 19:57, Matt Sicker wrote: > I like it. Will include in the refactoring I'm working on. > > > On 23 March

Re: Would like to change a bit of the SimpleLogger API. Feedback requested.

pport this? I don’t really have an objection but > am just wondering when other than the platform’s default encoding would > want to be used. After all, SimpleLogger wasn’t really meant to be what > people actually used on purpose. > > Ralph > > On Mar 23, 2014, at 6:01 PM,

Re: Would like to change a bit of the SimpleLogger API. Feedback requested.

wrote: > For StatusLogger you would then have to add a charset attribute to the > configuration element wouldn’t you? > > Ralph > > On Mar 23, 2014, at 7:09 PM, Matt Sicker wrote: > > It's mainly for StatusLogger, but that idea did cross my mind. > > > On 23 Marc

Re: Porting from 1.0 Logger.getLevel()

Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- Matt Sicker

Re: Rename AbstractLoggerWrapper ?

<http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Delivery Status Notification (Failure)

/src/main/java/org/apache/logging/log4j/core/config/json/JSONConfigurationFa > > - Message truncated - > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker

Re: Delivery Status Notification (Failure)

ng at each step. If keeping the code compiling and > testing cleanly is not possible, then one fat commit it is ;) My 2c that is. > > Gary > > > > On Mon, Mar 24, 2014 at 11:00 AM, Matt Sicker wrote: > >> I wanted to do that, but there were a lot of cross-dependencies.

Re: Delivery Status Notification (Failure)

some time ago but for some reason the build stopped > running. > > On Mar 24, 2014, at 9:53 AM, Matt Sicker wrote: > > Part of the atomic commit thing that I wanted to do (which seems to be an > agreed upon idea) is make sure each commit still builds. I've got a local > i

  1   2   3   4   5   6   7   8   9   10   >