Menu
▾
▴
wrapper-user
|
From: Jim R. <jr...@er...> - 2006-03-29 13:49:48
|
Does anyone else have a use for the feature where the name of the config file maps to the name of the application? It allows two applications in the same directory without adding arguments to the application and so is much cleaner. For example, MyApp.exe looks for MyApp.conf AnotherApp.exe looks for AnotherApp.conf etc. It then looks for wrapper.conf if the app-specific wrapper does not exist. We need to make this change to the lastest exe. If it's of general interest, I'll try and do it cleanly and create a diff. Otherwise I'll just hack it in there. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com |
|
From: Michael 'b. S. <msc...@gi...> - 2006-03-30 06:40:23
|
Oh yes, that would be perfect. We hacked the source here to add "fixed parameters" if none where given. A change like that would be just perfect.</repeat> Michael On Wed, 29 Mar 2006 - 6:49am, Jim Redman wrote: > Does anyone else have a use for the feature where the name of the config file > maps to the name of the application? > > It allows two applications in the same directory without adding arguments to > the application and so is much cleaner. For example, > > MyApp.exe looks for MyApp.conf > AnotherApp.exe looks for AnotherApp.conf > > etc. It then looks for wrapper.conf if the app-specific wrapper does not > exist. > > We need to make this change to the lastest exe. If it's of general interest, > I'll try and do it cleanly and create a diff. Otherwise I'll just hack it in > there. > > Jim > > -- I love deadlines, especially the sound they make as they go whooshing by. |
|
From: Tony S. <to...@ci...> - 2006-03-30 09:47:58
|
Gets my vote too - would simplify my install scripts. regards Tony > Oh yes, that would be perfect. > We hacked the source here to add "fixed parameters" if none where given. > > A change like that would be just perfect.</repeat> > > Michael > >> Does anyone else have a use for the feature where the name of the config file >> maps to the name of the application? >> >> It allows two applications in the same directory without adding arguments to >> the application and so is much cleaner. For example, >> >> MyApp.exe looks for MyApp.conf >> AnotherApp.exe looks for AnotherApp.conf >> >> etc. It then looks for wrapper.conf if the app-specific wrapper does not >> exist. >> >> We need to make this change to the lastest exe. If it's of general interest, >> I'll try and do it cleanly and create a diff. Otherwise I'll just hack it in >> there. >> >> Jim >> >> >> > > > |
|
From: Leif M. <le...@ta...> - 2006-03-31 03:57:33
|
Jim and all,
Ok. This sounds like a good idea. I took the opportunity to also
synchronize the
unix and Windows command line syntaxes. Their old formats are now supported
everywhere.
Here is the new usage:
-----
C:\MyApp\bin>wrapper.exe
Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
Usage:
wrapper.exe <command> <configuration file> [configuration properties]
[...]
wrapper.exe <configuration file> [configuration properties] [...]
(<command> implicitly '-c')
wrapper.exe <command>
(<configuration file> implicitly 'wrapper.conf')
wrapper.exe
(<command> implicitly '-c' and <configuration file> 'wrapper.conf')
where <command> can be one of:
-c --console run as a Console application
-t --start starT an NT service
-p --stop stoP a running NT service
-i --install Install as an NT service
-r --remove Remove as an NT service
-q --query Query the current status of the service
-qs --querysilent Silently Query the current status of the service
-? --help print this help message
<configuration file> is the wrapper.conf to use. Name must be absolute
or relative
to the location of wrapper.exe
[configuration properties] are configuration name-value pairs which
override values
in wrapper.conf. For example:
wrapper.debug=true
-----
The Windows only commands are of course invalid on UNIX.
This is all implemented and will be in the 3.2.1 release.
SourceForge's CVS is being
stubborn at the moment though, so I'll have to commit it later.
Cheers,
Leif
Jim Redman wrote:
> Does anyone else have a use for the feature where the name of the
> config file maps to the name of the application?
>
> It allows two applications in the same directory without adding
> arguments to the application and so is much cleaner. For example,
>
> MyApp.exe looks for MyApp.conf
> AnotherApp.exe looks for AnotherApp.conf
>
> etc. It then looks for wrapper.conf if the app-specific wrapper does
> not exist.
>
> We need to make this change to the lastest exe. If it's of general
> interest, I'll try and do it cleanly and create a diff. Otherwise
> I'll just hack it in there.
>
> Jim
>
|
|
From: Michael 'b. S. <msc...@gi...> - 2006-04-03 07:51:51
|
Good morning.
On Fri, 31 Mar 2006 - 12:57pm, Leif Mortenson wrote:
> wrapper.exe
> (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
Does that mean
foobar.exe
(<command> implicitly '-c' and <configuration file> 'foobar.conf') ?
> This is all implemented and will be in the 3.2.1 release. SourceForge's
> CVS is being stubborn at the moment though, so I'll have to commit it later.
Switch to Berlios then. SF is broken really often and has lags for anymous
cvs...
Just an idea. ;^)
Greetings,
Michael
--
I love deadlines, especially the sound they make as they go whooshing by.
|
|
From: Leif M. <le...@ta...> - 2006-04-04 14:55:03
|
Michael 'buk' Scherer wrote: >> wrapper.exe >> (<command> implicitly '-c' and <configuration file> 'wrapper.conf') >> > Does that mean > foobar.exe > (<command> implicitly '-c' and <configuration file> 'foobar.conf') ? > That is correct. The usage is generated dynamically based on the name of the binary. >> This is all implemented and will be in the 3.2.1 release. SourceForge's >> CVS is being stubborn at the moment though, so I'll have to commit it later. >> > Switch to Berlios then. SF is broken really often and has lags for anymous > cvs... > Just an idea. ;^) > SF isn't always perfect. But I have been happy with them over all. Been hosting the project here since 2001 I believe. Cheers, Leif |
|
From: Jim R. <jr...@er...> - 2006-04-04 15:19:25
|
Leif, Before I did through the code, does this "also" mean that you have made the changes as proposed so that the wrapper configuration file name follows the executable name or do I need to download the source and make changes? Jim Leif Mortenson wrote: > Jim and all, > Ok. This sounds like a good idea. I took the opportunity to also > synchronize the > unix and Windows command line syntaxes. Their old formats are now > supported > everywhere. > > Here is the new usage: > ----- > C:\MyApp\bin>wrapper.exe > Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org > > Usage: > wrapper.exe <command> <configuration file> [configuration properties] > [...] > wrapper.exe <configuration file> [configuration properties] [...] > (<command> implicitly '-c') > wrapper.exe <command> > (<configuration file> implicitly 'wrapper.conf') > wrapper.exe > (<command> implicitly '-c' and <configuration file> 'wrapper.conf') > > where <command> can be one of: > -c --console run as a Console application > -t --start starT an NT service > -p --stop stoP a running NT service > -i --install Install as an NT service > -r --remove Remove as an NT service > -q --query Query the current status of the service > -qs --querysilent Silently Query the current status of the service > -? --help print this help message > > <configuration file> is the wrapper.conf to use. Name must be absolute > or relative > to the location of wrapper.exe > > [configuration properties] are configuration name-value pairs which > override values > in wrapper.conf. For example: > wrapper.debug=true > ----- > > The Windows only commands are of course invalid on UNIX. > > This is all implemented and will be in the 3.2.1 release. > SourceForge's CVS is being > stubborn at the moment though, so I'll have to commit it later. > > Cheers, > Leif > > Jim Redman wrote: >> Does anyone else have a use for the feature where the name of the >> config file maps to the name of the application? >> >> It allows two applications in the same directory without adding >> arguments to the application and so is much cleaner. For example, >> >> MyApp.exe looks for MyApp.conf >> AnotherApp.exe looks for AnotherApp.conf >> >> etc. It then looks for wrapper.conf if the app-specific wrapper does >> not exist. >> >> We need to make this change to the lastest exe. If it's of general >> interest, I'll try and do it cleanly and create a diff. Otherwise >> I'll just hack it in there. >> >> Jim >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com |
|
From: Leif M. <le...@ta...> - 2006-04-04 15:59:15
|
Jim,
Yes. It defaults to the base name of the exe + ".conf" in the same
directory. Works
the same on unix as well.
This is all implemented, but CVS is down, so it is not yet committed.
Cheers,
Leif
Jim Redman wrote:
> Leif,
>
> Before I did through the code, does this "also" mean that you have
> made the changes as proposed so that the wrapper configuration file
> name follows the executable name or do I need to download the source
> and make changes?
>
> Jim
>
> Leif Mortenson wrote:
>> Jim and all,
>> Ok. This sounds like a good idea. I took the opportunity to also
>> synchronize the
>> unix and Windows command line syntaxes. Their old formats are now
>> supported
>> everywhere.
>>
>> Here is the new usage:
>> -----
>> C:\MyApp\bin>wrapper.exe
>> Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
>>
>> Usage:
>> wrapper.exe <command> <configuration file> [configuration
>> properties] [...]
>> wrapper.exe <configuration file> [configuration properties] [...]
>> (<command> implicitly '-c')
>> wrapper.exe <command>
>> (<configuration file> implicitly 'wrapper.conf')
>> wrapper.exe
>> (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
>>
>> where <command> can be one of:
>> -c --console run as a Console application
>> -t --start starT an NT service
>> -p --stop stoP a running NT service
>> -i --install Install as an NT service
>> -r --remove Remove as an NT service
>> -q --query Query the current status of the service
>> -qs --querysilent Silently Query the current status of the service
>> -? --help print this help message
>>
>> <configuration file> is the wrapper.conf to use. Name must be
>> absolute or relative
>> to the location of wrapper.exe
>>
>> [configuration properties] are configuration name-value pairs which
>> override values
>> in wrapper.conf. For example:
>> wrapper.debug=true
>> -----
>>
>> The Windows only commands are of course invalid on UNIX.
>>
>> This is all implemented and will be in the 3.2.1 release.
>> SourceForge's CVS is being
>> stubborn at the moment though, so I'll have to commit it later.
>>
>> Cheers,
>> Leif
>>
>> Jim Redman wrote:
>>> Does anyone else have a use for the feature where the name of the
>>> config file maps to the name of the application?
>>>
>>> It allows two applications in the same directory without adding
>>> arguments to the application and so is much cleaner. For example,
>>>
>>> MyApp.exe looks for MyApp.conf
>>> AnotherApp.exe looks for AnotherApp.conf
>>>
>>> etc. It then looks for wrapper.conf if the app-specific wrapper
>>> does not exist.
>>>
>>> We need to make this change to the lastest exe. If it's of general
>>> interest, I'll try and do it cleanly and create a diff. Otherwise
>>> I'll just hack it in there.
>>>
>>> Jim
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
|
|
From: Jim R. <jr...@er...> - 2006-04-06 16:58:40
|
We have a graphical application that we run as an .exe using the wrapper. It restarts on a timeout: ERROR | wrapper | 2006/04/07 00:08:05 | JVM appears hung: Timed out waiting for signal from JVM. ERROR | wrapper | 2006/04/07 00:08:05 | JVM did not exit on request, terminated I don't really case about the wrapper timeout, the application is interactive and the user can take care of real problems, but I'm wondering what we're doing that's causing a problem. Are the "pings" sent from the Java Event thread? The application could use a little optimization and is a memory hog. We tend to go into phases in the program where we'll take 100% CPU time, such as compiling applications, so we get, eg this: INFO | wrapper | 2006/04/06 23:32:15 | Wrapper Process has not received any CPU time for 141 seconds. Extending timeouts. but even during this the screen is repainting (usually and slowly). Not too important, but any thoughts appreciated. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com |
|
From: Eyal Bar-I. <ey...@gm...> - 2006-04-07 07:00:46
|
Jim, It could be a Full GC that takes too long use the "-verbose:gc" flag to see if it happnes when you have a Full GC Eyal On 4/6/06, Jim Redman <jr...@er...> wrote: > > We have a graphical application that we run as an .exe using the > wrapper. It restarts on a timeout: > > ERROR | wrapper | 2006/04/07 00:08:05 | JVM appears hung: Timed out > waiting for signal from JVM. > ERROR | wrapper | 2006/04/07 00:08:05 | JVM did not exit on request, > terminated > > I don't really case about the wrapper timeout, the application is > interactive and the user can take care of real problems, but I'm > wondering what we're doing that's causing a problem. > > Are the "pings" sent from the Java Event thread? The application > could use a little optimization and is a memory hog. We tend to go into > phases in the program where we'll take 100% CPU time, such as compiling > applications, so we get, eg this: > > INFO | wrapper | 2006/04/06 23:32:15 | Wrapper Process has not > received any CPU time for 141 seconds. Extending timeouts. > > but even during this the screen is repainting (usually and slowly). > > Not too important, but any thoughts appreciated. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
|
From: Leif M. <le...@ta...> - 2006-04-10 02:27:01
|
Jim,
What version of the Wrapper are you using? If 3.1.2, try setting the
wrapper.use_system_time=FALSE property. It is default in 3.2.0. This
new timing
mechanism handles heavily loaded systems much better.
If that fails, it may be necessary to set the following two timeout
properties.
Be sure to familiarize yourself with the docs of any of these properties
before
setting them however.
wrapper.cpu.timeout=180
wrapper.ping.timeout=300
http://wrapper.tanukisoftware.org/doc/english/prop-cpu-timeout.html
http://wrapper.tanukisoftware.org/doc/english/prop-ping-timeout.html
These will probably get rid of the problems you are seeing, but they
will
also slow down the Wrapper's ability to recover from a crashed jvm.
Cheers,
Leif
Jim Redman wrote:
> We have a graphical application that we run as an .exe using the
> wrapper. It restarts on a timeout:
>
> ERROR | wrapper | 2006/04/07 00:08:05 | JVM appears hung: Timed out
> waiting for signal from JVM.
> ERROR | wrapper | 2006/04/07 00:08:05 | JVM did not exit on request,
> terminated
>
> I don't really case about the wrapper timeout, the application is
> interactive and the user can take care of real problems, but I'm
> wondering what we're doing that's causing a problem.
>
> Are the "pings" sent from the Java Event thread? The application
> could use a little optimization and is a memory hog. We tend to go
> into phases in the program where we'll take 100% CPU time, such as
> compiling applications, so we get, eg this:
>
> INFO | wrapper | 2006/04/06 23:32:15 | Wrapper Process has not
> received any CPU time for 141 seconds. Extending timeouts.
>
> but even during this the screen is repainting (usually and slowly).
>
> Not too important, but any thoughts appreciated.
>
> Jim
>
|
|
From: Jim R. <jr...@er...> - 2006-04-21 15:32:17
|
Leif, Leif Mortenson wrote: > Jim, > Yes. It defaults to the base name of the exe + ".conf" in the same > directory. Works > the same on unix as well. > > This is all implemented, but CVS is down, so it is not yet committed. Any chance of a checkin or a 3.2.1 build? Jim > > Cheers, > Leif > > Jim Redman wrote: >> Leif, >> >> Before I did through the code, does this "also" mean that you have >> made the changes as proposed so that the wrapper configuration file >> name follows the executable name or do I need to download the source >> and make changes? >> >> Jim >> >> Leif Mortenson wrote: >>> Jim and all, >>> Ok. This sounds like a good idea. I took the opportunity to also >>> synchronize the >>> unix and Windows command line syntaxes. Their old formats are now >>> supported >>> everywhere. >>> >>> Here is the new usage: >>> ----- >>> C:\MyApp\bin>wrapper.exe >>> Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org >>> >>> Usage: >>> wrapper.exe <command> <configuration file> [configuration >>> properties] [...] >>> wrapper.exe <configuration file> [configuration properties] [...] >>> (<command> implicitly '-c') >>> wrapper.exe <command> >>> (<configuration file> implicitly 'wrapper.conf') >>> wrapper.exe >>> (<command> implicitly '-c' and <configuration file> 'wrapper.conf') >>> >>> where <command> can be one of: >>> -c --console run as a Console application >>> -t --start starT an NT service >>> -p --stop stoP a running NT service >>> -i --install Install as an NT service >>> -r --remove Remove as an NT service >>> -q --query Query the current status of the service >>> -qs --querysilent Silently Query the current status of the service >>> -? --help print this help message >>> >>> <configuration file> is the wrapper.conf to use. Name must be >>> absolute or relative >>> to the location of wrapper.exe >>> >>> [configuration properties] are configuration name-value pairs which >>> override values >>> in wrapper.conf. For example: >>> wrapper.debug=true >>> ----- >>> >>> The Windows only commands are of course invalid on UNIX. >>> >>> This is all implemented and will be in the 3.2.1 release. >>> SourceForge's CVS is being >>> stubborn at the moment though, so I'll have to commit it later. >>> >>> Cheers, >>> Leif >>> >>> Jim Redman wrote: >>>> Does anyone else have a use for the feature where the name of the >>>> config file maps to the name of the application? >>>> >>>> It allows two applications in the same directory without adding >>>> arguments to the application and so is much cleaner. For example, >>>> >>>> MyApp.exe looks for MyApp.conf >>>> AnotherApp.exe looks for AnotherApp.conf >>>> >>>> etc. It then looks for wrapper.conf if the app-specific wrapper >>>> does not exist. >>>> >>>> We need to make this change to the lastest exe. If it's of general >>>> interest, I'll try and do it cleanly and create a diff. Otherwise >>>> I'll just hack it in there. >>>> >>>> Jim >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by xPML, a groundbreaking scripting >>> language >>> that extends applications into web and mobile media. Attend the live >>> webcast >>> and join the prime developer group breaking into this new coding >>> territory! >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >>> _______________________________________________ >>> Wrapper-user mailing list >>> Wra...@li... >>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com |
|
From: Leif M. <le...@ta...> - 2006-04-21 19:13:17
|
Jim,
These changes have been checked in for quite a while.
Cheers,
Leif
Jim Redman wrote:
> Leif,
>
>
> Leif Mortenson wrote:
>> Jim,
>> Yes. It defaults to the base name of the exe + ".conf" in the
>> same directory. Works
>> the same on unix as well.
>>
>> This is all implemented, but CVS is down, so it is not yet committed.
>
> Any chance of a checkin or a 3.2.1 build?
>
> Jim
>
>>
>> Cheers,
>> Leif
>>
>> Jim Redman wrote:
>>> Leif,
>>>
>>> Before I did through the code, does this "also" mean that you have
>>> made the changes as proposed so that the wrapper configuration file
>>> name follows the executable name or do I need to download the source
>>> and make changes?
>>>
>>> Jim
>>>
>>> Leif Mortenson wrote:
>>>> Jim and all,
>>>> Ok. This sounds like a good idea. I took the opportunity to
>>>> also synchronize the
>>>> unix and Windows command line syntaxes. Their old formats are now
>>>> supported
>>>> everywhere.
>>>>
>>>> Here is the new usage:
>>>> -----
>>>> C:\MyApp\bin>wrapper.exe
>>>> Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
>>>>
>>>> Usage:
>>>> wrapper.exe <command> <configuration file> [configuration
>>>> properties] [...]
>>>> wrapper.exe <configuration file> [configuration properties] [...]
>>>> (<command> implicitly '-c')
>>>> wrapper.exe <command>
>>>> (<configuration file> implicitly 'wrapper.conf')
>>>> wrapper.exe
>>>> (<command> implicitly '-c' and <configuration file>
>>>> 'wrapper.conf')
>>>>
>>>> where <command> can be one of:
>>>> -c --console run as a Console application
>>>> -t --start starT an NT service
>>>> -p --stop stoP a running NT service
>>>> -i --install Install as an NT service
>>>> -r --remove Remove as an NT service
>>>> -q --query Query the current status of the service
>>>> -qs --querysilent Silently Query the current status of the service
>>>> -? --help print this help message
>>>>
>>>> <configuration file> is the wrapper.conf to use. Name must be
>>>> absolute or relative
>>>> to the location of wrapper.exe
>>>>
>>>> [configuration properties] are configuration name-value pairs which
>>>> override values
>>>> in wrapper.conf. For example:
>>>> wrapper.debug=true
>>>> -----
>>>>
>>>> The Windows only commands are of course invalid on UNIX.
>>>>
>>>> This is all implemented and will be in the 3.2.1 release.
>>>> SourceForge's CVS is being
>>>> stubborn at the moment though, so I'll have to commit it later.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> Jim Redman wrote:
>>>>> Does anyone else have a use for the feature where the name of the
>>>>> config file maps to the name of the application?
>>>>>
>>>>> It allows two applications in the same directory without adding
>>>>> arguments to the application and so is much cleaner. For example,
>>>>>
>>>>> MyApp.exe looks for MyApp.conf
>>>>> AnotherApp.exe looks for AnotherApp.conf
>>>>>
>>>>> etc. It then looks for wrapper.conf if the app-specific wrapper
>>>>> does not exist.
>>>>>
>>>>> We need to make this change to the lastest exe. If it's of
>>>>> general interest, I'll try and do it cleanly and create a diff.
>>>>> Otherwise I'll just hack it in there.
>>>>>
>>>>> Jim
>>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the
>>>> live webcast
>>>> and join the prime developer group breaking into this new coding
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>
>>>> _______________________________________________
>>>> Wrapper-user mailing list
>>>> Wra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
|
