6:38 a.m.
Hi all,
There is a problem about classpath.
Up to now, the jboss ws module of our tools use two commands --
'wsprovider.bat' 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
10:06 a.m.
Max Rydahl Andersen wrote:
> So I want to ask if we have a way to set a container or a jars folder
> for these jars.
What do you mean by a container or jars folder for these ? That
wouldn't solve the problem would it ?
Yes, I want a container for these jars,
but for this command
'wsprovider.bat', I do not know how to add a
container.
/max
11:22 a.m.
On 24-02-2009 10:06, feng.qian wrote:
Max Rydahl Andersen wrote:
>
>> So I want to ask if we have a way to set a container or a jars
>> folder for these jars.
> What do you mean by a container or jars folder for these ? That
> wouldn't solve the problem would it ?
Yes, I want a container for these jars, but for this command
'wsprovider.bat', I do not know how to add a
container.
What do you mean "container" ? Those jars are from a lot of
different
places so how can it be in a container/folder ?
Which jars does the wsprovider.bat actually need ?
/max
12:03 p.m.
Max Rydahl Andersen wrote:
On 24-02-2009 10:06, feng.qian wrote:
> Max Rydahl Andersen wrote:
>>
>>> So I want to ask if we have a way to set a container or a jars
>>> folder for these jars.
>> What do you mean by a container or jars folder for these ? That
>> wouldn't solve the problem would it ?
> Yes, I want a container for these jars, but for this command
> 'wsprovider.bat', I do not know how to add a
> container.
What do you mean "container" ? Those jars are from a lot of different
places so how can it be in a container/folder ?
It's true, these jars are from
different places. So I do not know if
there is a way to define a folder to instead of them in the command.
wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
............. thejavaclass
use a folder or something to instead of
'a.jar:b.jar:c.jar.............xxx.jar'
Which jars does the wsprovider.bat actually need ?
The wsprovider.bat need some
jars. But we do not care them because the
wsprovider.bat run in it's environment and don't need we set
the classpath for itself. But when we run the command, maybe our java
class(a service class) need some jars, we need to set classpath
for our java class.
/max
9:58 p.m.
My startup jboss launch config mimics startup.bat but I don't launch the
bat directly. I looked at the bat file and mimicked its behavior in a
launch config.
This way the launch configuration just launches a java type launch
rather than a .bat type launch.
This does add potential differences between the actual .bat and the
launch config clone of it, but it should solve your problem.
Just my 2 cents.
- RS
feng.qian wrote:
Max Rydahl Andersen wrote:
> On 24-02-2009 10:06, feng.qian wrote:
>> Max Rydahl Andersen wrote:
>>>
>>>> So I want to ask if we have a way to set a container or a jars
>>>> folder for these jars.
>>> What do you mean by a container or jars folder for these ? That
>>> wouldn't solve the problem would it ?
>> Yes, I want a container for these jars, but for this command
>> 'wsprovider.bat', I do not know how to add a
>> container.
> What do you mean "container" ? Those jars are from a lot of different
> places so how can it be in a container/folder ?
It's true, these jars are from different places. So I do not know if
there is a way to define a folder to instead of them in the command.
wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
............. thejavaclass
use a folder or something to instead of
'a.jar:b.jar:c.jar.............xxx.jar'
>
> Which jars does the wsprovider.bat actually need ?
The wsprovider.bat need some jars. But we do not care them because the
wsprovider.bat run in it's environment and don't need we set
the classpath for itself. But when we run the command, maybe our java
class(a service class) need some jars, we need to set classpath
for our java class.
>
> /max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:14 a.m.
Hi all,
Up to now, I resolved the problem. Write the mail is just for
introducing my method.
I have tested some methods:
1 call jboss ws runtime other class:
org.jboss.wsf.spi.tools.ant.WSProvideTask
This method can't fix this issue because the WSProvideTask class call
the command line too at last and can't avoid the issue.
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.
3 use ProcessBuilder
ProcessBuilder builder = new ProcessBuilder(command);
builder.directory(new File(commandLocation));
Process proc = builder.start();
command is a list that contain my command segments
This method can't fix this issue.
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.
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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:45 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:47 a.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
11:26 a.m.
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.
I am not familiar with
external tools. I will take a look on it. But if
use it, when we call
wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
............. thejavaclass
where should I set the 'a.jar:b.jar:c.jar.............xxx.jar'? if
still in the command, I think it can't resolve my issue because I study
the launch configuration, at last, all of launches will call
DebugPlugin.exec(command), the command is still long.
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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
11:38 a.m.
On 06-03-2009 11:26, feng.qian wrote:
> 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.
I am not familiar with external tools. I will take a look on it. But
if use it, when we call
wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
............. thejavaclass
where should I set the 'a.jar:b.jar:c.jar.............xxx.jar'? if
still in the command, I think it can't resolve my issue because I study
the launch configuration, at last, all of launches will call
DebugPlugin.exec(command), the command is still long.
You can launch External tools
or use a java launch - i'm pretty sure
java launch is not limited in the classpath length..i.e. TestNG
/junittests run with
the same project classpath as you would do.
/max
5:20 p.m.
Max Rydahl Andersen wrote:
On 06-03-2009 11:26, feng.qian wrote:
>
>> 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.
> I am not familiar with external tools. I will take a look on it. But
> if use it, when we call
> wsprovider -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
> ............. thejavaclass
> where should I set the 'a.jar:b.jar:c.jar.............xxx.jar'? if
> still in the command, I think it can't resolve my issue because I study
> the launch configuration, at last, all of launches will call
> DebugPlugin.exec(command), the command is still long.
You can launch External tools or use a java launch - i'm pretty sure
java launch is not limited in the classpath length..i.e. TestNG
/junittests run with
the same project classpath as you would do.
Yes, java launch is not limited in the
classpath. But we need to call
wsprovide.sh. In this scene, we can't use java launch.
If we want to use java launch, we can only use
org.jboss.wsf.spi.tools.cmd.WSProvide class. As my other mail, if you
should this class
you need to get some jars that the WSProvide class need from
wsprovide.sh. And resolving wsprovide.sh to get the jars is not easy.
If you launch external tools, I think we should do like this: run a
command in the external tool:
cmd /c wsprovide.bat -c 'a.jar:b.jar:c.jar.............xxx.jar' -w -k
............. thejavaclass
In case you call the cmd, you will get the issue: the command line is
too long.
/max
11:19 a.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
11:37 a.m.
:
>
>> 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
5:09 p.m.
:
>>
>>> 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
Manifest-Version: 1.2
Class-Path: /home/grid/workspace/runtime%20-ws/test/build/classes/ /ho
me/grid/workspace/runtime%20-ws/test/src/ /home/grid/softinstall/jbos
s-4.2.3.GA/client/jboss-common-client.jar /home/grid/softinstall/jbos
s-4.2.3.GA/client/antlr.jar /home/grid/softinstall/jboss-4.2.3.GA/cli
ent/jaxb-api.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss-j
axrpc.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbossws-framew
ork.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jaxws-rt.jar /ho
me/grid/softinstall/jboss-4.2.3.GA/client/jboss-jsr77-client.jar /hom
e/grid/softinstall/jboss-4.2.3.GA/client/trove.jar /home/grid/softins
tall/jboss-4.2.3.GA/client/jbossws-jboss42.jar /home/grid/softinstall
/jboss-4.2.3.GA/client/wstx.jar /home/grid/softinstall/jboss-4.2.3.GA
/client/stax-ex.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbos
ssx-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss-cli
ent.jar /home/grid/softinstall/jboss-4.2.3.GA/client/concurrent.jar /
home/grid/softinstall/jboss-4.2.3.GA/client/policy.jar /home/grid/sof
tinstall/jboss-4.2.3.GA/client/jaxb-xjc.jar /home/grid/softinstall/jb
oss-4.2.3.GA/client/jbossws-client.jar /home/grid/softinstall/jboss-4
.2.3.GA/client/wsdl4j.jar /home/grid/softinstall/jboss-4.2.3.GA/clien
t/streambuffer.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss
ws-common.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss-aspe
ct-jdk50-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/hibe
rnate-annotations.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jb
oss-jaxws.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbosscx-cl
ient.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jmx-invoker-ada
ptor-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jmx-clie
nt.jar /home/grid/softinstall/jboss-4.2.3.GA/client/stax-api.jar /hom
e/grid/softinstall/jboss-4.2.3.GA/client/logkit.jar /home/grid/softin
stall/jboss-4.2.3.GA/client/jboss-xml-binding.jar /home/grid/softinst
all/jboss-4.2.3.GA/client/jboss-ejb3x.jar /home/grid/softinstall/jbos
s-4.2.3.GA/client/getopt.jar /home/grid/softinstall/jboss-4.2.3.GA/cl
ient/FastInfoset.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbo
ss-system-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbo
ss-deployment.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss-
annotations-ejb3.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jbo
ss-ejb3-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jboss
jmx-ant.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jettison.jar
/home/grid/softinstall/jboss-4.2.3.GA/client/commons-codec.jar /home
/grid/softinstall/jboss-4.2.3.GA/client/jboss-saaj.jar /home/grid/sof
tinstall/jboss-4.2.3.GA/client/mail.jar /home/grid/softinstall/jboss-
4.2.3.GA/client/scout.jar /home/grid/softinstall/jboss-4.2.3.GA/clien
t/jacorb.jar /home/grid/softinstall/jboss-4.2.3.GA/client/xmlsec.jar
/home/grid/softinstall/jboss-4.2.3.GA/client/jboss-remoting.jar /home
/grid/softinstall/jboss-4.2.3.GA/client/jbossha-client.jar /home/grid
/softinstall/jboss-4.2.3.GA/client/commons-httpclient.jar /home/grid/
softinstall/jboss-4.2.3.GA/client/jboss-jaxws-ext.jar /home/grid/soft
install/jboss-4.2.3.GA/client/avalon-framework.jar /home/grid/softins
tall/jboss-4.2.3.GA/client/commons-logging.jar /home/grid/softinstall
/jboss-4.2.3.GA/client/jaxb-impl.jar /home/grid/softinstall/jboss-4.2
.3.GA/client/jbossmq-client.jar /home/grid/softinstall/jboss-4.2.3.GA
/client/jnp-client.jar /home/grid/softinstall/jboss-4.2.3.GA/client/j
avassist.jar /home/grid/softinstall/jboss-4.2.3.GA/client/log4j.jar /
home/grid/softinstall/jboss-4.2.3.GA/client/jbossws-spi.jar /home/gri
d/softinstall/jboss-4.2.3.GA/client/jboss-transaction-client.jar /hom
e/grid/softinstall/jboss-4.2.3.GA/client/jaxws-tools.jar /home/grid/s
oftinstall/jboss-4.2.3.GA/client/jboss-j2ee.jar /home/grid/softinstal
l/jboss-4.2.3.GA/client/jboss-serialization.jar /home/grid/softinstal
l/jboss-4.2.3.GA/client/jboss-aop-jdk50-client.jar /home/grid/softins
tall/jboss-4.2.3.GA/client/activation.jar /home/grid/softinstall/jbos
s-4.2.3.GA/client/ejb3-persistence.jar /home/grid/softinstall/jboss-4
.2.3.GA/client/jboss-iiop-client.jar /home/grid/softinstall/jboss-4.2
.3.GA/client/jbossall-client.jar /home/grid/softinstall/jboss-4.2.3.G
A/client/hibernate-client.jar /home/grid/softinstall/jboss-4.2.3.GA/c
lient/servlet-api.jar /home/grid/softinstall/jboss-4.2.3.GA/client/jb
oss-srp-client.jar /home/grid/softinstall/jboss-4.2.3.GA/lib/jaxb-api
.jar /home/grid/softinstall/jboss-4.2.3.GA/lib/concurrent.jar /home/g
rid/softinstall/jboss-4.2.3.GA/lib/jboss-xml-binding.jar /home/grid/s
oftinstall/jboss-4.2.3.GA/lib/getopt.jar /home/grid/softinstall/jboss
-4.2.3.GA/lib/commons-codec.jar /home/grid/softinstall/jboss-4.2.3.GA
/lib/commons-httpclient.jar /home/grid/softinstall/jboss-4.2.3.GA/lib
/jboss-jmx.jar /home/grid/softinstall/jboss-4.2.3.GA/lib/commons-logg
ing.jar /home/grid/softinstall/jboss-4.2.3.GA/lib/jaxb-impl.jar /home
/grid/softinstall/jboss-4.2.3.GA/lib/jboss-system.jar /home/grid/soft
install/jboss-4.2.3.GA/lib/log4j-boot.jar /home/grid/softinstall/jbos
s-4.2.3.GA/lib/jboss-common.jar /home/grid/softinstall/jboss-4.2.3.GA
/server/default/lib/jboss-iiop.jar /home/grid/softinstall/jboss-4.2.3
.GA/server/default/lib/jbossjta-integration.jar /home/grid/softinstal
l/jboss-4.2.3.GA/server/default/lib/antlr.jar /home/grid/softinstall/
jboss-4.2.3.GA/server/default/lib/bsh.jar /home/grid/softinstall/jbos
s-4.2.3.GA/server/default/lib/jboss.jar /home/grid/softinstall/jboss-
4.2.3.GA/server/default/lib/jboss-jaxrpc.jar /home/grid/softinstall/j
boss-4.2.3.GA/server/default/lib/hibernate3.jar /home/grid/softinstal
l/jboss-4.2.3.GA/server/default/lib/jbossws-framework.jar /home/grid/
softinstall/jboss-4.2.3.GA/server/default/lib/hsqldb-plugin.jar /home
/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jboss-hibernate.j
ar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jboss-srp
.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jboss-c
ommon-jdbc-wrapper.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/jbossws-jboss42.jar /home/grid/softinstall/jboss-4.2.3.GA/
server/default/lib/cglib.jar /home/grid/softinstall/jboss-4.2.3.GA/se
rver/default/lib/bsf.jar /home/grid/softinstall/jboss-4.2.3.GA/server
/default/lib/bindingservice-plugin.jar /home/grid/softinstall/jboss-4
.2.3.GA/server/default/lib/jboss-jsr88.jar /home/grid/softinstall/jbo
ss-4.2.3.GA/server/default/lib/jsp-api.jar /home/grid/softinstall/jbo
ss-4.2.3.GA/server/default/lib/mail-plugin.jar /home/grid/softinstall
/jboss-4.2.3.GA/server/default/lib/bsh-deployer.jar /home/grid/softin
stall/jboss-4.2.3.GA/server/default/lib/jbossws-common.jar /home/grid
/softinstall/jboss-4.2.3.GA/server/default/lib/jmx-adaptor-plugin.jar
/home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jnpserver.j
ar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/hibernate
-annotations.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default
/lib/jboss-jaxws.jar /home/grid/softinstall/jboss-4.2.3.GA/server/def
ault/lib/jboss-jca.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/scheduler-plugin-example.jar /home/grid/softinstall/jboss-
4.2.3.GA/server/default/lib/jboss-jsr77.jar /home/grid/softinstall/jb
oss-4.2.3.GA/server/default/lib/jboss-management.jar /home/grid/softi
nstall/jboss-4.2.3.GA/server/default/lib/autonumber-plugin.jar /home/
grid/softinstall/jboss-4.2.3.GA/server/default/lib/jboss-ejb3x.jar /h
ome/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jboss-remoting
-int.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/log
4j-snmp-appender.jar /home/grid/softinstall/jboss-4.2.3.GA/server/def
ault/lib/commons-codec.jar /home/grid/softinstall/jboss-4.2.3.GA/serv
er/default/lib/quartz.jar /home/grid/softinstall/jboss-4.2.3.GA/serve
r/default/lib/jboss-saaj.jar /home/grid/softinstall/jboss-4.2.3.GA/se
rver/default/lib/dom4j.jar /home/grid/softinstall/jboss-4.2.3.GA/serv
er/default/lib/mail.jar /home/grid/softinstall/jboss-4.2.3.GA/server/
default/lib/jboss-remoting.jar /home/grid/softinstall/jboss-4.2.3.GA/
server/default/lib/jboss-monitoring.jar /home/grid/softinstall/jboss-
4.2.3.GA/server/default/lib/commons-httpclient.jar /home/grid/softins
tall/jboss-4.2.3.GA/server/default/lib/jboss-jaxws-ext.jar /home/grid
/softinstall/jboss-4.2.3.GA/server/default/lib/hsqldb.jar /home/grid/
softinstall/jboss-4.2.3.GA/server/default/lib/el-api.jar /home/grid/s
oftinstall/jboss-4.2.3.GA/server/default/lib/xmlentitymgr.jar /home/g
rid/softinstall/jboss-4.2.3.GA/server/default/lib/commons-logging.jar
/home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jbossjta.ja
r /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/scheduler-
plugin.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/p
roperties-plugin.jar /home/grid/softinstall/jboss-4.2.3.GA/server/def
ault/lib/javassist.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/log4j.jar /home/grid/softinstall/jboss-4.2.3.GA/server/def
ault/lib/jbossws-spi.jar /home/grid/softinstall/jboss-4.2.3.GA/server
/default/lib/jaxen.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/jboss-transaction.jar /home/grid/softinstall/jboss-4.2.3.G
A/server/default/lib/bcel.jar /home/grid/softinstall/jboss-4.2.3.GA/s
erver/default/lib/jbossts-common.jar /home/grid/softinstall/jboss-4.2
.3.GA/server/default/lib/hibernate-entitymanager.jar /home/grid/softi
nstall/jboss-4.2.3.GA/server/default/lib/jboss-j2ee.jar /home/grid/so
ftinstall/jboss-4.2.3.GA/server/default/lib/jboss-serialization.jar /
home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/jbosssx.jar /
home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/activation.ja
r /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/joesnmp.ja
r /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/ejb3-persi
stence.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/lib/c
ommons-collections.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/jbossmq.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/lib/jboss-vfs.jar /home/grid/softinstall/jboss-4.2.3.GA/server
/default/lib/servlet-api.jar /home/grid/softinstall/jboss-4.2.3.GA/se
rver/default/deploy/jboss-web.deployer/jsf-libs/jsf-api.jar /home/gri
d/softinstall/jboss-4.2.3.GA/server/default/deploy/jboss-web.deployer
/jsf-libs/jsf-impl.jar /home/grid/softinstall/jboss-4.2.3.GA/server/d
efault/deploy/jboss-web.deployer/jsf-libs/jboss-faces.jar /home/grid/
softinstall/jboss-4.2.3.GA/server/default/deploy/jboss-aop-jdk50.depl
oyer/trove.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/d
eploy/jboss-aop-jdk50.deployer/jboss-aspect-library-jdk50.jar /home/g
rid/softinstall/jboss-4.2.3.GA/server/default/deploy/jboss-aop-jdk50.
deployer/pluggable-instrumentor.jar /home/grid/softinstall/jboss-4.2.
3.GA/server/default/deploy/jboss-aop-jdk50.deployer/jrockit-pluggable
-instrumentor.jar /home/grid/softinstall/jboss-4.2.3.GA/server/defaul
t/deploy/jboss-aop-jdk50.deployer/jboss-aop-jdk50.jar /home/grid/soft
install/jboss-4.2.3.GA/server/default/deploy/ejb3.deployer/jboss-ejb3
.jar /home/grid/softinstall/jboss-4.2.3.GA/server/default/deploy/ejb3
.deployer/jboss-annotations-ejb3.jar /home/grid/Download/CreditCheckW
ebService/build/ /home/grid/Download/CreditCheckWebService/src/ /home
/grid/softinstall/jdk1.5.0_15/jre/lib/rt.jar /home/grid/softinstall/j
dk1.5.0_15/jre/lib/jsse.jar /home/grid/softinstall/jdk1.5.0_15/jre/li
b/jce.jar /home/grid/softinstall/jdk1.5.0_15/jre/lib/charsets.jar /ho
me/grid/softinstall/jdk1.5.0_15/jre/lib/ext/dnsns.jar /home/grid/soft
install/jdk1.5.0_15/jre/lib/ext/localedata.jar /home/grid/softinstall
/jdk1.5.0_15/jre/lib/ext/sunpkcs11.jar /home/grid/softinstall/jdk1.5.
0_15/jre/lib/ext/sunjce_provider.jar
9:55 p.m.
>
> 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 ?
/max
3:26 a.m.
>>
>> 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?
/max
4:12 a.m.
I'll work with grid today to investigate a launch config solution.
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?
>
> /max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:27 a.m.
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.
/max
10:43 a.m.
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.
What idea?
Grid
/max
1:03 p.m.
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
5665
days inactive
5678
days old
jbosstools-dev@lists.jboss.org
20 comments
3 participants
participants (3)
-
feng.qian -
Max Rydahl Andersen -
Rob Stryker