[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)
10 years, 9 months
[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)
10 years, 9 months
[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)
10 years, 9 months
[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)
10 years, 9 months
[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)
10 years, 9 months
[JBoss JIRA] (WFCORE-543) Revisit how the model validation happens
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-543?page=com.atlassian.jira.plugin... ]
Kabir Khan resolved WFCORE-543.
-------------------------------
Resolution: Done
> Revisit how the model validation happens
> ----------------------------------------
>
> Key: WFCORE-543
> URL: https://issues.jboss.org/browse/WFCORE-543
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 1.0.0.Beta1
>
>
> Currently the ValidateModelStepHandler is triggered by AbstractAddStepHandler. Not all add handlers extend AbstractAddStepHandler. Also, it does not seem to be triggered for writes.
> Also if used in a composite along the lines of
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /system-property=xxx:add(value=test)
> [standalone@localhost:9990 / #] /system-property=xxx:remove
> [standalone@localhost:9990 / #] run-batch
> {code}
> the handler will get triggered at the end for the add. It will fail for the add since there is no such resource. While that is easy to work around by checking for a NoSuchResourceException around the OC.readResource() it seems that what triggers the use of the ValidateModelStepHandler should be more an intrinsic part of the controller which knows what has and has not been added/removed/written to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 9 months
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-4338:
----------------------------------
[~avlemos] Can you open a pull request at https://github.com/wildfly/wildfly? I believe the files are in https://github.com/wildfly/wildfly/tree/master/feature-pack/src/main/reso...
> 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)
10 years, 9 months
[JBoss JIRA] (JGRP-1922) FD_SOCK/FD: members are not unsuspected
by Bela Ban (JIRA)
Bela Ban created JGRP-1922:
------------------------------
Summary: FD_SOCK/FD: members are not unsuspected
Key: JGRP-1922
URL: https://issues.jboss.org/browse/JGRP-1922
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.4
When we have members \{A,B,C,D,E\} and E suspects B, then it broadcasts a SUSPECT(B) event and adds B to its suspects list. E then continues braodascting the SUSPECT(B) event until a new view has been installed.
Everybody adds B to its suspects list, except B which sends an I_AM_ALIVE message.
When VERIFY_SUSPECT on A detects that B is *not* dead, it sends an UNSUSPECT(B) event up and down the stack, removing B from its suspects list.
However, this event is *not broadcast*; E will continue sending its SUSPECT(B) message.
SOLUTION: broadcast an UNSUSPECT event for som protocols. This is needed for FD_SOCK and FD, and not needed by FD_ALL and FD_ALL2.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 9 months