Hi Guys,
If this is a case that needs to be covered there are numerous ways to do it.
One way is to call the com.sun.enterprise.tools.launcher.ProcessLauncher
directly with the proper settings (like the ones in the
/domaindir//bin/startserv script). But this call will invoke another
process. I believe a new process is currently necessary because of the
log manager settings as well as the other factories.
The ProcessLauncher can also hold (not detach) the process that has been
executed so it can be watch-dogged. This is how the EEInstancesManager
starts the server instances in the SE product, so the instances can be
monitored. This can be done by setting the
"-Dcom.sun.aas.launcherReturn" property of the ProcessLauncher to
something other than "return".
Hope this helps - Mark
Kedar Mhaswade wrote:
>
>
> Lloyd L Chambers wrote:
>
>> Perhaps I'm mistaken...what I meant was that if a JVM is running,
>> there isn't a way to set system properties that would normally be
>> set when launching a new process (JVM), since an in-process start of
>> the appserver doesn't create a new process. Is that an invalid
>> assumption eg is there a setSystemProperty() call somewhere?
>
>
> Oh no, you are right, but we can make the launching VM to provide
> some important system properties that cannot be set/reset later
> (Note: not all system properties are of this kind)
> and make the launching VM have all the java command invocation
> parameters.
>
> If the user is not ready to undertake provision of these (would be)
> documented
> properties, then it appears to be imperative to exec another VM.
>
> Another problem with having to launch the app server in a given VM
> is that of (lack of) isolation. What if app server crashes? It is
> going to crash
> the launching VM that user started. So, in some cases, it does make
> sense to exec/spawn a separate VM. That's what asadmin start-domain
> does (eventually), today.
>
>>
>> I agree exec'ing another process is perfectly fine, and probably
>> won't dig up a can of other worms in trying to run Appserver in an
>> existing JVM; AppServer pretty much assumes it has a "clean slate"
>> when main() is called.
>>
>> Lloyd
>>
>> On Jul 11, 2006, at 3:45 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Lloyd L Chambers wrote:
>>>
>>>> This is a feature we are considering for 9.1. It’s a bit tricky
>>>> though, given the JVM startup parameters.
>>>> Were we to provide an API, it might need to do the same exec()
>>>> call unless we are willing to include native code.
>>>
>>>
>>>
>>> Not sure about native code being required.
>>> Are you absolutely sure about this?
>>>
>>> Regarding the original question, I think we should understand the
>>> intent.
>>> It appears to me that you want to start the app server in a given
>>> VM. Is
>>> that right? I think this resembles Kohsuke's earlier requirement that
>>> he expressed in another e-mail thread regarding embedded GlassFish.
>>> Can someone file an enhancement request detailing the requirement, use
>>> cases and why exec'ing asadmin is not practical/useful.
>>>
>>> Thanks,
>>> Kedar
>>>
>>>> On Jul 11, 2006, at 3:08 PM, vince kraemer wrote:
>>>>
>>>>> I am looking for an API that can be used to start a GF domain
>>>>> that is callable from a java application, instead of something
>>>>> like Runtime.getRuntime().exec( <asadmin start-domain> ).
>>>>>
>>>>> Thanks,
>>>>> vbk
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>