[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2426 at 11/5/13 8:29 AM:
-------------------------------------------------------------
I think we had a discussion about this (regarding EAP) with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
was (Author: ozizka):
I think we have a discussion about this (regarding EAP) with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2391:
--------------------------------------
I have just been waiting for an XNIO release to get this in. Hopefully that will happen today.
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2426 at 11/5/13 8:24 AM:
-------------------------------------------------------------
I think we have a discussion about this (regarding EAP) with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
was (Author: ozizka):
I think we have a discussion about this with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1675:
-----------------------------------
[~dan.berindei]: This is the original description of this bug :) CREDIT_REQUEST is not marked as OOB by purpose (there's even a comment about that when the message is created) - the sender (which sends the credit request) should be blocked and NOT send any more messages until the previous ones get processed. The C_REQ shouldn't be needed at all because receiver should keep the credit amount on the sender side and as it approaches the threshold, send him the credit replenishment (and this is OOB).
As you speak about deadlock: the question is why the messages are not eventually retransmitted so that the request is processed - retransmissions are not blocked by FlowControl.
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
I think we have a discussion about this with Paul Gier, and the problem was with the fact that one never knows what will end up as a product, so the information is added when it pops out of Brew/Mead. Bringing Paul's attention.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFLY-2391:
------------------------------------------
We definitely need to schedule a fix before final goes out.
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis updated WFLY-2391:
-------------------------------------
Priority: Critical (was: Major)
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2341:
-----------------------------------
Verified that this is fixed in b114
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-2341
> URL: https://issues.jboss.org/browse/WFLY-2341
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Denis Kostousov
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> ... 8 more
> {code}
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2386) Hibernate envers related issues on JDK8
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2386?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2386:
-----------------------------------
Just tested and can verify that this is fixed in b114
> Hibernate envers related issues on JDK8
> ---------------------------------------
>
> Key: WFLY-2386
> URL: https://issues.jboss.org/browse/WFLY-2386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Environment: latest JDK8 build
> Reporter: Tomaz Cerar
> Assignee: Scott Marlow
>
> There are many hibernate / envers related tests that fail when running Testsuite on JDK8
> {noformat}
> [31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {noformat}
> for details see:
> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_Master...
--
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
11 years, 2 months