Perfect! Rejavanating legacy Java. I've witnessed the same in a big Oil company recently. It was a really great project that the company was over the moon about in terms of the stabilisation of the product. We also tested all of the services as part of the project and shifted completely to Test-Driven-Design.
We had different build targets to make SARs for different destinations. 'deploy-local' for the local phoenix, 'deploy-live' for the live one. Each uses differenr properties (however you want to configure that) and had diff config.xml...
Good luck!
- Paul
Paul,
thanks for the reply...
On Thursday 13 March 2003 13:12, Paul Hammant wrote:
<snip>
In the existing solution I have a concept of ProductDir vs ProjectDir,Tis up to you. We're lacking some context for this. Any chance you can
where the former is a standard distro, that the user never change, and
ProjectDir is for the user only, and can be placed at any place on disk
with a simple pointer to change at startup. Any recommendations regarding
this?
hint us about the application? It sounds intriguing.
It is a rather old Process Control and Industrial Automation framework, we have been using since 1997 and the third generation rewrite was in 1999, and it is now time again.
Number of installations are fairly small, about 50, but are long-running without human intervention, typically restarted less than once a year.
Since Bali Control (as it is called) has a model very similar to Avalon itself, it is fairly easy to make the port.
The lifecycles are similar (the initialization is combined configuration in Bali Control, but that is about it), and it has a notion of "installable" services, which each has a configuration file (java.util.Properties) and can easily (maybe even with automated tools) be shifted to config.xml, and each such service is in all major details an Avalon Block.
All in all it is a rather small undertaking to move to Avalon and Phoenix in particular.
As Bali Control is an underlying framework for "continous dataflow" domains, where there are continous streams of values, such as temperatures, pressures and humidity, one other company has an Building Automation Application on top of Bali Control, and they have implemented each of their "building blocks" as Bali Control services, although they didn't need to, they found it to be more convenient to work with bigger components. So, there will be some interesting time ahead to convert all these Bali Control services into Avalon-Phoenix Blocks.
Bali Control also has a bunch of class packages that are suitable to become "components" (sorry if I didn't know about a deprecated interface). This porting is a little bit tougher, since they are more JavaBeans oriented, and not as easy to maintain compatibility.
Enough background?
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
