> 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.
Given the number of occasions that the underlying teiid server is contacted and requests
made, this
might have a performance hit.
why ? how often are we talking and can't these operation be done in "bulk"
?
note, we do this in hibernatetools and its for sure not pretty and we are leaning towards
moving these calls out to an external vm to avoid the runtime version coupling.
> 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 ;)
Agreed. Some kind of interface service / adapter has to sit in front of all teiid client
method
calls to select the correct implementation prior to the method call. If JBT can do it
with
jboss-jars, I'm sure something is possible with teiid... I think!
All depends how complex its interaction is - if just "deploy/undeploy" then it
shouldn't be that hard.