[jbosstools-dev] a problem of classpath too long

[Max Rydahl Andersen]

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.

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