command line parameters in RCP-application?

I'm launching the my Spring RCP-application by following method and it works otherwise properly but ... I'm not able to use any of the command line arguments (args array). So the question goes: How do I set the command line parameters in my application?

public class Main {
public static void main(String[] args) {
String startupContext = ...;
String richclientApplicationContext = ...;
String applicationContext = ...;
new ApplicationLauncher(startupContext, new String[] {richclientApplicationContext, applicationContext});
}

I don't wan't to use the beans/properties in

I am not sure what you are trying to do with your paramaters, however one of the most usefull things is you can configure spring depending on the args passed in. Like this:

Code:

---

public class Main {
public static void main(String[] args) {

//do arg check...
String mode = args[0];
ConfigurableBeanFactory bf = new .....;    // create BeanFactory
  ...                      // now register some beans
// now register any needed BeanPostProcessors
MyBeanPostProcessor pp = new MyBeanPostProcessor();
bf.addBeanPostProcessor(pp);

// now start using the factory

}

---

http://www.springframework.org/docs/...ry-customizing

Thanks for the reply. Here are some detailed information regarding the problem I'm having here.

In my Spring RCP-application, I launch it by using the code above. The application is launched with some command line parameters which varies depending on the user who launched the application. There are couple of these parameters.

For somereason I don't find any way to launch my RCP application including both the beans in applicationContext.xml files and these command line arguments.

I've tried already the 'PropertyPlaceholderConfigurer' to set the new properties into the beans but this doesn't affect on the applicationContext once it's been loaded.

The main aim in here is to get the command line arguments so that they are available to my business class in my RCP-application. Also "non Spring" solutions and hints are welcome !!

Thanks

Have you tried:

Code:

---

        String[] contextFiles = new String[]
        { root + "richclient-application-context.xml", root + "richclient-preference-context.xml" };

        Launcher.setMessage("Initializing datawarehouse...");
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(contextFiles);
       
// create placeholderconfigurer to bring in some property
// values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));
// now actually do the replacement
cfg.postProcessBeanFactory(factory);

        Launcher.setMessage("Initializing gui components and services...");
        ApplicationLauncher launcher = new ApplicationLauncher(context);

---

This will do the trick, before rich-client was constructing the beans before you binded the postProcessBeanFactory

I think it is interesting that the splash screen with progress monitor can be used with ApplicationLauncher(String startupContextPath, ApplicationContext rootApplicationContext).

The actual implementation needs a loaded ApplicationContext, causing the splash to be showed late.

I think an AbstractApplicationContext can be passed instead of the ApplicationContext and refreshed if necessary inside the constructor, so the progress can be showed.

Is this the recommended way of passing/processing arguments to the application? Using a BeanPostProcessor?

It sounds somewhat clunky, since it means that the splashscreen won't get shown until the whole application context has been initialized and processed.

Would it make sense to have another ApplicationLauncher constructor that accepts a BeanPostProcessor as an argument, that gets applied to all contexts as they are constructed and read, similarly to the ProgressMonitoringBeanFactoryPostProcessor?

Or is there a better way of doing this?

To be honest, even with the PostProcessor, I'm still looking for an example of how to actually implement this.

For example, picture a text editor. If you provide a filename on the command line, it opens it and lets you edit it. Otherwise, it prompts for a file to edit. In the context of Spring Rich client, the "prompt command" is triggered from the LifecycleAdvisor's onPostStartup() handler.

One *VERY* dirty way of doing it would be to just save the main args[] as a static variable in my startup class, and then reference them directly when required, but that just makes my skin crawl to suggest it! :-)

Hey,

Have you tried saving args as System props (possibly with some namespace prefix) before applying PropertyPlaceholderConfigurer?

Oops, just looked at original post date... :rolleyes:

Thanks for the suggestion. I might well try that.

Rogan

Quote:

---

Originally Posted by rdawes

For example, picture a text editor. If you provide a filename on the command line, it opens it and lets you edit it. Otherwise, it prompts for a file to edit. In the context of Spring Rich client, the "prompt command" is triggered from the LifecycleAdvisor's onPostStartup() handler.

One *VERY* dirty way of doing it would be to just save the main args[] as a static variable in my startup class, and then reference them directly when required, but that just makes my skin crawl to suggest it! :-)

---

Hi rdawes,

just to put in my €0.02 to this discussion -- why do you call using a static variable dirty? I mean.. the commandline args are a global entity and you are starting out with a single thread anyways. I can't imagine another solution which doesn't involve something "very global" to achieve what you want :p ... you could use a temporary file, write into a database, try to set a system property, write into the registry, use some service MBean / EJB / wtf...

But one could try to make this "global thing" at least more clean: I'd use a conventional singleton for this purpose: in main(), you'd parse and evaluate the commandline and then access the singleton and put some flags into it. From within your startup hook, you'll access the singleton again and fetch the flags. And if they aren't set, you'd terminate the application immediately.

In several of our (server sided spring based applications -- not using spring rich client, but this doesn't make any difference to this discussion), we use
a similar approach together with the property placeholder configurer. Our implementation accesses a singleton to get some global "setup key", then accesses some database via normal JDBC and loads a set of configuration options, which are then used to configure the placeholders in the spring bean xml files.