Hey Barry: 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. Let's start with host. All IServer objects in WTP can get the host simply by server.getHost(), so that's easy. 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: as7.0 xpath: //*[local-name()="management-interfaces"]/*[local-name()="native-interface"] as7.1 xpath: //*[local-name()="socket-binding-group"]/*[local-name()="socket-binding"][@name="management-native"] xpath attribute: port file to search: standalone/configuration/${jboss_config_file} (probably standalone.xml) 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. 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: public static final String AS7_MANAGEMENT_PORT_DETECT= "org.jboss.ide.eclipse.as.core.server.as7.managementPortAutoDetect"; //$NON-NLS-1$ public static final String AS7_MANAGEMENT_PORT = "org.jboss.ide.eclipse.as.core.server.as7.managementPort"; //$NON-NLS-1$ boolean detect = getAttribute(detectKey, true); String result = null; if( !detect ) { result = getAttribute(attributeKey, (String)null); } else { // Load it from the xml xpaths listed above } 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: JBoss7Server jb7 = server.loadAdapter(JBoss7Server.class, null); if( jb7 != null ) { return jb7.getManagementPort(); } 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. 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; The way to access this service is via the following command: JBoss7ManagerUtil.getService(iserverObject); 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. 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. 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: JBoss7ManagerUtil.getService(iserverObject).stop(new AS7ManagementDetails(iserverObject)); 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: JBoss7ManagerUtil.getService(iserverObject).execute(IAS7ManagementDetails details, String request) throws Exception; 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: ModelNode request = new ModelNode(); request.get(OP).set(READ_CHILDREN_NAMES_OPERATION); request.get(CHILD_TYPE).set(getName()); request.get(OP_ADDR).set(getManagementAddress(getParent())); String requestString = request.toJSONString(true); String resultString = JBoss7ManagerUtil.getService(iserverObject).execute(new AS7ManagementDetails(iserverObject), requestString); ModelNode resultNode = ModelNode.fromJSONString(resultString); Another way to do this is via the following: protected ModelNode executeWithResult(final IServer server, final String request) throws Exception { String resultJSON = JBoss7ManagerUtil.executeWithService(new JBoss7ManagerUtil.IServiceAware<String>() { public String execute(IJBoss7ManagerService service) throws Exception { return service.execute(new AS7ManagementDetails(server), request); } }, server); ModelNode result = ModelNode.fromJSONString(resultJSON); return result; } 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. Good luck!! - Rob On 08/03/2012 10:19 PM, Barry Lafond wrote: > Rob, > > Over here in SOA-land the Teiid server//runtime team has changed their integration in AS to adapt to the AS 7 changes. > > One change in particular, dropping Teiid's custom PORT number, has required Teiid Designer to programmatically discover the JBoss Management HOST/PORT info. > > 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. > > Can you point me in the right direction? maybe another project that already does this? > > Thx > > Barry LaFond > Teiid Designer Project > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Since I saw Phantom work on this I was wondering if there were any follow up on this: On 14 Aug 2012, at 09:45, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: > im late on this, but if i'm reading this right Rob is outlining how to communicate with the AS7 server API's which is all fine and dandy; but > as far as I understand Teiid aren't there more to this than just api calls ? > > i.e. decide if Teiid servers is a part/extension of an AS/EAP server type or a server type on its own ? > wether Teiid actions are contributed to the server view menu or somewhere else ? > How datasource setup is done ? (today its scattered everywhere (hibernate, wtp, dtp, teiid, etc.) - time to make it less scattered imo) > > ...any other server dependent features teiid needs to do ? > > > On 06 Aug 2012, at 06:57, Rob Stryker <rstryker(a)redhat.com&gt; wrote: > >> Hey Barry: >> >> 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. >> >> Let's start with host. All IServer objects in WTP can get the host simply by server.getHost(), so that's easy. >> >> 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: >> >> as7.0 xpath: //*[local-name()="management-interfaces"]/*[local-name()="native-interface"] >> as7.1 xpath: //*[local-name()="socket-binding-group"]/*[local-name()="socket-binding"][@name="management-native"] >> xpath attribute: port >> file to search: standalone/configuration/${jboss_config_file} (probably standalone.xml) >> >> 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. >> >> 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: >> >> public static final String AS7_MANAGEMENT_PORT_DETECT= "org.jboss.ide.eclipse.as.core.server.as7.managementPortAutoDetect"; //$NON-NLS-1$ >> >> public static final String AS7_MANAGEMENT_PORT = "org.jboss.ide.eclipse.as.core.server.as7.managementPort"; //$NON-NLS-1$ >> >> boolean detect = getAttribute(detectKey, true); >> String result = null; >> if( !detect ) { >> result = getAttribute(attributeKey, (String)null); >> } else { >> // Load it from the xml xpaths listed above >> } >> >> 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: >> >> JBoss7Server jb7 = server.loadAdapter(JBoss7Server.class, null); >> if( jb7 != null ) { >> return jb7.getManagementPort(); >> } >> >> 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. >> >> 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; >> >> The way to access this service is via the following command: JBoss7ManagerUtil.getService(iserverObject); >> >> 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. >> >> 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. >> >> 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: >> >> JBoss7ManagerUtil.getService(iserverObject).stop(new AS7ManagementDetails(iserverObject)); >> >> 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: >> >> JBoss7ManagerUtil.getService(iserverObject).execute(IAS7ManagementDetails details, String request) throws Exception; >> >> 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: >> >> ModelNode request = new ModelNode(); >> request.get(OP).set(READ_CHILDREN_NAMES_OPERATION); >> request.get(CHILD_TYPE).set(getName()); >> request.get(OP_ADDR).set(getManagementAddress(getParent())); >> String requestString = request.toJSONString(true); >> String resultString = JBoss7ManagerUtil.getService(iserverObject).execute(new AS7ManagementDetails(iserverObject), requestString); >> ModelNode resultNode = ModelNode.fromJSONString(resultString); >> >> Another way to do this is via the following: >> >> protected ModelNode executeWithResult(final IServer server, final String request) throws Exception { >> String resultJSON = JBoss7ManagerUtil.executeWithService(new JBoss7ManagerUtil.IServiceAware<String>() { >> public String execute(IJBoss7ManagerService service) throws Exception { >> return service.execute(new AS7ManagementDetails(server), request); >> } >> }, server); >> ModelNode result = ModelNode.fromJSONString(resultJSON); >> return result; >> } >> >> >> 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. >> >> Good luck!! >> >> - Rob >> >> On 08/03/2012 10:19 PM, Barry Lafond wrote: >>> Rob, >>> >>> Over here in SOA-land the Teiid server//runtime team has changed their integration in AS to adapt to the AS 7 changes. >>> >>> One change in particular, dropping Teiid's custom PORT number, has required Teiid Designer to programmatically discover the JBoss Management HOST/PORT info. >>> >>> 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. >>> >>> Can you point me in the right direction? maybe another project that already does this? >>> >>> Thx >>> >>> Barry LaFond >>> Teiid Designer Project >>> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

FWIW The contribution of the teiid server aspects is a nice-to-have feature at the moment in Designer 8.0. I have added them at the moment on account of it being trivial to add the provider extensions to the Servers view. However, the changes to the Teiid Server view in Designer are such that the teiid server is being derived from an eclipse-defined jboss instance hence the TeiidServer POJO being aware of its parent IServer (jboss 7).

Regards PGR -- Paul Richardson * p.g.richardson(a)phantomjinx.co.uk * p.g.richardson(a)redhat.com * pgrichardson(a)linux.com On 08/31/2012 10:15 AM, Rob Stryker wrote: > I didn't get any updates Max. > > On 08/31/2012 05:14 PM, Max Rydahl Andersen wrote: >> Since I saw Phantom work on this I was wondering if there were any >> follow up on this: >> >> On 14 Aug 2012, at 09:45, Max Rydahl Andersen >> <max.andersen(a)redhat.com&gt; wrote: >> >>> im late on this, but if i'm reading this right Rob is outlining how >>> to communicate with the AS7 server API's which is all fine and dandy; >>> but >>> as far as I understand Teiid aren't there more to this than just api >>> calls ? >>> >>> i.e. decide if Teiid servers is a part/extension of an AS/EAP server >>> type or a server type on its own ? >>> wether Teiid actions are contributed to the server view menu or >>> somewhere else ? >>> How datasource setup is done ? (today its scattered everywhere >>> (hibernate, wtp, dtp, teiid, etc.) - time to make it less scattered imo) >>> >>> ...any other server dependent features teiid needs to do ? >>> >>> >>> On 06 Aug 2012, at 06:57, Rob Stryker <rstryker(a)redhat.com&gt; wrote: >>> >>>> Hey Barry: >>>> >>>> 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. >>>> >>>> Let's start with host. All IServer objects in WTP can get the host >>>> simply by server.getHost(), so that's easy. >>>> >>>> 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: >>>> >>>> as7.0 xpath: >>>> //*[local-name()="management-interfaces"]/*[local-name()="native-interface"] >>>> >>>> as7.1 xpath: >>>> //*[local-name()="socket-binding-group"]/*[local-name()="socket-binding"][@name="management-native"] >>>> >>>> xpath attribute: port >>>> file to search: standalone/configuration/${jboss_config_file} >>>> (probably standalone.xml) >>>> >>>> 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. >>>> >>>> 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: >>>> >>>> public static final String AS7_MANAGEMENT_PORT_DETECT= >>>> "org.jboss.ide.eclipse.as.core.server.as7.managementPortAutoDetect"; >>>> //$NON-NLS-1$ >>>> >>>> public static final String AS7_MANAGEMENT_PORT = >>>> "org.jboss.ide.eclipse.as.core.server.as7.managementPort"; >>>> //$NON-NLS-1$ >>>> >>>> boolean detect = getAttribute(detectKey, true); >>>> String result = null; >>>> if( !detect ) { >>>> result = getAttribute(attributeKey, (String)null); >>>> } else { >>>> // Load it from the xml xpaths listed above >>>> } >>>> >>>> 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: >>>> >>>> JBoss7Server jb7 = server.loadAdapter(JBoss7Server.class, null); >>>> if( jb7 != null ) { >>>> return jb7.getManagementPort(); >>>> } >>>> >>>> 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. >>>> >>>> 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; >>>> >>>> The way to access this service is via the following command: >>>> JBoss7ManagerUtil.getService(iserverObject); >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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: >>>> >>>> JBoss7ManagerUtil.getService(iserverObject).stop(new >>>> AS7ManagementDetails(iserverObject)); >>>> >>>> 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: >>>> >>>> JBoss7ManagerUtil.getService(iserverObject).execute(IAS7ManagementDetails >>>> details, String request) throws Exception; >>>> >>>> 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: >>>> >>>> ModelNode request = new ModelNode(); >>>> request.get(OP).set(READ_CHILDREN_NAMES_OPERATION); >>>> request.get(CHILD_TYPE).set(getName()); >>>> request.get(OP_ADDR).set(getManagementAddress(getParent())); >>>> String requestString = request.toJSONString(true); >>>> String resultString = >>>> JBoss7ManagerUtil.getService(iserverObject).execute(new >>>> AS7ManagementDetails(iserverObject), requestString); >>>> ModelNode resultNode = ModelNode.fromJSONString(resultString); >>>> >>>> Another way to do this is via the following: >>>> >>>> protected ModelNode executeWithResult(final IServer server, >>>> final String request) throws Exception { >>>> String resultJSON = JBoss7ManagerUtil.executeWithService(new >>>> JBoss7ManagerUtil.IServiceAware<String>() { >>>> public String execute(IJBoss7ManagerService service) >>>> throws Exception { >>>> return service.execute(new >>>> AS7ManagementDetails(server), request); >>>> } >>>> }, server); >>>> ModelNode result = ModelNode.fromJSONString(resultJSON); >>>> return result; >>>> } >>>> >>>> >>>> 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. >>>> >>>> Good luck!! >>>> >>>> - Rob >>>> >>>> On 08/03/2012 10:19 PM, Barry Lafond wrote: >>>>> Rob, >>>>> >>>>> Over here in SOA-land the Teiid server//runtime team has changed >>>>> their integration in AS to adapt to the AS 7 changes. >>>>> >>>>> One change in particular, dropping Teiid's custom PORT number, has >>>>> required Teiid Designer to programmatically discover the JBoss >>>>> Management HOST/PORT info. >>>>> >>>>> 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. >>>>> >>>>> Can you point me in the right direction? maybe another project that >>>>> already does this? >>>>> >>>>> Thx >>>>> >>>>> Barry LaFond >>>>> Teiid Designer Project >>>>> >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -- Paul Richardson * p.g.richardson(a)phantomjinx.co.uk * pgrichardson(a)linux.com * mob: +44 (0)9780 869490 * home: +44 (0)1633 892850 "I know exactly who reads the papers ... * The Daily Mirror is read by people who think they run the country. * The Guardian is read by people who think they ought to run the country. * The Times is read by people who do actually run the country. * The Daily Mail is read by the wives of the people who run the country. * The Financial Times is read by the people who own the country. * The Morning Star is read by the people who think the country ought to be run by another country. * The Daily Telegraph is read by the people who think it is." Jim Hacker, Yes Minister

On 08/31/2012 05:39 PM, phantomjinx wrote: > are such that > the teiid server is being derived from an eclipse-defined jboss instance eh? Does this mean you're extending generic server and the org.eclipse.jst.server.* jboss server types? That seems very strange