[jbosstools-dev] a problem of classpath too long

[feng.qian]

Max Rydahl Andersen wrote:
>
>> 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 ?
In the end of the wsprovider.sh:
"$JAVA" $JAVA_OPTS \
   -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \
   -Dlog4j.configuration=wstools-log4j.xml \
   -classpath "$WSPROVIDE_CLASSPATH" \
   org.jboss.wsf.spi.tools.cmd.WSProvide "$@"

the $WSPROVIDE_CLASSPATH include many jars too. If we use classloader or 
java launch configuration to run it, we need to resolve the sh and
get these jars and add them to environment's classpath.  I don't know if 
the format  of the sh files are same , so  it is  not easy to  do.


>> 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.
No, I do not copy any file. I just add the jars' paths to the temp.jar's 
manifest file. So I think to load the temp.jar  just is equivalent to 
load all the jars. 


>> 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 ?
These jars that I need to add to classpath are not all jboss ws jars, 
they are from user's project, maybe jboss as jars or jboss ws jars and 
maybe other user's
jars. Even if we do not add any jboss as or ws jar to classpath, we 
maybe need to add other many jars of user to classpath. So we need still 
to handle this
issue.

>
> /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
>