Re: [jbosstools-dev] Teiid Designer and TP

Is Teiid / teiid designer used against remote servers? Or is it all against local ones?

One of the strategies I used when initiating our jmx tooling was that, since each version of jboss-as would require different client jars, I'd simply find the IRuntime, and load the jars onto the classpath right at that moment. I'd use a URL Classloader. In the case of remote servers, I simply demanded a copy of the server also be local so that I can at least load the client jars.

Assuming you only need the client jars during critical operations, these jars don't need to be on the classpath at all times. In fact, having them on the CP at all times means you're bound to have your toolset work against only one server version at a time, which is clearly bad ;)

On 10/09/2012 12:33 AM, phantomjinx wrote: > On 10/08/2012 04:53 PM, Rob Stryker wrote: >>>> Rationalising the teiid jar dependencies, I have noticed that I can depend the teiid_embedded_query >>>> plugin on the following. This removes all jboss.as dependencies except for jboss-as-cli.jar >>>> * org.jboss.ide.eclipse.as.management.as71 >>> hmm - that sounds wrong - as.management.as71 are not guaranteed to be available/the correct one to use. >>> >> This *IS* weird, and I suspect it is not the correct way to do things. >> Almost no plugins should ever depend directly on as.management.as71, and >> by almost, i mean exactly none. >> >> They may require the feature (and plugin) be present, but they should >> have no compile time dependencies against the plugin. >> > So the as.management.as71 plugin happens to export the jboss-as jar libraries, which teiid 8.2 was > compiled against. See teiid's pom.xml for details of version dependencies. > > https://github.com/teiid/teiid/blob/master/pom.xml > >> The correct way to do this is to depend on org.jboss.ide.eclipse.as.dmr. >> This is a simple wrapper for the DMR jboss-as logic which allows you to >> build remote management requests. >> >> Unfortunately, due to classloading issues, we can't just give the caller >> a ModelNode reference. Actually we can, right now, but if AS-8 or any >> other version of AS ever requires a new management api (and I am QUITE >> sure they will), this will break 100 different ways. >> >> So, the expected thing you should be doing is to depend on >> org.jboss.ide.eclipse.as.dmr, and do something like the following: >> >> private String createResourceRequest() { >> ModelNode request = new ModelNode(); >> request.get(OP).set(READ_RESOURCE_OPERATION); >> // blah blah blah make more model node request >> return request.toJSONString(true); >> } >> >> Once it's available as a JSON string, you should do the following: >> >> String resultJSON = JBoss7ManagerUtil.executeWithService(new >> JBoss7ManagerUtil.IServiceAware<String>() { >> public String execute(IJBoss7ManagerService service) throws >> Exception { >> return service.execute(new >> AS7ManagementDetails(getServer()), createResourceRequest()); >> } >> }, getServer()); >> >> This will require you to have org.jboss.ide.eclipse.as.core on your >> classpath. The as.core plugin will search for a service interface that >> fits the given version of the server (ie for a while we had two >> different implementers, one for as7 and one for as7.1. Appserver team >> eventually fixed the broken backwards compatability and so the other was >> removed.) >> >> If you guys are doing something that doesn't involve wtp IServer objects >> at all, and can't use the constructor for AS7ManagementDetails, you can >> always fill out the interface in your own way via IAS7ManagementDetails >> >> I'll try to get a wiki page up to demonstrate this, and maybe an example >> plugin if possible. > > So I have used this logic in TD for directly finding if a teiid server is installed. Once we have > found that teiid server, we delegate to the teiid client Admin API for all our requests. The teiid > admin api comes from the teiid jars that is that concern of this thread. If teiid requires these > libraries then we just need them and delegate to teiid's admin interfaces. > > PGR > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev