If you use External Tools launch configurations you don't even
custom launch configuration type I would think.
...and if you used External Tools launch configurations for this users
would be able to adjust this launch if really needed.
I am not familiar with
external tools. I will take a look on it. But if
use it, when we call
wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
where should I set the 'a.jar:b.jar:c.jar.............xxx.jar'? if
still in the command, I think it can't resolve my issue because I study
the launch configuration, at last, all of launches will call
DebugPlugin.exec(command), the command is still long.
Just a thought.
>> 2 call org.jboss.wsf.spi.tools.cmd.WSProvide directly.
>> Thi methos has two way to realize:
>> One is using classloader and the other is using eclipse launch
>> configuration(as Rob said)
>> These two ways both need to load some jars according to the
>> wsprovider.sh. I do not know if these sh are same from different
>> verion of jboss AS or WS. So I tested them and know they can
>> resolved the issue. But I do not use it.
> eh - why not ? this sounds by far as the best solution and you can
> always have variations of it dependent on wether it is AS or WS you
> are using.
> And you would need to know that for what you do in solution 4 anway,
> right ?
>> 4 create a temp.jar and add all of the jars into the temp.jar's
>> menifest file. Then use this jar instead of all of the jars to the
>> class path
>> Now I use this method to resolve this issue.
> This does not sound like a good idea! Classloading rules changes
> when stuff is put into the same jar plus it is not how the user would
> run these
> if he could. Plus it requires a massive copying of classes/files.
>> 5 maybe have another way from a runtime guy: change the .sh file
>> and add all of the jars into the command line classpath, then run
>> the command as: wsprovider.sh -w -k ............. thejavaclass
>> The wsprovider.sh call org.jboss.wsf.spi.tools.cmd.WSProvide. I
>> have study the codes of the class, it create a classloader to run and
>> the classloader will extend parent's classpath. So we can use the
>> method to resolve this issue.
>> But we need to get the wsprovider.sh and modify it, then run.
>> I do not test it.
>> At the end, I think jboss ws team should offer a class to handle
>> this issue because in command line, the issue occurs too.
> Or we need to investigate which jars we *actually* need to pass on to
> WS for it to work ?
>>> Hi all,
>>> There is a problem about classpath.
>>> Up to now, the jboss ws module of our tools use two commands --
>>> 'wsprovider.sh' and 'wsconsumer.bat' -- to generate codes
>>> in both scenes: bottow-up(from a java class) and top-down(from a
>>> wsdl file).
>>> When we call wsprovider.bat to generate codes, we may create a
>>> command to run in our eclipse console like this:
>>> wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
>>> ............. thejavaclass
>>> My codes run this command like this in my plugins:
>>> Runtime rt = Runtime.getRuntime();
>>> rt.exec(command.toString(), null, new
>>> On linux, this is ok. But on windows, a error occurs: the command
>>> is too long. This is caused by the classpath parameter is
>>> too long because we add very many jars to '-c'
>>> I think, in enterprise scenes, we will often meet this problem --
>>> need to add many jars to classpath.
>>> So I want to ask if we have a way to set a container or a jars
>>> folder for these jars.
>>> jbosstools-dev mailing list
>> jbosstools-dev mailing list
> jbosstools-dev mailing list