Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-16 Thread Afkham Azeez
Please try this distribution out and let me know [1]... I have tested on Mac
and Windows and works fine. If everything goes well, I will commit this
change today.


1.
https://docs.google.com/a/wso2.com/leaf?id=0B3W7aoJmJW4wYWRmZDY4NDktZWI3ZC00ZWFmLTk2ZTQtYzhiZGU1YTM5OTMzhl=en

On Sat, Apr 16, 2011 at 11:26 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 Ah ok now I understood what you want to do .. yep sounds good.

 Only change you could do is instead of saying sh -c 'exec java ...' you
 could simply say java  Essentially you're creating a shell and
 immediately running one command so might as well run that command directly.

 Sanjiva.


 On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the java
 process to spawn a new instance, instead of the dying java process spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng
 in there. In that case you might as well just say java .. (without the
 exec at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana sanj...@wso2.com
  wrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same 
 process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have
 we used exec here? I'm trying to solve the restart issue using exit 
 codes,
 and when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787
 6880 | +1 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior 

Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-16 Thread Afkham Azeez
This solution works well on Ubuntu 10.10 as well.


On Sat, Apr 16, 2011 at 2:54 PM, Afkham Azeez az...@wso2.com wrote:

 Please try this distribution out and let me know [1]... I have tested on
 Mac and Windows and works fine. If everything goes well, I will commit this
 change today.


 1.
 https://docs.google.com/a/wso2.com/leaf?id=0B3W7aoJmJW4wYWRmZDY4NDktZWI3ZC00ZWFmLTk2ZTQtYzhiZGU1YTM5OTMzhl=en


 On Sat, Apr 16, 2011 at 11:26 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 Ah ok now I understood what you want to do .. yep sounds good.

 Only change you could do is instead of saying sh -c 'exec java ...' you
 could simply say java  Essentially you're creating a shell and
 immediately running one command so might as well run that command directly.

 Sanjiva.


 On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the java
 process to spawn a new instance, instead of the dying java process spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana sanj...@wso2.com
  wrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng
 in there. In that case you might as well just say java .. (without the
 exec at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.com wrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same 
 process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.comwrote:

 Instead of simply doing; java ... we do exec java  Why have
 we used exec here? I'm trying to solve the restart issue using exit 
 codes,
 and when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787
 6880 | +1 650 265 8311
 

Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-16 Thread Afkham Azeez
I have tested this on Mac OS x 10.6, Ubuntu 10.10 as well as Windows 7
Ultimate. The solution works perfectly on all of this platforms and hence I
have committed the code. Now we can review and resolve all issues related to
memory leaks on restart.

Azeez

On Sat, Apr 16, 2011 at 3:25 PM, Afkham Azeez az...@wso2.com wrote:

 This solution works well on Ubuntu 10.10 as well.


 On Sat, Apr 16, 2011 at 2:54 PM, Afkham Azeez az...@wso2.com wrote:

 Please try this distribution out and let me know [1]... I have tested on
 Mac and Windows and works fine. If everything goes well, I will commit this
 change today.


 1.
 https://docs.google.com/a/wso2.com/leaf?id=0B3W7aoJmJW4wYWRmZDY4NDktZWI3ZC00ZWFmLTk2ZTQtYzhiZGU1YTM5OTMzhl=en


 On Sat, Apr 16, 2011 at 11:26 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 Ah ok now I understood what you want to do .. yep sounds good.

 Only change you could do is instead of saying sh -c 'exec java ...' you
 could simply say java  Essentially you're creating a shell and
 immediately running one command so might as well run that command directly.

 Sanjiva.


 On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once 
 the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the java
 process to spawn a new instance, instead of the dying java process spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml
 \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana 
 sanj...@wso2.com wrote:

 No saying sh -c .. means you're creating a new shell and then
 exec'ng in there. In that case you might as well just say java .. 
 (without
 the exec at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.com wrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch 
 of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should
 be that of the exec'ed command IIRC (new command is run in the same
 process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.comwrote:

 Instead of simply doing; java ... we do exec java  Why have
 we used exec here? I'm trying to solve the restart issue using exit 
 codes,
 and when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 

Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-16 Thread Senaka Fernando
Great. I tried this on Ubuntu 10.04 a few minutes ago, and it works
perfectly. Verified doing 'ps -ef', and performing multiple sequential
restarts as well.

Thanks,
Senaka.

On Sat, Apr 16, 2011 at 4:28 PM, Afkham Azeez az...@wso2.com wrote:

 I have tested this on Mac OS x 10.6, Ubuntu 10.10 as well as Windows 7
 Ultimate. The solution works perfectly on all of this platforms and hence I
 have committed the code. Now we can review and resolve all issues related to
 memory leaks on restart.

 Azeez


 On Sat, Apr 16, 2011 at 3:25 PM, Afkham Azeez az...@wso2.com wrote:

 This solution works well on Ubuntu 10.10 as well.


 On Sat, Apr 16, 2011 at 2:54 PM, Afkham Azeez az...@wso2.com wrote:

 Please try this distribution out and let me know [1]... I have tested on
 Mac and Windows and works fine. If everything goes well, I will commit this
 change today.


 1.
 https://docs.google.com/a/wso2.com/leaf?id=0B3W7aoJmJW4wYWRmZDY4NDktZWI3ZC00ZWFmLTk2ZTQtYzhiZGU1YTM5OTMzhl=en


 On Sat, Apr 16, 2011 at 11:26 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 Ah ok now I understood what you want to do .. yep sounds good.

 Only change you could do is instead of saying sh -c 'exec java ...'
 you could simply say java  Essentially you're creating a shell and
 immediately running one command so might as well run that command directly.

 Sanjiva.


 On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once 
 the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the 
 java
 process to spawn a new instance, instead of the dying java process 
 spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed 
 to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml
 \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana 
 sanj...@wso2.com wrote:

 No saying sh -c .. means you're creating a new shell and then
 exec'ng in there. In that case you might as well just say java .. 
 (without
 the exec at all).

 Doesn't having exec java at the end give the return code of the
 java command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.comwrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.com wrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch 
 of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should
 be that of the exec'ed command IIRC (new command is run in the same
 process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.comwrote:

 Instead of simply doing; java ... we do exec java  Why
 have we used exec here? I'm trying to solve the restart issue using 
 exit
 codes, and when exec is used, the process exit code cannot be 
 captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* 

[Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Afkham Azeez
Instead of simply doing; java ... we do exec java  Why have we used
exec here? I'm trying to solve the restart issue using exit codes, and when
exec is used, the process exit code cannot be captured.

-- 
*Afkham Azeez*
Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
*
*
*Member; Apache Software Foundation;
**http://www.apache.org/*http://www.apache.org/
*
email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
blog: **http://blog.afkham.org* http://blog.afkham.org*
twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Sanjiva Weerawarana
Its good to use exec so that the parent shell process doesn't hang around.
That's common practice for shell scripts which set up a bunch of stuff and
run something else right at the end.

But that should not be a problem as the process exit status should be that
of the exec'ed command IIRC (new command is run in the same process).

Here's a small test:

$ cat /tmp/foo.sh
#!/bin/sh

exit 79
$ sh -c exec /tmp/foo.sh
$ echo $?
79

Sanjiva.

On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we used
 exec here? I'm trying to solve the restart issue using exit codes, and when
 exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

Lean . Enterprise . Middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Afkham Azeez
Thanks!

sh -c exec java ...
worked!

Earlier the script only had exec java ...

On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang around.
 That's common practice for shell scripts which set up a bunch of stuff and
 run something else right at the end.

 But that should not be a problem as the process exit status should be that
 of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




-- 
*Afkham Azeez*
Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
*
*
*Member; Apache Software Foundation;
**http://www.apache.org/*http://www.apache.org/
*
email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
blog: **http://blog.afkham.org* http://blog.afkham.org*
twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Sanjiva Weerawarana
No saying sh -c .. means you're creating a new shell and then exec'ng in
there. In that case you might as well just say java .. (without the exec
at all).

Doesn't having exec java at the end give the return code of the java
command to the calling shell? That's what's spsed to happen.

Sanjiva.

On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang around.
 That's common practice for shell scripts which set up a bunch of stuff and
 run something else right at the end.

 But that should not be a problem as the process exit status should be that
 of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com
 ,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*




-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

Lean . Enterprise . Middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Afkham Azeez
If you do;

$ exec ./foo.sh

You will simply see the following line;
[Process completed]

and the control does not return to the current shell.


On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng in
 there. In that case you might as well just say java .. (without the exec
 at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com
 ,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 |
 +1 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




-- 
*Afkham Azeez*
Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com,
*
*
*Member; Apache Software Foundation;
**http://www.apache.org/*http://www.apache.org/
*
email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
blog: **http://blog.afkham.org* http://blog.afkham.org*
twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev


Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Afkham Azeez
This is what I'm doing in the wso2server.sh. When I restart, I issue a
System.exit(121) command. So the shel will spawn a new Java process once the
current one exits. This can be done on Windows too with the ERRORLEVEL
variable. So, we are relying on the original process which spawned the java
process to spawn a new instance, instead of the dying java process spawning
a new java process just before it dies. That solution is not working on
certain Windows environments. The exit code based approach is guaranteed to
work since we are handing back the control to the original shell that
spawned the java process.

Here is the relevant code segment in wso2server.sh

START_EXIT_STATUS=121;
status=$START_EXIT_STATUS;

while [ $status = $START_EXIT_STATUS ]
do
sh -c exec $JAVACMD \
-Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
-Xms256m -Xmx512m -XX:MaxPermSize=128m \
$JAVA_OPTS \
-Dimpl.prefix=Carbon \
-Dcom.sun.management.jmxremote \
-classpath $CARBON_CLASSPATH \
-Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
\
-Djava.io.tmpdir=$CARBON_HOME/tmp \
-Dwso2.server.standalone=true \
-Dcarbon.registry.root=/ \
-Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
-Djava.command=$JAVACMD \
-Dcarbon.home=$CARBON_HOME \
-Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml \
-Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
-Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
-Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
-Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
-Dcom.atomikos.icatch.hide_init_file_path=true \
org.wso2.carbon.bootstrap.Bootstrap $*

status=$?

done

On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana sanj...@wso2.comwrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng in
 there. In that case you might as well just say java .. (without the exec
 at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, 
 and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com
 ,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; 

Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Afkham Azeez
This solution is working on Windows as well! Here is the relevant change to
the wso2server.bat

:runJava
%JAVA_HOME%\bin\java -Xbootclasspath/a:%CARBON_XBOOTCLASSPATH% -Xms256m
-Xmx512m -XX:MaxPermSize=128m -Dimpl.prefix=Carbon
-Dcom.sun.management.jmxremote -classpath %CARBON_CLASSPATH% %JAVA_OPTS%
-Djava.endorsed.dirs=%JAVA_ENDORSED% -Dcarbon.registry.root=/
-Dcarbon.home=%CARBON_HOME% -Dwso2.server.standalone=true
-Djava.command=%JAVA_HOME%\bin\java -Djava.opts=%JAVA_OPTS%
-Dcarbon.xbootclasspath=%CARBON_XBOOTCLASSPATH%
-Djava.io.tmpdir=%CARBON_HOME%\tmp
-Dwso2.carbon.xml=%CARBON_HOME%\repository\conf\carbon.xml
-Dwso2.registry.xml=%CARBON_HOME%\repository\conf\registry.xml
-Dwso2.user.mgt.xml=%CARBON_HOME%\repository\conf\user-mgt.xml
-Dwso2.transports.xml=%CARBON_HOME%\repository\conf\mgt-transports.xml
-Djava.util.logging.config.file=%CARBON_HOME%\lib\log4j.properties
-Dcarbon.config.dir.path=%CARBON_HOME%\repository\conf
-Dcarbon.logs.path=%CARBON_HOME%\repository\logs
-Dcomponents.repo=%CARBON_HOME%\repository\components
-Dcom.atomikos.icatch.file=%CARBON_HOME%\lib\transactions.properties
-Dcom.atomikos.icatch.hide_init_file_path=true
-Dcarbon.classpath=%CARBON_CLASSPATH% org.wso2.carbon.bootstrap.Bootstrap
%CMD%
if %ERRORLEVEL%==121 goto runJava

On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the java
 process to spawn a new instance, instead of the dying java process spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng
 in there. In that case you might as well just say java .. (without the
 exec at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, 
 and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 

Re: [Carbon-dev] Why do we use exec in wso2server.sh?

2011-04-15 Thread Sanjiva Weerawarana
Ah ok now I understood what you want to do .. yep sounds good.

Only change you could do is instead of saying sh -c 'exec java ...' you
could simply say java  Essentially you're creating a shell and
immediately running one command so might as well run that command directly.

Sanjiva.

On Sat, Apr 16, 2011 at 10:53 AM, Afkham Azeez az...@wso2.com wrote:

 This is what I'm doing in the wso2server.sh. When I restart, I issue a
 System.exit(121) command. So the shel will spawn a new Java process once the
 current one exits. This can be done on Windows too with the ERRORLEVEL
 variable. So, we are relying on the original process which spawned the java
 process to spawn a new instance, instead of the dying java process spawning
 a new java process just before it dies. That solution is not working on
 certain Windows environments. The exit code based approach is guaranteed to
 work since we are handing back the control to the original shell that
 spawned the java process.

 Here is the relevant code segment in wso2server.sh

 START_EXIT_STATUS=121;
 status=$START_EXIT_STATUS;

 while [ $status = $START_EXIT_STATUS ]
 do
 sh -c exec $JAVACMD \
 -Xbootclasspath/a:$CARBON_XBOOTCLASSPATH \
 -Xms256m -Xmx512m -XX:MaxPermSize=128m \
 $JAVA_OPTS \
 -Dimpl.prefix=Carbon \
 -Dcom.sun.management.jmxremote \
 -classpath $CARBON_CLASSPATH \
 -Djava.endorsed.dirs=$CARBON_HOME/lib/endorsed:$JAVA_HOME/jre/lib/endorsed:$JAVA_HOME/lib/endorsed
 \
 -Djava.io.tmpdir=$CARBON_HOME/tmp \
 -Dwso2.server.standalone=true \
 -Dcarbon.registry.root=/ \
 -Dcarbon.xbootclasspath=$CARBON_XBOOTCLASSPATH \
 -Djava.command=$JAVACMD \
 -Dcarbon.home=$CARBON_HOME \
 -Dwso2.transports.xml=$CARBON_HOME/repository/conf/mgt-transports.xml \
 -Djava.util.logging.config.file=$CARBON_HOME/lib/log4j.properties \
 -Dcarbon.config.dir.path=$CARBON_HOME/repository/conf \
 -Dcomponents.repo=$CARBON_HOME/repository/components/plugins \
 -Dcom.atomikos.icatch.file=$CARBON_HOME/lib/transactions.properties \
 -Dcom.atomikos.icatch.hide_init_file_path=true \
 org.wso2.carbon.bootstrap.Bootstrap $*

 status=$?

 done

 On Sat, Apr 16, 2011 at 10:41 AM, Afkham Azeez az...@wso2.com wrote:

 If you do;

 $ exec ./foo.sh

 You will simply see the following line;
 [Process completed]

 and the control does not return to the current shell.


 On Sat, Apr 16, 2011 at 10:21 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 No saying sh -c .. means you're creating a new shell and then exec'ng
 in there. In that case you might as well just say java .. (without the
 exec at all).

 Doesn't having exec java at the end give the return code of the java
 command to the calling shell? That's what's spsed to happen.

 Sanjiva.


 On Sat, Apr 16, 2011 at 9:53 AM, Afkham Azeez az...@wso2.com wrote:

 Thanks!

 sh -c exec java ...
 worked!

 Earlier the script only had exec java ...


 On Sat, Apr 16, 2011 at 7:15 AM, Sanjiva Weerawarana 
 sanj...@wso2.comwrote:

 Its good to use exec so that the parent shell process doesn't hang
 around. That's common practice for shell scripts which set up a bunch of
 stuff and run something else right at the end.

 But that should not be a problem as the process exit status should be
 that of the exec'ed command IIRC (new command is run in the same process).

 Here's a small test:

 $ cat /tmp/foo.sh
 #!/bin/sh

 exit 79
 $ sh -c exec /tmp/foo.sh
 $ echo $?
 79

 Sanjiva.

 On Sat, Apr 16, 2011 at 4:13 AM, Afkham Azeez az...@wso2.com wrote:

 Instead of simply doing; java ... we do exec java  Why have we
 used exec here? I'm trying to solve the restart issue using exit codes, 
 and
 when exec is used, the process exit code cannot be captured.

 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.;
 http://wso2.com,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*


 ___
 Carbon-dev mailing list
 Carbon-dev@wso2.org
 http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev




 --
 Sanjiva Weerawarana, Ph.D.
 Founder, Chairman  CEO; WSO2, Inc.;  http://wso2.com/
 email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1
 650 265 8311
 blog: http://sanjiva.weerawarana.org/

 Lean . Enterprise . Middleware




 --
 *Afkham Azeez*
 Senior Software Architect  Senior Manager; WSO2, Inc.; http://wso2.com
 ,
 *
 *
 *Member; Apache Software Foundation; 
 **http://www.apache.org/*http://www.apache.org/
 *
 email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919
 blog: **http://blog.afkham.org* http://blog.afkham.org*
 twitter: 
 **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
 *
 linked-in: