<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hey Barry:<br>
<br>
You'll probably really want to investigate using JBossTools if you
want some ready-made APIs to really help send management
commands. Also, discovering the management port will require you
either parsing xml yourself or accessing some string constants in
our server. <br>
<br>
Let's start with host. All IServer objects in WTP can get the
host simply by server.getHost(), so that's easy. <br>
<br>
For getting the management port, there are a few ways to do it.
The first is with raw xml, searching the proper file. The xpath
you'll need and file data is:<br>
<br>
as7.0 xpath:
//*[local-name()="management-interfaces"]/*[local-name()="native-interface"]<br>
as7.1 xpath:
//*[local-name()="socket-binding-group"]/*[local-name()="socket-binding"][@name="management-native"]<br>
xpath attribute: port<br>
file to search: standalone/configuration/${jboss_config_file}
(probably standalone.xml)<br>
<br>
Obviously here the xpaths differ based on jboss version. AS7.0 has
one xpath. AS7.1 has a different. However, none of these allow
the 'overrides' available in the UI. In the JBossTools UI, you
can double-click the server to see the editor. There's a port
section there, and there's the opportunity to ignore the xml value
and override it via UI. So if the default xpath has 9999 but
somehow you're using more complicated features in the
standalone.xml such that the actual value is 9998, you'll need to
override this in the UI. <br>
<br>
So how to get this value that respects the user's UI choices?
Well, two ways. One is by using hard-coded strings (if you want to
avoid dependency on jbosstools). The code for that would look
like this:<br>
<br>
public static final String AS7_MANAGEMENT_PORT_DETECT=
"org.jboss.ide.eclipse.as.core.server.as7.managementPortAutoDetect";
//$NON-NLS-1$<br>
<br>
public static final String AS7_MANAGEMENT_PORT =
"org.jboss.ide.eclipse.as.core.server.as7.managementPort";
//$NON-NLS-1$<br>
<br>
boolean detect = getAttribute(detectKey, true);<br>
String result = null;<br>
if( !detect ) {<br>
result = getAttribute(attributeKey, (String)null);<br>
} else {<br>
// Load it from the xml xpaths listed above<br>
}<br>
<br>
This is if you're trying to avoid any dependencies on jbosstools
of course. If you don't mind having dependencies on jbosstools,
the best way to get this port is as follows:<br>
<br>
JBoss7Server jb7 = server.loadAdapter(JBoss7Server.class,
null);<br>
if( jb7 != null ) {<br>
return jb7.getManagementPort();<br>
}<br>
<br>
So what other benefits can JBT provide other than just helping to
find the port? Well, we can also run your remote commands for you.
JBoss7 servers have a remote management service registered in
eclipse, which can run your remote commands and return the
results. <br>
<br>
The first is our management service. The service interface is
IJBoss7ManagerService. You can see a lot of methods there for
deploying or stopping a server. But there's also a method to run
arbitrary commands: public String execute(IAS7ManagementDetails
details, String request) throws Exception;<br>
<br>
The way to access this service is via the following command:
JBoss7ManagerUtil.getService(iserverObject);<br>
<br>
This API ensures that if for example the protocol changes slightly
(either intentionally or as a bug) between as7.1 and as7.2 /
as8.0, the proper service is returned for the proper AS version.
Using these APIs ensure that all the management jars are of the
proper version, talking to the proper remote version. It's
possible to do all of this on your own, but I'm pretty sure you'll
find it a LOT more trouble and you'll simply be replicating our
work. <br>
<br>
And worse yet, how you intend to get the jboss-as jars on the
classpath is a point of interest. We currently will be bundling
the management jars for each version (or more specifically for any
set of jars that cannot talk to each other. We also work hard to
ensure that regressions upstream (ie a new version unable to talk
to older ones) is fixed promptly). If you intend to bundle these
jars, it'll be inflating the size of your product substantially.
And you'll most likely be re-engineering our solution for
separation of version jars. <br>
<br>
So we've already discussed how to get the port via xml, and how to
get a port that respects user settings. We've discussed how to get
the management service regardless of app-server version. From
there, running the default commands is simple. For example:<br>
<br>
JBoss7ManagerUtil.getService(iserverObject).stop(new
AS7ManagementDetails(iserverObject));<br>
<br>
So the last thing that remains is how to run an arbitrary command.
Due to classpath and classloading concerns, we can't have the
management service api and interfaces include references to
jboss-as jars or classes like ModelNode, so the method for
executing arbitrary commands is:<br>
<br>
JBoss7ManagerUtil.getService(iserverObject).execute(IAS7ManagementDetails
details, String request) throws Exception;<br>
<br>
The "String request" is a JBoss-dmr string. And to generate that
string, we have yet another plugin called
org.jboss.ide.eclipse.as.dmr. By depending on this plugin you can
write code as follows:<br>
<br>
ModelNode request = new ModelNode();<br>
request.get(OP).set(READ_CHILDREN_NAMES_OPERATION);<br>
request.get(CHILD_TYPE).set(getName());<br>
request.get(OP_ADDR).set(getManagementAddress(getParent()));<br>
String requestString = request.toJSONString(true);<br>
String resultString =
JBoss7ManagerUtil.getService(iserverObject).execute(new
AS7ManagementDetails(iserverObject), requestString);<br>
ModelNode resultNode =
ModelNode.fromJSONString(resultString);<br>
<br>
Another way to do this is via the following:<br>
<br>
protected ModelNode executeWithResult(final IServer server,
final String request) throws Exception {<br>
String resultJSON =
JBoss7ManagerUtil.executeWithService(new
JBoss7ManagerUtil.IServiceAware<String>() {<br>
public String execute(IJBoss7ManagerService service)
throws Exception {<br>
return service.execute(new
AS7ManagementDetails(server), request);<br>
}<br>
}, server);<br>
ModelNode result = ModelNode.fromJSONString(resultJSON);<br>
return result;<br>
}<br>
<br>
<br>
Hopefully this gives you a good starting point to discovering
ports and running management commands against AS7, as well as what
concerns there are. I'm sure Max or the build team can assist /
advise if you start addign dependencies on jbt plugins.<br>
<br>
Good luck!!<br>
<br>
- Rob<br>
<br>
On 08/03/2012 10:19 PM, Barry Lafond wrote:<br>
</div>
<blockquote
cite="mid:947082938.10003328.1344003545471.JavaMail.root@redhat.com"
type="cite">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: verdana,helvetica,sans-serif; font-size:
12pt; color: #000000">Rob,<br>
<br>
Over here in SOA-land the Teiid server//runtime team has changed
their integration in AS to adapt to the AS 7 changes.<br>
<br>
One change in particular, dropping Teiid's custom PORT number,
has required Teiid Designer to programmatically discover the
JBoss Management HOST/PORT info.<br>
<br>
Currently my code-base does not depend on JBT code of any kind
except for our swt.bot tests. I've looked at the structure of
your contributions to WTP's ServerTools framework, so I
understand that at a high level.<br>
<br>
Can you point me in the right direction? maybe another project
that already does this?<br>
<br>
Thx<br>
<br>
<div><span name="x"></span>Barry<span name="x"></span> LaFond<br>
Teiid Designer Project<br>
</div>
<br>
</div>
</blockquote>
<br>
<br>
</body>
</html>