Bug #4306


add command line params to the configuration

Added by Chad Berkley over 14 years ago. Updated over 14 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Estimated time:


There's been a request to have an actor know what the command line params were when Kepler was started. It should be pretty easy to add these as parameters of the configuration upon startup. An actor could then just get the configuration and look up the params.

Actions #1

Updated by Christopher Brooks over 14 years ago

I'm off work this week, but I would support adding the command line
arguments to the Configuration. I would consider doing this work
myself after Tue., August 18.

Actions #2

Updated by David Welker over 14 years ago

Fixed with an alternative solution.

Now, all the command-line args can be iterated through anywhere from Kepler with the following:

for( String arg : CommandLineArgs.get() )

Actions #3

Updated by Christopher Brooks over 14 years ago

Adding another class is not as clean a solution as having this information
in the Configuration. The reason is that adding another class adds
complexity. We have a Configuration for this purpose, we should use it.

I'll take this bug and mark it for after 2.0.0.

Actions #4

Updated by Christopher Brooks over 14 years ago

Here's some email about this. Note that adding a separate CommandLineArgs
solution might not work with PN:

Colin writes:

Just as a last note, the stack trace solution will not work under the PN >director as the actor's thread starts at the "ProcessThread" class.


David Welker wrote:

Hi Michal,

I have added a fix to this. Now, if you want to know what command-line args were passed, you can cycle through them. For example, here is code that would allow you to see if -nogui was specified.

import org.kepler.CommandLineArgs;


public void fire() throws IllegalActionException {
boolean noguiSpecified = false;

for( String arg : CommandLineArgs.get() )
if( arg.equals("-nogui") ) {
noguiSpecified = true;


Hope that helps. It certainly is a little cleaner that looking at stack traces.


On Aug 12, 2009, at 12:10 PM, Michal Owsiak wrote:

Thanks for the info.

The hack-way is not a pretty solution, but it will do a thing - I will
check that and tell you whether it works fine.

What I am trying to accomplish is creating an actor that is able to show
dialog window - when GUI mode is enabled, and skip showing it, when
-nogui is passed. This way I can easily (without changing actor's
parameters within workflow) use the same scenario for both cases.
Otherwise I have to enable/disable some parameter.

But as I have mentioned, I will check the "stack thing" - it should work.

Anyway, if it is possible to add this feature it would be fine.

Another useful feature (in case of -nogui mode) would be providing
Kepler developers with an access to command line arguments. This way it
would be possible to parametrize workflow from outside through the
application's parameters - this would useful whenever Kepler is started
as a part of a process.



There is no really good way to do this at present.

If -nogui passed in as an argument, then that affects what is called
(either org.kepler.KeplerConfigurationApplication or
ptolemy.moml.MoMLCommandLineApplication) but unfortunately the fact that
-nogui was passed in is not otherwise stored.

A hackish way to detect whether new -nogui was passed in that should
work (I haven't tried it) would be to examine the current stack trace
and see if either of the following is present.

org.kepler.KeplerConfigurationApplication.main(String[] args)


ptolemy.moml.MoMLCommandLineApplication(String[] args)

One of these classes is called if and only if -nogui was passed in as a
command-line argument.

What are you trying to accomplish? Should we make it more convenient to
determine whether -nogui has been passed in on the command line?


On Aug 12, 2009, at 2:38 AM, Michal Owsiak wrote:

Hello all,

I want to check within the actor's fire() method whether Kepler was
started with "-nogui" argument. Is it possible to determine whether this
switch was used during Kepler execution? How this information can be



Michal Owsiak <>
Poznan Supercomputing and Networking Center
ul. Noskowskiego 10, 61-704 Poznan, POLAND
Kepler-dev mailing list

Michal Owsiak <>
Poznan Supercomputing and Networking Center
ul. Noskowskiego 10, 61-704 Poznan, POLAND

Kepler-dev mailing list

Actions #5

Updated by Redmine Admin over 10 years ago

Original Bugzilla ID was 4306


Also available in: Atom PDF