I will give it a try tomorrow morning when I am back at work and let you
know the result.


On Thu, Jul 18, 2013 at 9:41 PM, Nick Williams <
[email protected]> wrote:

> Okay. Can you configure an additional, simple appender (like a file
> appender or similar) so that every event that gets logged goes to BOTH
> appenders?
>
> Then, run your scenario again (works--redeploy--doesn't work). What I'm
> looking for is if it's JUST the JPAAppender that quits working or if it's
> ALL appenders that quit working.
>
> Nick
>
> On Jul 18, 2013, at 2:37 PM, JD Buys wrote:
>
> Yes it is the only appender I have configured and it's added to the root
> logger
>
>
> On Thu, Jul 18, 2013 at 9:35 PM, Nick Williams <
> [email protected]> wrote:
>
>> Is the JPAAppender the only appender you have configured?
>>
>> Nick
>>
>> On Jul 18, 2013, at 2:32 PM, JD Buys wrote:
>>
>> Yep that about sums it up.
>> The rest of the application runs 100%.
>>
>>
>> On Thu, Jul 18, 2013 at 4:58 PM, Nick Williams <
>> [email protected]> wrote:
>>
>>>
>>> On Jul 18, 2013, at 9:52 AM, JD Buys wrote:
>>>
>>> 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.
>>>
>>>
>>> That's interesting. I'm very surprised that it works...
>>>
>>> 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 stack trace:
>>>
>>>
>>> So it runs for a while, logs messages to your database just fine and as
>>> you expect it to, but when you redeploy the application you get the
>>> exception below and the appender no longer logs events to the database?
>>> Does the rest of your application run? Normally I'd say if Log4j were
>>> encountering errors you should see them logged to the console / stdout.
>>> However, based on the stack trace it looks like Log4j can't even open the
>>> StatusLogger (the internal logger that we use to log errors and messages
>>> internal to Log4j).
>>>
>>> *scratches head*
>>>
>>>
>>> [#|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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Reply via email to