[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
10 years, 11 months
[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
10 years, 11 months
[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
10 years, 11 months
[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
10 years, 11 months
[JBoss JIRA] (WFLY-1442) Web console branding across community and product versions
by Harald Pehl (JIRA)
Harald Pehl created WFLY-1442:
---------------------------------
Summary: Web console branding across community and product versions
Key: WFLY-1442
URL: https://issues.jboss.org/browse/WFLY-1442
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Reporter: Harald Pehl
Assignee: Harald Pehl
Define a way to specify the branding for the web console across different community and product versions. The name and version used for the branding should be read from the {{product-name}} and {{product-version}} attributes of the root DMR resource. Regarding the logo there are different options:
# Use a unique logo for the web console across all community and products / versions
# Choose between a community (WildFly) and a product logo (RedHat)
# Hold up all logos for any community / product version in the HAL release stream and choose dynamically.
--
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
10 years, 11 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-1406:
------------------------------------
If there is a bug, I'm not yet sure where it is. You could try posting to the Hibernate or WildFly forums to follow up with a wider audience.
> 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
10 years, 11 months
[JBoss JIRA] (WFLY-843) Cannot restart webapp bundle after activation failure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-843?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-843:
----------------------------------------------
Horia Chiorean <hchiorea(a)redhat.com> made a comment on [bug 959426|https://bugzilla.redhat.com/show_bug.cgi?id=959426]
Even though the web app itself isn't packaged as an OSGI bundle, one of its libs:
chemistry-opencmis-server-jcr-0.9.0-beta-1-classes.jar is.
However, I don't know if that's enough to qualify the entire web app as an OSGI bundle. Also, the jar which provides the implementation of the endpoints, isn't an OSGI bundle.
> Cannot restart webapp bundle after activation failure
> -----------------------------------------------------
>
> Key: WFLY-843
> URL: https://issues.jboss.org/browse/WFLY-843
> Project: WildFly
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> {code}
> Caused by: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.setup(CachedConnectionManagerSetupProcessor.java:74)
> at org.jboss.as.web.ThreadSetupBindingListener.bind(ThreadSetupBindingListener.java:50)
> at org.apache.catalina.core.StandardContext.bindThread(StandardContext.java:4234)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3740)
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102)
> {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
10 years, 11 months