Status about DPML on Unix

Stephen McConnell mcconnell at dpml.net
Thu Mar 23 15:56:08 EST 2006


 

> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org 
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of 
> Stephen McConnell
> Sent: Friday, 24 March 2006 6:45 AM
> To: 'DPML Development'
> Subject: RE: Status about DPML on Unix
> 
>  
> 
> > -----Original Message-----
> > From: dev-dpml-bounces at lists.ibiblio.org
> > [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of 
> Carel Paradis
> > Sent: Thursday, 23 March 2006 11:49 AM
> > To: DPML Development
> > Subject: Re: Status about DPML on Unix
> > 
> > Hi Steve,
> > 
> > I provide below the requested data.
> 
> Thanks!
> 
> I don't have definitive answers yet but basically it seems 
> that the commands that are prepared by the station console 
> are correct - specifically, when you invoke 'station startup' 
> the station console plugin is being activated and the 
> 'startup' option handler is correctly doing the construction 
> of the server command:
> 
> [69319] [FINE   ] (depot): server startup command:
>   command elements: 5
>   1 station
>   2 -server
>   3 1099
>   4 -Ddpml.logging.config=local:properties:dpml/station/logging
>   5 -Ddpml.subprocess=true
> 
> The station console is then requesting a new OS process via 
> Runtime.exec( args, null ).  The resulting process is 
> basically 'depot' with the 'station'
> application switch.  We can see from the server log file that 
> the correct plugin is being launched however the commandline 
> arguments that are being processed by the plugin are not the 
> same as the commandline arguments we constructed above.  If 
> effect by the time depot has finished processing the raw 
> arguments the only remaining argument should be the port 
> value.  The big question is where the 'startup' argument is 
> coming from because its clearly not being supplied in the 
> command issued to Runtime.exec().
> 
> In order to track this down I've updated the station console 
> plugin to enable debug mode in the station server if debug 
> has been enabled in the console.  This will give us a bunch 
> more information in the log file - and in particular you 
> should be seeing something like the following:
> 
>   $ station startup -debug
> 
>   ... And inside data/logs/station/server-0.log
> 
>   [3540 ] [FINE   ] (depot): system: station.server
>   [3540 ] [FINE   ] (depot): uri:
> artifact:part:dpml/station/dpml-station-server#SNAPSHOT
>   [3540 ] [FINE   ] (depot): args: [1099]
> 
> If the nix variant is showing more than the single 1099 
> commandline argument we know that something is going wrong at 
> the level of the scripts.  Can you run the 'station startup 
> -debug' command (after updating you build) and post back the 
> log file (which should take us a step closer to solving this).

I think I understand!

We are invoking the following:

  Process process = Runtime.getRuntime().exec( args, null );

What this means is that the evironment variables from the current running
session are includined in the process we are creating.  As a result our call
to exec depot is being polluted with the environment data created during the
current 'station startup' process. 

Looking at the depot script I think I see the problem - in the following
code the $DEPOT_ARGS value already exists and holds the "startup" option
that was supplied under the initial station command. As this environment
variable exists it is being prepended to the args supplied to depot when we
launch the server process.

  if [ "$DEPOT_ARGS" = "" ] ; then
      DEPOT_ARGS=$@
  else
      DEPOT_ARGS="$DEPOT_ARGS $@"
  fi
  export DEPOT_ARGS

This naturally result is the following:

  Exception: java.lang.Exception
  Message: Server commandline processing error.
  Argument count: 2
    arg (0): [startup]
    arg (1): [1099]

I figure that replacing the above if/fi block with DEPOT_ARGS=$@ will solve
the issue and have updated the depot script to reflect this.

Cheers, Steve.






More information about the dev-dpml mailing list