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 <[email protected]>
To: Log4J Developers List <[email protected]> 
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 <[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
>>>>>>JUnit in Action, Second Edition
>>>>>>Spring Batch in Action
>>>>>>Blog: http://garygregory.wordpress.com 
>>>>>>Home: http://garygregory.com/
>>>>>>Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Reply via email to