parc-developers Mailing List for Pipeline Architecture
Brought to you by:
pmckinstry
Menu
▾
▴
parc-developers — parc developers list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pete M. <pet...@ya...> - 2003-08-23 07:27:38
|
Vaibhav has added some support for nested property
files. This is especially useful when using multiple
datasources within a single parc application.
Take a look @ CompositeProperties.java along w/ it's
unit test to see how this works. Thanks Vaibhav!
On another note, to support multiple data sources,
some changes were required to the DataSourceFactory,
and the DBUtil class. The DataSourceFactory used to
take a Properties object that contained the
configuration data for a certain data source. It has
now changed to pass a data source name which keys to a
set of values in the configuration repositories. It is
nicer to use, but has a drawback. It breaks backward
compatibility w/ existing code. You now have to either
use DBUtil.getDataSource(), which retrieves the
default data source or DBUtil.getDataSource(String
name) which retrieves the named datasource. The
DataSource objects are also now loaded @ startup
instead of lazily upon first request.
For users who got a DataSource by calling
DBUtil.getDataSource(), the required changes are
minimal. Basically you have to change your
configuration repository (properties file, database,
whatever) to prefix the datasource properties w/
DataSource.default.
For an example of the change, take a look @ the
DataSourceFactoryTest.properties.
If users have been calling the DataSourceFactory
directly & not going through the DBUtil.java class,
the changes are more significant. They will need to
change the calls to pass a String ("default" for the
above example) instead of the actual properties
object.
Anyway, I think the changes are a positive move, but I
wanted to get other peoples feedback on how painful
this change would be. Should we spend more time & find
a better compromise or is changing the property
prefixes minor enough that people are fine w/ it?
Comments?
-pgm
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
|
|
From: Pete M. <pet...@ya...> - 2003-08-23 06:41:51
|
Vaibjav- I added a default constructor & overrode the load(InputStream) method so that BatchApplication could us it seamlessly and still have all the references resolve properly. Let me know if you have any issues w/ that. It's checked in to the com.rhi.architecture.lang package. -pgm __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: McKinstry, P. (HQP) <Pet...@rh...> - 2002-11-04 16:25:53
|
Testing to make sure the lists are working.... -pgm Pete McKinstry IT Web Applications Robert Half Int'l *: 925.598.5422 *: pet...@rh... |
