Menu
▾
▴
Re: [Wrapper-user] are any of these features I have added desirable in the wrapper code base
|
From: Glen <gle...@mo...> - 2005-02-16 20:08:52
|
I forgot about using the command line java vm arg -server. Thanks!!!!
You my be surprised but I agree with you. Which is why I was thinking
of having a separate executable for the more app-like stuff (versus the
service-like stuff). Sharing code where applicable.
Ultimately my question is, is this desired in the JSW code base? Or
better as my own project to be possibly merged later?
So of the features I mentioned originally
1.SERVICE and APP - auto creation of the java program if using the
java.command.name parm and the specified value does not exist. This is
configurable the default is to NOT do it.
2.NOT NEEDED - choose hotspot/server/client VM no longer needed
3. APP - have a special executable that is app mode only. It will no
tlook for any commadn line parms (-i -c etc) instead it will look for a
.conf file of the same name as the executable. So myapp.exe would be
maypp.conf
4. APP - linked to 3 invoke the JVM in the same process (configurable
would cause several other config options to be ignored for example
java.command.name)
nic...@uk... wrote:
>
>
>>>The VM to use (client/server/hotspot) is pertinent regardless of app or
>>>service.
>>>
>>>
>We just use a command-line parameter ("-server" or whatever)
>
>
>
>>>You are right about the others they are specific to using JSW to run
>>>apps. Which is why I have a wrapperw.exe which is separate and distinct
>>>from wrapper.exe. Wrapperw.exe has allthe cool app features I mentioned
>>>(though I rename the wrapperw.exe to myapp.exe) and I still use
>>>wrapper.exe for running services.
>>>The idea here is that from my research of the various java start
>>>products JSW is by far hte most mature so why not use the excelent code
>>>base to make a great app launcher too.
>>>
>>>
>
>Its only my personal opinion, but it appears to me that a Generic App
>Launcher is a seperate project.
>Perhaps JSW would be an excellent starting point.
>
>JSW is one of the nicest OSS projects I have seen. It addresses one
>problem, and does it very well (I dont think these two facts are
>coincidental).
>It would be a shame to see that focus diluted.
>But thats just my opinion :-)
>
>-Nick
>
>
>
>
>
>
>Internet
>gle...@mo...@lists.sourceforge.net - 15/02/2005 15:15
>
>
>Please respond to wra...@li...
>
>Sent by: wra...@li...
>
>
>
>To: wrapper-user
>
>cc:
>
>
>Subject: Re: [Wrapper-user] are any of these features I have added
> desirable in the wrapper code base
>
>
>The VM to use (client/server/hotspot) is pertinent regardless of app or
>service.
>
>You are right about the others they are specific to using JSW to run
>apps. Which is why I have a wrapperw.exe which is separate and distinct
>from wrapper.exe. Wrapperw.exe has allthe cool app features I mentioned
>(though I rename the wrapperw.exe to myapp.exe) and I still use
>wrapper.exe for running services.
>
>The idea here is that from my research of the various java start
>products JSW is by far hte most mature so why not use the excelent code
>base to make a great app launcher too.
>
>
>
>
>nic...@uk... wrote:
>
>
>
>> It seems most of these enhancements are centred around a generic
>> java-executable-wrapper rather than a "service wrapper".
>> The latter being for server, long running, tasks...
>>
>> Is that where JSW wants to go?
>> Its quite a different goal...
>>
>> -Nick
>>
>>
>>
>>
>>
>>
>>Internet
>>gle...@ap...@lists.sourceforge.net - 15/02/2005 03:39
>>
>>
>>Please respond to wra...@li...
>>
>>Sent by: wra...@li...
>>
>>
>>
>>To: wrapper-user
>>
>>cc:
>>
>>
>>Subject: [Wrapper-user] are any of these features I have added
>>
>>
>desirable
>
>
>> in the wrapper code base
>>
>>
>>Hi All,
>>I have added a few options to java service wrapper and I am wondeirng
>>if they are desirable for the main branch. Here they are
>>
>> * An option to create the java command specified in the
>> "wrapper.java.command" property if it doesn't already exist. This
>> is a simplification for me. Before I did this I would just have a
>> scrpit run to create all the java command copies I needed, which
>> worked but was more maintenance. With this I have more
>> flexibility (like if I think a java comand is not used anymore I
>> can just delete it knowing that the wrapper will recreate it if
>> needed)
>> * An altered wrapperw.exe that runs as a console application and
>> looks for a .conf file in the same directory with the same base
>> name as the wrapperw.exe. So if the wrapperw.exe is renamed to
>> myprog.exe it will look for myprog.conf. Also any command line
>> arguments are passed directly into the java app. This allows one
>> to use myprog.exe as a windows explorer file handler with minimum
>> effort. If you use the wrapper.exe as is you would have to go
>> into the registry and add the appropriate command line parms (-c
>> myprog.conf). I implemented this as a completely new executable
>> since all the options (-c -t -p -i -r -?) are still there just as
>> (--c --t --p --i --r --?)
>> * An option for running in console mode to run the java app in the
>> same process as wrapper.exe. Now I know this sort of defeats the
>> robustness that the java service wrapper offers but for "quick
>> click" utilities it is simpler and slightly less resource intensive.
>> * An option to choose the JIT (client or server). This currently
>> only works on win32 since I don't currently vae a linux machine to
>> play with but I am fairly certain I could make it portable with
>> minimum effort. Also questions about hwo this should work with
>> non-sun jvm's
>>
>>
>>If these ideas are desirable I am willing to code it (currently it is
>>50% hack 50% clean by code it I mean make it 100% clean). I am also
>>open to alternative ways of implementing.
>>
>>Let me know what you all think.
>>
>>regards,
>>Glen
>>
>>
>>(See attached file: C.htm)
>>
>>This message and any attachments (the "message") is
>>intended solely for the addressees and is confidential.
>>If you receive this message in error, please delete it and
>>immediately notify the sender. Any use not in accord with
>>its purpose, any dissemination or disclosure, either whole
>>or partial, is prohibited except formal approval. The internet
>>can not guarantee the integrity of this message.
>>BNP PARIBAS (and its subsidiaries) shall (will) not
>>therefore be liable for the message if modified.
>>
>>**********************************************************************************************
>>
>>
>
>
>
>>BNP Paribas Private Bank London Branch is authorised
>>by CECEI & AMF and is regulated by the Financial Services
>>Authority for the conduct of its investment business in the
>>United Kingdom.
>>
>>BNP Paribas Securities Services London Branch is authorised
>>by CECEI & AMF and is regulated by the Financial Services
>>Authority for the conduct of its investment business in the
>>United Kingdom.
>>
>>BNP Paribas Fund Services UK Limited is authorised and
>>regulated by the Financial Services Authority.
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>Hi All,
>>I have added a few options to java service wrapper and I am wondeirng
>>if they are desirable for the main branch. Here they are
>>
>> * An option to create the java command specified in the
>> "wrapper.java.command" property if it doesn't already exist.
>> This is a simplification for me. Before I did this I would just
>> have a scrpit run to create all the java command copies I
>> needed, which worked but was more maintenance. With this I have
>> more flexibility (like if I think a java comand is not used
>> anymore I can just delete it knowing that the wrapper will
>> recreate it if needed)
>> * An altered wrapperw.exe that runs as a console application and
>> looks for a .conf file in the same directory with the same base
>> name as the wrapperw.exe. So if the wrapperw.exe is renamed to
>> myprog.exe it will look for myprog.conf. Also any command line
>> arguments are passed directly into the java app. This allows
>> one to use myprog.exe as a windows explorer file handler with
>> minimum effort. If you use the wrapper.exe as is you would
>> have to go into the registry and add the appropriate command
>> line parms (-c myprog.conf). I implemented this as a completely
>> new executable since all the options (-c -t -p -i -r -?) are
>> still there just as (--c --t --p --i --r --?)
>> * An option for running in console mode to run the java app in the
>> same process as wrapper.exe. Now I know this sort of defeats
>> the robustness that the java service wrapper offers but for
>> "quick click" utilities it is simpler and slightly less resource
>> intensive.
>> * An option to choose the JIT (client or server). This currently
>> only works on win32 since I don't currently vae a linux machine
>> to play with but I am fairly certain I could make it portable
>> with minimum effort. Also questions about hwo this should work
>> with non-sun jvm's
>>
>>
>>If these ideas are desirable I am willing to code it (currently it is
>>50% hack 50% clean by code it I mean make it 100% clean). I am also
>>open to alternative ways of implementing.
>>
>>Let me know what you all think.
>>
>>regards,
>>Glen
>>
>>
>>
>
>
>(See attached file: C.htm)
>
>This message and any attachments (the "message") is
>intended solely for the addressees and is confidential.
>If you receive this message in error, please delete it and
>immediately notify the sender. Any use not in accord with
>its purpose, any dissemination or disclosure, either whole
>or partial, is prohibited except formal approval. The internet
>can not guarantee the integrity of this message.
>BNP PARIBAS (and its subsidiaries) shall (will) not
>therefore be liable for the message if modified.
>
>**********************************************************************************************
>
>BNP Paribas Private Bank London Branch is authorised
>by CECEI & AMF and is regulated by the Financial Services
>Authority for the conduct of its investment business in the
>United Kingdom.
>
>BNP Paribas Securities Services London Branch is authorised
>by CECEI & AMF and is regulated by the Financial Services
>Authority for the conduct of its investment business in the
>United Kingdom.
>
>BNP Paribas Fund Services UK Limited is authorised and
>regulated by the Financial Services Authority.
>
>
>
>
> ------------------------------------------------------------------------
>
> The VM to use (client/server/hotspot) is pertinent regardless of app
> or service.
>
> You are right about the others they are specific to using JSW to run
> apps. Which is why I have a wrapperw.exe which is separate and
> distinct from wrapper.exe. Wrapperw.exe has allthe cool app features
> I mentioned (though I rename the wrapperw.exe to myapp.exe) and I
> still use wrapper.exe for running services.
>
> The idea here is that from my research of the various java start
> products JSW is by far hte most mature so why not use the excelent
> code base to make a great app launcher too.
>
>
>
>
> nic...@uk... wrote:
>
>> It seems most of these enhancements are centred around a generic
>> java-executable-wrapper rather than a "service wrapper".
>> The latter being for server, long running, tasks...
>>
>> Is that where JSW wants to go?
>> Its quite a different goal...
>>
>> -Nick
>>
>>
>>
>>
>>
>>
>>Internet
>>gle...@ap...@lists.sourceforge.net - 15/02/2005 03:39
>>
>>
>>Please respond to wra...@li...
>>
>>Sent by: wra...@li...
>>
>>
>>
>>To: wrapper-user
>>
>>cc:
>>
>>
>>Subject: [Wrapper-user] are any of these features I have added desirable
>> in the wrapper code base
>>
>>
>>Hi All,
>>I have added a few options to java service wrapper and I am wondeirng
>>if they are desirable for the main branch. Here they are
>>
>> * An option to create the java command specified in the
>> "wrapper.java.command" property if it doesn't already exist. This
>> is a simplification for me. Before I did this I would just have a
>> scrpit run to create all the java command copies I needed, which
>> worked but was more maintenance. With this I have more
>> flexibility (like if I think a java comand is not used anymore I
>> can just delete it knowing that the wrapper will recreate it if
>> needed)
>> * An altered wrapperw.exe that runs as a console application and
>> looks for a .conf file in the same directory with the same base
>> name as the wrapperw.exe. So if the wrapperw.exe is renamed to
>> myprog.exe it will look for myprog.conf. Also any command line
>> arguments are passed directly into the java app. This allows one
>> to use myprog.exe as a windows explorer file handler with minimum
>> effort. If you use the wrapper.exe as is you would have to go
>> into the registry and add the appropriate command line parms (-c
>> myprog.conf). I implemented this as a completely new executable
>> since all the options (-c -t -p -i -r -?) are still there just as
>> (--c --t --p --i --r --?)
>> * An option for running in console mode to run the java app in the
>> same process as wrapper.exe. Now I know this sort of defeats the
>> robustness that the java service wrapper offers but for "quick
>> click" utilities it is simpler and slightly less resource intensive.
>> * An option to choose the JIT (client or server). This currently
>> only works on win32 since I don't currently vae a linux machine to
>> play with but I am fairly certain I could make it portable with
>> minimum effort. Also questions about hwo this should work with
>> non-sun jvm's
>>
>>
>>If these ideas are desirable I am willing to code it (currently it is
>>50% hack 50% clean by code it I mean make it 100% clean). I am also
>>open to alternative ways of implementing.
>>
>>Let me know what you all think.
>>
>>regards,
>>Glen
>>
>>
>>(See attached file: C.htm)
>>
>>This message and any attachments (the "message") is
>>intended solely for the addressees and is confidential.
>>If you receive this message in error, please delete it and
>>immediately notify the sender. Any use not in accord with
>>its purpose, any dissemination or disclosure, either whole
>>or partial, is prohibited except formal approval. The internet
>>can not guarantee the integrity of this message.
>>BNP PARIBAS (and its subsidiaries) shall (will) not
>>therefore be liable for the message if modified.
>>
>>**********************************************************************************************
>>
>>BNP Paribas Private Bank London Branch is authorised
>>by CECEI & AMF and is regulated by the Financial Services
>>Authority for the conduct of its investment business in the
>>United Kingdom.
>>
>>BNP Paribas Securities Services London Branch is authorised
>>by CECEI & AMF and is regulated by the Financial Services
>>Authority for the conduct of its investment business in the
>>United Kingdom.
>>
>>BNP Paribas Fund Services UK Limited is authorised and
>>regulated by the Financial Services Authority.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Hi All,
>> I have added a few options to java service wrapper and I am
>> wondeirng if they are desirable for the main branch. Here they are
>>
>> * An option to create the java command specified in the
>> "wrapper.java.command" property if it doesn't already exist.
>> This is a simplification for me. Before I did this I would
>> just have a scrpit run to create all the java command copies I
>> needed, which worked but was more maintenance. With this I
>> have more flexibility (like if I think a java comand is not
>> used anymore I can just delete it knowing that the wrapper will
>> recreate it if needed)
>> * An altered wrapperw.exe that runs as a console application and
>> looks for a .conf file in the same directory with the same base
>> name as the wrapperw.exe. So if the wrapperw.exe is renamed to
>> myprog.exe it will look for myprog.conf. Also any command line
>> arguments are passed directly into the java app. This allows
>> one to use myprog.exe as a windows explorer file handler with
>> minimum effort. If you use the wrapper.exe as is you would
>> have to go into the registry and add the appropriate command
>> line parms (-c myprog.conf). I implemented this as a
>> completely new executable since all the options (-c -t -p -i -r
>> -?) are still there just as (--c --t --p --i --r --?)
>> * An option for running in console mode to run the java app in
>> the same process as wrapper.exe. Now I know this sort of
>> defeats the robustness that the java service wrapper offers but
>> for "quick click" utilities it is simpler and slightly less
>> resource intensive.
>> * An option to choose the JIT (client or server). This currently
>> only works on win32 since I don't currently vae a linux machine
>> to play with but I am fairly certain I could make it portable
>> with minimum effort. Also questions about hwo this should work
>> with non-sun jvm's
>>
>>
>> If these ideas are desirable I am willing to code it (currently it is
>> 50% hack 50% clean by code it I mean make it 100% clean). I am also
>> open to alternative ways of implementing.
>>
>> Let me know what you all think.
>>
>> regards,
>> Glen
>>
>
|
