[JBoss JIRA] Created: (JOPR-73) Add support for changing arguments passed to start/stop operations
by Charles Crouch (JIRA)
Add support for changing arguments passed to start/stop operations
------------------------------------------------------------------
Key: JOPR-73
URL: https://jira.jboss.org/jira/browse/JOPR-73
Project: Jopr
Issue Type: Feature Request
Components: Plugin - JBoss AS 4, Plugin - JBoss AS 5
Reporter: Charles Crouch
Comes out of case: 264527
Right now if you change the start/stop scripts used by a JBAS instance the new scripts have to understand the same arguments which the default jbas ones takes, e.g. for shutdown thats:
--server=jnp://localhost:1099 --user=myuser --password=mypassword --shutdown
Given we enable people to specify their own scripts for these operations we should enable them to configure the arguments we pass to the scripts, just like we do when executing a JBAS script resource.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JOPR-32) Deleting a WAR/EAR resource deletes the underlying file but doesn't actually undeploy it from JBAS
by Charles Crouch (JIRA)
Deleting a WAR/EAR resource deletes the underlying file but doesn't actually undeploy it from JBAS
--------------------------------------------------------------------------------------------------
Key: JOPR-32
URL: https://jira.jboss.org/jira/browse/JOPR-32
Project: Jopr
Issue Type: Bug
Components: Plugin - JBoss AS 4
Affects Versions: 2.1
Reporter: Charles Crouch
Fix For: 2.2
This causes problems for Embedded (EMBJOPR-45) but should also show up when monitoring EAP instances with JON. Steps to reproduce the problem before the fix:
1) Setup an EAP instance, make sure you have the jmx-console.war deployed. I picked EAP because by default its deployment scanner is set for 60mins, iirc, but an JBAS instance where the deployment scanner has a long delay or is disabled should show this.
2) Inventory the instance, including the jmx-console.war
3) check you can hit the jmx-console: http://localhost:8080/jmx-console
4) Go to the Inventory tab of the EAP instance in JON and delete (not uninventory) the jmx-console.war. This should succeed.
5) Check the jmx-console.war is no longer in the /deploy folder
6) Check the EAP log and you should not see any entries talking about undeploying jmx-console
7) Check you can hit the jmx-console again: http://localhost:8080/jmx-console
After the fix:
1)..
6) Check the EAP log and you *should* see entries talking about undeploying jmx-console
7) Check you *cannot* hit the jmx-console again: http://localhost:8080/jmx-console
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JOPR-84) Make JBAS availability check take account of which actual instance is responding on jnp url
by Charles Crouch (JIRA)
Make JBAS availability check take account of which actual instance is responding on jnp url
-------------------------------------------------------------------------------------------
Key: JOPR-84
URL: https://jira.jboss.org/jira/browse/JOPR-84
Project: Jopr
Issue Type: Feature Request
Components: Plugin - JBoss AS 4
Affects Versions: 2.1
Reporter: Charles Crouch
Fix For: 2.2
Use case:
I have 2 JBAS instances on a box. Sometimes i run one instance, sometimes I run another, based on what application version I have deployed. Both instances have different install paths but share ip and port settings (which is fine because they dont both run at the same time)
Over time a JON agent running on this box will detect both instances so they can be added to the inventory. The issue is that in JON both resources will show as available because they both have the same jnp url.
The suggestion would be to make the getAvailabilityCheck be smarter so that the component recognizes when its querying an instance that its not associated with, e.g. on JBossASServerComponent
public AvailabilityType getAvailability() {
try {
EmsConnection connection = loadConnection();
EmsBean bean = connection.getBean("jboss.system:type=ServerConfig");
File serverHomeViaJNP = (File) bean.getAttribute("ServerHomeDir").refresh();
if (this.configPath.equals(serverHomeViaJNP))
return AvailabilityType.UP;
else
// a different server must have been started on our jnp url
return AvailabilityType.DOWN;
} catch (Exception e) {
return AvailabilityType.DOWN;
}
}
This is going to break existing resources (they will show red availability) where the configPath no longer matches where the instance is actually installed, though script/filesystem based operations (e.g. start, deploy apps) would already be broken for these resources. Re-inventorying the resources should fix this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months