What is this private list? As a committer, should I be a subscriber to the
private list? Or is this just for PMC members?
N
On Sep 11, 2013, at 11:50 PM, Ralph Goers wrote:
> I prefer holding the discussions on the private list but voting on the public
> list. Just my preference though.
>
>
Thanks, Remko.
Team: should this method Remko added be called automatically from
LoggerContext#stop()?
N
On Sep 19, 2013, at 6:51 PM, Remko Popma (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&fo
Ralph Goers wrote:
> From my reading it sounds like they will definitely support the usage for
> formatting Throwables but may not for what ClassLoaderContextSelector
> requires.
>
> Ralph
>
> Sent from my iPad
>
> On Sep 3, 2013, at 6:40 PM, Nick Williams
Well I personally don't see a reason for loggers to be serialized. IMO, if you
put loggers in domain objects, "you're doing it wrong." But that's just my
stance.
IF you need to put a logger in a domain object, just make it static! There's no
advantage to it being an instance variable over it be
Here are my thoughts: http://log4j.markmail.org/thread/3kcao26u5ugxc6jb :-)
I was actually just thinking earlier about bringing this back up. I know it has
been a very exhausted discussion, but I think it's worth having one more time
before we go GA.
I spent considerable time researching and re
(Foreword: Apologies for my scarcity of late. I'm a month behind on my book,
mostly due to my wasted work on getCallerClass for Java 8, and I still have
$work to contend with.)
Agreed that the unicode stuff is a problem with a non-compliant driver. There's
nothing we can do about that per se. O
On Oct 11, 2013, at 10:29 AM, Gary Gregory wrote:
> On Fri, Oct 11, 2013 at 11:10 AM, Nick Williams
> wrote:
>> (Foreword: Apologies for my scarcity of late. I'm a month behind on my book,
>> mostly due to my wasted work on getCallerClass for Java 8, and I still have
&
Not yet. There are several outstanding issues regarding the web configuration
that need to be solved. I plan on tackling them next week. I'm finally
finishing my book this weekend—four months late. :-(
Nick
On Jan 2, 2014, at 1:23 PM, Gary Gregory wrote:
> So, should we call for a vote?
>
> G
Sorry. I got confused and thought you were talking about a vote on the thread
for release. ;-)
Nick
On Jan 2, 2014, at 4:11 PM, Gary Gregory wrote:
> On Thu, Jan 2, 2014 at 2:36 PM, Nick Williams
> wrote:
> Not yet. There are several outstanding issues regarding the web configuratio
Filter initialization is one of the last things to happen in web app 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.
Wanted to update y'all. As you know, I've been very absent lately due to the
book consuming every minute of my free time. I know I haven't been contributing
my due, and for that please accept my sincerest apologies. The book is finally
done (goes on sale next month!) and I can get back to regula
the log4j jar is present it can’t be disabled or be modified by
>>>> the end user. We’ve had some issues with Spring initialization and now
>>>> LOG4J2-452 reinforces that. I would propose that if we want to keep it
>>>> that we move the min
gt;>>>> I don’t really understand the point of FINE or FINER.
>>>>>>
>>>>>> On the other hand, VERBOSE does make a bit more sense, but I’m
>>>>>> struggling with how that is any different than TRACE. I guess the idea
>>>>
to being). It's a bit of a modification from the attached patch
> on LOG4J2-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
Okay, I finally got a minute to read all of these emails, and...
EVERYBODY FREEZE!
What if I could get you an extensible enum that required no interface changes
and no binary-incompatible changes at all? Sound too good to be true? I
proposed this months ago (LOG4J2-41) and it got shot down mult
A ZOMBIE_APOCALYPSE Level would be EPIC! ;-)
N
On Jan 23, 2014, at 1:31 AM, Christian Grobmeier wrote:
> Maybe:
>
> ZOMBIE_APOCALYPSE > APOCALYPSE > CATASTROPHE > EMERGENCY > FATAL > ...
>
> On 23 Jan 2014, at 3:56, Gary Gregory wrote:
>
>> But that is not as high as APOCALYPSE right?
>>
>>
There has obviously been some serious discussion about these topics. We're not
going to come to a total agreement on this. I propose:
- We have a committers-only vote in the "Enums and Custom Levels" thread on
whether to make Level an extensible enum.
- AFTER having that vote, we have a committe
ill think we should continue that
>> path. At any rate, this will hopefully lead to a synthesis of ideas and
>> agreement.
>>
>>
>> On Thu, Jan 23, 2014 at 8:22 AM, Matt Sicker wrote:
>> Neat idea. I'd update it for proper concurrency, though. I could wri
Rory,
We have been actively testing Log4j with JDK 8 since about March 2013. The only
problem we found so far was the removal of
sun.reflect.Reflection#getCallerClass(int), which spurred months of
discussions, disagreements, and proposed fixes. Ultimately, the change was
reverted and has been
I may have missed something. Did we decide on an approach? Last I heard, the
camp was still split: Some wanted to go with my extensible enum, others wanted
to change Level to an interface and make a Levels enum.
So I'm a bit confused. Which implementation are you working on?
Nick
On Jan 25, 20
Can you post a diff or the related files somewhere? Obviously it can be tweaked
after commit if necessary, but I'd like to see if there's anything major that
sticks out to me before you commit.
Thanks,
Nick
On Jan 26, 2014, at 2:57 AM, Ralph Goers wrote:
> I have completed the work on custom
Never mind I see you just committed. :-)
I'll review and provide feedback if necessary.
N
On Jan 26, 2014, at 1:36 PM, Nick Williams wrote:
> Can you post a diff or the related files somewhere? Obviously it can be
> tweaked after commit if necessary, but I'd like to see if
Some (ok, a lot of) feedback:
- `private static ConcurrentMap levels` should be final.
- `private static Object constructorLock` should be final. In fact, code
inspection flags this as a warning since code synchronizes on it.
- The standard Level constants should be instantiated in a static ini
to whether it is automatically initialized.
>>>
>>> Am I the only one who feels this way? Frankly, this and one other issue I
>>> plan to work on this weekend are the only things I see as blockers for a GA
>>> release.
>>>
>>> For m
ion to stay as it
> is and get rid of the need for synchronization in the constructor.
>
> Ralph
>
> On Jan 26, 2014, at 12:41 PM, Nick Williams
> wrote:
>
>> Some (ok, a lot of) feedback:
>>
>> - `private static ConcurrentMap levels` should be final.
&g
cker wrote:
> +1 to everything Nick said.
>
>
> On 26 January 2014 16:40, Nick Williams wrote:
> I would be OK with getting rid of the ordinal. It makes it less enum-like,
> but I agree that the ordinal really has little purpose now. The intLevel is
> more important.
>
&
Generating a logger /interface/ is going to be hard. Sure, writing the code
automatically will be a piece of cake. But then what do we do with that code?
The user needs to program against it. So we have to have a command-line utility
or Maven/Ant plug-in to generate the source pre-compile. Howev
If they are named something like void
> diag(String msg) then there is no need to annotate them.
>
> Ralph
>
> On Jan 26, 2014, at 3:51 PM, Nick Williams
> wrote:
>
>> Generating a logger /interface/ is going to be hard. Sure, writing the code
>> automa
There are two separate discussions going on here, so it's easy to get lost. We
should probably split discussions again.
Discussion 1: The finer details of custom levels. I'm fine with using a static
factory method and making the constructor private, but I'm not a big fan of the
name. Just sound
Here's a split-off thread for discussing how we can make using custom levels
easier. Some on the team have expressed a desire to make it even easier. Given
hypothetical custom levels DIAG and NOTE, the following would be nice to have:
logger.note("message");
logger.diag("message");
etc.
We're t
ugh configuration that would
> be ideal.
>
> I'm trying to find a way to remove my request for additional built in levels
> but through configuration instead of adding them ourselves.
>
> Scott
> Scott
>
> On Jan 26, 2014 7:38 PM, "Nick Williams"
> wrote:
>
n 2.
>
> I also am not in love with the method name but it does describe what it does.
> If anyone has any ideas on a better name please suggest it (we are talking
> about the getOrCreateLevel method name).
>
> Ralph
>
> On Jan 26, 2014, at 6:59 PM, Nick Williams
> wro
ored unless the
> Level is created. Yes, that could lead to some problems if there are
> conflicts, but I think returning the registered level is better than throwing
> an exception.
>
> Ralph
>
> On Jan 26, 2014, at 7:46 PM, Nick Williams
> wrote:
>
>> Level.f
I think I'll attend, but I'd like to see if someone here can answer some
questions for me. I can direct my questions to someone at ApacheCon, but I
figured this would be a quick first-go.
I noticed the fee is normally $799 (until Friday, then $1099), but it's $275
for "committers." That means t
I wouldn't necessarily vote against a GA, but given that we just MAJORLY
overhauled Level, I think a brief RC is in order. It would be a shame if
someone found a problem with Level a week after GA that caused us to need to
change the API to fix it.
Nick
On Jan 27, 2014, at 12:51 AM, Remko Popm
logging (DSL!), I do not want
> to extend, I want to wrap a logger. See my DEFCON example.
>
> Gary
>
>
> On Sun, Jan 26, 2014 at 6:51 PM, Nick Williams
> wrote:
> Generating a logger /interface/ is going to be hard. Sure, writing the code
> automatically will be a
> From: Ralph Goers
> Date:01/27/2014 11:19 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels - completed.
>
> If the user creates a custom Logger Wrapper then they can just code against
> that and not use an interface, correct?
>
> Ral
I would veto such a change, and here is my technical justification:
You will break EVERYTHING currently using the Log4j 2 API.
EVERYTHING that EVERY Log4j 2 user has currently written will have to be
changed to use StandardLogger instead of Logger. That's not even considering
the fact that Logg
e) AND an extension to
> StandardLogger with refined levels (NOTICE, DIAG, VERBOSE).
Nick
On Jan 27, 2014, at 1:25 PM, Paul Benedict wrote:
> On Jan 27, 2014, at 11:15 AM, Nick Williams
> wrote:
>> However, what I WOULD be okay with is creating a SimpleLogger interface for
>> things l
ks seems pretty frequent for our
>> bunch for a ramp down.
>>
>> Thoughts on that?
>>
>> I am not so much concerned about OSGi now since I look at this as more of a
>> packaging issue and how much gets dragged in the container with
>> dependencies
It's only necessary to guard logging statements like that when some additional
processing is required before the logging method is called. For example:
logger.info("Some info statement");
That's always efficient. But:
logger.info("Some info {} statement {}", request.getHeader("header1"),
reque
The JavaDoc for Logger has "@doubt See LOG4J2-16" in it. Anybody know what this
is about? Can the doubt be removed?
N
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h
ingly.
Inline below I have included the answers I got to some questions I asked Rich.
I hope some of you will come to ApacheCon with me! It'll be a great opportunity
to publicize Log4j 2.0 GA!
Nick
On Jan 27, 2014, at 6:21 AM, Nick Williams wrote:
> - What exactly is a project summit?
ng would
> surely help us
> to promote log4j in the US.
>
>
>
> On 28 Jan 2014, at 18:59, Remko Popma wrote:
>
> > I'm interested but not sure if I can go (we are expecting our second
> > child
> > early May...)
> > -Remko
> >
> &
On Jan 28, 2014, at 5:43 PM, Remko Popma wrote:
> I would really like everyone's feedback on this. I have two questions:
>
> 1. Does this fulfill everyone's requirements?
> Another way of asking this is: would you use this in your own projects? (If
> not, why not?)
Personally, no. I don't like
ecting Loggers using
> annotations.
>
>
> On 29 January 2014 07:46, Remko Popma wrote:
>
>
> On Wednesday, January 29, 2014, Nick Williams
> wrote:
>
> On Jan 28, 2014, at 5:43 PM, Remko Popma wrote:
>
>> I would really like everyone's feedback o
er logging APIs not 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 expert
On Jan 30, 2014, at 9:25 PM, Matt Sicker wrote:
> On 30 January 2014 18:01, Nick Williams wrote:
> Matt,
>
> Do you want to share a hotel room? I know it would certainly help my finances
> to split one, and depending on whether you get employer support, it should
> prob
I do not think appenders should be in the API. Appenders are pretty much the
definition of an implementation detail.
As for setLevel, I absolutely think it's a problem point when migrating from
Log4j 1 to Log4j 2. In my Log4j 1 apps, I offer a simple admin console for
changing the log levels of
Tsk tsk. Using auto-refactor again without checking the output. :-P
N
On Jan 31, 2014, at 7:40 AM, Gary Gregory (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/LOG4J2-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887754#comment-1388
On Jan 31, 2014, at 3:29 PM, Gary Gregory wrote:
> On Fri, Jan 31, 2014 at 2:00 PM, Nick Williams
> wrote:
> I do not think appenders should be in the API. Appenders are pretty much the
> definition of an implementation detail.
>
> As for setLevel, I absolutely think it
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 wr
Matt and I coordinated off-list today and got our presentation proposals
submitted to ApacheCon. Assuming they're all accepted, Log4j will have four
presentations representing it. Go us!
Nick
On Jan 31, 2014, at 11:25 PM, Nick Williams wrote:
> Matt, sorry for the delay. I've h
I'm finalizing the logging chapter of my book to send to the printers Wednesday
(I'm so glad I got to correct it to say Level was extendable!), and I need to
know what the Maven artifact GA version number will be. I print the new Maven
artifacts used in each chapter on the first page of the chap
My wiki name is NickWilliams.
Nick
On Feb 3, 2014, at 4:10 AM, Christian Grobmeier wrote:
> Hello,
>
> yes, there is a reason! Please give me your wiki name.
>
> You need to be added to the contributors group.
>
> I will add a note to the wiki page as well
>
> Cheers
> Christian
>
> On 3 Fe
> Sent from my iPad
>>
>>> On Feb 2, 2014, at 8:59 PM, Nick Williams
>>> wrote:
>>>
>>> I'm finalizing the logging chapter of my book to send to the printers
>>> Wednesday (I'm so glad I got to correct it to say Level was extendabl
Wow. This is going to be hard...
I have submitted my nominations. What's the next step? I read the JIRA, but I
saw nothing talking about this "nomination" stage on the Wiki. IMO, doing the
*actual* voting on the mailing list is preferable. Voting on the wiki will be
hard and discourage particip
On Mon, Feb 3, 2014 at 6:36 PM, Nick Williams
> wrote:
> Wow. This is going to be hard...
>
> I have submitted my nominations. What's the next step? I read the JIRA, but I
> saw nothing talking about this "nomination" stage on the Wiki. IMO, doing the
> *actual*
sion number be?
> >>
> >> Also 2.0 or 2.0.0 for me
> >>
> >> On 3 Feb 2014, at 7:41, Ralph Goers wrote:
> >>
> >>> I had thought it would be 2.0.
> >>>
> >>> Sent from my iPad
> >>>
> >>>> On F
.0 in the book. I'm OK with 2.0
> and 2.0.0 even though 2.0.0 feels redundant. Like someone else posted I find
> the .FINAL and -RELEASE and whatnot ludicrous.
>
> Gary
>
>
> On Tue, Feb 4, 2014 at 2:14 AM, Nick Williams
> wrote:
> Well well well. I'm sen
Maybe he'll respond again tonight and let us know if he's set on 2.0 or fine
with 2.0.0. :-)
N
On Feb 4, 2014, at 1:42 AM, Gary Gregory wrote:
> I'm happy to let Ralph pick, either way is fine with me.
>
> Gary
>
>
> On Tue, Feb 4, 2014 at 2:27 AM, Ni
Guys,
Currently, the JDBCAppender allows users to specify a mechanism for connecting
to the database using one of three options:
- DataSourceConnectionSource: Looks up a JNDI data source
- FactoryMethodConnectionSource: User specifies a class and static method for
retrieving connections
- Drive
On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>
>
> On Thursday, February 6, 2014, Nick Williams
> wrote:
> Guys,
>
> Currently, the JDBCAppender allows users to specify a mechanism for
> connecting to the database using one of three options:
>
> - DataSour
It doesn't so much matter because the XML element names are case insensitive,
but if we change the plugin name for CouchDB we should probably also change it
for MongoDB. There's a reason I did that, I just can't remember what it was...
I don't see any compelling reason to rename the package. The
valid if they are backed by
> a technical justification.
>
> Scott
>
> On Feb 7, 2014 8:07 AM, "Nick Williams" wrote:
> I'm not convinced it really makes a difference, but it's better than couchdb,
> so if the majority wants couchbase it I won't vet
f veto.
>>
>> I would like to see folks ask questions and talk about concerns, and then
>> only mention a veto when there is no other recourse.
>> On Feb 7, 2014 8:14 AM, "Nick Williams"
>> wrote:
>>
>>> Yep. I would've accompanied any veto
2014 7:54 AM, "Christian Grobmeier" wrote:
> On 7 Feb 2014, at 16:19, Nick Williams wrote:
>
> It doesn't so much matter because the XML element names are case insensitive,
> but if we change the plugin name for CouchDB we should probably also change
> it for MongoDB. T
cp?
>
>
> On 5 February 2014 18:07, Remko Popma wrote:
>
>
> On Thursday, February 6, 2014, Nick Williams
> wrote:
>
> On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>
>>
>>
>> On Thursday, February 6, 2014, Nick Williams
>> wrote:
Yes, I'm confused by this addition to. Why did we do this?
Nick
On Jan 30, 2014, at 12:24 AM, Gary Gregory wrote:
> I'm slightly confused by this addition because it seems redundant with using
> StringFormattedMessage and StringFormattedMessageFactory
>
> Gary
>
> --
> E-Mail: garydgreg...@
many database vendors these days. What do you think?
>
> Thanks!
>
>
> On 7 Feb 2014, at 17:55, Nick Williams wrote:
>
>> Ohhh okay. I misunderstood. H. Well I suppose in that case we really
>> must rename it, although I'm not super happy about it. But
Let's roll 2.0-rc1 tonight. We've all basically agreed that there are no
showstoppers. I've fixed a whole bunch of appender-related bugs, and there's no
issue with the Servlet 3.0 auto-initialization. Can someone kick that off so
that we can have a vote this weekend and get this out there ASAP?
cus on OSGi for RC2...
>
> Gary
>
>
> On Fri, Feb 7, 2014 at 10:31 PM, Nick Williams
> wrote:
> Let's roll 2.0-rc1 tonight. We've all basically agreed that there are no
> showstoppers. I've fixed a whole bunch of appender-related bugs, and there's
> no iss
nd
>> HttpComponenent, it's not exactly something I'd call 'fun'.
>>
>> You might need to be on the PMC, I'm not sure, Ralph?
>>
>> Gary
>>
>>
>>
>> On Fri, Feb 7, 2014 at 11:55 PM, Nick Williams
>> wrote:
>> I hav
If someone could point out to me how to tell Maven to generate release notes
for rc1, that would be great. Google is useless because it removes the hyphen
from the Maven command, so my only search results are release notes for Maven.
Nick
On Feb 8, 2014, at 10:07 AM, Nick Williams wrote:
>
Figured it out! The Wiki doesn't say to change the Log4jReleaseVersion
property. *mental note to fix this*
Nick
On Feb 8, 2014, at 10:36 AM, Nick Williams wrote:
> *sigh* I got stuck on step TWO. TWO!
>
> • Run "mvn -P release-notes generate-resources" to cre
expression ${project.version}
[INFO] Ignoring artifact version update for expression ${project.version}
[INFO] Ignoring artifact version update for expression ${project.version}
[INFO] Ignoring artifact version update for expression ${project.version}
[INFO] Ignoring artifact version update fo
bunch of times
> to set they version. I have never gotten messages like below when releasing.
>
> Sent from my iPad
>
> On Feb 8, 2014, at 9:02 AM, Nick Williams
> wrote:
>
>> The wiki does NOT have enough info on this...
>>
>> I got the following
figuration."
I need someone to:
- Delete the rc1 tag, please.
- Either give me permissions to roll a release, or just do it for me. I've
already run steps 1-5. The release notes have been committed.
Nick
On Feb 8, 2014, at 12:13 PM, Nick Williams wrote:
> Christian was right. The d
On Feb 8, 2014, at 1:06 PM, Christian Grobmeier wrote:
> Nick,
>
> i totally feel your pain. Releasing is always evil, i never experienced it
> otherwise in what ever project.
>
> On 8 Feb 2014, at 19:56, Nick Williams wrote:
>> Well, after wasting a couple hours, it
Nick
On Feb 8, 2014, at 1:17 PM, Christian Grobmeier wrote:
> On 8 Feb 2014, at 20:11, Nick Williams wrote:
>> On Feb 8, 2014, at 1:06 PM, Christian Grobmeier wrote:
>>> OK, so just confirming you want me to do:
>>> svn delete
>>> https://svn.apac
. I've emailed Infra to get my email address corrected,
since it's read-only in Sonatype.
Nick
On Feb 8, 2014, at 2:52 PM, Christian Grobmeier wrote:
> On 8 Feb 2014, at 21:12, Nick Williams wrote:
>
>> Almost done. In the vote email, I'm supposed to, "Provide a lis
>>
>> Ralph, get well soon!
>> -Remko
>>
>>
>> On Sunday, February 9, 2014, Nick Williams
>> wrote:
>> Turns out my email address in Sonatype is not correct (it's just my Apache
>> ID, "nickwilliams," instead of my Apache emai
Well, unfortunately my first release attempt didn't turn out so well. The vote
for Log4j 2.0-rc1 RC1 has been canceled:
- There are unsupported licenses. I will fix those shortly.
- There might be something pointing to rc2 instead of rc1. I'll look into that.
Gary also pointed out LOG4J2-531, re
In changes.xml, I see some committers put changes at the top of a and
others put changes at the bottom of a . Which is the best practice?
Nick
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional com
Feb 9, 2014 at 1:55 PM, Nick Williams
> wrote:
> In changes.xml, I see some committers put changes at the top of a
> and others put changes at the bottom of a . Which is the best
> practice?
>
> Nick
> -
On Feb 8, 2014, at 11:13 PM, Remko Popma wrote:
>
> On Sun, Feb 9, 2014 at 1:31 PM, Nick Williams
> wrote:
> Well, unfortunately my first release attempt didn't turn out so well. The
> vote for Log4j 2.0-rc1 RC1 has been canceled:
>
> - There are unsupported
I didn't. I renamed the tag to ...2.0-rc1-rc1. But when I tried to roll 2.0-rc1
RC2, Sonatype crashed halfway through the release and stopped responding.
THAT'S the tag I deleted, as clearly shown by the commit logs.
N
On Feb 9, 2014, at 12:12 AM, Gary Gregory wrote:
>
>
>
>
> Never delete
Gary,
One of your commits tonight changed all of the methods in Level from being
final to being non-final. This is not what we agreed upon. Why did you make
this change? Was this one of the auto-refactor changes? I've noticed a lot of
cleanup tonight that smells like that. :-)
Nick
---
Ahh. The class was originally abstract, hence why the methods were final. I see
now why that's not needed. My bad.
N
On Feb 9, 2014, at 12:34 AM, Gary Gregory wrote:
> On Sun, Feb 9, 2014 at 1:22 AM, Nick Williams
> wrote:
> Gary,
>
> One of your commits tonight change
I'm giving up for today. First pass: Resulted in a canceled vote. Second pass:
Sonatype crashed halfway through and stopped accepting uploads to the staging
repository. Third pass: Now `mvn site` fails with strange error about a missing
file that it shouldn't be looking for to begin with. I give
bution/src/site/site.vm'
does not exist -> [Help 1]
As far as I can tell, nothing has changed with the log4j-distribution project
since it worked this morning. I'm at a loss to explain this sudden failure.
Help?
N
On Feb 9, 2014, at 12:43 AM, Nick Williams wrote:
> I'm
runk/src/site/site.vm
>
> Does it exist on your system? If not maybe you should work on on a fresh
> checkout.
>
> On 9 Feb 2014, at 7:56, Nick Williams wrote:
>
>> By the way, this is the error I'm getting when building site now:
>>
>> [ERROR] Failed to e
I checked out a fresh trunk anyway and built site again. Same error, so it's
not something wrong with my local copy. I don't understand...and we can't
release until this is fixed. :-(
N
On Feb 9, 2014, at 11:14 AM, Nick Williams wrote:
> No, that's not it. It's lo
understand whats your problem too
>
>
> On 9 Feb 2014, at 18:42, Nick Williams wrote:
>
>> I checked out a fresh trunk anyway and built site again. Same error, so it's
>> not something wrong with my local copy. I don't understand...and we can't
>> release
That is not how we have done it in the past. We have never done it that way.
When releasing beta8, we originally created the tag log4j-2.0-beta8. When the
vote failed, we renamed that tag to log4j-2.0-beta8-rc1 and re-created the tag
log4j-2.0-beta8. The vote on that tag passed. This is clearly
Furthermore, I'm doing this like the Wiki
(https://wiki.apache.org/logging/Log4j2ReleaseGuide) says:
If the release fails after sending the vote email:
...
2. Rename the release tag in subversion to add rcn to the end of the tag.
Nick
On Feb 9, 2014, at 1:22 PM, Nick Williams wrote:
&
ps://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
>
> looks like i would need to downgrade maven to 3.0.
>
> Weird, i never saw this before
>
> On 9 Feb 2014, at 19:28, Nick Williams wrote:
>
>> I disabled the site plugin on the distribution module and that f
There have been extensive discussions about getCallerClass(), which you can
find throughout the archives of the developer's list and the JDK core-libs-dev
list. In very abbreviated form, only privileged, JDK code can call
getCallerClass(). They initially removed getCallerClass(int), but we convi
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 Sicker wrote:
> Then I'm guessing abuse of JNI is out of the question, too?
>
>
> On 9 February 2014 13:41, Nick Williams wrote:
>
wrote:
> 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,
1 - 100 of 642 matches
Mail list logo
