[jbosstools-dev] a problem of classpath too long
Max Rydahl Andersen
max.andersen at redhat.com
Mon Mar 9 08:03:20 EDT 2009
On 09-03-2009 10:43, feng.qian wrote:
> Max Rydahl Andersen wrote:
>>
>>
>> feng.qian wrote:
>>>>>> 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.
>>>> Well, you would be running this possibly many times so why wait
>>>> until your VM shutsdown to delete all those jars ?
>>> Delete all those jars?
>>> You means when user run our tools, maybe genrate many temp jars and
>>> I should delete every temp.jar after use it every time?
>> Yes.
> Ok, it is very easy to do.
>
> And today Rob and me work together for a java launch to fix this issue.
> Thanks Rob very much for working with me all the afternoon! I got much
> knowledge from Rob.
>
> I found if Rob want to use java launch, he need to write some codes to
> mock the wsprovide.sh to set a environment to run.
> He said for every version of jboss WS or As, we can check the
> wsprovide.sh, if have some changes, we can change our codes
> to support every version, if no changes, it is ok.
>
> So I do not know what idea is better? Rob's or mine?
> My idea need to create a temp jar, Rob's idea need to mock the
> wsprovide.sh.
> I think the temp.jar is just like a variable to contain the jars'
> path, creating it and deleting it are easy to do.
I don't want us to break on updates to wsprovide.sh if we can avoid it,
so why not just
keep this simple and use external launch config's to run wsprovide.sh
with your temp.jar trick ?
/max
More information about the jbosstools-dev
mailing list