[JBoss JIRA] (WFLY-9491) MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9491:
-------------------------------------------
Summary: MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
Key: WFLY-9491
URL: https://issues.jboss.org/browse/WFLY-9491
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 10.1.0.Final
Reporter: Nuno Godinho de Matos
Priority: Minor
In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
Now I have come accross the following but while trying to refactor a mechanism that fires an "ApplicationDeployed" event that hard-coded elements that stopped working once I tried to generalize the logic.
The problem is the following, if when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
MBeanServer mBeanServer = createMBeanServer();
ObjectName targetObject = new ObjectName(objectName);
mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
I can successfully register, without any problem a LISTENER and an OBSERVER on the object:
jboss.as:deployment=someapp-war.war
In fact, this is what I had hard-coded when the mechanism was married to the application I was analyzing.
This approach works 100% of the time.
The registration work flawlelessly.
And when the application is finally deployed my listener gets the event and can notify the application that the deployment is done.
The Problem now is that once I tried to generalize the mechanism, Istead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
jboss.as:deployment=*
And now I have the problem that I am coming out empty handed, no results.
Better said, the current approach has two possible behaviors.
If Wildfly is stopped, and on eclipse I drag and drop the WAR file to the APP server.
Then I start wildfly.
In this case, the jboss.as:deployment=* will give me the deployed applications.
The generic mechanism works.
If instead I start Wildfly with no deployments, and then I drag and drop the APP, then I get no results.
Here is a Log snippet from the application:
{panel}
####2017-10-27 11:44:10,171 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,246 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,253 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,328 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,332 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,406 ThreadId:512 WARN [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,409 ThreadId:512 INFO [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,490 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,494 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,569 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,574 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,649 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,653 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,726 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,729 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,802 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,804 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,884 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,893 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,967 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:10,970 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,044 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,050 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,129 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,138 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,217 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,227 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,304 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,312 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,386 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,393 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,472 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,480 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,559 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,568 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,646 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,656 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,736 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,744 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,822 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,831 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,904 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,907 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,985 ThreadId:512 WARN [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war - returned: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,991 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: [] <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,992 ThreadId:512 INFO [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes. <LogContext:Facade> <ServerService Thread Pool -- 339>
####2017-10-27 11:44:11,995 ThreadId:512 INFO [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms} <LogContext:Facade> <ServerService Thread Pool -- 339>
{panel}
I can try to create a sample application to reproduce this.
I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
Many thanks for any help on this.
I will try to give you a sample application for analysis.
Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (DROOLS-2056) Add some 'Impact Analysis' functionality for Business Assets
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2056?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-2461 to DROOLS-2056:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-2056 (was: GUVNOR-2461)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Impact Analysis
(was: Impact Analysis)
> Add some 'Impact Analysis' functionality for Business Assets
> ------------------------------------------------------------
>
> Key: DROOLS-2056
> URL: https://issues.jboss.org/browse/DROOLS-2056
> Project: Drools
> Issue Type: Feature Request
> Components: Impact Analysis
> Reporter: Rafael Soares (Tuelho)
> Assignee: Mark Proctor
>
> Would be nice have some kind of traceability in KIE Workbench for Business Assets.
> Some way to track/list all the places where a Rule is been used/referenced inside the project?
> From the Business Process perspective you can open a Rule Task, get the Ruleflow-group and then open the Rule definition (one by one).
> But looking in a different angle... Lets say I want to change a specific Rule definition and want to know what points (rule tasks in all process) will be affected by this change. Imagine I have many Business Process definitions (.bpmn2) inside the same project.
> Does It makes sense?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (DROOLS-2057) Indexers: Tests can use Byteman instead of sleeping
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2057?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-3053 to DROOLS-2057:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-2057 (was: GUVNOR-3053)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Impact Analysis
(was: Impact Analysis)
Affects Version/s: 7.0.0.CR3
(was: 7.0.0.CR3)
> Indexers: Tests can use Byteman instead of sleeping
> ---------------------------------------------------
>
> Key: DROOLS-2057
> URL: https://issues.jboss.org/browse/DROOLS-2057
> Project: Drools
> Issue Type: Task
> Components: Impact Analysis
> Affects Versions: 7.0.0.CR3
> Reporter: Michael Anstis
> Priority: Minor
>
> Indexers' Unit Tests contain {{Thread.sleep(...)}} which can either be an excessive wait or (on rare occasions on slow hardware) not long enough. Uberfire has support for indexing tests using Byteman that watch for completion of indexing and hence eliminate the waits. All indexing Unit Tests should be updated.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (DROOLS-2058) Remove hardcoded Thread.sleeps() in indexing tests
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2058?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-2493 to DROOLS-2058:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-2058 (was: GUVNOR-2493)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Impact Analysis
(was: Impact Analysis)
> Remove hardcoded Thread.sleeps() in indexing tests
> --------------------------------------------------
>
> Key: DROOLS-2058
> URL: https://issues.jboss.org/browse/DROOLS-2058
> Project: Drools
> Issue Type: Task
> Components: Impact Analysis
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> There are guvnor/kie-wb-common/drools-wb modules which contain hardcoded waits (Thread.sleeps()) to make sure the backend indexes the files. This needs to be removed and handled different without those waits.
> List of affected modules (will be updated over time):
> kie-wb-common-refactoring-backend
> Why we need to fix this?
> The tests take way too much time. It is great pain to run those tests locally as they spent most of the time just doing nothing and waiting.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (DROOLS-2050) Enumerations: PropertyAccessException
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2050?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-2077 to DROOLS-2050:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-2050 (was: GUVNOR-2077)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Enumerations Editor
(was: Enumerations)
Affects Version/s: 6.0.0.Final
(was: drools-6.0.0.Final)
> Enumerations: PropertyAccessException
> -------------------------------------
>
> Key: DROOLS-2050
> URL: https://issues.jboss.org/browse/DROOLS-2050
> Project: Drools
> Issue Type: Bug
> Components: Enumerations Editor
> Affects Versions: 6.0.0.Final
> Environment: CentOS 6.4
> JBoss 7.2.0 Final
> Reporter: Stephen Johns
> Assignee: Mark Coble
>
> I get PropertyAccessException on enumeration access: see at bottom
> getAllListingGroupNames is a public method.
> The jar file that contains that class is in .../WEB-INF/lib
> The class is public with the annotation @Stateless
> I get this error when I validate the enumeration file.
> The Guided Rule editor sees ListingGroupBean and allListingGroupNames as one of its fields, but is that because I have it uploaded to the artifact repository? Do you need to upload jars that are already in .../WEB-INF/lib?
> -----------------------------------------------------------------------------
> src/exception
> -----------------------------------------------------------------------------
> 1. | 'ListingGroupxxx.name' : ['a','b','c']
> 2. | 'ListingGroup.name' : (new
> com.xyz.mgmt.listing.ListingGroupBean()).getAllListingGroupNames()
> Unable to load enumeration data.
> [Error: unable to invoke method: getAllListingGroupNames] [Near : {...
> ng.ListingGroupBean()).getAllListingGroupNames() ] ....}] ^ [Line: 2,
> Column: 74]
> Error type: org.mvel2.PropertyAccessException
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months