[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931455#comment-15931455
 ] 

Ralph Goers commented on LOG4J2-1359:
-

I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931455#comment-15931455
 ] 

Ralph Goers edited comment on LOG4J2-1359 at 3/18/17 11:05 PM:
---

I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

I still have to do some performance testing, but please take a look.


was (Author: ralph.go...@dslextreme.com):
I have created branch LOG4J2-1359. To build Log4j you must install Java 9 and 
create a toolchains.xml that points to it. 

I have created a Jenkins job that verifies the build works in Jenkins 
(obviously). The only thing I don't like is that the toolchains.xml file has to 
be updated to point to the latest java 9 install. For some reason there is no 
symlink.

> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931412#comment-15931412
 ] 

ASF subversion and git services commented on LOG4J2-1359:
-

Commit e6ce8e4e137f00e9c3ab2f341dfda03c1f76a88a in logging-log4j2's branch 
refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=e6ce8e4 ]

LOG4J2-1359 - Ignore javadoc problems in core due to Java 9 classes. Modify 
build instructions


> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931396#comment-15931396
 ] 

ASF subversion and git services commented on LOG4J2-1359:
-

Commit 4e44466fddb33da1835d82f44a538277741b9156 in logging-log4j2's branch 
refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=4e44466 ]

LOG4J2-1359 - Remove profiles


> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

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

[Ralph Goers]

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 subscribers - no problem
> Creating bounce messages directing people to use the merged target list - no 
> problem
> 
> People will know in advance this merger is going to take place, and if they 
> forget I think it'll take only one or two bounce messages to get the hint.
> 
> If you are :-
> 
> a) Happy with that - pick a date this can be done , let all lists users know 
> this is happening and the date then let me know.
> b) Not Happy with that - ping this ticket again and we'll escalate further.
> 
> Thanks
> 
> On 16 March 2017 at 22:23, Matt Sicker  > wrote:
> 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? 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 the subject line.
>> 3. This is the main thing that needs to happen.
>> 
>> Ralph
>> 
>> 
>> 
>>> On Mar 12, 2017, at 7:49 PM, Matt Sicker >> > wrote:
>>> 
>>> Some things:
>>> 
>>> 1. Archives won't be merged.
>>> 2. Infra suggests it might be a better idea to have the old email addresses 
>>> respond with a canned reply saying that the lists have moved over to dev@, 
>>> though they can set it up all as aliases if we prefer.
>>> 3. Current subscribers from all dev lists would be automatically subscribed 
>>> to the combined list.
>>> 
>>> So, use aliases or have the old addresses bounce back and inform senders to 
>>> use the new list?
>>> 
>>> On 12 March 2017 at 18:31, Matt Sicker >> > wrote:
>>> Created a request, not sure if it's public: 
>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13651 
>>> 
>>> 
>>> On 12 March 2017 at 17:11, Ralph Goers >> > wrote:
>>> Yes,
>>> 
>>> If you could send the request to infra I would appreciate it.
>>> 
>>> Ralph
>>> 
 On Mar 12, 2017, at 1:13 PM, Matt Sicker > wrote:
 
 The vote has been open for 5 days now. Based on the tallies and 
 discussions, it sounds like we'd like to merge the dev lists but keep the 
 user lists as is. Shall we move forward with combining them now?
 
 On 10 March 2017 at 12:27, Dominik Psenner > wrote:
 Total agreement.
 
 On 10 Mar 2017 6:26 p.m., "Ralph Goers" > wrote:
 This is exactly why we need one dev list. These last two responses dropped 
 the other lists.  This is a horrible way to have discussions that affect 
 all the sub projects.
 
 Ralph
 
 
> On Mar 10, 2017, at 9:11 AM, Matt Sicker  > wrote:
> 
> I'd love to see more unified configurations in all the subprojects. Gary 
> mentioned that as an idea for log4cxx as that would make it useful for 
> his use case where they're using both Java and C++ in various projects.
> 
> While the programming languages in use here (Java, .NET, PHP, and C++) 
> aren't really compatible with each other, having similar architectures 
> and plugin systems could help a bit in this regard. Having more inclusive 
> conversations about this would be great.
> 
> On 10 March 2017 at 04:29, Mikael Ståldal  > wrote:
> I think that a vast majority of our users only uses one of the languages 
> we support, and therefore only are interested in one of the subprojects.
> 
> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner  > wrote:
> We had once the discussion that we wanted all Apache Logging projects to 
> become very similar in their usage, starting with the same or a very 
> similar configuration. Given that we should aim towards one Apache 
> Logging specification and several Apache Logging specification 
> implementations in the form of Apache Logging subprojects. That means 

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

[Matt Sicker]

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 merger is going to take place, and if they
forget I think it'll take only one or two bounce messages to get the hint.

If you are :-

a) Happy with that - pick a date this can be done , let all lists users
know this is happening and the date then let me know.
b) Not Happy with that - ping this ticket again and we'll escalate further.

Thanks

On 16 March 2017 at 22:23, Matt Sicker  wrote:

> 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? 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 the subject line.
>> 3. This is the main thing that needs to happen.
>>
>> Ralph
>>
>>
>>
>> On Mar 12, 2017, at 7:49 PM, Matt Sicker  wrote:
>>
>> Some things:
>>
>> 1. Archives won't be merged.
>> 2. Infra suggests it might be a better idea to have the old email
>> addresses respond with a canned reply saying that the lists have moved over
>> to dev@, though they can set it up all as aliases if we prefer.
>> 3. Current subscribers from all dev lists would be automatically
>> subscribed to the combined list.
>>
>> So, use aliases or have the old addresses bounce back and inform senders
>> to use the new list?
>>
>> On 12 March 2017 at 18:31, Matt Sicker  wrote:
>>
>>> Created a request, not sure if it's public: https://issues.apache.
>>> org/jira/servicedesk/customer/portal/1/INFRA-13651
>>>
>>> On 12 March 2017 at 17:11, Ralph Goers 
>>> wrote:
>>>
 Yes,

 If you could send the request to infra I would appreciate it.

 Ralph

 On Mar 12, 2017, at 1:13 PM, Matt Sicker  wrote:

 The vote has been open for 5 days now. Based on the tallies and
 discussions, it sounds like we'd like to merge the dev lists but keep the
 user lists as is. Shall we move forward with combining them now?

 On 10 March 2017 at 12:27, Dominik Psenner  wrote:

> Total agreement.
>
> On 10 Mar 2017 6:26 p.m., "Ralph Goers" 
> wrote:
>
>> This is exactly why we need one dev list. These last two responses
>> dropped the other lists.  This is a horrible way to have discussions that
>> affect all the sub projects.
>>
>> Ralph
>>
>>
>> On Mar 10, 2017, at 9:11 AM, Matt Sicker  wrote:
>>
>> I'd love to see more unified configurations in all the subprojects.
>> Gary mentioned that as an idea for log4cxx as that would make it useful 
>> for
>> his use case where they're using both Java and C++ in various projects.
>>
>> While the programming languages in use here (Java, .NET, PHP, and
>> C++) aren't really compatible with each other, having similar 
>> architectures
>> and plugin systems could help a bit in this regard. Having more inclusive
>> conversations about this would be great.
>>
>> On 10 March 2017 at 04:29, Mikael Ståldal 
>>  wrote:
>>
>>> I think that a vast majority of our users only uses one of the
>>> languages we support, and therefore only are interested in one of the
>>> subprojects.
>>>
>>> On Fri, Mar 10, 2017 at 11:23 AM, Dominik Psenner <
>>> dpsen...@gmail.com> wrote:
>>>
 We had once the discussion that we wanted all Apache Logging
 projects to become very similar in their usage, starting with the same 
 or a
 very similar configuration. Given that we should aim towards one Apache
 Logging specification and several Apache Logging specification
 implementations in the form of Apache Logging subprojects. That means 
 all
 the devs for all subprojects have to talk more. To me this is a good
 reasons to merge the dev mailing lists. Further I don't see why the 
 same
 use case should not apply to the user mailing lists, too. Those mailing
 lists see very low traffic but all of them need a larger audience. Just
 quoting the last few messages of two user mailing lists I follow:

 log4j-user: the last topic came in a week ago, the topic before
 that about two weeks ago
 log4net-user: the last topic came in 24 hours ago and the 

[jira] [Closed] (LOG4J2-1370) Log4j2 cannot get env. variable

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1370.
---
Resolution: Resolved

User reported that a they could not reproduce the issue any more after 
upgrading Windows. 

> Log4j2 cannot get env. variable
> ---
>
> Key: LOG4J2-1370
> URL: https://issues.apache.org/jira/browse/LOG4J2-1370
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.5
>Reporter: Some dude
>Priority: Critical
>
> Please check issue here
> http://stackoverflow.com/questions/36693517/log4j2-cannot-get-env-variable



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931099#comment-15931099
 ] 

ASF subversion and git services commented on LOG4J2-1359:
-

Commit 0854d32523cc2f244a0ed9a927154dadfbf9534e in logging-log4j2's branch 
refs/heads/LOG4J2-1359 from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=0854d32 ]

LOG4J2-1359 - Java 9 support


> Add support for Java 9 StackWalker API in ReflectionUtil
> 
>
> Key: LOG4J2-1359
> URL: https://issues.apache.org/jira/browse/LOG4J2-1359
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
> Environment: Java 1.9+
>Reporter: Matt Sicker
>Assignee: Ralph Goers
>  Labels: jdk9
>
> [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html]
> Based on the functional nature of this API, supporting it may require 
> compiling at least one class using javac 1.9 and reflectively loading it in 
> ReflectionUtil similar to how Spring supports newer JDK APIs.
> Without support for StackWalker, ReflectionUtil will fall back to using a 
> slower API in Java 1.9. This is because the Reflection class is a 
> sun-internal class which are no longer exported to non-JDK code without 
> setting special command line flags.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org