[jbosstools-dev] a problem of classpath too long

[feng.qian]

> :
>>>
>>>> 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 ?
Yes, WSPROVIDE_CLASSPATH is easy to find. And now we only use jboss as 
4.2 or 4.3, and jboss ws 2.x.
So it is same. We can  get the jars from the sh file and add them to a 
java launch or classloader's classpath.
We may ask the jboss ws team about the WSPROVIDE_CLASSPATH's jars too. 
But I think it is not a good
way. Because maybe now we can get the jars, for example 10 jars. But 
maybe in future, we will use jboss ws 3.x,
if the wsprovide.sh from jboss ws 3.x has 11jars, I believe the jboss ws 
guys do not know what the ws future version
will be like. Then how should we do?
So I think the right way is to resolve the wsprovide.sh to get the jars 
when we want to use, don't care the version of jboss ws or as.
But if we use this way -- resolve the wsprovide.sh--, there is a 
problem. The wsprovider.sh has not a good format, so resolving the
wsprovide.sh in java codes is not easy.
As above what I said, I think this not a good way. At least, this is 
worse than using temp.jar. ;-)

>>
>>
>>>> 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 ?
No, manifest.mf may use absolute path. When we use jar, we hope wherever 
we can use the jar,my machine, your machine or other machine, so we need 
to use relative path all time.
But we can use absolute path in manifest.mf because in our scene, we 
need it only one time.
>
> Could you give an example of the manifest.mf file you generate ?
Of course! See the attached file. For the manifest.mf file can refer to 
.jars spread all over the filesystem, windows or linux, I do much work 
to handle the absolute path, for exmaple:
how to instead of the space in the path, how to handle the directory, 
how to replace windows' file sperator and so on.

>
> p.s. Make sure you create a uniquely named file and delete it again ;)
I use some codes to generate jar:
tempJar = File.createTempFile("temp", ".jar");
org.jboss.tools.common.util.FileUtil.jar(new File[0], 
tempJar.getAbsolutePath(), mf);

The jar is just a temp file, so we need not to care the uniquely named 
file and how to delete it.
>
> /max

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MANIFEST.MF
Url: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090307/6826495f/attachment.pl