[jbosstools-dev] a problem of classpath too long

[feng.qian]

> If you use External Tools launch configurations you don't even need a 
> 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   
.............   thejavaclass
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.
> /max
>>
>>> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>