[JBoss JIRA] (JGRP-1639) Locking: lock name with negative hashCode() throws out of bound exception
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1639?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1639:
---------------------------
Fix Version/s: (was: 3.2.10)
This regression is only in 3.4
> Locking: lock name with negative hashCode() throws out of bound exception
> -------------------------------------------------------------------------
>
> Key: JGRP-1639
> URL: https://issues.jboss.org/browse/JGRP-1639
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> [Steve Luebbe]
> Based on the code in the org.jgroups.protocols.Locking it tries to calculate an index based on the lock name (code in next 2 lines):
> {code}
> protected Lock _getLock(String lock_name) {
> int index=lock_name != null? lock_name.hashCode() % locks.length : 0;
> return locks[index];
> }
> {code}
>
> When debugging I can see that:
> lock_name = dpa_project
> lock_name.hashCode() = -1316662737
> locks.length = 10
> SOLUTION: use Math.abs() on the hash 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
13 years, 1 month
[JBoss JIRA] (JGRP-1639) Locking: lock name with negative hashCode() throws out of bound exception
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1639?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1639.
----------------------------
Resolution: Done
> Locking: lock name with negative hashCode() throws out of bound exception
> -------------------------------------------------------------------------
>
> Key: JGRP-1639
> URL: https://issues.jboss.org/browse/JGRP-1639
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> [Steve Luebbe]
> Based on the code in the org.jgroups.protocols.Locking it tries to calculate an index based on the lock name (code in next 2 lines):
> {code}
> protected Lock _getLock(String lock_name) {
> int index=lock_name != null? lock_name.hashCode() % locks.length : 0;
> return locks[index];
> }
> {code}
>
> When debugging I can see that:
> lock_name = dpa_project
> lock_name.hashCode() = -1316662737
> locks.length = 10
> SOLUTION: use Math.abs() on the hash 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
13 years, 1 month
[JBoss JIRA] (WFLY-1444) CNFE: javax.persistence.Converter
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-1444:
----------------------------------------
Summary: CNFE: javax.persistence.Converter
Key: WFLY-1444
URL: https://issues.jboss.org/browse/WFLY-1444
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 8.0.0.Alpha2
Reporter: Juergen Zimmermann
Assignee: Scott Marlow
I'm using the latest WildFly snapshot containing Hibernate 4.3.0.Beta3. However, I'm getting a CNFE for javax.persistence.Converter (see stacktrace below). This class is definitely contained in modules/system/layers/base/javax/persistence/api/main/hibernate-jpa-2.1-api-1.0.0.Draft-16.jar
Stacktrace:
...
16:45:00,362 INFO [org.hibernate.Version] HHH000412: Hibernate Core {4.3.0.Beta3}
16:45:00,362 INFO [org.hibernate.cfg.Environment] HHH000206: hibernate.properties not found
16:45:00,362 INFO [org.hibernate.cfg.Environment] HHH000021: Bytecode provider name : javassist
16:45:00,658 ERROR [org.hibernate.AssertionFailure] HHH000099: an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session): java.lang.ClassNotFoundException: javax.persistence.Converter from [Module "org.jboss.jandex:main" from local module loader @c84051 (finder: local module finder @f6a711 (roots: C:\Software\wildfly-8.0.0.Alpha2-20130602\modules,C:\Software\wildfly-8.0.0.Alpha2-20130602\modules\system\layers\base))]
16:45:00,658 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.persistenceunit."shop2.war#de.shop.PU": org.jboss.msc.service.StartException in service jboss.persistenceunit."shop2.war#de.shop.PU": org.hibernate.AssertionFailure: The annotation javax.persistence.Converter does not define a parameter 'autoApply'
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:112) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.hibernate.AssertionFailure: The annotation javax.persistence.Converter does not define a parameter 'autoApply'
at org.hibernate.metamodel.source.annotations.JandexHelper.getDefaultValue(JandexHelper.java:328)
at org.hibernate.metamodel.source.annotations.JandexHelper.getValue(JandexHelper.java:111)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.prepareMetadataSources(EntityManagerFactoryBuilderImpl.java:391)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:224)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:186)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:43)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:55)
at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:214) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:59) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:108) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
... 4 more
Caused by: java.lang.ClassNotFoundException: javax.persistence.Converter from [Module "org.jboss.jandex:main" from local module loader @c84051 (finder: local module finder @f6a711 (roots: C:\Software\wildfly-8.0.0.Alpha2-20130602\modules,C:\Software\wildfly-8.0.0.Alpha2-20130602\modules\system\layers\base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.1.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.1.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.1.Final]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.1.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.1.Final]
at org.hibernate.metamodel.source.annotations.JandexHelper.getDefaultValue(JandexHelper.java:320)
... 14 more
--
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
13 years, 1 month
[JBoss JIRA] (JGRP-1639) Locking: lock name with negative hashCode() throws out of bound exception
by Bela Ban (JIRA)
Bela Ban created JGRP-1639:
------------------------------
Summary: Locking: lock name with negative hashCode() throws out of bound exception
Key: JGRP-1639
URL: https://issues.jboss.org/browse/JGRP-1639
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.2.10, 3.4
[Steve Luebbe]
Based on the code in the org.jgroups.protocols.Locking it tries to calculate an index based on the lock name (code in next 2 lines):
{code}
protected Lock _getLock(String lock_name) {
int index=lock_name != null? lock_name.hashCode() % locks.length : 0;
return locks[index];
}
{code}
When debugging I can see that:
lock_name = dpa_project
lock_name.hashCode() = -1316662737
locks.length = 10
SOLUTION: use Math.abs() on the hash 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
13 years, 1 month
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann updated WFLY-1406:
-------------------------------------
Attachment: server.log.zip
I guess there is a bug in the interaction between MSC and Hibernate Commons. I attached server.log.zip with log level set to TRACE for org.jboss.module and org.hibernate.annotations. Perhaps David Lloyd might have also a look.
Look at line 36244:
16:08:08,578 TRACE [org.jboss.modules] Defined class de.shop.kundenverwaltung.domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader
However, when you look at the lines 51385ff: you see "." between the packages, and suddenly a "/" when it comes to package-info
16:08:10,840 TRACE [org.jboss.modules] Loading class org.hibernate.annotations.common.AssertionFailure locally from Module "org.hibernate.commons-annotations:main" from local module loader @c84051 (finder: local module finder @f6a711 (roots: C:\Software\wildfly-8.0.0.Alpha2-20130602\modules,C:\Software\wildfly-8.0.0.Alpha2-20130602\modules\system\layers\base))
16:08:10,840 TRACE [org.jboss.modules] Attempting to define class org.hibernate.annotations.common.AssertionFailure in Module "org.hibernate.commons-annotations:main" from local module loader @c84051 (finder: local module finder @f6a711 (roots: C:\Software\wildfly-8.0.0.Alpha2-20130602\modules,C:\Software\wildfly-8.0.0.Alpha2-20130602\modules\system\layers\base))
16:08:10,840 TRACE [org.jboss.modules] Defined class org.hibernate.annotations.common.AssertionFailure in Module "org.hibernate.commons-annotations:main" from local module loader @c84051 (finder: local module finder @f6a711 (roots: C:\Software\wildfly-8.0.0.Alpha2-20130602\modules,C:\Software\wildfly-8.0.0.Alpha2-20130602\modules\system\layers\base))
16:08:10,840 TRACE [org.jboss.modules] Finding class de/shop/artikelverwaltung/domain.package-info from Module "deployment.shop2.war:main" from Service Module Loader
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Attachments: javap.log, server.log, server.log.zip, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
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
13 years, 1 month
[JBoss JIRA] (JBRULES-3141) Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
by Mark Proctor (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3141?page=com.atlassian.jira.plug... ]
Mark Proctor closed JBRULES-3141.
---------------------------------
Resolution: Rejected
> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
> Key: JBRULES-3141
> URL: https://issues.jboss.org/browse/JBRULES-3141
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brad Davis
> Assignee: Brad Davis
> Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java, IndexAwareQueue.java, SalienceAwareQueue.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation. I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation. Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue. There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was:
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann updated WFLY-1406:
-------------------------------------
Forum Reference: https://community.jboss.org/thread/228926
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Attachments: javap.log, server.log, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
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
13 years, 1 month
[JBoss JIRA] (DROOLS-158) Improve Drools Fusion Documentation of Event expiration mechanism
by Mark Proctor (JIRA)
[ https://issues.jboss.org/browse/DROOLS-158?page=com.atlassian.jira.plugin... ]
Mark Proctor moved JBRULES-3639 to DROOLS-158:
----------------------------------------------
Project: Drools (was: JBRULES)
Key: DROOLS-158 (was: JBRULES-3639)
Issue Type: Task (was: Patch)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: 5.4.0.Final)
Component/s: (was: drools-core (fusion))
(was: drools-compiler (fusion))
> Improve Drools Fusion Documentation of Event expiration mechanism
> -----------------------------------------------------------------
>
> Key: DROOLS-158
> URL: https://issues.jboss.org/browse/DROOLS-158
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Environment: Eclipse 3.7 SR2, Jboss Tools, Drools 5.4.0.Final, Win XP. Attaching Eclipse project
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: Screenshot-2012-09-27_18.25.40.png, SimpleCEP2 (very simple demo).zip
>
>
> h4. Executive Summary
> This is to kindly request, if you can please improve the Drools Fusion documentation to explain more specifically about “Automatic Event Lifecycle Management”, and the basis how Event expiration actually works. Possibly by means of simple examples, or blueprints detailing CEP best implementation patterns specifically for Fusion, could greatly benefit.
> Thank you, I love RedHat and the JBoss Community :) but trying to understand completely Fusion’s Event expiration is making me crazy :P
> h4. Rationale
> The documentation in [par. “2.5.2. Stream Mode”| http://docs.jboss.org/drools/release/5.4.0.Final/drools-fusion-docs/html_...] is imho vague in the second requirement, specifically the generic statement “the use of non-time-synchronized streams may result in some unexpected results”. Especially it seems to me not only streams must be time-synchronized, but +also streams and the session clock must be strictly in-sync?+
> Take for instance the attached Eclipse project, to replicate one un-expected behavior - I’m specifically not raising this JIRA as a bug, because of the aforementioned “vagueness” in the doc, I don’t have specific evidence this is strictly a bug.
> (!) The assumption in this application: Events are inserted with a lag if compared to the session clock to simulate a communication lag and slight delay. However, all Events are inserted in strict chronological order. The issue here is: *because Events, despite in chronological order, are inserted slightly late if compared to the session clock, some unexpected behavior of the After LHS operator occurs*
> There is a simple rule that checks for two Event of type Message to happen within 1minute delay.
> {code:title=Sample.drl|borderStyle=solid}
> declare Message
> @role(event)
> @timestamp (timestamp)
> end
> rule "asd"
> when
> $m1 : Message()
> $m2 : Message(this after[0, 1m] $m1, this != $m1)
> then
> System.out.println("x");
> end
> {code}
> Events are being inserted in strict chronological order. A first Event of type Message is inserted. Pseudo clock is advanced rapidly. Then a second Event of type Message is inserted having timestamp {{\+1}} second to the previous one.
> In the Audit log, also attached, you will see the very first Event, matched as {{$m1}}, get expired and retracted immediately after the rule has fired. This is OK: now the very first Event can no longer match in this rule, and because is the only rule available, gets expired and retracted. As you would expect from the documentation. Happily.
> This analogously repeats in the application and reflected in the audit log.
> !Screenshot-2012-09-27_18.25.40.png|align=center!
> Now skip to the *last* Event of type Message inserted. The consequence of this last Event being inserted is that the rule had fired again; analogously, this is the only Event of type Message remaining in the working memory. Happily.
> As the pseudo clock gets advanced rapidly, now no more Events are inserted. When the pseudo clock reaches {{\+60}} seconds from the +session time+ when this last Event was inserted, the Event is retracted. This is the issue and the unexpected behavior. I have NOT specified {{window:time(1m)}} in my rule, but seems to behaving like that. Shouldn’t the engine wait for a very next Event *of any type* to be inserted into the working memory, to evaluate the current stream timestamp and therefore infer this Event can now safely be expired and retracted?
> The rule, by the way it’s written, would check to see if two Events of type Message are available within a 1minute of timespan. While instead, seems to me by the unexpected results, this also implicitly stating {{window:time(1m)}} being the Max of the parameters for the time constraint operators available in the rule.
> If you can explain better the Event expiration mechanism and improve the Documentation, it would greatly help to understand for instance why this scenario behaves in this (from my perspective) unexpected behavior.
> I seize the chance to thank you once again, Ciao
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1186) Create JPA service callback for invoking database migration
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1186?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-1186:
------------------------------------
Anil, in your environment, does the database account associated with the application deployment, have permissions to create tables in the database? It sounds like the http://flywaydb.org solution only requires a deployment time callback into application deployment code. But, if the database account associated with the application, doesn't have "create resource" permissions, all bets are off.
> Create JPA service callback for invoking database migration
> -----------------------------------------------------------
>
> Key: WFLY-1186
> URL: https://issues.jboss.org/browse/WFLY-1186
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Anil Arora
> Assignee: Scott Marlow
>
> Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
> Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit.
> Essentially, this would solve the lack of migration support in Hibernate itself.
--
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
13 years, 1 month