Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

The problem with the API as it is now is that I have no idea if the API did what I asked it to do. It does initialize log4j all right but not in a way I expect. I see that we could: 1) make the current API throw an IllegalArgumentException that means "file not found", this keeps the API signature

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

That’s a good point. It is a programmatic interface so it should return an error. But generally we want logging to do something reasonable other than fail, so it should either use whatever configuration it finds or use the default. Ralph > On Apr 11, 2017, at 8:42 PM, Remko Popma wrote: > >

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

I thought Gary needed a way to detect that the specified location didn't work. But perhaps a warning message is sufficient. Sent from my iPhone > On Apr 12, 2017, at 10:05, Ralph Goers wrote: > > I'd prefer an error message but then have it continue with the current > behavior. > > Sent fro

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

I'd prefer an error message but then have it continue with the current behavior. Sent from my iPhone > On Apr 11, 2017, at 5:47 PM, Remko Popma wrote: > > I can see both sides of the argument. > > Rather than changing the semantics of the existing method, what about adding > a method `Config

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

I can see both sides of the argument. Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Re: Configuration file discovery

A better error message sounds like a good idea. If you make a Jira ticket for this, please make it part of the "ergonomics" epic: https://issues.apache.org/jira/browse/LOG4J2-1811 On Tue, Apr 11, 2017 at 9:19 PM, Mikael Ståldal wrote: > Some configuration file formats (JSON, YAML) require additi

Re: [Scala] Let's get version 11.0 going

1. Perform the release build. 2. Build the site. 3. Upload the site to where we can view it. 4. Vote on it. 5. When it passes upload the site to a directory adjacent to the log4j2 site directory. Something like log4j-scala/log4j-scala-11.0. Once you have that we can modify the links in the log4j

Re: [14/14] logging-log4j2 git commit: Update BOM

Thanks!! Sent from my iPhone > On Apr 11, 2017, at 18:09, Mikael Ståldal wrote: > > OK, moved now. > >> On Mon, Apr 10, 2017 at 6:15 PM, Ralph Goers >> wrote: >> Yes, that is the repo. Initially, all it needs is a parent pom that >> references the module you created. We can move other stuf

Re: [14/14] logging-log4j2 git commit: Update BOM

OK, moved now. On Mon, Apr 10, 2017 at 6:15 PM, Ralph Goers wrote: > Yes, that is the repo. Initially, all it needs is a parent pom that > references the module you created. We can move other stuff in later. It > will need a web site of some kind but we can also worry about that later. > > Ralp

Re: [14/14] logging-log4j2 git commit: Update BOM

Yes, that is the repo. Initially, all it needs is a parent pom that references the module you created. We can move other stuff in later. It will need a web site of some kind but we can also worry about that later. Ralph > On Apr 10, 2017, at 9:11 AM, Mikael Ståldal wrote: > > Is it this repo

Re: [14/14] logging-log4j2 git commit: Update BOM

Maybe, but if it is large enough I would just migrate it from svn to its own git repo. Ralph > On Apr 10, 2017, at 9:05 AM, Gary Gregory wrote: > > Is this where a Chainsaw refresh would live? > > Gary > > On Apr 10, 2017 9:01 AM, "Ralph Goers" > wrote: >

Re: [14/14] logging-log4j2 git commit: Update BOM

Is it this repo? git://git.apache.org/logging-log4j-tools.git It is currently empty (except two text files). I don't feel confident to do the initial setup of the repository. On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers wrote: > I created a new git repo for log4j2-tools. We should not create a

Re: [14/14] logging-log4j2 git commit: Update BOM

Is this where a Chainsaw refresh would live? Gary On Apr 10, 2017 9:01 AM, "Ralph Goers" wrote: > I’m fine with that. I just don’t want more modules in the main project. > > Ralph > > On Apr 10, 2017, at 8:56 AM, Mikael Ståldal > wrote: > > The whole point of this is to get the server componen

Re: [14/14] logging-log4j2 git commit: Update BOM

I’m fine with that. I just don’t want more modules in the main project. Ralph > On Apr 10, 2017, at 8:56 AM, Mikael Ståldal wrote: > > The whole point of this is to get the server components out of log4j-core, so > we need to create a new module. Maybe this new module can be moved to > log4j2

Re: [14/14] logging-log4j2 git commit: Update BOM

The whole point of this is to get the server components out of log4j-core, so we need to create a new module. Maybe this new module can be moved to log4j2-tools repo. On Mon, Apr 10, 2017 at 5:48 PM, Ralph Goers wrote: > I created a new git repo for log4j2-tools. We should not create any more >

Re: [14/14] logging-log4j2 git commit: Update BOM

I created a new git repo for log4j2-tools. We should not create any more modules if we can avoid it. Ralph > On Apr 10, 2017, at 7:28 AM, Remko Popma wrote: > > I guess this is a matter of preference but we already have a lot of modules. > Having one for all standalone applications makes it e

Re: [14/14] logging-log4j2 git commit: Update BOM

I guess this is a matter of preference but we already have a lot of modules. Having one for all standalone applications makes it easier for our users to find things. On Mon, Apr 10, 2017 at 11:24 PM, Mikael Ståldal wrote: > Wouldn't it be better to have one for server and another for the other >

Re: [14/14] logging-log4j2 git commit: Update BOM

Wouldn't it be better to have one for server and another for the other tools? On Mon, Apr 10, 2017 at 4:23 PM, Remko Popma wrote: > I thought we were going to name this module log4j-tools instead of > log4j-server, so it can host all our standalone apps? > > On Mon, Apr 10, 2017 at 11:11 PM, wr

Re: [14/14] logging-log4j2 git commit: Update BOM

I thought we were going to name this module log4j-tools instead of log4j-server, so it can host all our standalone apps? On Mon, Apr 10, 2017 at 11:11 PM, wrote: > Update BOM > > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo > Commit: http://git-wip-us.apache.org/repos/as

Re: Failed tests

Maybe Gary can have a look? According to Git history, he added those tests. On Mon, Apr 10, 2017 at 4:06 PM, Matt Sicker wrote: > I've always seen strange error logs in the socket tests, though they've > always passed for me. > > On 10 April 2017 at 04:59, Mikael Ståldal > wrote: > >> These two

Re: Failed tests

I've always seen strange error logs in the socket tests, though they've always passed for me. On 10 April 2017 at 04:59, Mikael Ståldal wrote: > These two tests fail on Java 8 (at least on Linux). They work on Java 7 > (that's why the Jenkins build doesn't fail). > > On Mon, Apr 10, 2017 at 11:3

Re: Module for server components

Yeah, I think we're ready to work toward 2.9 now. On 10 April 2017 at 05:28, Mikael Ståldal wrote: > OK to merge branch LOG4J2-1851 to master? > > https://issues.apache.org/jira/browse/LOG4J2-1851 > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikae

Re: Failed tests

These two tests fail on Java 8 (at least on Linux). They work on Java 7 (that's why the Jenkins build doesn't fail). On Mon, Apr 10, 2017 at 11:32 AM, Mikael Ståldal wrote: > I get these test failures on master branch: > > Failed tests: > SecureSocketAppenderSocketOptionsTest.testSocketOptions

Re: [ANN] Log4j 2.8.2 released

Yup - it updated after I cleared my cache. Ralph > On Apr 9, 2017, at 12:02 PM, Matt Sicker wrote: > > I used the 2.8.2 logo in the site commit to svn, but the site zip > distribution has the 2.8.1 logo since that was the release artifact > technically. If you don't see the new logo on the si

Re: [ANN] Log4j 2.8.2 released

I used the 2.8.2 logo in the site commit to svn, but the site zip distribution has the 2.8.1 logo since that was the release artifact technically. If you don't see the new logo on the site, it's probably a caching issue. On 9 April 2017 at 13:52, Ralph Goers wrote: > Thanks, but you used the 2.8

Re: [ANN] Log4j 2.8.2 released

Thanks, but you used the 2.8.1 logo instead of 2.8.2. Oh darn, I just noticed the web site wasn’t updated either. I guess I will have to fix that. Ralph > On Apr 8, 2017, at 4:36 PM, Remko Popma wrote: > > Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released >

Re: Jenkins and Maven 3.5.0

I typically will test the Log4J build during the maven release vote. That is the time to see if there are problems. I don't upgrade the maven version on the machine that performs the releases very often. Ralph > On Apr 9, 2017, at 8:20 AM, Gary Gregory wrote: > > I was thinking of just using

Re: Jenkins and Maven 3.5.0

I was thinking of just using 3.5.0. Gary On Apr 9, 2017 6:48 AM, "Apache" wrote: > Why? There is no reason our build process has to support every maven > release. > > Sent from my iPad > > On Apr 8, 2017, at 5:44 PM, Matt Sicker wrote: > > Now that Maven 3.5.0 is out, whenever Infra adds it to

Re: Jenkins and Maven 3.5.0

Why? There is no reason our build process has to support every maven release. Sent from my iPad > On Apr 8, 2017, at 5:44 PM, Matt Sicker wrote: > > Now that Maven 3.5.0 is out, whenever Infra adds it to Jenkins, would it make > sense to switch to it there? I know in theory everything seems t

Re: Jenkins and Maven 3.5.0

Sure, why not? Let's eat our own Apache dog food. Fresh too! Gary On Apr 8, 2017 5:44 PM, "Matt Sicker" wrote: > Now that Maven 3.5.0 is out, whenever Infra adds it to Jenkins, would it > make sense to switch to it there? I know in theory everything seems to work > with any version of Maven 3.x

Re: [ANN] Log4j 2.8.2 released

Blogged: https://blogs.apache.org/logging/entry/log4j-2-8-2-released On Sun, Apr 9, 2017 at 1:53 AM, Matt Sicker wrote: > The Apache Log4j 2 team is pleased to announce the Log4j 2.8.2 release! > > Apache Log4j is a well known framework for logging application behavior. > Log4j 2 is an upgrade t

Re: Build failed in Jenkins: Log4jWindows » Windows,JDK 1.8 (unlimited security) 64-bit Windows only #51

--- > > [INFO] Reactor Summary: > [INFO] > [INFO] Apache Log4j 2 . SUCCESS [ > 4.222 s] > [INFO] Apache Log4j API ....... SUCCESS [ > 32.274 s] > [INFO] Ap

Re: Weird compilation error

Could be I'm going to run the build with each ActiveMQ release since what we have and see what happens. I'll nuke the latest one I have just in case it's junked. Gary On Fri, Apr 7, 2017 at 1:49 PM, Matt Sicker wrote: > Corrupted downloads perhaps? That's very odd! > > On 7 April 2017 at 15:48,

Re: Weird compilation error

Corrupted downloads perhaps? That's very odd! On 7 April 2017 at 15:48, Gary Gregory wrote: > Hm, > > I had changed active mq testing from 5.14.1 to 5.14.4 and that yields: > > [ERROR] error: error reading C:\Users\ggregory\.m2\repository\org\apache\ > activemq\activemq-broker\5.14.4\activemq-br

Re: Weird compilation error

Hm, I had changed active mq testing from 5.14.1 to 5.14.4 and that yields: [ERROR] error: error reading C:\Users\ggregory\.m2\repository\org\apache\activemq\activemq-broker\5.14.4\activemq-broker-5.14.4.jar; invalid LOC header (bad signature) [ERROR] error: error reading C:\Users\ggregory\.m2\rep

Re: Weird compilation error

It's already in the pom: https://github.com/apache/logging-log4j2/blob/master/log4j-1.2-api/pom.xml#L74 I don't think it's scope=test, but type=test-jar. On 7 April 2017 at 15:41, Gary Gregory wrote: > I added to log4j-1.2-api: > > > org.apache.logging.log4j > log4j-core >

Re: Weird compilation error

I added to log4j-1.2-api: org.apache.logging.log4j log4j-core test test but that blows up Maven 3.3.9: [ERROR] [ERROR] Some problems were encountered while processing the POMs: [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be uniq

Re: Weird compilation error

Maybe it's because it's a new snapshot version and you need to run "mvn install" at least once? On 7 April 2017 at 15:40, Matt Sicker wrote: > This is the first I've ever seen that error, and it's not popping up in > Jenkins or anything. I don't think the code has changed since 2.8.2, so I > don

Re: Weird compilation error

This is the first I've ever seen that error, and it's not popping up in Jenkins or anything. I don't think the code has changed since 2.8.2, so I don't know why it would break. On 7 April 2017 at 15:34, Gary Gregory wrote: > This is with Maven 3.3.9 though. > > Gary > > On Fri, Apr 7, 2017 at 1:

Re: Weird compilation error

This is with Maven 3.3.9 though. Gary On Fri, Apr 7, 2017 at 1:11 PM, Matt Sicker wrote: > Does it have a dependency on log4j-core:test? It should. Could be a bug in > your beta version of Maven ;) > > On 7 April 2017 at 14:46, Gary Gregory wrote: > >> Hi All: >> >> I'm seeing this in master:

Re: Weird compilation error

Does it have a dependency on log4j-core:test? It should. Could be a bug in your beta version of Maven ;) On 7 April 2017 at 14:46, Gary Gregory wrote: > Hi All: > > I'm seeing this in master: > > [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-1.2-api > --- > [INFO] > [INFO] ---

Re: Yet another logging facade

See http://stackoverflow.com/questions/41633278/can-we-use-all-features-of-log4j2-if-we-use-it-along-with-slf4j-api/41635246#41635246 . Note that item 10 on this li

Re: Yet another logging facade

I just took a look at the list. I don’t see the response that points to bugzilla. In your comment you mentioned that Log4j provides an api but you didn’t list the reasons why it is better. Remko posted a stack overflow post that has 10 reasons why it is better. But more importantly, users have

Re: Yet another logging facade

I got a response on the mailing list. There's a public bugzilla we can comment on apparently which is linked in the PDF. On 6 April 2017 at 20:02, Matt Sicker wrote: > I'm not sure where they develop the standards, but there's an osgi-dev > mailing list (where I found this posted today): https:/

Re: [qos.ch-announce] Release of SLF4J version 1.8.0-alpha0

We will have to modify log4j-slf4j-impl to support the new binding mechanism. I know it uses service loader but I haven’t looked at the details. I looked at service loader when I created the binding between our api and core but decided not to use it because I wanted to also include the logic to

Re: Yet another logging facade

I'm not sure where they develop the standards, but there's an osgi-dev mailing list (where I found this posted today): https://www.osgi.org/community/mail-lists/ I don't see Apache on this list despite being the foundation behind most of the open source OSGi projects out there: https://www.osgi.or

Re: Yet another logging facade

A quick review of the document appears to have SLF4J as a requirement. Shame about that. Gary On Thu, Apr 6, 2017 at 5:34 PM, Ralph Goers wrote: > Where does one comment on these? > > The problem is that they mention Java 8 support, but SLF4J doesn’t take > advantage of any Java 8 features yet.

Re: Yet another logging facade

Where does one comment on these? The problem is that they mention Java 8 support, but SLF4J doesn’t take advantage of any Java 8 features yet. No support for Lamda’s. From what I am seeing the next release will support running in Java 9 and will leverage StackWalker and support Java modules bu

Re: Yet another logging facade

Good find. I noticed that the document points to Apache Sling and says "uses the most common parts today used for logging: SLF4J for clients and logback for processing." Seems like Sling decided that in 2013 and never looked back. Which is fine, but I believe Log4j2 has changed the landscape th

Re: [VOTE] Release Log4j 2.8.2 rc1

Retagged on reporter as I missed the fact that I needed LOG4J- as a prefix. Also marked the release in JIRA. I already removed fix version 2.8.2 from everything that wasn't resolved/closed in 2.8.2. On 5 April 2017 at 20:58, Matt Sicker wrote: > Also, there was a major upgrade in gpg (2.0.x ->

Re: [VOTE] Release Log4j 2.8.2 rc1

Also, there was a major upgrade in gpg (2.0.x -> 2.1.x) since I signed the original artifacts, so the signature file on the site zip might be a slightly different format (it displays differently when I use "gpg --verify *.asc"). On 5 April 2017 at 20:56, Matt Sicker wrote: > I've committed the s

Re: [VOTE] Release Log4j 2.8.2 rc1

I've committed the src, bin, and site zips/tarballs to svn and deleted the 2.8 release from svn as it's now two versions behind. I'm going to wait until tomorrow to delete 2.8.1 from svn and to commit the site and do the release email. Artifacts have been released from Nexus, though as usual, givin

Re: [VOTE] Release Log4j 2.8.2 rc1

And my +1 The vote passes with +1s from Gary, Mikael, Remko, and myself. On 4 April 2017 at 20:08, Matt Sicker wrote: > Looks like those javadoc warnings are legit. See < > https://rgoers.github.io/log4j2-site/log4j-api/apidocs/ > org/apache/logging/log4j/ThreadContext.html> for example where t

Re: Syslog

No, if anything I would propose to remove (or deprecate) SyslogAppender. But never mind. On Wed, Apr 5, 2017 at 4:06 PM, Ralph Goers wrote: > Let me rephrase. http://logging.apache.org/log4j/2.x/manual/ > appenders.html#SyslogAppender describes exactly what it does - write > either using the BSD

Re: Syslog

Let me rephrase. http://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender describes exactly what it does - write either using the BSD Syslog format or the RFC 5424 format. A user who wants to write to sys

Re: Syslog

Why? Ralph > On Apr 5, 2017, at 6:56 AM, Mikael Ståldal wrote: > > I see. But couldn't it be a bit confusing for users to have both? > > On Wed, Apr 5, 2017 at 3:54 PM, Ralph Goers > wrote: > I’m not sure I understand the question. Have you looked at the cod

Re: Syslog

I see. But couldn't it be a bit confusing for users to have both? On Wed, Apr 5, 2017 at 3:54 PM, Ralph Goers wrote: > I’m not sure I understand the question. Have you looked at the code? The > syslog appender is nothing more than the SocketAppender hardwired to use > one of those two layouts.

Re: Syslog

I’m not sure I understand the question. Have you looked at the code? The syslog appender is nothing more than the SocketAppender hardwired to use one of those two layouts. However, there is nothing preventing someone from using those Layouts with a different appender. Ralph > On Apr 5, 2017,

Re: [VOTE] Release Log4j 2.8.2 rc1

Looks like those javadoc warnings are legit. See < https://rgoers.github.io/log4j2-site/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html> for example where the @value isn't inserted properly. Thankfully, that's also linked in the javadocs to the manual about thread context. I added th

Re: MessageLayout

Roger that! Thank you all for your comments. Flume with unique keys it is. Gary On Mon, Apr 3, 2017 at 10:15 PM, Ralph Goers wrote: > Again, if you use an async logger you will lose whatever is in the memory > buffer when the server stops or crashes. If you log directly to Flume you > are guara

Re: MessageLayout

Again, if you use an async logger you will lose whatever is in the memory buffer when the server stops or crashes. If you log directly to Flume you are guaranteed that the audit event is written when the logging call returns and your application can count on that. The only thing you really need

Re: MessageLayout

No. JMS does not guarantee delivery in the way your would want. Sure, if the JMS service says it accepted the event then it is guaranteed, but if it doesn’t what are you going to do with the event? It is stuck in the client. You would have to invent some way to queue the events and then retry th

Re: MessageLayout

I'm pretty sure you do, yes, though the async loggers do have less reliability in theory due to more log messages being buffered in memory before being written, so more messages could be lost in case of failure. That's configurable to whatever level of reliability you want, though. On 3 April 2017

Re: MessageLayout

Thanks Matt. With the Flume appender, do I still need to use an async logger to get the best perf? Gary On Mon, Apr 3, 2017 at 8:31 PM, Matt Sicker wrote: > Clarifications: other than the file appenders, the flume appender is > probably the most reliable appender. > > And for the direct appende

Re: MessageLayout

Clarifications: other than the file appenders, the flume appender is probably the most reliable appender. And for the direct appender config, that's also with fully async loggers. I've been considering putting together a small blog post about the most efficient log4j2.xml configurations. On 3 Apr

Re: MessageLayout

The Flume appender can persist messages within the same process to files before sending them to other agents. I don't think any other appender can guarantee that. Personally, I've been using direct console appenders lately and using graylog to slurp stdout on docker containers, but I'm not the one

Re: MessageLayout

Wait a sec. A JMS provider can guarantee message delivery. How can events be lost once they are in the provider? Are you saying that using an async logger is 'unsafe' because the events in the ring buffer go away if the JVM goes down? Ideally I want to publish and forget, with the publish part asy

Re: MessageLayout

What’s the point though when all you have to do is specify the pattern layout with “%m%ex{none}”? How can you do auditing with the async logger? You may lose events with that. Your use case is exactly why I wrote the FlumeAppender. It is very much like JMS but a whole lot faster and guarantees

Re: MessageLayout

Right. I want to post to JMS message objects I've serialized to JSON. All I care about is the message. I log these events to a specially named logger with a specially named marker. These are the only events that should be published to JMS (I use a filter and the one marker). I am in charge of the

Re: MessageLayout

So, exceptions are swallowed and no newlines are rendered? Interesting. What's the use case? Sent from my iPhone > On Apr 4, 2017, at 7:30, Gary Gregory wrote: > > Hi All, > > I am considering a new layout called "MessageLayout" which would be > synonymous with:. Thoughts? > > Gary > > --

Re: Deep Dive into Java 9’s Stack-Walking API

On a biz trip to the NL for a week, then a vacation to the UK and France for two weeks ;-) G On Apr 2, 2017 10:35 PM, "Ralph Goers" wrote: > Where have you been? I posted performance benchmarks based on that a week > or two ago. See all my updates to LOG4J2-1359. > > I have already implemented

Re: Scala

I believe Flume is using Sphinx, but I think that is still driving from Maven. I would look at some other Apache sites, find one you like and then figure out how they did it. Ralph > On Apr 3, 2017, at 7:11 AM, Matt Sicker wrote: > > We don't have to use maven-site-plugin to generate the Scal

Re: Scala

We don't have to use maven-site-plugin to generate the Scala site. That's just the easy way to do it in theory, though I find it cumbersome. If you know of any better documentation generator that we could use there (or even in log4j-core), please let us know! On 3 April 2017 at 04:06, Mikael Ståld

Re: Scala

Using SBT would help to avoid having to duplicate the source code for each Scala version. However, I'm not sure about how to do the Maven site stuff with SBT. On Sun, Apr 2, 2017 at 10:41 PM, Matt Sicker wrote: > I'm not too experienced with it, but now that the Scala APIs are in their > own rep

Re: [VOTE] Release Log4j 2.8.2 rc1

+1 Works for me. On Sun, Apr 2, 2017 at 11:08 PM, Matt Sicker wrote: > This is a vote to release Log4j 2.8.2. Please download, test, and cast > your votes on this mailing list. > > [] +1, release the artifacts > > [] -1, don't release because... > > The vote will remain open for 72 hours at lea

Re: Deep Dive into Java 9’s Stack-Walking API

Where have you been? I posted performance benchmarks based on that a week or two ago. See all my updates to LOG4J2-1359. I have already implemented StackWalker support on branch java9NoMultiRelease. I started on a branch for LOG4J2-1359 but trouble with the Multi-Release jar made me rethink it

Re: [VOTE] Release Log4j 2.8.2 rc1

... and thank you Matt for picking up RM duty this time around. I look forward to getting 2.8.2 out the door and seeing what we have in store for 2.9! Gary On Sun, Apr 2, 2017 at 2:08 PM, Matt Sicker wrote: > This is a vote to release Log4j 2.8.2. Please download, test, and cast > your votes o

Re: Need a 2.8.2 logo

Thanks! I'll make sure to commit that to svn after the site gets committed later. On 2 April 2017 at 20:11, Ralph Goers wrote: > I created a logo and updated src/site/resources/images/logo.png. > > Ralph > > On Apr 2, 2017, at 2:35 PM, Matt Sicker wrote: > > The download page is templated based

Re: Need a 2.8.2 logo

I created a logo and updated src/site/resources/images/logo.png. Ralph > On Apr 2, 2017, at 2:35 PM, Matt Sicker wrote: > > The download page is templated based on a couple properties in the root > pom.xml. I think I added that back when I did my first release. I did > remember to update that

Re: [VOTE] Release Log4j 2.8.2 rc1

+1 MD5, SHA1, ASC OK. Following BUILDING.md: RAT check OK CLIRR check on API OK mvn clean install OK CLIRR check on 1.2 API OK mvn site OK but with some Javadoc warnings: [WARNING] C:\temp\rc\apache-log4j-2.8.2-src\log4j-api\src\main\java\ org\apache\logging\log4j\ThreadContext.java:49: warnin

Re: Need a 2.8.2 logo

The download page is templated based on a couple properties in the root pom.xml. I think I added that back when I did my first release. I did remember to update that before making the RC. On 2 April 2017 at 16:24, Ralph Goers wrote: > Oh. I just saw the release vote email. You should have done t

Re: Need a 2.8.2 logo

Oh. I just saw the release vote email. You should have done this before you ran the release build. It isn’t a showstopper though. Ralph > On Apr 2, 2017, at 2:22 PM, Ralph Goers wrote: > > I believe I follow the same process as Gary. In src/site/resources/logo you > will find a bunch of logo’

Re: Need a 2.8.2 logo

I believe I follow the same process as Gary. In src/site/resources/logo you will find a bunch of logo’s that Gary generated. All the ones that have been used have a version numbered image. I just pick the next one I like and edit it in gimp and add the version number. If you are unable to do t

Re: Scala

I'm not too experienced with it, but now that the Scala APIs are in their own repo, it might be easier to use SBT instead of Maven for it. Just a thought for a future release. On 2 April 2017 at 15:27, Matt Sicker wrote: > And don't mind the site commit I made earlier. That was from a snapshot,

Re: Scala

And don't mind the site commit I made earlier. That was from a snapshot, so I have to commit it again anyways. On 2 April 2017 at 15:25, Matt Sicker wrote: > No, I figured I'd do log4j-core first. Still working on that right now, > had to restart the build from the tag because a test randomly de

Re: Scala

No, I figured I'd do log4j-core first. Still working on that right now, had to restart the build from the tag because a test randomly decided to fail at the worst possible time. On 2 April 2017 at 15:11, Ralph Goers wrote: > Has a Scala release been performed? The site needs to be deployed befor

Re: Upcoming release planning

Go for it :-) Gary On Mar 31, 2017 8:19 AM, "Matt Sicker" wrote: > I'd like to see two releases happen soon: > > log4j-api-scala v11: let's get this out the door soon > log4j-core 2.8.2: we have bugfixes ready and I'd also like to see a > release of this before we move on to major 2.9 work > >

Re: Upcoming release planning

Sounds good, I think that both core and api-scala are ready for release. On Fri, Mar 31, 2017 at 5:19 PM, Matt Sicker wrote: > I'd like to see two releases happen soon: > > log4j-api-scala v11: let's get this out the door soon > log4j-core 2.8.2: we have bugfixes ready and I'd also like to see a

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

We should start a new vote for issues@. We've already voted to merge dev@ and keep the user lists as is. On 28 March 2017 at 14:18, Paul Benedict wrote: > Yes, I think combining the "user@" and "dev@" variants into two are > appropriate. +1 (non-binding) for me. > > Furthermore --- and this has

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

Yes, I think combining the "user@" and "dev@" variants into two are appropriate. +1 (non-binding) for me. Furthermore --- and this has always been a scratch of mine to itch (and I raise this about once a year!) -- I would like a dedicated "issues@" mailing list like other Apache projects. The trad

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

I followed up with infra over the weekend but haven't gotten a response yet. On 27 March 2017 at 20:21, Ralph Goers wrote: > Matt, > > Any update on this? > > Ralph > > On Mar 21, 2017, at 10:27 AM, Ralph Goers > wrote: > > Thanks Matt! > > Ralph > > On Mar 21, 2017, at 10:15 AM, Matt Sicker w

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

Matt, Any update on this? Ralph > On Mar 21, 2017, at 10:27 AM, Ralph Goers wrote: > > Thanks Matt! > > Ralph > >> On Mar 21, 2017, at 10:15 AM, Matt Sicker > > wrote: >> >> No other opinions apparently. I suppose we'll go with the single list with >> bounce messag

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

Thanks Matt! Ralph > On Mar 21, 2017, at 10:15 AM, Matt Sicker wrote: > > No other opinions apparently. I suppose we'll go with the single list with > bounce messages. I'll follow up with infra later today. > > On 18 March 2017 at 13:12, Ralph Goers > wrote

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

No other opinions apparently. I suppose we'll go with the single list with bounce messages. I'll follow up with infra later today. On 18 March 2017 at 13:12, Ralph Goers wrote: > OK. I guess I am fine with the bounce messages. Any other opinions? > > Ralph > > On Mar 18, 2017, at 8:42 AM, Matt S

Re: Java 9 support

I opened https://issues.apache.org/jira/browse/FELIX-5527 . Apparently the problem is with bnd-tools who seem to be ignoring the problem because Java 9 isn’t final. Since OSGi bundles don’t or won’t have support for multi-release jars they will

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

OK. I guess I am fine with the bounce messages. Any other opinions? Ralph > On Mar 18, 2017, at 8:42 AM, Matt Sicker wrote: > > I got this response from Gavin: > > Hi [~jvz] Sorry but I think I'm going to push back on that last request. > > Merging the lists - no problem > Merging all the sub

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

I got this response from Gavin: Hi [~jvz] Sorry but I think I'm going to push back on that last request. Merging the lists - no problem Merging all the subscribers - no problem Creating bounce messages directing people to use the merged target list - no problem People will know in advance this m

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

Oh, I didn't realise I had a response on how to handle that. Let me follow up with infra. On 16 March 2017 at 21:46, Ralph Goers wrote: > Is there any follow-up to this? > > Ralph > > On Mar 12, 2017, at 9:30 PM, Ralph Goers > wrote: > > 1. That seems fine to me. > 2. Is it possible to do both?

Re: [Discuss][VOTE] Combine the project user and dev mailing lists into user@ and dev@

Is there any follow-up to this? Ralph > On Mar 12, 2017, at 9:30 PM, Ralph Goers wrote: > > 1. That seems fine to me. > 2. Is it possible to do both? I like the idea of annoying the sender but > still allowing the email to be sent. It would cool if it could even add > [list] to the start of

Re: Java 9 support

OSGi and Jigsaw have considerable overlap in concepts, so I'm assuming there will be integration efforts eventually. However, a friend went to JavaOne a year or two ago, and the Jigsaw folk were very dismissive of OSGi in general despite one of the leading OSGi spec leads being on the Jigsaw projec

  1   2   3   4   5   6   7   8   9   10   >