Re: Using BasicContextSelector in OSGI application

2018-09-28 Thread Ralph Goers 
Despite what I said below, it seems that the patch for LOG4J2-920 was applied 
over 2 years ago so this should not be happening with 2.11.1.

Ralph

> On Sep 28, 2018, at 10:34 AM, Ralph Goers  wrote:
> 
> It sounds related to LOG4J2-920 but the solution provided there has to be 
> incorrect. There is no way the Log4j API should be declaring any requirements 
> on Log4j Core stuff, especially since the Log4j API doesn’t have a clue what 
> a ContextSelector is. That is only use by the Log4jContextFactory. I suspect 
> the problem is that LoaderUtil resides in log4j-api and since it is actually 
> doing the loading it is causing the problem. That means we are either doing 
> the loading wrong or there is something broken in OSGi.
> 
> Ralph
> 
>> On Sep 28, 2018, at 10:20 AM, Rob Gansevles  wrote:
>> 
>> Yes, that makes sense, but it seems they are still loaded by the log4j-api.
>> I guess this is the reason there are a few optional import-package
>> declarations in the manifest-generation in the pom for log4j-api:
>> 
>> 
>>   org.apache.felix
>>   maven-bundle-plugin
>>   
>> 
>>   org.apache.logging.log4j.*
>>   
>> sun.reflect;resolution:=optional,
>> org.apache.logging.log4j.core.osgi;resolution:=optional,
>> org.apache.logging.log4j.core.util;resolution:=optional,
>> org.apache.logging.log4j.core.async;resolution:=optional,
>> *
>>   
>> 
>> org.apache.logging.log4j.util.Activator
>>   <_fixupmessages>"Classes found in the wrong
>> directory";is:=warning
>> 
>>   
>> 
>> 
>> I get the error below when I use the BasicContextSelector, and when I add
>> org.apache.logging.log4j.core.selector to the imports in the manifest it
>> works.
>> 
>> Maybe it is the same issue as discussed in LOG4J2-920 but then
>> for BundleContextSelector and should a similar patch being applied.
>> What do you think?
>> 
>> ERROR StatusLogger Unable to create custom ContextSelector. Falling back to
>> default.
>> java.lang.ClassNotFoundException:
>> org.apache.logging.log4j.core.selector.BasicContextSelector cannot be found
>> by org.apache.logging.log4j.api_2.11.2.SNAPSHOT
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
>> at
>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
>> at
>> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:264)
>> at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168)
>> at
>> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207)
>> at
>> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228)
>> at
>> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253)
>> at
>> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98)
>> at
>> org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:59)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at java.lang.Class.newInstance(Class.java:442)
>> at org.apache.logging.log4j.LogManager.(LogManager.java:94)
>> at
>> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>> at
>> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49)
>> at
>> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>> at
>> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355)
>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380)
>> at com.servoy.j2db.server.main.Activator.(Activator.java:44)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at java.lang.Class.newInstance(Class.java:442)
>> at
>> org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763)
>> at
>> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716)
>> at
>> org.eclipse.osgi

Re: Using BasicContextSelector in OSGI application

2018-09-28 Thread Ralph Goers 
It sounds related to LOG4J2-920 but the solution provided there has to be 
incorrect. There is no way the Log4j API should be declaring any requirements 
on Log4j Core stuff, especially since the Log4j API doesn’t have a clue what a 
ContextSelector is. That is only use by the Log4jContextFactory. I suspect the 
problem is that LoaderUtil resides in log4j-api and since it is actually doing 
the loading it is causing the problem. That means we are either doing the 
loading wrong or there is something broken in OSGi.

Ralph

> On Sep 28, 2018, at 10:20 AM, Rob Gansevles  wrote:
> 
> Yes, that makes sense, but it seems they are still loaded by the log4j-api.
> I guess this is the reason there are a few optional import-package
> declarations in the manifest-generation in the pom for log4j-api:
> 
>  
>org.apache.felix
>maven-bundle-plugin
>
>  
>org.apache.logging.log4j.*
>
>  sun.reflect;resolution:=optional,
>  org.apache.logging.log4j.core.osgi;resolution:=optional,
>  org.apache.logging.log4j.core.util;resolution:=optional,
>  org.apache.logging.log4j.core.async;resolution:=optional,
>  *
>
> 
> org.apache.logging.log4j.util.Activator
><_fixupmessages>"Classes found in the wrong
> directory";is:=warning
>  
>
>  
> 
> I get the error below when I use the BasicContextSelector, and when I add
> org.apache.logging.log4j.core.selector to the imports in the manifest it
> works.
> 
> Maybe it is the same issue as discussed in LOG4J2-920 but then
> for BundleContextSelector and should a similar patch being applied.
> What do you think?
> 
> ERROR StatusLogger Unable to create custom ContextSelector. Falling back to
> default.
> java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.selector.BasicContextSelector cannot be found
> by org.apache.logging.log4j.api_2.11.2.SNAPSHOT
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at
> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168)
> at
> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207)
> at
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228)
> at
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:59)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.apache.logging.log4j.LogManager.(LogManager.java:94)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380)
> at com.servoy.j2db.server.main.Activator.(Activator.java:44)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763)
> at
> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716)
> at
> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at
> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:4

Re: Using BasicContextSelector in OSGI application

2018-09-28 Thread Rob Gansevles 
Yes, that makes sense, but it seems they are still loaded by the log4j-api.
I guess this is the reason there are a few optional import-package
declarations in the manifest-generation in the pom for log4j-api:

  
org.apache.felix
maven-bundle-plugin

  
org.apache.logging.log4j.*

  sun.reflect;resolution:=optional,
  org.apache.logging.log4j.core.osgi;resolution:=optional,
  org.apache.logging.log4j.core.util;resolution:=optional,
  org.apache.logging.log4j.core.async;resolution:=optional,
  *


org.apache.logging.log4j.util.Activator
<_fixupmessages>"Classes found in the wrong
directory";is:=warning
  

  

I get the error below when I use the BasicContextSelector, and when I add
org.apache.logging.log4j.core.selector to the imports in the manifest it
works.

Maybe it is the same issue as discussed in LOG4J2-920 but then
for BundleContextSelector and should a similar patch being applied.
What do you think?

ERROR StatusLogger Unable to create custom ContextSelector. Falling back to
default.
 java.lang.ClassNotFoundException:
org.apache.logging.log4j.core.selector.BasicContextSelector cannot be found
by org.apache.logging.log4j.api_2.11.2.SNAPSHOT
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
at
org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168)
at
org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:207)
at
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:228)
at
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:253)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:98)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:59)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.apache.logging.log4j.LogManager.(LogManager.java:94)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:49)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:355)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:380)
at com.servoy.j2db.server.main.Activator.(Activator.java:44)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.loadBundleActivator(BundleContextImpl.java:763)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:716)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
at
org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
at
org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
at
org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
at
org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
at
org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:466)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
at
org.eclips

RV: Flush in RollingRandomAccessFile

2018-09-28 Thread Joan Balagueró - ventusproxy 
Hi Ralph,

I think that adding 
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
 to make all loggers asynchronous has solved this problem.

Thanks,

Joan.

-Mensaje original-
De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Enviado el: viernes, 28 de septiembre de 2018 18:41
Para: Log4J Users List
Asunto: Re: Flush in RollingRandomAccessFile

1. The relevant appenders are listed below? If so, they are stopping correctly. 
Are they asynchronous? Can you provide the log4j2.xml?
2. I think the failure to shutdown the thread has been reported. It wouldn’t be 
causing your problem though.

Ralph

> On Sep 28, 2018, at 9:17 AM, Joan Balagueró - ventusproxy 
>  wrote:
> 
> Hi Ralph,
> 
> Below  the trace when tomcat is stopped:
> 
> 28-Sep-2018 18:14:36.251 INFORMACIÓN [main] 
> org.apache.catalina.core.StandardServer.await Se ha recibido un comando de 
> apagado a través del puerto de apagado. Parando la instancia del Servidor.
> 28-Sep-2018 18:14:36.252 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
> ["http-nio-80"]
> 28-Sep-2018 18:14:36.302 INFORMACIÓN [main] 
> org.apache.catalina.core.StandardService.stopInternal Parando servicio 
> [Catalina]
> 2018-09-28 18:14:36,974 localhost-startStop-2 DEBUG Stopping 
> LoggerContext[name=3e73c8d6, 
> org.apache.logging.log4j.core.LoggerContext@64df2b5a]...
> 2018-09-28 18:14:36,976 localhost-startStop-2 DEBUG Appender 
> CLUSTER_LOG stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender 
> SYSTEM_LOG stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender 
> MONITOR_LOG stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ERROR_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender 
> ACCESS_LOG stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Log4j2 
> ConfigurationScheduler shutting down threads in 
> java.util.concurrent.ScheduledThreadPoolExecutor@7b51e3ab[Running,
> pool size = 5, active threads = 0, queued tasks = 5, completed tasks = 
> 0]
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Stopped 
> XmlConfiguration[location=/home/ventusproxy/app/ROOT/WEB-INF/log4j.xml
> ] OK
> 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Stopped 
> LoggerContext[name=3e73c8d6, 
> org.apache.logging.log4j.core.LoggerContext@64df2b5a] with status true
> 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Log4jServletFilter 
> destroyed.
> 2018-09-28 18:14:36,979 localhost-startStop-2 DEBUG 
> Log4jServletContextListener ensuring that Log4j shuts down properly.
> 28-Sep-2018 18:14:36.984 ADVERTENCIA [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [ROOT] appears to have started a thread named 
> [Log4j2-TF-7-Scheduled-6] but has fail ed to stop it. This is very likely to 
> create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
> awaitNanos(AbstractQueuedSynchronizer.java:2078)
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take
> (ScheduledThreadPoolExecutor.java:1093)
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take
> (ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.jav
> a:1074)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1134)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:624)
> java.lang.Thread.run(Thread.java:748)
> 28-Sep-2018 18:14:37.025 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler 
> ["http-nio-80"]
> 28-Sep-2018 18:14:37.055 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
> ["http-nio-80"]
> 
> Thanks,
> 
> Joan.
> 
> -Mensaje original-
> De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Enviado el: viernes, 28 de septiembre de 2018 18:00
> Para: Log4J Users List
> Asunto: Re: Flush in RollingRandomAccessFile
> 
> That all sounds correct to me. I would suggest you add status=“DEBUG” to the 
> configuration element in your log4j2.xml and see what happens during shutdown.
> 
> Ralph
> 
>> On Sep 28, 2018, at 8:57 AM, Joan Balagueró - ventusproxy 
>>  wrote:
>> 
>> Hello,
>> 
>> The jars we have in our app are: log4j-1.2-api-2.11.1.jar, 
>> log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar.
>> 
>> Are the right jars, or may I add something else?
>> 
>> Thanks,
>> 
>> Joan.
>> 
>> -Mensaje original-
>> De: Joan Balagueró - ventusproxy
>> [mailto:joan.balagu...@ventusproxy.com]
>> Enviado el: jueves, 27 de septiembre de 2018 18:20
>> Para: 'Log4J Users List'
>> Asunto: RE

Re: Flush in RollingRandomAccessFile

2018-09-28 Thread Ralph Goers 
1. The relevant appenders are listed below? If so, they are stopping correctly. 
Are they asynchronous? Can you provide the log4j2.xml?
2. I think the failure to shutdown the thread has been reported. It wouldn’t be 
causing your problem though.

Ralph

> On Sep 28, 2018, at 9:17 AM, Joan Balagueró - ventusproxy 
>  wrote:
> 
> Hi Ralph,
> 
> Below  the trace when tomcat is stopped:
> 
> 28-Sep-2018 18:14:36.251 INFORMACIÓN [main] 
> org.apache.catalina.core.StandardServer.await Se ha recibido un comando de 
> apagado a través del puerto de apagado. Parando la instancia del Servidor.
> 28-Sep-2018 18:14:36.252 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
> ["http-nio-80"]
> 28-Sep-2018 18:14:36.302 INFORMACIÓN [main] 
> org.apache.catalina.core.StandardService.stopInternal Parando servicio 
> [Catalina]
> 2018-09-28 18:14:36,974 localhost-startStop-2 DEBUG Stopping 
> LoggerContext[name=3e73c8d6, 
> org.apache.logging.log4j.core.LoggerContext@64df2b5a]...
> 2018-09-28 18:14:36,976 localhost-startStop-2 DEBUG Appender CLUSTER_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender SYSTEM_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender MONITOR_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ERROR_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ACCESS_LOG 
> stopped with status true
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Log4j2 
> ConfigurationScheduler shutting down threads in 
> java.util.concurrent.ScheduledThreadPoolExecutor@7b51e3ab[Running, pool size 
> = 5, active threads = 0, queued tasks = 5, completed
> tasks = 0]
> 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Stopped 
> XmlConfiguration[location=/home/ventusproxy/app/ROOT/WEB-INF/log4j.xml] OK
> 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Stopped 
> LoggerContext[name=3e73c8d6, 
> org.apache.logging.log4j.core.LoggerContext@64df2b5a] with status true
> 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Log4jServletFilter 
> destroyed.
> 2018-09-28 18:14:36,979 localhost-startStop-2 DEBUG 
> Log4jServletContextListener ensuring that Log4j shuts down properly.
> 28-Sep-2018 18:14:36.984 ADVERTENCIA [localhost-startStop-2] 
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
> web application [ROOT] appears to have started a thread named 
> [Log4j2-TF-7-Scheduled-6] but has fail
> ed to stop it. This is very likely to create a memory leak. Stack trace of 
> thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> 28-Sep-2018 18:14:37.025 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler 
> ["http-nio-80"]
> 28-Sep-2018 18:14:37.055 INFORMACIÓN [main] 
> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
> ["http-nio-80"]
> 
> Thanks,
> 
> Joan.
> 
> -Mensaje original-
> De: Ralph Goers [mailto:ralph.go...@dslextreme.com] 
> Enviado el: viernes, 28 de septiembre de 2018 18:00
> Para: Log4J Users List
> Asunto: Re: Flush in RollingRandomAccessFile
> 
> That all sounds correct to me. I would suggest you add status=“DEBUG” to the 
> configuration element in your log4j2.xml and see what happens during shutdown.
> 
> Ralph
> 
>> On Sep 28, 2018, at 8:57 AM, Joan Balagueró - ventusproxy 
>>  wrote:
>> 
>> Hello,
>> 
>> The jars we have in our app are: log4j-1.2-api-2.11.1.jar, 
>> log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar.
>> 
>> Are the right jars, or may I add something else?
>> 
>> Thanks,
>> 
>> Joan.
>> 
>> -Mensaje original-
>> De: Joan Balagueró - ventusproxy 
>> [mailto:joan.balagu...@ventusproxy.com]
>> Enviado el: jueves, 27 de septiembre de 2018 18:20
>> Para: 'Log4J Users List'
>> Asunto: RE: Flush in RollingRandomAccessFile
>> 
>> It seems my web.xml is ok. It's a servlet 3.1 with tomcat 8.5.32. I only 
>> have this context parameter, necessary for a correct log4j startup:
>> 
>> http://xmlns.jcp.org/xml/ns/javaee";
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
>> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1

RE: Flush in RollingRandomAccessFile

2018-09-28 Thread Joan Balagueró - ventusproxy 
Hi Ralph,

Below  the trace when tomcat is stopped:

28-Sep-2018 18:14:36.251 INFORMACIÓN [main] 
org.apache.catalina.core.StandardServer.await Se ha recibido un comando de 
apagado a través del puerto de apagado. Parando la instancia del Servidor.
28-Sep-2018 18:14:36.252 INFORMACIÓN [main] 
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-80"]
28-Sep-2018 18:14:36.302 INFORMACIÓN [main] 
org.apache.catalina.core.StandardService.stopInternal Parando servicio 
[Catalina]
2018-09-28 18:14:36,974 localhost-startStop-2 DEBUG Stopping 
LoggerContext[name=3e73c8d6, 
org.apache.logging.log4j.core.LoggerContext@64df2b5a]...
2018-09-28 18:14:36,976 localhost-startStop-2 DEBUG Appender CLUSTER_LOG 
stopped with status true
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender SYSTEM_LOG stopped 
with status true
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender MONITOR_LOG 
stopped with status true
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ERROR_LOG stopped 
with status true
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ACCESS_LOG stopped 
with status true
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Log4j2 
ConfigurationScheduler shutting down threads in 
java.util.concurrent.ScheduledThreadPoolExecutor@7b51e3ab[Running, pool size = 
5, active threads = 0, queued tasks = 5, completed
tasks = 0]
2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Stopped 
XmlConfiguration[location=/home/ventusproxy/app/ROOT/WEB-INF/log4j.xml] OK
2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Stopped 
LoggerContext[name=3e73c8d6, 
org.apache.logging.log4j.core.LoggerContext@64df2b5a] with status true
2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Log4jServletFilter 
destroyed.
2018-09-28 18:14:36,979 localhost-startStop-2 DEBUG Log4jServletContextListener 
ensuring that Log4j shuts down properly.
28-Sep-2018 18:14:36.984 ADVERTENCIA [localhost-startStop-2] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [ROOT] appears to have started a thread named 
[Log4j2-TF-7-Scheduled-6] but has fail
ed to stop it. This is very likely to create a memory leak. Stack trace of 
thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 java.lang.Thread.run(Thread.java:748)
28-Sep-2018 18:14:37.025 INFORMACIÓN [main] 
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-80"]
28-Sep-2018 18:14:37.055 INFORMACIÓN [main] 
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
["http-nio-80"]

Thanks,

Joan.

-Mensaje original-
De: Ralph Goers [mailto:ralph.go...@dslextreme.com] 
Enviado el: viernes, 28 de septiembre de 2018 18:00
Para: Log4J Users List
Asunto: Re: Flush in RollingRandomAccessFile

That all sounds correct to me. I would suggest you add status=“DEBUG” to the 
configuration element in your log4j2.xml and see what happens during shutdown.

Ralph

> On Sep 28, 2018, at 8:57 AM, Joan Balagueró - ventusproxy 
>  wrote:
> 
> Hello,
> 
> The jars we have in our app are: log4j-1.2-api-2.11.1.jar, 
> log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar.
> 
> Are the right jars, or may I add something else?
> 
> Thanks,
> 
> Joan.
> 
> -Mensaje original-
> De: Joan Balagueró - ventusproxy 
> [mailto:joan.balagu...@ventusproxy.com]
> Enviado el: jueves, 27 de septiembre de 2018 18:20
> Para: 'Log4J Users List'
> Asunto: RE: Flush in RollingRandomAccessFile
> 
> It seems my web.xml is ok. It's a servlet 3.1 with tomcat 8.5.32. I only have 
> this context parameter, necessary for a correct log4j startup:
> 
> http://xmlns.jcp.org/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd";
> version="3.1">
> 
>  ventusproxy
>  ventusproxy
> 
>  
>isLog4jContextSelectorNamed
>true  
> 
>  
>log4jContextName
>ventusproxy
>  
> 
> ( ... )
> 
> Joan.
> 
> 
> -Mensaje original-
> De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Enviado el: jueves, 27 de septiembre de 2018 18:05
> Para: Log4J Users List
> Asunto: Re: Flush in RollingRandomAccessFile
> 
> That depends on what servlet version you are using. Take a look at 
> ht

Re: Using BasicContextSelector in OSGI application

2018-09-28 Thread Ralph Goers 
All ContextSelectors are part of log4j-core, not log4j-api.

Ralph

> On Sep 28, 2018, at 7:59 AM, Rob Gansevles  wrote:
> 
> Hi,
> 
> I would like to use the BasicContextSelector in our OSGI application so
> have a single global log4j connfiguration as described in
> http://logging.apache.org/log4j/2.x/manual/logsep.html
> 
> However, BasicContextSelector lives in
> package org.apache.logging.log4j.core.selector which does not seem to be
> usable from log4j-api.
> 
> This package is not imported in the manifest of log4j-api like other
> packages (for example org.apache.logging.log4j.core.async).
> 
> Is this missing, or am I missing something?
> 
> I am using log4j 2.11.1
> 
> Regards,
> 
> Rob



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

Re: Flush in RollingRandomAccessFile

2018-09-28 Thread Ralph Goers 
That all sounds correct to me. I would suggest you add status=“DEBUG” to the 
configuration element in your log4j2.xml and see what happens during shutdown.

Ralph

> On Sep 28, 2018, at 8:57 AM, Joan Balagueró - ventusproxy 
>  wrote:
> 
> Hello,
> 
> The jars we have in our app are: log4j-1.2-api-2.11.1.jar, 
> log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar.
> 
> Are the right jars, or may I add something else?
> 
> Thanks,
> 
> Joan.
> 
> -Mensaje original-
> De: Joan Balagueró - ventusproxy [mailto:joan.balagu...@ventusproxy.com] 
> Enviado el: jueves, 27 de septiembre de 2018 18:20
> Para: 'Log4J Users List'
> Asunto: RE: Flush in RollingRandomAccessFile
> 
> It seems my web.xml is ok. It's a servlet 3.1 with tomcat 8.5.32. I only have 
> this context parameter, necessary for a correct log4j startup:
> 
> http://xmlns.jcp.org/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd";
> version="3.1"> 
> 
>  ventusproxy
>  ventusproxy
> 
>  
>isLog4jContextSelectorNamed
>true
>  
> 
>  
>log4jContextName
>ventusproxy
>  
> 
> ( ... )
> 
> Joan.
> 
> 
> -Mensaje original-
> De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Enviado el: jueves, 27 de septiembre de 2018 18:05
> Para: Log4J Users List
> Asunto: Re: Flush in RollingRandomAccessFile
> 
> That depends on what servlet version you are using. Take a look at 
> http://logging.apache.org/log4j/2.x/manual/webapp.html 
> .
> 
> Ralph
> 
>> On Sep 27, 2018, at 9:02 AM, Joan Balagueró - ventusproxy 
>>  wrote:
>> 
>> Hi Ralph,
>> 
>> After adding the log4j-web-2.11.1.jar to our app, it doesn't work yet.
>> 
>> Do I need to add something to the web.xml file, or some environment variable?
>> 
>> Thanks,
>> 
>> Joan.
>> 
>> -Mensaje original-
>> De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
>> Enviado el: jueves, 27 de septiembre de 2018 17:33
>> Para: Log4J Users List
>> Asunto: Re: Flush in RollingRandomAccessFile
>> 
>> Are you using the log4j-web jar?  It is supposed to handle this.
>> 
>> Ralph
>> 
>>> On Sep 27, 2018, at 8:14 AM, Joan Balagueró - ventusproxy 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> After sending thousands of requests to our app, we stop the sender 
>>> and the log file appears like below:
>>> 
>>> 
>>> 
>>> 1,54.38.179.175,2018-09-27
>>> 16:55:51.618,A,13,A,39,A,72,A,120,N,,54.38.179.182:8080,g,8457,403,68
>>> 3
>>> ,58,ok
>>> ,2018-09-27 16:55:51.677
>>> 
>>> 1,54.38.179.17
>>> 
>>> 
>>> 
>>> Now we stop tomcat (when our app is running). And it seems the queue 
>>> of pending events is not flushed, so the log remains like above. Our 
>>> log configuration is:
>>> 
>>> 
>>> 
>>> >> fileName="${sys:log.dir}vproxy_access"
>>> filePattern="${sys:log.dir}vproxy_access.%d{-MM-dd}" append="true"
>>> immediateFlush="false">
>>> 
>>> 
>>> 
>>> Pattern>%m%d{-MM-dd HH:mm:ss.SSS}%n
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >> />
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >> additivity="false">
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Can we tell log4j2 to flush these pending lines when we shutdown our app?
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> Joan.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 



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

RE: Flush in RollingRandomAccessFile

2018-09-28 Thread Joan Balagueró - ventusproxy 
Hello,

The jars we have in our app are: log4j-1.2-api-2.11.1.jar, 
log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar.

Are the right jars, or may I add something else?

Thanks,

Joan.

-Mensaje original-
De: Joan Balagueró - ventusproxy [mailto:joan.balagu...@ventusproxy.com] 
Enviado el: jueves, 27 de septiembre de 2018 18:20
Para: 'Log4J Users List'
Asunto: RE: Flush in RollingRandomAccessFile

It seems my web.xml is ok. It's a servlet 3.1 with tomcat 8.5.32. I only have 
this context parameter, necessary for a correct log4j startup:

http://xmlns.jcp.org/xml/ns/javaee";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd";
 version="3.1"> 
  
  ventusproxy
  ventusproxy

  
isLog4jContextSelectorNamed
true
  

  
log4jContextName
ventusproxy
  

( ... )

Joan.


-Mensaje original-
De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Enviado el: jueves, 27 de septiembre de 2018 18:05
Para: Log4J Users List
Asunto: Re: Flush in RollingRandomAccessFile

That depends on what servlet version you are using. Take a look at 
http://logging.apache.org/log4j/2.x/manual/webapp.html 
.

Ralph

> On Sep 27, 2018, at 9:02 AM, Joan Balagueró - ventusproxy 
>  wrote:
> 
> Hi Ralph,
> 
> After adding the log4j-web-2.11.1.jar to our app, it doesn't work yet.
> 
> Do I need to add something to the web.xml file, or some environment variable?
> 
> Thanks,
> 
> Joan.
> 
> -Mensaje original-
> De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Enviado el: jueves, 27 de septiembre de 2018 17:33
> Para: Log4J Users List
> Asunto: Re: Flush in RollingRandomAccessFile
> 
> Are you using the log4j-web jar?  It is supposed to handle this.
> 
> Ralph
> 
>> On Sep 27, 2018, at 8:14 AM, Joan Balagueró - ventusproxy 
>>  wrote:
>> 
>> Hello,
>> 
>> 
>> 
>> After sending thousands of requests to our app, we stop the sender 
>> and the log file appears like below:
>> 
>> 
>> 
>> 1,54.38.179.175,2018-09-27
>> 16:55:51.618,A,13,A,39,A,72,A,120,N,,54.38.179.182:8080,g,8457,403,68
>> 3
>> ,58,ok
>> ,2018-09-27 16:55:51.677
>> 
>> 1,54.38.179.17
>> 
>> 
>> 
>> Now we stop tomcat (when our app is running). And it seems the queue 
>> of pending events is not flushed, so the log remains like above. Our 
>> log configuration is:
>> 
>> 
>> 
>> > fileName="${sys:log.dir}vproxy_access"
>> filePattern="${sys:log.dir}vproxy_access.%d{-MM-dd}" append="true"
>> immediateFlush="false">
>> 
>> 
>> 
>> Pattern>%m%d{-MM-dd HH:mm:ss.SSS}%n
>> 
>> 
>> 
>> 
>> 
>> > />
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > additivity="false">
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Can we tell log4j2 to flush these pending lines when we shutdown our app?
>> 
>> 
>> 
>> Thanks,
>> 
>> Joan.
>> 
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 



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




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

Using BasicContextSelector in OSGI application

2018-09-28 Thread Rob Gansevles 
Hi,

I would like to use the BasicContextSelector in our OSGI application so
have a single global log4j connfiguration as described in
http://logging.apache.org/log4j/2.x/manual/logsep.html

However, BasicContextSelector lives in
package org.apache.logging.log4j.core.selector which does not seem to be
usable from log4j-api.

This package is not imported in the manifest of log4j-api like other
packages (for example org.apache.logging.log4j.core.async).

Is this missing, or am I missing something?

I am using log4j 2.11.1

Regards,

Rob