We may need to change the website so that people can download both 2.0.2 and 2.1-beta.
Sent from my iPhone > On 2014/09/17, at 10:45, Gary Gregory <[email protected]> wrote: > > A beta sounds reasonable. > > Gary > >> On Tue, Sep 16, 2014 at 9:33 PM, Matt Sicker <[email protected]> wrote: >> Perhaps it's time to release a beta or milestone or something? That way we >> can get some extra testing while we polish for 2.1 and hopefully get a >> release candidate out within, oh, let's say early October? Try to release >> 2.1 around the end of October/early November at the latest? I think we can >> probably do it, and I can RM again. >> >>> On 16 September 2014 01:15, Remko Popma <[email protected]> wrote: >>> Perhaps the label "Experimental" caused a misunderstanding. >>> I fully intend to do my due diligence and ensure this is properly >>> documented and has JUnit tests that all pass on Windows, Solaris and Linux. >>> So this appender is no more and no less experimental than our new JUL >>> bridge or the new GELF layout. >>> >>> You'll remember that I initially marked the RandomAccessFile appenders as >>> "Experimental" in the documentation. >>> This is not because they were of lesser quality in any way, it was just an >>> indication to users that these appenders did not have the same track record >>> that the File appenders had. >>> We removed that label after a number of releases when we felt that they had >>> built enough of a track record and the "Experimental" label was no longer >>> useful or correct. >>> >>> My intention is to do the same with the MemoryMappedFile appender. On the >>> one hand this appender promises better performance, but users should be >>> aware that they are a new addition and they should do their own due >>> diligence. >>> >>> I expect to finish the work for MemoryMappedFileAppender by the end of next >>> week. >>> I hope that is soon enough to be able to include it in 2.1. >>> >>> >>> Speaking of JUL, we should update this image: >>> http://logging.apache.org/log4j/2.x/faq.html#which_jars >>> >>> Regards, -Remko >>> >>> Sent from my iPhone >>> >>>> On 2014/09/16, at 11:26, Gary Gregory <[email protected]> wrote: >>>> >>>> I do not think we can or should include "experimental code" unless it is >>>> in a separate module with flashing red lights. At that point, we might as >>>> well leave it in git, with a pointer from our docs. But even experimental >>>> code needs proper documentation and I personally barely have time to do >>>> what I am doing... >>>> >>>> 2.1 has a good chunk of new features already, let's not try and stuff more >>>> in there. I'd like to stabilize what we have now, release 2.1, and >>>> continue on to 2.2 and beyond. If we RERO, there is no need to try to >>>> stuff features under the wire. >>>> >>>> I think that if we focus on 2.1 now, then you can ask the ML to pitch in >>>> this new feature for 2.2. This would let more focus be on the new code and >>>> another feature to look forward to in 2.2. I think we are doing well now >>>> and there is no reason we cannot keep on RERO. >>>> >>>> Are we done with the clock business? I think someone wanted to run some >>>> benchmarks and possibly deprecate some code. Once that is done, I think we >>>> can start 2.1. >>>> >>>> Gary >>>> >>>>> On Mon, Sep 15, 2014 at 9:55 PM, Remko Popma <[email protected]> >>>>> wrote: >>>>> I'd like to include it in 2.1 as an experimental feature to get some >>>>> early user feedback. But I don't want to hold everyone up either. >>>>> Do we have a release date in mind? >>>>> >>>>> Remko >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 2014/09/16, at 9:07, Gary Gregory <[email protected]> wrote: >>>>>> >>>>>> On deck for 2.2 perhaps? >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Remko Popma >>>>>> Date:09/15/2014 19:28 (GMT-05:00) >>>>>> To: Log4J Developers List >>>>>> Subject: Re: Analysis of apache-maven-3.2.3's dependency on JDK-Internal >>>>>> APIs >>>>>> >>>>>> (Dropped Oracle people from recipients) >>>>>> >>>>>> MemoryMappedFileAppender is still in progress in a local branch. I >>>>>> haven't been able to spend much time on it yet. I'll push the branch >>>>>> when I get some unit tests working. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 2014/09/15, at 23:47, Gary Gregory <[email protected]> wrote: >>>>>>> >>>>>>>> On Mon, Sep 15, 2014 at 10:35 AM, Remko Popma <[email protected]> >>>>>>>> wrote: >>>>>>>> One more: the lack of a public API to unmap a memory mapped file means >>>>>>>> we may need to use sun.misc.Cleaner to implement rollover for the >>>>>>>> upcoming MemoryMappedFileAppender. Still investigating this... >>>>>>> >>>>>>> Is the MemoryMappedFileAppender on a branch? I do not see it in >>>>>>> master... >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Monday, September 15, 2014, Remko Popma <[email protected]> >>>>>>>>> wrote: >>>>>>>>> And separately from the caller class issue, log4j2 async loggers >>>>>>>>> depend on the LMAX Disruptor, which makes heavy use of >>>>>>>>> sun.misc.Unsafe, I think mostly for concurrency primitives. >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On 2014/09/15, at 22:59, Gary Gregory <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> If you download the source zip or git clone, please see the class >>>>>>>>>> org.apache.logging.log4j.core.impl.ReflectiveCallerClassUtility. >>>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>>> On Mon, Sep 15, 2014 at 9:56 AM, Gary Gregory >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Ah, let's see... >>>>>>>>>>> >>>>>>>>>>> These links discuss our problems: >>>>>>>>>>> >>>>>>>>>>> - https://issues.apache.org/jira/browse/LOG4J2-245 >>>>>>>>>>> - https://issues.apache.org/jira/browse/LOG4J2-809 >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>>> On Mon, Sep 15, 2014 at 8:54 AM, Rory O'Donnell Oracle, Dublin >>>>>>>>>>>> Ireland <[email protected]> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Can I point you to the following paragraphs below. >>>>>>>>>>>> >>>>>>>>>>>> "For anything where your migration path is unclear, I would >>>>>>>>>>>> appreciate comments on the JDK-internal API usage patterns in the >>>>>>>>>>>> attached jdeps report, in particular comments elaborating on the >>>>>>>>>>>> rationale for them either to me or on this list. >>>>>>>>>>>> >>>>>>>>>>>> Finding suitable replacements for unsupported interfaces is not >>>>>>>>>>>> always straightforward, which is why I am reaching out to you >>>>>>>>>>>> early in the JDK 9 development cycle so you can give feedback >>>>>>>>>>>> about new APIs that may be needed to facilitate this exercise." >>>>>>>>>>>> >>>>>>>>>>>> Please feel free to send me your comments, explanations etc on why >>>>>>>>>>>> you are using JDK-internal APIs ? >>>>>>>>>>>> >>>>>>>>>>>> Rgds,Rory >>>>>>>>>>>> >>>>>>>>>>>> P.S. I haven't gotten round to running the tool on log4j yet. >>>>>>>>>>>> >>>>>>>>>>>>> On 15/09/2014 12:52, Gary Gregory wrote: >>>>>>>>>>>>> Sad, isn't it? Like going to the Dr. and he tells you you've got >>>>>>>>>>>>> something he can't help you with! >>>>>>>>>>>>> >>>>>>>>>>>>> Gary >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Sep 15, 2014 at 7:33 AM, Ralph Goers >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> Yes, but if you follow the link you will notice that there is >>>>>>>>>>>>>> still no replacement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>>> >>>>>>>>>>>>>> > On Sep 15, 2014, at 3:55 AM, Gary Gregory >>>>>>>>>>>>>> > <[email protected]> wrote: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > This is of interest to use and our call stack query hacks, >>>>>>>>>>>>>> > isn't kt? >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Gary >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > -------- Original message -------- >>>>>>>>>>>>>> > From: "Rory O'Donnell Oracle, Dublin Ireland" >>>>>>>>>>>>>> > Date:09/15/2014 06:17 (GMT-05:00) >>>>>>>>>>>>>> > To: [email protected] >>>>>>>>>>>>>> > Cc: Maven Developers List ,Balchandra Vaidya ,Dalibor Topic >>>>>>>>>>>>>> > Subject: Re: Analysis of apache-maven-3.2.3's dependency on >>>>>>>>>>>>>> > JDK-Internal APIs >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Hi Stephen, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > One more time, hope this is ok. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Rgds,Rory >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â JDK Internal API Usage Report for apache-maven-3.2.3 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > The OpenJDK Quality Outreach campaign has run a compatibility >>>>>>>>>>>>>> > report to >>>>>>>>>>>>>> > identify usage of JDK-internal APIs. Usage of these >>>>>>>>>>>>>> > JDK-internal APIs >>>>>>>>>>>>>> > could pose compatibility issues, as the Java team explained in >>>>>>>>>>>>>> > 1996 >>>>>>>>>>>>>> > <http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html>. >>>>>>>>>>>>>> > We have created this report to help you identify which >>>>>>>>>>>>>> > JDK-internal APIs >>>>>>>>>>>>>> > your project uses, what to use instead, and where those >>>>>>>>>>>>>> > changes should >>>>>>>>>>>>>> > go. Making these changes will improve your compatibility, and >>>>>>>>>>>>>> > in some >>>>>>>>>>>>>> > cases give better performance. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Migrating away from the JDK-internal APIs now will give your >>>>>>>>>>>>>> > team >>>>>>>>>>>>>> > adequate time for testing before the release of JDK 9. If you >>>>>>>>>>>>>> > are unable >>>>>>>>>>>>>> > to migrate away from an internal API, please provide us with an >>>>>>>>>>>>>> > explanation below to help us understand it better. As a >>>>>>>>>>>>>> > reminder, >>>>>>>>>>>>>> > supported APIs are determined by the OpenJDK's Java Community >>>>>>>>>>>>>> > Process >>>>>>>>>>>>>> > and not by Oracle. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > This report was generated by jdeps >>>>>>>>>>>>>> > <http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html> >>>>>>>>>>>>>> > through static analysis of artifacts: it does not identify any >>>>>>>>>>>>>> > usage of >>>>>>>>>>>>>> > those APIs through reflection or dynamic bytecode. You may >>>>>>>>>>>>>> > also run >>>>>>>>>>>>>> > jdeps on your own >>>>>>>>>>>>>> > <https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool> >>>>>>>>>>>>>> > if you would prefer. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Summary of the analysis of the jar files within >>>>>>>>>>>>>> > apache-maven-3.2.3: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â * Numer of jar files depending on JDK-internal APIs: 1 >>>>>>>>>>>>>> >Â Â * Internal APIs that have known replacements: 0 >>>>>>>>>>>>>> >Â Â * Internal APIs that your team should migrate away: 1 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â Â Â APIs that have known replacements >>>>>>>>>>>>>> >Â Â Â Â >>>>>>>>>>>>>> ><https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool>: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > ID Replace Usage of With Inside >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â Â Â JDK-internal APIs without supported replacements: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > ID Internal APIs (do not use) Used by >>>>>>>>>>>>>> > 1 sun.misc.Unsafe >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â * lib/guava-14.0.1.jar >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Explanation... >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >Â Â Â Â Identify External Replacements >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > You should use a separate third-party library that performs >>>>>>>>>>>>>> > this >>>>>>>>>>>>>> > functionality. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > ID Internal API (grouped by package) Used By Identify External >>>>>>>>>>>>>> > Replacement >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > On 15/09/2014 10:22, Stephen Connolly wrote: >>>>>>>>>>>>>> > > I think the mailing list stripped the attachment >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > On Monday, 15 September 2014, Rory O'Donnell Oracle, Dublin >>>>>>>>>>>>>> > > Ireland < >>>>>>>>>>>>>> > > [email protected]> wrote: >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >> Hi Robert,Kristian, >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> As part of the preparations for JDK 9, Oracle's engineers >>>>>>>>>>>>>> > >> have been >>>>>>>>>>>>>> > >> analyzing open source projects like yours to understand >>>>>>>>>>>>>> > >> usage. >>>>>>>>>>>>>> > >> One area of concern involves identifying compatibility >>>>>>>>>>>>>> > >> problems, such as >>>>>>>>>>>>>> > >> reliance on JDK-internal APIs. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Our engineers have already prepared guidance on migrating >>>>>>>>>>>>>> > >> some of the more >>>>>>>>>>>>>> > >> common usage patterns of JDK-internal APIs to supported >>>>>>>>>>>>>> > >> public interfaces. >>>>>>>>>>>>>> > >> The list is on the OpenJDK wiki [0], along with >>>>>>>>>>>>>> > >> instructions on how to run >>>>>>>>>>>>>> > >> the jdeps analysis tool yourself . >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> As part of the ongoing development of JDK 9, I would like >>>>>>>>>>>>>> > >> to encourage >>>>>>>>>>>>>> > >> migration from JDK-internal APIs towards the supported Java >>>>>>>>>>>>>> > >> APIs. I have >>>>>>>>>>>>>> > >> prepared a report for your project release >>>>>>>>>>>>>> > >> apache-maven-3.2.3 based on the >>>>>>>>>>>>>> > >> jdeps output. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> The report is attached to this e-mail. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> For anything where your migration path is unclear, I would >>>>>>>>>>>>>> > >> appreciate >>>>>>>>>>>>>> > >> comments on the JDK-internal API usage patterns in the >>>>>>>>>>>>>> > >> attached jdeps >>>>>>>>>>>>>> > >> report - in particular comments elaborating on the >>>>>>>>>>>>>> > >> rationale for them - >>>>>>>>>>>>>> > >> either to me or on this list. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Finding suitable replacements for unsupported interfaces is >>>>>>>>>>>>>> > >> not always >>>>>>>>>>>>>> > >> straightforward, which is why I am reaching out to you >>>>>>>>>>>>>> > >> early in the JDK 9 >>>>>>>>>>>>>> > >> development cycle so you can give feedback about new APIs >>>>>>>>>>>>>> > >> that may be >>>>>>>>>>>>>> > >> needed to facilitate this exercise. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Thank you in advance for any efforts and feedback helping >>>>>>>>>>>>>> > >> us make JDK 9 >>>>>>>>>>>>>> > >> better. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Rgds,Rory >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> [0] >>>>>>>>>>>>>> > >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+ >>>>>>>>>>>>>> > >> Analysis+Tool >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> -- >>>>>>>>>>>>>> > >> Rgds,Rory O'Donnell >>>>>>>>>>>>>> > >> Quality Engineering Manager >>>>>>>>>>>>>> > >> Oracle EMEA , Dublin, Ireland >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > -- >>>>>>>>>>>>>> > Rgds,Rory O'Donnell >>>>>>>>>>>>>> > Quality Engineering Manager >>>>>>>>>>>>>> > Oracle EMEA , Dublin, Ireland >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Rgds,Rory O'Donnell >>>>>>>>>>>> Quality Engineering Manager >>>>>>>>>>>> Oracle EMEA , Dublin, Ireland >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> 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 >> >> >> >> -- >> Matt Sicker <[email protected]> > > > > -- > E-Mail: [email protected] | [email protected] > 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
