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
[
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
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
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
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
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
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
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
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
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
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
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
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
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.)
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
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?
>
>
>
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.
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
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
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,
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
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
> 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
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
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
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
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
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
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
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
[
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
[
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
> -
[
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
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
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
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
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
37 matches
Mail list logo