[launcher] ordered system properties

["Samaroo, Trevor J" <tr...@gs.com>]

Hello,

 

We had the need to order system properties passed into our program.  I
modified LaunchTask.java in order to accomplish this.  

 

How can I contribute this 'feature'/codechange to the project?  I don't want
to diverge from the launcher codebase.

 

We need sysprops to be ordered for our application monitoring programs to
find our process correctly.  (we pass in -Dapp.id=aUniqueId and this must
exist as the first element in the command line.) Considering this change
makes a previously unordered sysprop list ordered, there shouldn't be any
impact on existing code.

 

Can someone (Patrick Luby?) from the commons-launcher project advise?

 

Regards,

 

Trevor Samaroo

Re: [launcher] ordered system properties

[Craig McClanahan <cr...@gmail.com>]

I am not a participant in the [launcher] project at Jakarta Commons,
but if I were, I would vote against such a proposal on general
principles -- dependence on behavior like this is *incredibly*
fragile, and is pretty much guaranteed to break the next time someone
tweaks your persistence strategy (or you upgrade to a new JVM that
iterates HashMap keys in a different order ... :-).

By far the better strategy would be to arrange the lifecycle of your
service objects so that they had (at least) two phases:

* Configuration -- property settings can occur in any desired order.
  This is really critical if you expect your component to be supported
  by development tools, and is required for maintainability even if you
  do not care about tools support.

* Lifecycle -- some sort of a start() method that is guaranteed to not
  be invoked until *after* all the relevant properties have been set from
  the configuration information.

Even if you can craft an order-dependent solution now, you are really
going to kick yourself in the rear end a year from now -- my strong
recommendation is to avoid that kind of pain and embarrasement :-),
and start with a strategy that is scalable over the long term.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org