[JBoss JIRA] (WFLY-4470) Duplicate message deliveries when start an MDB twice via CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4470?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4470:
-----------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1159572|https://bugzilla.redhat.com/show_bug.cgi?id=1159572] from ASSIGNED to POST
> Duplicate message deliveries when start an MDB twice via CLI
> -------------------------------------------------------------
>
> Key: WFLY-4470
> URL: https://issues.jboss.org/browse/WFLY-4470
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 9.0.0.Beta2
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 9.0.0.CR1
>
>
> Description of problem:
> A singleton MDB delivers duplicate messages when start-delivery() is invoked twice while the message being delivered
> Steps to Reproduce:
> 1. Create a producer, which keeps sending messages for every second
> 2. Deploy a singleton consumer MDB
> 3. Invoke start-delivery() method on the MDB while the messages being delivered
> Actual results:
> MDB delivers duplicate messages
> Expected results:
> MDB needs to ignore start-delivery() call if the MDB has already been started.
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4419) Dependency on a deployed CDI module - beans are not injected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4419?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4419:
--------------------------------------
I just tried this out by modifying a test from the test suite and it appeared to work fine. Can you attach a reproducer?
> Dependency on a deployed CDI module - beans are not injected
> ------------------------------------------------------------
>
> Key: WFLY-4419
> URL: https://issues.jboss.org/browse/WFLY-4419
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Dirk Buchhorn
> Assignee: Stuart Douglas
>
> I want to deploy two modules to wildfly 8.2.0 The module-a contains beans (and later CDI producer and other stuff) and module-b use this beans. Beans from module-a should be injected with CDI in module-b (There is a beans.xml in both modules.). All works fine if the module-a is direct referenced as dependency like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" meta-inf="import" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
>
> But the dependency to module-a should be without to know the deployed version, so I tried to set a module alias and (or) to re-export module-a under a different name like this.
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <module-alias name="deployment.module-a-alias" />
> </deployment>
> </jboss-deployment-structure>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <module name="deployment.module-a">
> <module-alias name="deployment.module-a-alias" />
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" export="true" meta-inf="export" />
> </dependencies>
> </module>
> </jboss-deployment-structure>
>
> But either the module alias or a re-export under a new module name worked. The reported exception is always:
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type XYZ with qualifiers @Default
>
> The module alias fit my requirements and I guess is should work with CDI but it dosn't.
> Two questions:
> - Why CDI don't work with module alias and module re-export?
> - How to deal with dependencies and module versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-4338:
-------------------------------------
The linked PR reverts the change for https://issues.jboss.org/browse/WFLY-3829. We should find a way to accommodate both issues.
> JConsole script builds wrong path
> ---------------------------------
>
> Key: WFLY-4338
> URL: https://issues.jboss.org/browse/WFLY-4338
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.2.0.Final
> Environment: Linux (Ubuntu 14.10) and Mac OS X Yosemite (10.10.2)
> Reporter: André Lemos
> Assignee: Kabir Khan
> Priority: Trivial
> Labels: bash, jconsole, wildfly
> Attachments: jconsole.patch
>
>
> The path built by the jconsole.sh script is incorrect, and as a result, when calling {{service:jmx:http-remoting-jmx://{insert server ip here}:9990}} is probably never recognized and the connection is never done.
> The path, under mac is:
> {{/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/jconsole -J-Djava.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/tools.jar:"/Users/user/Documents/playground/wild/wildfly-8.2.0.Final"/bin/client/jboss-cli-client.jar}}
> So, there are " on the path for the jboss-cli-client.jar. which breaks things. This problem happens with both Linux and Mac.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Andries Ehlers (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Andries Ehlers commented on WFLY-3386:
--------------------------------------
Ochieng, not sure if the cause for your issue is the same as ours, but here goes: I shelved this issue a long time ago and didn't get back to it, but in seeing your comment I decided to revisit. I guess time does wonders because I think I spotted the issue, or at least part of it. I believe it came down to a fault on our side. We were injecting the activiti BusinessProcess in a stateless session bean, which was called from an Rest resource. The exception was thrown when we tried to use that injected resource to extract a variable from an Activiti process (or start a task) , which won't work - we injected a business process from outside of Activiti CDI - ie how would activiti know which business process it's supposed to inject?? As soon as we changed it to using RuntimeManager, TaskManager etc to find the process instance by name and start the task, it worked perfectly. We continue using BusinessProcess within beans that are referenced from within activiti processes - there it works fine because it's injected from within the Activiti context. Hope that helps.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Andries Ehlers (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Andries Ehlers commented on WFLY-3386:
--------------------------------------
Ochieng, not sure if the cause for your issue is the same as ours, but here goes: I shelved this issue a long time ago and didn't get back to it, but in seeing your comment I decided to revisit. I guess time does wonders because I think I spotted the issue, or at least part of it. I believe it came down to a fault on our side. We were injecting the activiti BusinessProcess in a stateless session bean, which was called from an Rest resource. The exception was thrown when we tried to use that injected resource to extract a variable from an Activiti process (or start a task) , which won't work - we injected a business process from outside of Activiti CDI - ie how would activiti know which business process it's supposed to inject?? As soon as we changed it to using RuntimeManager, TaskManager etc to find the process instance by name and start the task, it worked perfectly. We continue using BusinessProcess within beans that are referenced from within activiti processes - there it works fine because it's injected from within the Activiti context. Hope that helps.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-467) improve "patch inspect" functionality to support patch bundles
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-467?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky updated WFCORE-467:
-------------------------------------
Summary: improve "patch inspect" functionality to support patch bundles (was: improve "patch inspect" functionality to support cumulative patches)
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/587
I've changed "cumulative" to "bundle" in the title.
As CP, like one-off, use the same patch.xml.
A patch bundle may consist of one or more one-offs and/or CPs and use patches.xml to describe what it contains.
> improve "patch inspect" functionality to support patch bundles
> --------------------------------------------------------------
>
> Key: WFCORE-467
> URL: https://issues.jboss.org/browse/WFCORE-467
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Patching
> Reporter: Martin Simka
> Assignee: Alexey Loubyansky
>
> WFLY-2710 added new command "patch inspect" that displays information (patch id, patch type, target identity name and version, description) from the patch.xml of the specified patch file.
> However it works only for "one-off" patches, not for cumulative patches. CPs don't contain patch.xml file but patches.xml.
> It would be nice if it could display list of patches included in CP together with their metadata.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by André Lemos (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
André Lemos commented on WFLY-4338:
-----------------------------------
Done (pull #7298).
> JConsole script builds wrong path
> ---------------------------------
>
> Key: WFLY-4338
> URL: https://issues.jboss.org/browse/WFLY-4338
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.2.0.Final
> Environment: Linux (Ubuntu 14.10) and Mac OS X Yosemite (10.10.2)
> Reporter: André Lemos
> Assignee: Kabir Khan
> Priority: Trivial
> Labels: bash, jconsole, wildfly
> Attachments: jconsole.patch
>
>
> The path built by the jconsole.sh script is incorrect, and as a result, when calling {{service:jmx:http-remoting-jmx://{insert server ip here}:9990}} is probably never recognized and the connection is never done.
> The path, under mac is:
> {{/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/jconsole -J-Djava.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/tools.jar:"/Users/user/Documents/playground/wild/wildfly-8.2.0.Final"/bin/client/jboss-cli-client.jar}}
> So, there are " on the path for the jboss-cli-client.jar. which breaks things. This problem happens with both Linux and Mac.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month