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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> *To:* Log4J Developers List <[email protected]> >>> *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+0000|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.<init>(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.<clinit>(ProviderUtil.java:64) >>> at >>> org.apache.logging.log4j.util.PropertiesUtil.<init>(PropertiesUtil.java:40) >>> at >>> org.apache.logging.log4j.util.PropertiesUtil.<clinit>(PropertiesUtil.java:30) >>> at >>> org.apache.logging.log4j.status.StatusLogger.<clinit>(StatusLogger.java:48) >>> at >>> org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:48) >>> at >>> com.spacial.service.cron.ActivityProcessorCron.<clinit>(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:186) >>> at >>> org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257) >>> at >>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) >>> at >>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) >>> at >>> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244) >>> at >>> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232) >>> at >>> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:459) >>> at >>> com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209) >>> at >>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) >>> at >>> com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) >>> at >>> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238) >>> at >>> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) >>> at >>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) >>> at >>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019) >>> at >>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) >>> at >>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) >>> at >>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) >>> at >>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) >>> at >>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) >>> at >>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) >>> at >>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) >>> at com.sun.grizzly.ContextTask.run(ContextTask.java:71) >>> at >>> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) >>> at >>> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) >>> at java.lang.Thread.run(Thread.java:722) >>> >>> >>> >>> On Thu, Jul 18, 2013 at 4:35 PM, Nick Williams < >>> [email protected]> wrote: >>> >>> JD, >>> >>> I look forward to the additional information you provide. In the >>> meantime, just a bit of info that I'm planning on putting in the >>> documentation because it was left out: >>> >>> The JPAAppender was written for JPA 2.1 (minimum EclipseLink 2.5.0 or >>> Hibernate ORM 4.3.0), but strives to have backwards compatibility with JPA >>> 2.0 (minimum EclipseLink 2.0.0 or Hibernate 3.6.0). As such, there are >>> certain JPAAppender features that you can use if you have JPA 2.1 that make >>> it easier to use. If you only have JPA 2.0 (which it appears is the case >>> for you), you have to do things "the hard way." >>> >>> There are two abstract entities classes for the JPAAppender, and you >>> should extend exactly one of them if you are using the >>> JPAAppender. >>> org.apache.logging.log4j.core.appender.db.jpa.AbstractLogEventWrapperEntity >>> works with either 2.0 or 2.1 and requires you to provide an ID property and >>> manually specify all of the getter methods and map them appropriately. If >>> you are using JPA 2.1, you can use the AttributeConverters >>> in org.apache.logging.log4j.core.appender.db.jpa.converter to help you >>> convert certain event properties to database columns. If you are not using >>> JPA 2.1, you must provide other mechanisms to convert the values. >>> >>> If you are using JPA 2.1 (and only then) you can >>> extend org.apache.logging.log4j.core.appender.db.jpa.BasicLogEventEntity. >>> Using this, all you have to do is create a database table to match the >>> mappings and provide an ID property. This abstract entity uses new JPA 2.1 >>> features that allow it to instruct the JPA provider how to convert the >>> values. >>> >>> This may or may not help you. Hopefully we'll know more once you provide >>> error messages, etc. >>> >>> Nick >>> >>> On Jul 18, 2013, at 8:58 AM, Gary Gregory wrote: >>> >>> JD, >>> >>> Thank you for the info, we look forward to your further details. At this >>> point, you can put it all in a new JIRA: >>> https://issues.apache.org/jira/browse/LOG4J2 >>> >>> Gary >>> >>> >>> On Thu, Jul 18, 2013 at 9:34 AM, JD Buys <[email protected]> wrote: >>> >>> Yes, sorry, after I sent the email I realized it was very vague. >>> >>> I am using log4j2 beta8 with eclipselink 2.3.0 on mysql. >>> >>> The project is a ear module with which contains a war and ejb module, >>> and I am configuring log4j via code. >>> I will try and create a unit test or small program. >>> >>> If the server starts up, with the ear deployed, logging to the db works, >>> but then when I deploy the ear again the logging to the db stops without >>> any exceptions. >>> My configuration is done inside a singleton ejb with the @StartUp >>> annotation. >>> >>> JD >>> >>> >>> On Thu, Jul 18, 2013 at 3:09 PM, Gary Gregory <[email protected]>wrote: >>> >>> Your report is too vague, can you be more precise please? >>> >>> Which version of log4j2? What does your config look like? What does >>> not work exactly? Can you create a unit test or small program to >>> reproduce the issue? Which JPA provider? Which JDBC driver? Please >>> provide any information another person would need to reproduce the >>> issue you see in the most minimal manner. >>> >>> Gary >>> >>> On Jul 18, 2013, at 9:05, JD Buys <[email protected]> wrote: >>> >>> > Hi, >>> > >>> > I have a strange error where if I deploy my application again, the JPA >>> appender stops working. >>> > Any ideas why? >>> > >>> > I am running Glassfish 3.1.1 >>> > >>> > JD Buys >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second >>> Edition<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> >>> >>> >> > >
