[jbosstools-dev] a problem of classpath too long

[Max Rydahl Andersen]

:
>>
>>> 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.
I do not understand the problem ?

WSPROVIDE_CLASSPATH is something that is easy to find is it not ? And 
isn't WS and AS using the same ?
If would ask on the WS forums about this issue and show them how you 
suggest to get WSPROVIDE_CLASSPATH (you can see that in the .sh)
and then ask if that is something to rely on.
>
>
>>> 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.
Ohh - ok that is very different from what I read :) I like that, but how 
can your manifest.mf file refer to .jar's spread all over the filesystem 
? manifest.mf's are
always relative not absolute are they ?

Could you give an example of the manifest.mf file you generate ?

p.s. Make sure you create a uniquely named file and delete it again ;)

/max