[jira] [Created] (LOG4J2-603) Use Gora as storage abstraction for Log4j 2.X

2014-04-14 Thread Lewis John McGibbney (JIRA)
Lewis John McGibbney created LOG4J2-603: --- Summary: Use Gora as storage abstraction for Log4j 2.X Key: LOG4J2-603 URL: https://issues.apache.org/jira/browse/LOG4J2-603 Project: Log4j 2 I

[jira] [Commented] (LOG4J2-603) Use Gora as storage abstraction for Log4j 2.X

2014-04-14 Thread Lewis John McGibbney (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968264#comment-13968264 ] Lewis John McGibbney commented on LOG4J2-603: - If someone can assign to me tha

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Łukasz Dywicki
Hey Matt, I assumed JSON is default (or has higher priority than XML at least) based on documentation. Log4j will inspect the "log4j.configurationFile" system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension. If no syste

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Matt Sicker
Oh right, that is true. Well, you still need to provide the Jackson dependencies for JSON files to work. I agree on the god library front, too. I just don't know how to get the point across without upsetting everyone. On Monday, 14 April 2014, Łukasz Dywicki wrote: > Hey Matt, > I assumed JSON

Intention to modify API

2014-04-14 Thread Matt Sicker
I was thinking about how to best support strange class loader environments (like OSGi or Servlets), and in order to support a LoggerContextFactory, we should have a registry of sorts for it. This way, a new LCF can dynamically add or remove itself at runtime. Ideally, we'd fall back to the SimpleLo

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Ralph Goers
I, for one, am not upset by this discussion. As I have said, I have no objection to pulling some stuff out of core and I am thinking we need to start a companion project for “extra” stuff. That said, most Log4j users will expect that the core will contain roughly the same components that were

Re: Intention to modify API

2014-04-14 Thread Ralph Goers
Hopefully the changes won’t be too significant. Can you please post what you intend to do before commit? Ralph On Apr 14, 2014, at 7:55 AM, Matt Sicker wrote: > I was thinking about how to best support strange class loader environments > (like OSGi or Servlets), and in order to support a Log

Re: svn commit: r1587119 - /logging/log4j/log4j2/trunk/.travis.yml

2014-04-14 Thread Ralph Goers
Matt, Please reply to commits to the dev list. Although I do review the commits it isn’t always as timely as reviewing the dev list. Yes, I have a github account although I rarely use it. I’ve never even heard of Travis before so it may require a bit of work. Also, all PMC members should ha

How good is log4j2 at variable management?

2014-04-14 Thread Paul Benedict
Asking the developers here... One thing I would like to accomplish is to use the same log4j config file for different appservers. Unfortunately, each appserver has a different logging root variable (${catalina.home} = Tomcat, ${jboss.server.log.dir} = JBoss, etc.). One way to solve this is to mak

Re: Intention to modify API

2014-04-14 Thread Matt Sicker
Will do. The main thing I'd like to change is the LogManager initialisation. I'd prefer that to keep a registry of LoggerContextFactories so that a different factory can be registered later on (for instance, in OSGi, you could install log4j-api, then log4j-core, and core would register itself and t

Re: How good is log4j2 at variable management?

2014-04-14 Thread Ralph Goers
Have you looked at http://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution? Ralph On Apr 14, 2014, at 9:32 AM, Paul Benedict wrote: > Asking the developers here... > > One thing I would like to accomplish is to use the same log4j config file for > different appser

Re: How good is log4j2 at variable management?

2014-04-14 Thread Paul Benedict
No, but I am not sure this what I am looking for either. I am looking for the programmatic injection of properties; I can't accomplish this using a declarative approach. I want a class to be called by log4j at startup. On Mon, Apr 14, 2014 at 12:15 PM, Ralph Goers wrote: > Have you looked at > h

Re: How good is log4j2 at variable management?

2014-04-14 Thread Ralph Goers
The Interpolator class manages variables. During configuration you can currently use the system properties, environment variables, thread context, date and jndi lookups. In addition, if you are running in a web container the web lookup is also used. You can programmatically add variables to any

NDN:

2014-04-14 Thread Internet
Sorry. Your message could not be delivered to: internet,PackerCollegiate (The name was not found at the remote site. Check that the name has been entered correctly.)

Re: How good is log4j2 at variable management?

2014-04-14 Thread Paul Benedict
If I am understanding you correctly, all I have to do is write a new class that implements StrLookup and annotate it with @Plugin? On Mon, Apr 14, 2014 at 2:01 PM, Ralph Goers wrote: > The Interpolator class manages variables. During configuration you can > currently use the system properties, e

Re: How good is log4j2 at variable management?

2014-04-14 Thread Matt Sicker
Take a look at the other StrLookup implementations. One that uses ELResolver sounds pretty neat to be honest. On 14 April 2014 16:08, Paul Benedict wrote: > If I am understanding you correctly, all I have to do is write a new class > that implements StrLookup and annotate it with @Plugin? > > >

Re: svn commit: r1587119 - /logging/log4j/log4j2/trunk/.travis.yml

2014-04-14 Thread Matt Sicker
Oh, my bad, I thought I was replying to the dev list. That's what happens when I don't pay attention! I'm not sure about the github thing. I tried filing a ticket with INFRA and they basically said "fuck github" in so many words. As long as Jenkins is set up, we don't need to worry about Travis.

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Matt Sicker
I feel as though anything that requires an outside dependency (other than log4j-api) should probably be in its own module. The core should consist of everything that is doable without dependencies outside Java SE. So, even though JMS uses Java EE, it could be its own module since that's not standa

Re: svn commit: r1587119 - /logging/log4j/log4j2/trunk/.travis.yml

2014-04-14 Thread Ralph Goers
Jenkins is set up and was working for a time. Then one night I magically stopped getting notifications. Ralph On Apr 14, 2014, at 2:18 PM, Matt Sicker wrote: > Oh, my bad, I thought I was replying to the dev list. That's what happens > when I don't pay attention! > > I'm not sure about the

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Ralph Goers
While I agree in principal that may not be practical. For example, I don’t know that that could be done with the disruptor, and to be honest given the interest there seems to be in asynch mode I’m not sure that would be a good idea even if it could be done. Ralph On Apr 14, 2014, at 2:19 PM,

Re: svn commit: r1587119 - /logging/log4j/log4j2/trunk/.travis.yml

2014-04-14 Thread Matt Sicker
Argh Jenkins! :shakes fist: On 14 April 2014 16:22, Ralph Goers wrote: > Jenkins is set up and was working for a time. Then one night I magically > stopped getting notifications. > > Ralph > > On Apr 14, 2014, at 2:18 PM, Matt Sicker wrote: > > Oh, my bad, I thought I was replying to the dev

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Matt Sicker
The disruptor might actually have to be an exception to the rule! You raise a great point. The async logger is one of the coolest new features, so we should probably bring that dependency in. We could go the Tomcat route and package-rename an internal version of it, or we could just keep an externa

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Remko Popma
> On 2014/04/15, at 0:21, Ralph Goers wrote: > > I, for one, am not upset by this discussion. As I have said, I have no > objection to pulling some stuff out of core and I am thinking we need to > start a companion project for “extra” stuff. That said, most Log4j users > will expect that

Re: Maven build improvements & osgi stuff

2014-04-14 Thread Matt Sicker
JMX is part of Java SE. I think it should work fine. The GUI can still be its own JAR as it's needed for JConsole, but the MBeans and such work fine in Java SE. On 14 April 2014 17:15, Remko Popma wrote: > > > On 2014/04/15, at 0:21, Ralph Goers wrote: > > I, for one, am not upset by this disc

Re: Intention to modify API

2014-04-14 Thread Matt Sicker
Alright, here's what I'm thinking so far: Add a class named something like LoggerContextFactoryRegistry (yeah I hate that name already). Make it a singleton class. It should keep a SortedMap of int -> LoggerContextFactory (similar to how they're scanned in LogManager). This class should also keep

Re: Intention to modify API

2014-04-14 Thread Remko Popma
To be honest, it all sounds pretty complex to me. What is the use case? You mention you want to dynamically add/remove logger context factories at runtime but I'm not clear on why this is desired/required. If there are class loader issues we should focus on that. If there is an issue that prev

Re: Intention to modify API

2014-04-14 Thread Matt Sicker
It's mainly to add OSGi support. Since log4j-core (or any of the providers) might not be available at the same time as log4j-api, there needs to be a way to add a LoggerContextFactory afterward to take over. This is due to how OSGi works where you can dynamically add or remove bundles at runtime. B

Re: Intention to modify API

2014-04-14 Thread Remko Popma
If the separation between log4j-api and log4j-core causes issues for OSGi, then would it be an option to combine these two into a single bundle for OSGi? Would that avoid the need for registry complexity? Sent from my iPhone > On 2014/04/15, at 9:45, Matt Sicker wrote: > > It's mainly to add

Re: Intention to modify API

2014-04-14 Thread Matt Sicker
It would defeat the purpose of using OSGi. Plus, how would that work if you wanted to use log4j-to-slf4j? On 14 April 2014 19:06, Remko Popma wrote: > If the separation between log4j-api and log4j-core causes issues for OSGi, > then would it be an option to combine these two into a single bundl

[jira] [Created] (LOG4J2-604) Audit use of ClassLoader, Class.forName, etc.

2014-04-14 Thread Matt Sicker (JIRA)
Matt Sicker created LOG4J2-604: -- Summary: Audit use of ClassLoader, Class.forName, etc. Key: LOG4J2-604 URL: https://issues.apache.org/jira/browse/LOG4J2-604 Project: Log4j 2 Issue Type: Epic

[jira] [Commented] (LOG4J2-603) Use Gora as storage abstraction for Log4j 2.X

2014-04-14 Thread Matt Sicker (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969169#comment-13969169 ] Matt Sicker commented on LOG4J2-603: It doesn't look like I can assign this to someone

[jira] [Commented] (LOG4J2-547) Update LoggerStream API

2014-04-14 Thread Matt Sicker (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969191#comment-13969191 ] Matt Sicker commented on LOG4J2-547: Added in r1587396. > Update LoggerStream API > -

[jira] [Commented] (LOG4J2-547) Update LoggerStream API

2014-04-14 Thread Matt Sicker (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969192#comment-13969192 ] Matt Sicker commented on LOG4J2-547: Although I'd recommend creating builders instead

Can any PMCs or chairs take a look at this?

2014-04-14 Thread Matt Sicker
https://travis-ci.org/apache/logging-log4j2 If you log in with your GitHub account, does it give you any administrative options? Particularly from the upper right corner gearbox thing. -- Matt Sicker

Re: Can any PMCs or chairs take a look at this?

2014-04-14 Thread Scott Deboy
Nope, it just shows my personal repositories, even though I am part of the 'Apache' organization in GitHub. On 4/14/14, Matt Sicker wrote: > https://travis-ci.org/apache/logging-log4j2 > > If you log in with your GitHub account, does it give you any administrative > options? Particularly from the

Re: Can any PMCs or chairs take a look at this?

2014-04-14 Thread Matt Sicker
I have the same problem, and INFRA refuses to do anything about it. Oh well. On 14 April 2014 21:58, Scott Deboy wrote: > Nope, it just shows my personal repositories, even though I am part of > the 'Apache' organization in GitHub. > > On 4/14/14, Matt Sicker wrote: > > https://travis-ci.org/a

[jira] [Created] (LOG4J2-605) NoSQL appender logging password in clear text.

2014-04-14 Thread Poorna Subhash P (JIRA)
Poorna Subhash P created LOG4J2-605: --- Summary: NoSQL appender logging password in clear text. Key: LOG4J2-605 URL: https://issues.apache.org/jira/browse/LOG4J2-605 Project: Log4j 2 Issue Ty