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 ?
/max
Grid
> 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 File(commandLocation));
> 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.
>
> Thanks
> Grid
>
>
> _______________________________________________
> 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