[EMAIL PROTECTED] wrote: > >The solution of adding the Jar to the classpath works but, as you said, it >is certainly not a nice way of doing this. > >Regarding the class loader: >If I have specified the jar in the runtime classpath for ant, then call the >IBM class to stop the server from a build file supplied to ant, do they not >share a loader? > > what really matters is :
- which class is instantiating the WSLauncher class ? I have stumbled against the same problem when I created an ant task which was doing some work with MQ Series across a JNDI driver. I had to put the JNDI driver in the classpath before starting ant, because the JNDI driver gets loaded by the Java Runtime, which is living in a classloader which does not know ant and certainly not the <taskdef/> of the custom task which requires it. So my experience is that you have to put in the classpath all drivers which are loaded by the Java runtime (JNDI or JDBC drivers are the examples which come to mind). Maybe this WSLauncher class is written in such a way that it is an implementation of an interface known generally to the java runtime, and it gets instantiated with a class.forName(); This type of questions gets discussed often on the user list and on the dev list. for instance : posting by Rainer Noack with a patch http://marc.theaimsgroup.com/?l=ant-dev&m=107930923613690&w=2 bug report in bugzilla : http://issues.apache.org/bugzilla/show_bug.cgi?id=6606 Actually there is a lot of litterature concerning this issue, so I hope that the other posters who have written something about this issue do not feel offended that I do not citate them. Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
