Re: JPAAppender error
Hi JD, This is how I see the workflow: 1. User reports issue, JIRA ticket gets raised. 2. Developer commits solution, marks JIRA ticket as Resolved. 3. User verifies that solution fixes the original problem and marks JIRA ticket as Closed. Variations: Between 1 and 2, developers may ask for clarification, users can attach patches etc. Not all solutions require code changes. Anyone can re-open an issue if the solution is not satisfactory and needs more work. When I look at the list of JIRA tickets, I only look at the Unresolved issues, I filter out the Resolved ones. So better not to mark issues as closed or resolved if you still want developers to do something with this ticket. Hope this helps, Remko From: JD Buys To: Log4J Developers List Sent: Wednesday, August 7, 2013 4:32 PM Subject: Re: JPAAppender error Hi Nick, The JIRA ticket is: https://issues.apache.org/jira/browse/LOG4J2-320 The solution for me as to close the inputstream that was opened when loading the properties in ProviderUtil.java I attached the patch and my changed version to the ticket just in case you want to take a look. Should I close the ticket, or do want to take a look? (Sorry, I am not sure about the workflow process you follow) JD On Fri, Jul 19, 2013 at 2:41 PM, Nick Williams wrote: JD, > > >This is getting too complicated to troubleshoot on the mailing list. Though I >still haven't figured out if it's a bug or a user issue, please file a JIRA >bug at http://issues.apache.org/jira/browse/LOG4J2. In the description, >include all of the stack traces that you have shown and mentioned in here and >describe the problem just as you have described it. Also include the source >code of your entity class (the one that extends BasicLogEventEntity) and your >entire XML configuration. I'm doing to need those two things for sure to >figure out the latest error you mentioned. > > >Thanks, > > >Nick > > >On Jul 19, 2013, at 5:36 AM, JD Buys wrote: > >I found the location which causes the appender to fail, but no solution yet. >> >> >>The problem is on line 72 in the JPADatabaseManager.java --> entity = >>this.entityConstructor.newInstance(event); >>The entity does not have a id, and then I get a >>java.lang.IllegalArgumentException: Object: is not a known entity type >>exception. >> >> >>JD >> >> >> >>On Fri, Jul 19, 2013 at 8:13 AM, JD Buys wrote: >> >>I have included the jars in the classpath, and I also added a >>FastRollingFileAppender, which keeps on working after I redeploy, so it is >>only the JPAAppender that stops working. >>> >>>JD >>> >>> >>> >>>On Fri, Jul 19, 2013 at 12:18 AM, Remko Popma wrote: >>> >>>What is your classpath? Your app dies while trying to load the resource "META-INF/log4j-provider.properties". This resource is in the log4j core jar. Do you have the log4j-core-2.0 jar in the classpath? Remko From: JD Buys To: Log4J Developers List Sent: Thursday, July 18, 2013 11:52 PM Subject: Re: JPAAppender error I wonder if that might be where my problem is. I am using the BasicLogEventEntity, which works like I said until I redeploy then no logging to the JPAAppender occurs. I just said there was no stacktrace, but that was when starting up. When the app is deployed, or the Glassfish server is shut down I do get the following stacktrace: [#|2013-07-18T11:52:34.015+|WARNING|glassfish3.1.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=105;_ThreadName=Thread-2;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace java.lang.Throwable at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.(ASURLClassLoader.java:1230) at com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1338) at java.net.URL.openStream(URL.java:1037) at org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:64) at org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:40) at org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:30) at org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:48) at org.apache.logging.log4j.LogManager.(LogManager.java:48) at com.spacial.service.cron.ActivityProcessorCron.(ActivityProcessorCron.java:19) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccesso
[jira] [Commented] (LOG4J2-336) AsyncLogger.log fail with NullPointerException after double reconfigure
[
https://issues.apache.org/jira/browse/LOG4J2-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733030#comment-13733030
]
Remko Popma commented on LOG4J2-336:
Thanks for finding this.
On reconfiguration, a new Disruptor instance is created, but no new thread pool
is created. The new Disruptor instances references the old thread pool, which
has been shut down (or is in the middle of shutting down), resulting in various
errors. The solution is to create a new thread pool object every time a new
Disruptor instance is created.
> AsyncLogger.log fail with NullPointerException after double reconfigure
> ---
>
> Key: LOG4J2-336
> URL: https://issues.apache.org/jira/browse/LOG4J2-336
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta8
> Environment: LUbuntu 13.04, OpenJDK 7
>Reporter: Andre Bogus
>
> Using reconfigure() to select log files at runtime.
> After the second reconfigure, the next log fails with a NullPointerException
> in {{org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253}}
> It appears that the disruptor has been nulled and not been brought back up by
> the second {{reconfigure()}}.
> Trying to get a minimal test case I came up with the following log4j2.xml:
> {code}
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> The following Java class did NOT bring up the error, instead it threw a
> different exception (stack trace below):
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
> import org.apache.logging.log4j.core.LoggerContext;
> public class Log4jAsyncReconfTest {
> private static final Logger log =
> LogManager.getLogger(Log4jAsyncReconfTest.class);
> public static void main(String[] args) throws InterruptedException {
> System.out.println("test");
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> ctx.reconfigure();
> ctx.reconfigure();
> log.warn("Danger!");
> }
> }
> {code}
>
> throws:
> java.util.concurrent.RejectedExecutionException: Task
> com.lmax.disruptor.BatchEventProcessor@7ea4461e rejected from
> java.util.concurrent.ThreadPoolExecutor@52f79c86[Terminated, pool size = 0,
> active threads = 0, queued tasks = 0, completed tasks = 1]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:628)
> at
> com.lmax.disruptor.dsl.EventProcessorInfo.start(EventProcessorInfo.java:77)
> at com.lmax.disruptor.dsl.Disruptor.start(Disruptor.java:263)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper.initDisruptor(AsyncLoggerConfigHelper.java:119)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-336) AsyncLogger.log fail with NullPointerException after double reconfigure
[
https://issues.apache.org/jira/browse/LOG4J2-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-336:
---
Description:
Using reconfigure() to select log files at runtime.
After the second reconfigure, the next log fails with a NullPointerException in
{{org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253}}
It appears that the disruptor has been nulled and not been brought back up by
the second {{reconfigure()}}.
Trying to get a minimal test case I came up with the following log4j2.xml:
{code}
{code}
The following Java class did NOT bring up the error, instead it threw a
different exception (stack trace below):
{code}
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.core.LoggerContext;
public class Log4jAsyncReconfTest {
private static final Logger log =
LogManager.getLogger(Log4jAsyncReconfTest.class);
public static void main(String[] args) throws InterruptedException {
System.out.println("test");
LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
ctx.reconfigure();
ctx.reconfigure();
log.warn("Danger!");
}
}
{code}
throws:
java.util.concurrent.RejectedExecutionException: Task
com.lmax.disruptor.BatchEventProcessor@7ea4461e rejected from
java.util.concurrent.ThreadPoolExecutor@52f79c86[Terminated, pool size = 0,
active threads = 0, queued tasks = 0, completed tasks = 1]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at
java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:628)
at
com.lmax.disruptor.dsl.EventProcessorInfo.start(EventProcessorInfo.java:77)
at com.lmax.disruptor.dsl.Disruptor.start(Disruptor.java:263)
at
org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper.initDisruptor(AsyncLoggerConfigHelper.java:119)
was:
Using reconfigure() to select log files at runtime.
After the second reconfigure, the next log fails with a NullPointerException in
org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253
It appears that the disruptor has been nulled and not been brought back up by
the second reconfigure().
Trying to get a minimal test case I came up with the following log4j2.xml:
The following Java class did NOT bring up the error, instead it threw a
different exception (stack trace below):
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.core.LoggerContext;
public class Log4jAsyncReconfTest {
private static final Logger log =
LogManager.getLogger(Log4jAsyncReconfTest.class);
public static void main(String[] args) throws InterruptedException
\{
System.out.println("test");
LoggerContext ctx = (LoggerContext)
LogManager.getContext(false);
ctx.reconfigure();
ctx.reconfigure();
log.warn("Danger!");
\}
}
throws:
java.util.concurrent.RejectedExecutionException: Task
com.lmax.disruptor.BatchEventProcessor@7ea4461e rejected from
java.util.concurrent.ThreadPoolExecutor@52f79c86[Terminated, pool size = 0,
active threads = 0, queued tasks = 0, completed tasks = 1]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at
java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:628)
at
com.lmax.disruptor.dsl.EventProcessorInfo.start(EventProcessorInfo.java:77)
at com.lmax.disruptor.dsl.Disruptor.start(Disruptor.java:263)
at
org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper.initDisruptor(AsyncLoggerConfigHelper.java:119)
> AsyncLogger.log fail with NullPointerException after double reconfigure
> ---
>
> Key: LOG4J2-336
> URL: https://issues.apache.org/jira/browse/LOG4J2-336
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta8
> Environment: LUbuntu 13.04, OpenJDK 7
>Reporter: Andre Bogus
>
> Using reconfigure() to select log files at runtime.
> After the second reconfigure, the next log fails with a NullPointerException
> in {{org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253}}
> It appears that the disruptor has been nulled and not been brought back up by
> the second {{re
[jira] [Resolved] (LOG4J2-320) JPAAppender stops logging because META-INF/log4j-provider.properties is left open
[
https://issues.apache.org/jira/browse/LOG4J2-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-320.
-
Resolution: Fixed
Fix Version/s: 2.0-beta9
{noformat}
commit -m "[LOG4J2-320] JPAAppender stops logging because
META-INF/log4j-provider.properties is left open. Refactor loading and closing a
properties stream into a new method PropertiesUtil#loadClose()."
C:/vcs/svn/apache/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/util/ProviderUtil.java
C:/vcs/svn/apache/log4j2/trunk/src/changes/changes.xml
C:/vcs/svn/apache/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java
Sending
C:/vcs/svn/apache/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java
Sending
C:/vcs/svn/apache/log4j2/trunk/api/src/main/java/org/apache/logging/log4j/util/ProviderUtil.java
SendingC:/vcs/svn/apache/log4j2/trunk/src/changes/changes.xml
Transmitting file data ...
Committed revision 1511342.
{noformat}
> JPAAppender stops logging because META-INF/log4j-provider.properties is left
> open
> -
>
> Key: LOG4J2-320
> URL: https://issues.apache.org/jira/browse/LOG4J2-320
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta8
> Environment: EclipseLink, version: Eclipse Persistence Services -
> 2.3.0.v20110604-r9504
> Glassfish 3.1.1
> Mysql 5
>Reporter: jd
>Priority: Trivial
> Fix For: 2.0-beta9
>
> Attachments: JpaLog.java, Log4jSetup.java, patch.diff,
> ProviderUtil.java
>
>
> After the EAR is redeployed the JPAAppender stops logging.
> The exception is: SEVERE: java.lang.IllegalArgumentException: Object:
> com.log4j.JpaLog@1b7d808 is not a known entity type.
> The log4j setup is done in a singleton bean with the Startup annotation
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-320) JPAAppender stops logging because META-INF/log4j-provider.properties is left open
[ https://issues.apache.org/jira/browse/LOG4J2-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-320: Summary: JPAAppender stops logging because META-INF/log4j-provider.properties is left open (was: JPAAppender stops logging) > JPAAppender stops logging because META-INF/log4j-provider.properties is left > open > - > > Key: LOG4J2-320 > URL: https://issues.apache.org/jira/browse/LOG4J2-320 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8 > Environment: EclipseLink, version: Eclipse Persistence Services - > 2.3.0.v20110604-r9504 > Glassfish 3.1.1 > Mysql 5 >Reporter: jd >Priority: Trivial > Attachments: JpaLog.java, Log4jSetup.java, patch.diff, > ProviderUtil.java > > > After the EAR is redeployed the JPAAppender stops logging. > The exception is: SEVERE: java.lang.IllegalArgumentException: Object: > com.log4j.JpaLog@1b7d808 is not a known entity type. > The log4j setup is done in a singleton bean with the Startup annotation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-336) AsyncLogger.log fail with NullPointerException after double reconfigure
Andre Bogus created LOG4J2-336:
--
Summary: AsyncLogger.log fail with NullPointerException after
double reconfigure
Key: LOG4J2-336
URL: https://issues.apache.org/jira/browse/LOG4J2-336
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.0-beta8
Environment: LUbuntu 13.04, OpenJDK 7
Reporter: Andre Bogus
Using reconfigure() to select log files at runtime.
After the second reconfigure, the next log fails with a NullPointerException in
org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253
It appears that the disruptor has been nulled and not been brought back up by
the second reconfigure().
Trying to get a minimal test case I came up with the following log4j2.xml:
The following Java class did NOT bring up the error, instead it threw a
different exception (stack trace below):
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.core.LoggerContext;
public class Log4jAsyncReconfTest {
private static final Logger log =
LogManager.getLogger(Log4jAsyncReconfTest.class);
public static void main(String[] args) throws InterruptedException
\{
System.out.println("test");
LoggerContext ctx = (LoggerContext)
LogManager.getContext(false);
ctx.reconfigure();
ctx.reconfigure();
log.warn("Danger!");
\}
}
throws:
java.util.concurrent.RejectedExecutionException: Task
com.lmax.disruptor.BatchEventProcessor@7ea4461e rejected from
java.util.concurrent.ThreadPoolExecutor@52f79c86[Terminated, pool size = 0,
active threads = 0, queued tasks = 0, completed tasks = 1]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at
java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:628)
at
com.lmax.disruptor.dsl.EventProcessorInfo.start(EventProcessorInfo.java:77)
at com.lmax.disruptor.dsl.Disruptor.start(Disruptor.java:263)
at
org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper.initDisruptor(AsyncLoggerConfigHelper.java:119)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: JPAAppender error
Hi Nick, The JIRA ticket is: https://issues.apache.org/jira/browse/LOG4J2-320 The solution for me as to close the inputstream that was opened when loading the properties in ProviderUtil.java I attached the patch and my changed version to the ticket just in case you want to take a look. Should I close the ticket, or do want to take a look? (Sorry, I am not sure about the workflow process you follow) JD On Fri, Jul 19, 2013 at 2:41 PM, Nick Williams < nicho...@nicholaswilliams.net> wrote: > JD, > > This is getting too complicated to troubleshoot on the mailing list. > Though I still haven't figured out if it's a bug or a user issue, please > file a JIRA bug at http://issues.apache.org/jira/browse/LOG4J2. In the > description, include all of the stack traces that you have shown and > mentioned in here and describe the problem just as you have described it. > Also include the source code of your entity class (the one that extends > BasicLogEventEntity) and your entire XML configuration. I'm doing to need > those two things for sure to figure out the latest error you mentioned. > > Thanks, > > Nick > > On Jul 19, 2013, at 5:36 AM, JD Buys wrote: > > I found the location which causes the appender to fail, but no solution > yet. > > The problem is on line 72 in the JPADatabaseManager.java --> entity = > this.entityConstructor.newInstance(event); > The entity does not have a id, and then I get a > java.lang.IllegalArgumentException: Object: is not a known entity type > exception. > > JD > > > On Fri, Jul 19, 2013 at 8:13 AM, JD Buys wrote: > >> I have included the jars in the classpath, and I also added a >> FastRollingFileAppender, which keeps on working after I redeploy, so it is >> only the JPAAppender that stops working. >> >> JD >> >> >> On Fri, Jul 19, 2013 at 12:18 AM, Remko Popma wrote: >> >>> What is your classpath? >>> >>> Your app dies while trying to load the resource >>> "META-INF/log4j-provider.properties". >>> This resource is in the log4j core jar. Do you have the log4j-core-2.0 >>> jar in the classpath? >>> >>> Remko >>> >>> -- >>> *From:* JD Buys >>> *To:* Log4J Developers List >>> *Sent:* Thursday, July 18, 2013 11:52 PM >>> *Subject:* Re: JPAAppender error >>> >>> I wonder if that might be where my problem is. I am using the >>> BasicLogEventEntity, which works like I said until I redeploy then no >>> logging to the JPAAppender occurs. >>> >>> I just said there was no stacktrace, but that was when starting up. When >>> the app is deployed, or the Glassfish server is shut down I do get the >>> following stacktrace: >>> >>> [#|2013-07-18T11:52:34.015+|WARNING|glassfish3.1.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=105;_ThreadName=Thread-2;|Input >>> stream has been finalized or forced closed without being explicitly closed; >>> stream instantiation reported in following stack trace >>> java.lang.Throwable >>> at >>> com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.(ASURLClassLoader.java:1230) >>> at >>> com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1338) >>> at java.net.URL.openStream(URL.java:1037) >>> at >>> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:64) >>> at >>> org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:40) >>> at >>> org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:30) >>> at >>> org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:48) >>> at >>> org.apache.logging.log4j.LogManager.(LogManager.java:48) >>> at >>> com.spacial.service.cron.ActivityProcessorCron.(ActivityProcessorCron.java:19) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> at >>> java.lang.reflect.Constructor.newInstance(Constructor.java:525) >>> at java.lang.Class.newInstance0(Class.java:374) >>> at java.lang.Class.newInstance(Class.java:327) >>> at >>> com.sun.ejb.containers.BaseContainer.instantiateOptionalEJBLocalBusinessObjectImpl(BaseContainer.java:3861) >>> at >>> com.sun.ejb.containers.AbstractSingletonContainer.initializeHome(AbstractSingletonContainer.java:276) >>> at >>> com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167) >>> at >>> org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230) >>> at >>> org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290) >>> at >>> org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101) >>> at >>> org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:18
[jira] [Updated] (LOG4J2-320) JPAAppender stops logging
[ https://issues.apache.org/jira/browse/LOG4J2-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jd updated LOG4J2-320: -- Attachment: ProviderUtil.java patch.diff > JPAAppender stops logging > - > > Key: LOG4J2-320 > URL: https://issues.apache.org/jira/browse/LOG4J2-320 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8 > Environment: EclipseLink, version: Eclipse Persistence Services - > 2.3.0.v20110604-r9504 > Glassfish 3.1.1 > Mysql 5 >Reporter: jd >Priority: Trivial > Attachments: JpaLog.java, Log4jSetup.java, patch.diff, > ProviderUtil.java > > > After the EAR is redeployed the JPAAppender stops logging. > The exception is: SEVERE: java.lang.IllegalArgumentException: Object: > com.log4j.JpaLog@1b7d808 is not a known entity type. > The log4j setup is done in a singleton bean with the Startup annotation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-320) JPAAppender stops logging
[ https://issues.apache.org/jira/browse/LOG4J2-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731723#comment-13731723 ] jd commented on LOG4J2-320: --- The problem was fixed by closing the stream that was opened when loading the properties in the ProviderUtil.java Attached are two files: The patch (which I am not sure I created correctly) The fixed ProviderUtil.java > JPAAppender stops logging > - > > Key: LOG4J2-320 > URL: https://issues.apache.org/jira/browse/LOG4J2-320 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta8 > Environment: EclipseLink, version: Eclipse Persistence Services - > 2.3.0.v20110604-r9504 > Glassfish 3.1.1 > Mysql 5 >Reporter: jd >Priority: Trivial > Attachments: JpaLog.java, Log4jSetup.java, patch.diff, > ProviderUtil.java > > > After the EAR is redeployed the JPAAppender stops logging. > The exception is: SEVERE: java.lang.IllegalArgumentException: Object: > com.log4j.JpaLog@1b7d808 is not a known entity type. > The log4j setup is done in a singleton bean with the Startup annotation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
