[jira] [Resolved] (LOGCXX-519) Version11 - "INSTALL.TXT" and "vstudio.apt" miss explenation for generating the log4cxx.dll
[ https://issues.apache.org/jira/browse/LOGCXX-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Middleton resolved LOGCXX-519. - Fix Version/s: 0.13.0 Resolution: Fixed > Version11 - "INSTALL.TXT" and "vstudio.apt" miss explenation for generating > the log4cxx.dll > --- > > Key: LOGCXX-519 > URL: https://issues.apache.org/jira/browse/LOGCXX-519 > Project: Log4cxx > Issue Type: Bug > Components: Build, Documentation >Affects Versions: 0.11.0 > Environment: IDE: Microsoft Visual Studio Professional 2019 Version > 16.8.4 > C++ Language Standard: Default (ISO C++14 Standard) >Reporter: Brayan Khosravian >Priority: Blocker > Fix For: 0.13.0 > > Attachments: image-2021-02-16-14-40-30-658.png > > > Hello! > *Introduktion:* > After downloading the > [apache-log4cxx-0.11.0.zip|https://downloads.apache.org/logging/log4cxx/0.11.0/apache-log4cxx-0.11.0.zip] > I realized that the files "INSTALL.txt" and "vsstudio.apt" do not guide > users to build the "log4cxx.dll" using Visual Studio. > *Tooling:* > IDE: Microsoft Visual Studio Professional 2019 Version 16.8.4 > C++ Language Standard: Default (ISO C++14 Standard) > *Explaining the Issue:* > The "INSTALL.txt" which is located in the root directory redirects me to the > file "src/site/apt/building/vstudio.apt". > *1.)* In the chapter +"*Preparation"+ the components > "apr-1.2.11-win32-src.zip" and "apr-util-1.2.10-win32-src.zip" are mentioned. > There are already newer versions available. What are the newer versions used > for or is the "vstudio.apt" just outdated? > *2.)* We should execute the "configure-aprutil.bat" after the "configure.bat" > but there is no "configure-aprutil.bat" in the folder. > *3.)* In the chapter "*Building log4cxx.dll" we should open > "projects/log4cxx.dsw" with Visual Studio. The issue is, that there is not > "projects" folder in this > [apache-log4cxx-0.11.0.zip|https://downloads.apache.org/logging/log4cxx/0.11.0/apache-log4cxx-0.11.0.zip] > . > *4.)* However, I picked the "projects" folder from Version 10 and tried to > open the "projects/log4cxx.dsw" but as a result the "xml" project can not be > loaded. > !image-2021-02-16-14-40-30-658.png! > > Creating a dll of this library should be more user friendly and straight > forward. > I hope my feedback helps to improve the library, its usability and > documentation. > Sincerely > Brayan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOGCXX-551) CMake documented build option for Boost vs C++17 Implementation for shared_mutex
[
https://issues.apache.org/jira/browse/LOGCXX-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Middleton resolved LOGCXX-551.
-
Resolution: Fixed
> CMake documented build option for Boost vs C++17 Implementation for
> shared_mutex
>
>
> Key: LOGCXX-551
> URL: https://issues.apache.org/jira/browse/LOGCXX-551
> Project: Log4cxx
> Issue Type: Wish
> Components: Build, Documentation
>Affects Versions: 0.12.1
>Reporter: Nicholas Clark
>Assignee: Robert Middleton
>Priority: Minor
> Fix For: 0.13.0
>
>
> There was a recent approach to detecting if boost' implementation is needed,
> but I feel that it is not succinct and cannot be when it comes to linker
> issues. Referencing PR:
> [https://github.com/apache/logging-log4cxx/pull/107.|https://github.com/apache/logging-log4cxx/pull/107]
> I have large applications that use shared_mutex, but require boost'
> implementation as not all components linked are able to use C+\+17
> implementation at this time. A problem occurs during linkage when log4cxx is
> built using C+\+17's implementation but our other component is built using
> boost' implementation.
>
> *Workaround:*
> We currently can force cmake into using Boost' implementation by passing:
> {code:java}
> -DSTD_SHARED_MUTEX_FOUND=0{code}
> This isn't a documented 'feature'. I would like a documented approach to
> this. If -DSTD_SHARED_MUTEX_FOUND=0 is what we should use for this feature
> request, then it should be documented as such. I am putting forth this issue
> as current usage is not documented as supported and thus I suspect it may be
> lost in future commits.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4cxx] rm5248 merged pull request #109: Switch around how searching for boost works and add documentation
rm5248 merged PR #109: URL: https://github.com/apache/logging-log4cxx/pull/109 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a diff in pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
ppkarwasz commented on code in PR #804:
URL: https://github.com/apache/logging-log4j2/pull/804#discussion_r850737474
##
log4j-api-java9/src/test/java/org/apache/logging/log4j/util/java9/ServiceLoaderUtilTest.java:
##
@@ -0,0 +1,77 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.util.java9;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.fail;
+
+import java.lang.invoke.MethodHandles;
+import java.util.Collections;
+import java.util.List;
+import java.util.ServiceConfigurationError;
+import java.util.stream.Collectors;
+
+import org.apache.logging.log4j.util.PropertySource;
+import org.apache.logging.log4j.util.ServiceLoaderUtil;
+import org.apache.logging.log4j.util.java9.test.BetterService;
+import org.apache.logging.log4j.util.java9.test.Service;
+import org.junit.jupiter.api.Test;
+
+public class ServiceLoaderUtilTest {
+
+@Test
+public void testServiceResolution() {
+// Run only if we are a module
+if (ServiceLoaderUtil.class.getModule().isNamed()) {
Review Comment:
My mistake, Surefire is running the tests as [POJO
tests](https://maven.apache.org/surefire/maven-surefire-plugin/examples/pojo-test.html).
Since these also use the `JUnit3Provider`, I thought that JUnit 3 was
involved. It isn't.
However these tests are not run by JUnit 5, which wasn't even supported in
version 2.13.
I found a way around Surefire's limitation in [PR
#822](https://github.com/apache/logging-log4j2/pull/822) and I'll apply your
suggestions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request, #822: Fix `log4j-api` Java 9 tests
ppkarwasz opened a new pull request, #822: URL: https://github.com/apache/logging-log4j2/pull/822 Due to [SUREFIRE-2073](https://issues.apache.org/jira/browse/SUREFIRE-2073), the tests in `log4j-api-java9` are executed on the classpath instead of the modulepath. This can be fixed by compiling the tests themselves using Java 8, to work around Surefire's limitation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522527#comment-17522527
]
Remko Popma commented on LOG4J2-3476:
-
Sounds like we have consensus. :-)
Are we okay with merging https://github.com/apache/logging-log4j2/pull/821 then?
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] remkop commented on a diff in pull request #821: LOG4J2-3476 ignore JUL ApiLogger.setLevel without error
remkop commented on code in PR #821:
URL: https://github.com/apache/logging-log4j2/pull/821#discussion_r850772206
##
log4j-jul/src/main/java/org/apache/logging/log4j/jul/ApiLogger.java:
##
@@ -91,7 +92,8 @@ public String getName() {
@Override
public void setLevel(final Level newLevel) throws SecurityException {
-throw new UnsupportedOperationException("Cannot set level through
log4j-api");
+StatusLogger.getLogger().error("Cannot set JUL log level through
log4j-api: " +
+"ignoring call to Logger.setLevel(" + newLevel + ")");
Review Comment:
@ppkarwasz Thank you for the suggestion. Done.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a diff in pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
ppkarwasz commented on code in PR #804:
URL: https://github.com/apache/logging-log4j2/pull/804#discussion_r850737474
##
log4j-api-java9/src/test/java/org/apache/logging/log4j/util/java9/ServiceLoaderUtilTest.java:
##
@@ -0,0 +1,77 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.util.java9;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.fail;
+
+import java.lang.invoke.MethodHandles;
+import java.util.Collections;
+import java.util.List;
+import java.util.ServiceConfigurationError;
+import java.util.stream.Collectors;
+
+import org.apache.logging.log4j.util.PropertySource;
+import org.apache.logging.log4j.util.ServiceLoaderUtil;
+import org.apache.logging.log4j.util.java9.test.BetterService;
+import org.apache.logging.log4j.util.java9.test.Service;
+import org.junit.jupiter.api.Test;
+
+public class ServiceLoaderUtilTest {
+
+@Test
+public void testServiceResolution() {
+// Run only if we are a module
+if (ServiceLoaderUtil.class.getModule().isNamed()) {
Review Comment:
My mistake, Surefire is running the tests as [POJO
tests](https://maven.apache.org/surefire/maven-surefire-plugin/examples/pojo-test.html).
Since these also use the `JUnit3Provider`, I thought that JUnit 3 was
involved. It isn't.
However these tests are not run by JUnit 5, which wasn't even supported in
version 2.13. I'll try some hacks (like compiling the tests using Java 8 and
`module-info.java` using Java 9) and maybe it will work on the latest Surefire
release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522499#comment-17522499
]
Ralph Goers commented on LOG4J2-3476:
-
This is where you start to cross the line between API and implementation in my
opinion. It was bad enough when we added shutdown, but manipulating the logging
configuration is an implementation feature IMO.
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522494#comment-17522494
]
Carter Kozak commented on LOG4J2-3476:
--
I agree with the api/implementation separation and would prefer not to add
level/configuration-mutation features to the api logger. In fact, I consider it
a feature that JUL backed by log4j cannot override my configuration
unexpectedly, although I can understand why it is desirable and wouldn't be
opposed to supporting it :-)
It sounds reasonable that the CoreLogger could support level updates, while the
ApiLogger would not (if log4j-core is not available, some other facade like
slf4j may not support level updates)
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] jvz commented on a diff in pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
jvz commented on code in PR #804:
URL: https://github.com/apache/logging-log4j2/pull/804#discussion_r850710356
##
log4j-api-java9/src/test/java/org/apache/logging/log4j/util/java9/ServiceLoaderUtilTest.java:
##
@@ -0,0 +1,77 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.util.java9;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.fail;
+
+import java.lang.invoke.MethodHandles;
+import java.util.Collections;
+import java.util.List;
+import java.util.ServiceConfigurationError;
+import java.util.stream.Collectors;
+
+import org.apache.logging.log4j.util.PropertySource;
+import org.apache.logging.log4j.util.ServiceLoaderUtil;
+import org.apache.logging.log4j.util.java9.test.BetterService;
+import org.apache.logging.log4j.util.java9.test.Service;
+import org.junit.jupiter.api.Test;
+
+public class ServiceLoaderUtilTest {
+
+@Test
+public void testServiceResolution() {
+// Run only if we are a module
+if (ServiceLoaderUtil.class.getModule().isNamed()) {
Review Comment:
Huh, oh well. If this is running via JUnit 3, shouldn't the test extend
TestCase or something like that?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3472) Allow configuration of custom Disruptor WaitStrategy
[
https://issues.apache.org/jira/browse/LOG4J2-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522488#comment-17522488
]
Matt Sicker commented on LOG4J2-3472:
-
Depending on how immediately you need this feature, I've been considering
porting the DI system in 3.x to 2.x (for 2.18.0 at the current state). Without
using DI, though, I'd probably lean toward option 1 as similar to how I made
the particular BlockingQueue class to use in an async appender configurable.
The factories should be easy to migrate to DI as well which is nice.
> Allow configuration of custom Disruptor WaitStrategy
>
>
> Key: LOG4J2-3472
> URL: https://issues.apache.org/jira/browse/LOG4J2-3472
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Core
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> See also LOG4J2-2858.
> Currently Log4j allows a fixed set of disruptor WaitStrategies to be
> configured. The current code has two drawbacks:
> * the fixed set does not include all built-in WaitStrategies that the
> disruptor library provides
> * the configuration does not allow custom implementations of the
> {{com.lmax.disruptor.WaitStrategy}} interface.
> h4. Proposal:
> Introduce a {{org.apache.logging.log4j.core.async.WaitStrategyProvider}}
> interface. Users may configure instances of this interface by setting system
> property {{log4j2.asyncWaitStrategyProvider}}.
> Proposed implementation is to modify {{DisruptorUtil::createWaitStrategy}} to
> check for the existence of this system property, before doing anything else.
> If this property exists and a class can be instantiated based on the value of
> this property, and the resulting WaitStrategyProvider instance provides a
> non-null {{com.lmax.disruptor.WaitStrategy}} instance, then this waitstrategy
> is returned from {{DisruptorUtil::createWaitStrategy}}. Otherwise, we fall
> back to the existing logic.
> Note that for simplicity I do not propose to have separate system properties
> for Async Loggers and Async LoggerConfigs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522486#comment-17522486
]
Matt Sicker commented on LOG4J2-3476:
-
That's a feature people request in SLF4J, too, which is always rejected as not
an API level concern. I sort of agree with that, though plenty of Log4j users
expect some basic configuration settings to be controllable via the API. I had
initially implemented ApiLogger for scenarios where log4j-core isn't the
provider being used (e.g., when using Logback or JUL) and no other extension of
that ApiLogger class is available (in theory, you could add other variants of
ApiLogger).
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
[ https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522337#comment-17522337 ] Swapnil Markhedkar commented on LOG4J2-3463: [~pkarwasz] Thank you for your detailed reply, I will wait until it's stable. > java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: > Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype > --- > > Key: LOG4J2-3463 > URL: https://issues.apache.org/jira/browse/LOG4J2-3463 > Project: Log4j 2 > Issue Type: Bug > Components: API, Core, Log4j 1.2 bridge, Web/Servlet >Affects Versions: 2.17.3 > Environment: Configuration: > Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api, > log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration > across applications running on tomcat. >Reporter: Swapnil Markhedkar >Priority: Blocker > Attachments: Provider error.txt > > > Came across this error while using tomcat at application level. Similar to > https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even > when added 2.10 jars. > In depth stack trace has been attached as text file. > NOTE: Tomcat server and it's logging is working fine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a diff in pull request #821: LOG4J2-3476 ignore JUL ApiLogger.setLevel without error
ppkarwasz commented on code in PR #821:
URL: https://github.com/apache/logging-log4j2/pull/821#discussion_r850388680
##
log4j-jul/src/main/java/org/apache/logging/log4j/jul/ApiLogger.java:
##
@@ -91,7 +92,8 @@ public String getName() {
@Override
public void setLevel(final Level newLevel) throws SecurityException {
-throw new UnsupportedOperationException("Cannot set level through
log4j-api");
+StatusLogger.getLogger().error("Cannot set JUL log level through
log4j-api: " +
+"ignoring call to Logger.setLevel(" + newLevel + ")");
Review Comment:
I would suggest a parameterized message, instead of string joining.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522249#comment-17522249
]
Gary D. Gregory commented on LOG4J2-3476:
-
Ah, right. So the next question is why not add a level setting method to
log4j-api. This is one feature that all the apps I have worked on and up using.
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522240#comment-17522240
]
Remko Popma commented on LOG4J2-3476:
-
Gary, that was my original idea also.
But then I saw we have two implementations: ApiLogger and CoreLogger.
CoreLogger is implemented using log4j-core features, while ApiLogger can only
use log4j-api features.
So, I don't think we can use log4j-core features like Configurator in ApiLogger.
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522238#comment-17522238
]
Gary D. Gregory commented on LOG4J2-3476:
-
Since log4j-jul already has an optional dependency on log4j-core, why not
actually implement the API using our Configurator class?
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1759#comment-1759
]
Remko Popma commented on LOG4J2-3476:
-
Great, thank you for the feedback!
I created https://github.com/apache/logging-log4j2/pull/821 for this.
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] remkop opened a new pull request, #821: LOG4J2-3476 ignore JUL ApiLogger.setLevel without error
remkop opened a new pull request, #821: URL: https://github.com/apache/logging-log4j2/pull/821 This PR implements the change discussed in https://issues.apache.org/jira/browse/LOG4J2-3476: When JUL ApiLogger.setLevel is called, do not throw an UnsupportedOperationException, but instead log an error in the status logger. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3472) Allow configuration of custom Disruptor WaitStrategy
[
https://issues.apache.org/jira/browse/LOG4J2-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522196#comment-17522196
]
Remko Popma commented on LOG4J2-3472:
-
I have been thinking about how to make this work as a configuration plugin.
(And one restriction is that I prefer to avoid DI features that are only
available in 3.x, because I am hoping to include this in a 2.x release.)
What makes this tricky is that the Disruptor provides multiple WaitStrategy
implementations, some with default constructors, some with constructors that
take arguments of various types. Custom WaitStrategy implementations will
likely also have constructors requiring some arguments, and we don't know what
types those arguments will be.
So, what would a configuration look like?
h3. Idea 1: Users configure a factory
The simplest thing to implement (but not very pretty) that I can think of is
where users configure a factory.
The specified factory class name must have a public no-argument constructor.
During configuration Log4j will instantiate the factory and ask the factory to
create a WaitStrategy object.
looks something like this:
{code:java}
...
{code}
...where the specified class name implements a new
{{org.apache.logging.log4j.core.async.AsyncWaitStrategyFactory}} interface:
{code:java}
public interface AsyncWaitStrategyFactory {
/**
* Returns a non-null implementation of the LMAX Disruptor's WaitStrategy
interface.
* This wait strategy will be used by Async Loggers and Async LoggerConfigs.
*
* @return the WaitStrategy instance to be used by Async Loggers and Async
LoggerConfigs
*/
WaitStrategy createWaitStrategy();
}
{code}
h3. Idea 2: Users configure a WaitStrategy
Alternatively, without the factory idea, we can try to allow users to configure
the WaitStrategy directly.
I imagine a configuration could then look like something like this:
{code:xml}
...
{code}
Question:
Are the existing plugin facilities available in 2.x able to handle this? I
don't think we have anything this generic.
I could be wrong but perhaps the closest thing would be something like the
below, where we create separate plugins for a limited number of supported types:
{code:xml}
...
{code}
This last one is technically feasible but limited to the supported types.
The drawback of this approach is that users may not be able to configure their
custom WaitStrategy if it requires constructor arguments for which there is no
plugin types. (Unless they are committed enough to become familiar with the
Log4j 2 plugin system and create their own plugin - quite a steep hurdle, since
[our plugin docs|https://logging.apache.org/log4j/2.x/manual/plugins.html] are
very high level...)
So perhaps option 1 is the most flexible and straightforward.
Thoughts?
> Allow configuration of custom Disruptor WaitStrategy
>
>
> Key: LOG4J2-3472
> URL: https://issues.apache.org/jira/browse/LOG4J2-3472
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Core
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> See also LOG4J2-2858.
> Currently Log4j allows a fixed set of disruptor WaitStrategies to be
> configured. The current code has two drawbacks:
> * the fixed set does not include all built-in WaitStrategies that the
> disruptor library provides
> * the configuration does not allow custom implementations of the
> {{com.lmax.disruptor.WaitStrategy}} interface.
> h4. Proposal:
> Introduce a {{org.apache.logging.log4j.core.async.WaitStrategyProvider}}
> interface. Users may configure instances of this interface by setting system
> property {{log4j2.asyncWaitStrategyProvider}}.
> Proposed implementation is to modify {{DisruptorUtil::createWaitStrategy}} to
> check for the existence of this system property, before doing anything else.
> If this property exists and a class can be instantiated based on the value of
> this property, and the resulting WaitStrategyProvider instance provides a
> non-null {{com.lmax.disruptor.WaitStrategy}} instance, then this waitstrategy
> is returned from {{DisruptorUtil::createWaitStrategy}}. Otherwise, we fall
> back to the existing logic.
> Note that for simplicity I do not propose to have separate system properties
> for Async Loggers and Async LoggerConfigs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a diff in pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
ppkarwasz commented on code in PR #804:
URL: https://github.com/apache/logging-log4j2/pull/804#discussion_r850133905
##
log4j-api-java9/src/test/java/org/apache/logging/log4j/util/java9/ServiceLoaderUtilTest.java:
##
@@ -0,0 +1,77 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.util.java9;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.fail;
+
+import java.lang.invoke.MethodHandles;
+import java.util.Collections;
+import java.util.List;
+import java.util.ServiceConfigurationError;
+import java.util.stream.Collectors;
+
+import org.apache.logging.log4j.util.PropertySource;
+import org.apache.logging.log4j.util.ServiceLoaderUtil;
+import org.apache.logging.log4j.util.java9.test.BetterService;
+import org.apache.logging.log4j.util.java9.test.Service;
+import org.junit.jupiter.api.Test;
+
+public class ServiceLoaderUtilTest {
+
+@Test
+public void testServiceResolution() {
+// Run only if we are a module
+if (ServiceLoaderUtil.class.getModule().isNamed()) {
Review Comment:
I am afraid I will have to leave it for now, since the module runs tests
using Surefire 2.13 and JUnit 3. Upgrading the Surefire plugin is impossible
due to [SUREFIRE-2073](https://issues.apache.org/jira/browse/SUREFIRE-2073).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a diff in pull request #804: [LOG4J2-3427] Replace ServiceLoader calls with ServiceLoaderUtil
ppkarwasz commented on code in PR #804:
URL: https://github.com/apache/logging-log4j2/pull/804#discussion_r850132543
##
log4j-api/src/main/java/org/apache/logging/log4j/util/OsgiServiceLocator.java:
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.util;
+
+import java.lang.invoke.MethodHandles.Lookup;
+import java.util.Arrays;
+import java.util.stream.Stream;
+
+import org.apache.logging.log4j.status.StatusLogger;
+import org.osgi.framework.Bundle;
+import org.osgi.framework.BundleContext;
+import org.osgi.framework.FrameworkUtil;
+import org.osgi.framework.ServiceReference;
+
+public class OsgiServiceLocator {
+
+private static final boolean OSGI_AVAILABLE = checkOsgiAvailable();
+
+private static boolean checkOsgiAvailable() {
+try {
+Class.forName("org.osgi.framework.Bundle");
+return true;
+} catch (final ClassNotFoundException | LinkageError e) {
+return false;
+} catch (final Throwable e) {
+LowLevelLogUtil.logException("Unknown error checking for existence
of class: org.osgi.framework.Bundle", e);
+return false;
+}
+}
+
+public static boolean isAvailable() {
+return OSGI_AVAILABLE;
+}
+
+public static Stream loadServices(final Class serviceType, final
Lookup lookup) {
+return loadServices(serviceType, lookup, true);
+}
+
+public static Stream loadServices(final Class serviceType, final
Lookup lookup, final boolean verbose) {
+final Bundle bundle = FrameworkUtil.getBundle(lookup.lookupClass());
+if (bundle != null) {
+final BundleContext ctx = bundle.getBundleContext();
+try {
+@SuppressWarnings("unchecked")
+final ServiceReference[] serviceRefs =
(ServiceReference[]) ctx
+.getAllServiceReferences(serviceType.getName(), null);
Review Comment:
Oh, somehow I missed that, probably because the new method is not called
`getAllServiceReferences`. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
