You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(15) |
Feb
(10) |
Mar
(12) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: RefuX Z. <re...@ya...> - 2002-04-29 17:42:32
|
I was just thinking it could be a helpful housekeeping feature. Kinda like how we close resultsets, connections etc.. --- David Colwell <dco...@sp...> wrote: > You hit it - the idea was that the queue facade > could be long lived, but > many senders may come and go. In the spirit of > releasing resources as soon > as possible, the interface was made as such. > > Dave > > -----Original Message----- > From: RefuX Zanzebarr > To: arc...@li... > Sent: 4/26/02 4:35 PM > Subject: [Arch4j-developers] ARCH4J JMS > > I looking at the ARCH4J MessageQueueFacade JavaDoc's > example code: > > --- snip --- > > MessageQueueFacade qFacade = > MessagingProvider.getProvider().getMessageQueueFacade(false); > > > QueueSender sender = > qFacade.createQueueSender("exampleQueue"); > > qFacade.startConnection(); > > TextMessage message = qFacade.createTextMessage(new > StringBuffer("Hello Whirled")); > > sender.send(message); > > sender.close(); > > qFacade.close(); > > --- snip --- > > and was thinking, why don't we just do the > 'sender.close()' in qFacade.close() ? > I understand there could be multiple QueueSenders > within the scope of one QueueFacade instance, but > there's no reason why we couldn't track them all and > just close them all (if they're not already closed) > automagically on qFacade.close() > > Thoughts? > > __________________________________________________ > Do You Yahoo!? > Yahoo! Games - play chess, backgammon, pool and more > http://games.yahoo.com/ > > _______________________________________________ > Arch4j-developers mailing list > Arc...@li... > https://lists.sourceforge.net/lists/listinfo/arch4j-developers > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
From: David C. <dco...@sp...> - 2002-04-29 13:09:28
|
You hit it - the idea was that the queue facade could be long lived, but many senders may come and go. In the spirit of releasing resources as soon as possible, the interface was made as such. Dave -----Original Message----- From: RefuX Zanzebarr To: arc...@li... Sent: 4/26/02 4:35 PM Subject: [Arch4j-developers] ARCH4J JMS I looking at the ARCH4J MessageQueueFacade JavaDoc's example code: --- snip --- MessageQueueFacade qFacade = MessagingProvider.getProvider().getMessageQueueFacade(false); QueueSender sender = qFacade.createQueueSender("exampleQueue"); qFacade.startConnection(); TextMessage message = qFacade.createTextMessage(new StringBuffer("Hello Whirled")); sender.send(message); sender.close(); qFacade.close(); --- snip --- and was thinking, why don't we just do the 'sender.close()' in qFacade.close() ? I understand there could be multiple QueueSenders within the scope of one QueueFacade instance, but there's no reason why we couldn't track them all and just close them all (if they're not already closed) automagically on qFacade.close() Thoughts? __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers |
From: RefuX Z. <re...@ya...> - 2002-04-26 21:35:33
|
I looking at the ARCH4J MessageQueueFacade JavaDoc's example code: --- snip --- MessageQueueFacade qFacade = MessagingProvider.getProvider().getMessageQueueFacade(false); QueueSender sender = qFacade.createQueueSender("exampleQueue"); qFacade.startConnection(); TextMessage message = qFacade.createTextMessage(new StringBuffer("Hello Whirled")); sender.send(message); sender.close(); qFacade.close(); --- snip --- and was thinking, why don't we just do the 'sender.close()' in qFacade.close() ? I understand there could be multiple QueueSenders within the scope of one QueueFacade instance, but there's no reason why we couldn't track them all and just close them all (if they're not already closed) automagically on qFacade.close() Thoughts? __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
From: RefuX Z. <re...@ya...> - 2002-03-29 04:26:57
|
FYI Just to let you guys know I changed the Queue and Topic facades to explicitly close the connection when close is called. It was previous closing the Session but not the Connection, it wasn't totally clear from the docs if closing a Session closes the Connection, so I put it in just to be safe. __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ |
From: Allan W. <al...@wi...> - 2002-03-10 03:33:34
|
Hello again, I have updated the Where's Lunch application to include the installation document. Sorry for not including it in the original release ;) Regards, -Allan Wick |
From: Allan W. <al...@wi...> - 2002-03-09 17:24:17
|
First things first we need to get the howto and stuff into the web site! They aren't in any distribution file. My fault ;) > -----Original Message----- > From: arc...@li... > [mailto:arc...@li...]On Behalf Of RefuX > Zanzebarr > Sent: Saturday, March 09, 2002 10:36 AM > To: Arch4j-Developers > Subject: RE: [Arch4j-developers] New Release > > > --- Allan Wick <al...@wi...> wrote: > > I'm sorry, I thought U DID! :) > > Its on my list honest :) > Along with the other 12 things you guys have dished > out :P > > > I might try to work out how to use the tasks list on > sourceforge later and add some of those tasks to it. > > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > > _______________________________________________ > Arch4j-developers mailing list > Arc...@li... > https://lists.sourceforge.net/lists/listinfo/arch4j-developers > |
From: RefuX Z. <re...@ya...> - 2002-03-09 16:36:19
|
--- Allan Wick <al...@wi...> wrote: > I'm sorry, I thought U DID! :) Its on my list honest :) Along with the other 12 things you guys have dished out :P I might try to work out how to use the tasks list on sourceforge later and add some of those tasks to it. __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ |
From: Allan W. <al...@wi...> - 2002-03-09 06:43:34
|
Hello again, Where's lunch, the sample application that utilizes the Arch4J components, has been released. Regards, -Allan Wick |
From: Allan W. <al...@wi...> - 2002-03-09 06:41:33
|
I'm sorry, I thought U DID! :) > -----Original Message----- > From: arc...@li... > [mailto:arc...@li...]On Behalf Of RefuX > Zanzebarr > Sent: Saturday, March 09, 2002 12:10 AM > To: Arch4j-Developers > Subject: Re: [Arch4j-developers] New Release > > > > enhancements to Data Access to use JDBC > > 2.0 classes for database > > pooling and RowSet caching. > > I know I put in the RowSet caching stuff, who put in > the db pooling stuff? :P > > > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > > _______________________________________________ > Arch4j-developers mailing list > Arc...@li... > https://lists.sourceforge.net/lists/listinfo/arch4j-developers > |
From: RefuX Z. <re...@ya...> - 2002-03-09 06:10:30
|
> enhancements to Data Access to use JDBC > 2.0 classes for database > pooling and RowSet caching. I know I put in the RowSet caching stuff, who put in the db pooling stuff? :P __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ |
From: Allan W. <al...@wi...> - 2002-03-09 05:32:55
|
Hello, Arch4J release 1.0.1 is now available. This release supports JDK1.4 as well as JBoss, enhancements to Data Access to use JDBC 2.0 classes for database pooling and RowSet caching. There will be a Where's Lunch very soon. Thank you for your continued support. Regards, -Allan Wick |
From: RefuX Z. <re...@ya...> - 2002-03-01 16:26:38
|
TEST Can seem to get any emails onto the list. __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com |
From: RefuX Z. <re...@ya...> - 2002-03-01 16:26:02
|
Hmm, I sent a reply to this topic already. But I think maybe I sent it to Chuck rather than the list. Anyways "James' Reply Take Two!" Actually I already have a ID Generator implementation (http://ejbutils.sourceforge.net/), which works like David describes. (pats David on back and gives him a cookie) My posting to the list was more of a: Hey how does this interface look? Is it a good idea that I should put it in Arch4J? Trying to keep everyone in the loop kinda thing :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com |
From: Chuck L. <chu...@po...> - 2002-03-01 16:01:36
|
For the most part, I think Dave is right, but ... 1. If several applications/systems are inserting rows into the database and generating overlapping keys, then multiple hits will be made to the database every time that an insert is attempted with a duplicate key. However, this problem can be minimized by programmatically avoiding the creation of a duplicate key in each application/system. 2. Using native database calls instead of SQL Inserts, a row can be inserted and the auto-generated key returned with only one hit to the database. I did this at my last job calling stored procedures for each insert (I created a little utility to automatically generate a stored procedure for each object/table). I'm not sure if the current EJB vendors are that clever, but I suspect that they will be soon if they are not already--they do go to great lengths to improve performance and this is a very common problem. I'm not exactly recommending the auto-numbering approach yet, but I do think it is a solid candidate worth investigating further (although, I am not promising to actually do the research any time soon). If double-hits to the database can be avoided easily, then auto-numbering offers a simple, fast, robust solution. Chuck -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of David Colwell Sent: Friday, March 01, 2002 9:32 AM To: 'arc...@li... ' Subject: RE: [Arch4j-developers] ID Generator Right, I don't know of any databases that don't offer some sort of auto-number feature. The problem I see with using these is in keeping business objects in synch with the data they represent. The problem situation arises when storing a newly created business object. I must first store the data then query the database to get the primary key it just set for me so I can update my business object. The cost is two hits to the database. The buffering solution only costs one plus a fraction based on the buffer size configured for each business object. Dave -----Original Message----- From: Chuck Lewin To: arc...@li... Sent: 2/28/02 11:18 AM Subject: RE: [Arch4j-developers] ID Generator I believe that most major databases and EJB containers support using auto-number fields in the database tables as primary keys for EJBs. This approach probably would be the most robust in terms of high performance and low concurrency issues. However, it only makes sense if it is truly a platform independent solution. It may be worth the effort of researching how portable this approach is (unless someone already knows the answer). Chuck -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of David Colwell Sent: Thursday, February 28, 2002 11:08 AM To: ''arc...@li...' ' Subject: RE: [Arch4j-developers] ID Generator In the past, we've had luck modelling a unique ID generator against a table that knows the largest unused number for each of a set of unique keys. Our provider would grab the highest unused value for the "PERSON_ID" key and increment it in the database by 100, for example. It could then serve out 100 unique IDs without the cost of hitting the database. The unique ID table had the following fields: key_name, value, buffer_size. The only cost of losing the server VM that it lived in was the unserved set of values. If this was an issue for a given table, the buffer_size field could be set to 1. Dave -----Original Message----- From: RefuX Zanzebarr To: 'arc...@li...' Sent: 2/28/02 10:03 AM Subject: [Arch4j-developers] ID Generator For the Lunch-o-Matic example I've been working on, I created an ID Generator Service for generating Primary Key IDs. I'm thinking I should probably add it into the main Arch4J. Here the current interface, how does it look? /** Service for generating IDs to be used as primary keys for the DB. * @author Jroome */ public interface IDGeneratorService { /** Get the next id * @return the next id * @param key Key to be used in generating the next id. For example the key could be a table name. Thus person table and location table could have the same ids as their primary keys. */ public IdentifierDomain getID( String key ); } Ok, I know its a simple interface, but this is an opensource project so I figure best to get the dev mailing list a little bit more active :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com <http://greetings.yahoo.com> _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers <https://lists.sourceforge.net/lists/listinfo/arch4j-developers> |
From: David C. <dco...@sp...> - 2002-03-01 15:31:52
|
Right, I don't know of any databases that don't offer some sort of auto-number feature. The problem I see with using these is in keeping business objects in synch with the data they represent. The problem situation arises when storing a newly created business object. I must first store the data then query the database to get the primary key it just set for me so I can update my business object. The cost is two hits to the database. The buffering solution only costs one plus a fraction based on the buffer size configured for each business object. Dave -----Original Message----- From: Chuck Lewin To: arc...@li... Sent: 2/28/02 11:18 AM Subject: RE: [Arch4j-developers] ID Generator I believe that most major databases and EJB containers support using auto-number fields in the database tables as primary keys for EJBs. This approach probably would be the most robust in terms of high performance and low concurrency issues. However, it only makes sense if it is truly a platform independent solution. It may be worth the effort of researching how portable this approach is (unless someone already knows the answer). Chuck -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of David Colwell Sent: Thursday, February 28, 2002 11:08 AM To: ''arc...@li...' ' Subject: RE: [Arch4j-developers] ID Generator In the past, we've had luck modelling a unique ID generator against a table that knows the largest unused number for each of a set of unique keys. Our provider would grab the highest unused value for the "PERSON_ID" key and increment it in the database by 100, for example. It could then serve out 100 unique IDs without the cost of hitting the database. The unique ID table had the following fields: key_name, value, buffer_size. The only cost of losing the server VM that it lived in was the unserved set of values. If this was an issue for a given table, the buffer_size field could be set to 1. Dave -----Original Message----- From: RefuX Zanzebarr To: 'arc...@li...' Sent: 2/28/02 10:03 AM Subject: [Arch4j-developers] ID Generator For the Lunch-o-Matic example I've been working on, I created an ID Generator Service for generating Primary Key IDs. I'm thinking I should probably add it into the main Arch4J. Here the current interface, how does it look? /** Service for generating IDs to be used as primary keys for the DB. * @author Jroome */ public interface IDGeneratorService { /** Get the next id * @return the next id * @param key Key to be used in generating the next id. For example the key could be a table name. Thus person table and location table could have the same ids as their primary keys. */ public IdentifierDomain getID( String key ); } Ok, I know its a simple interface, but this is an opensource project so I figure best to get the dev mailing list a little bit more active :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com <http://greetings.yahoo.com> _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers <https://lists.sourceforge.net/lists/listinfo/arch4j-developers> |
From: Allan W. <al...@wi...> - 2002-02-28 19:40:55
|
RE: [Arch4j-developers] Arch4J Full Build SourceRoss, I agree. I will have James fix the build script to copy all the = necessary files ;) -Allan ----- Original Message -----=20 From: Ross Greinke=20 To: 'Allan Wick '=20 Sent: Thursday, February 28, 2002 11:33 AM Subject: RE: [Arch4j-developers] Arch4J Full Build Source Allan,=20 I agree that we shouldn't redistribute those jar files, but the full = source release didn't include the build files that are supposed to be in = the root directory, nor the version file(s) in etc, nor the ant = executables (if needed) in the bin directory. Excluding jars that a user needs to get on his/her own, I'd like to = see the full source distribution have everything needed to re-build = either another full distribution (bin, doc, src) and/or any of the = individual sub-projects. Ross=20 -----Original Message-----=20 From: Allan Wick=20 To: arc...@li...=20 Sent: 2/28/02 9:50 AM=20 Subject: Re: [Arch4j-developers] Arch4J Full Build Source=20 Ross,=20 =20 There are properties in the build.xml file that need to be set for the = j2ee and junit installs. These you have to install on your own and=20 point the build to them. I believe you cannot re-distribute the = j2skdee=20 jar files. For Junit this is done so that you only have the junit jar = files in one place.=20 =20 Allan=20 ----- Original Message -----=20 From: Ross <mailto:rgr...@sp...> Greinke=20 To: 'arc...@li...'=20 <mailto:'arc...@li...'> =20 Sent: Wednesday, February 27, 2002 7:44 PM=20 Subject: [Arch4j-developers] Arch4J Full Build Source=20 The full build source (arch4j-1.0-src.zip) doesn't contain all of the=20 files in the root directory, namely those files to build another=20 release.=20 My intention with the 0.9.x releases was that the full source=20 distribution contained everything you needed to completely rebuild = each=20 of the distributions (src, bin, doc).=20 Does that still hold true?=20 Ross=20 |
From: Chuck L. <chu...@po...> - 2002-02-28 17:18:47
|
I believe that most major databases and EJB containers support using auto-number fields in the database tables as primary keys for EJBs. This approach probably would be the most robust in terms of high performance and low concurrency issues. However, it only makes sense if it is truly a platform independent solution. It may be worth the effort of researching how portable this approach is (unless someone already knows the answer). Chuck -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of David Colwell Sent: Thursday, February 28, 2002 11:08 AM To: ''arc...@li...' ' Subject: RE: [Arch4j-developers] ID Generator In the past, we've had luck modelling a unique ID generator against a table that knows the largest unused number for each of a set of unique keys. Our provider would grab the highest unused value for the "PERSON_ID" key and increment it in the database by 100, for example. It could then serve out 100 unique IDs without the cost of hitting the database. The unique ID table had the following fields: key_name, value, buffer_size. The only cost of losing the server VM that it lived in was the unserved set of values. If this was an issue for a given table, the buffer_size field could be set to 1. Dave -----Original Message----- From: RefuX Zanzebarr To: 'arc...@li...' Sent: 2/28/02 10:03 AM Subject: [Arch4j-developers] ID Generator For the Lunch-o-Matic example I've been working on, I created an ID Generator Service for generating Primary Key IDs. I'm thinking I should probably add it into the main Arch4J. Here the current interface, how does it look? /** Service for generating IDs to be used as primary keys for the DB. * @author Jroome */ public interface IDGeneratorService { /** Get the next id * @return the next id * @param key Key to be used in generating the next id. For example the key could be a table name. Thus person table and location table could have the same ids as their primary keys. */ public IdentifierDomain getID( String key ); } Ok, I know its a simple interface, but this is an opensource project so I figure best to get the dev mailing list a little bit more active :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers |
From: David C. <dco...@sp...> - 2002-02-28 17:08:06
|
In the past, we've had luck modelling a unique ID generator against a table that knows the largest unused number for each of a set of unique keys. Our provider would grab the highest unused value for the "PERSON_ID" key and increment it in the database by 100, for example. It could then serve out 100 unique IDs without the cost of hitting the database. The unique ID table had the following fields: key_name, value, buffer_size. The only cost of losing the server VM that it lived in was the unserved set of values. If this was an issue for a given table, the buffer_size field could be set to 1. Dave -----Original Message----- From: RefuX Zanzebarr To: 'arc...@li...' Sent: 2/28/02 10:03 AM Subject: [Arch4j-developers] ID Generator For the Lunch-o-Matic example I've been working on, I created an ID Generator Service for generating Primary Key IDs. I'm thinking I should probably add it into the main Arch4J. Here the current interface, how does it look? /** Service for generating IDs to be used as primary keys for the DB. * @author Jroome */ public interface IDGeneratorService { /** Get the next id * @return the next id * @param key Key to be used in generating the next id. For example the key could be a table name. Thus person table and location table could have the same ids as their primary keys. */ public IdentifierDomain getID( String key ); } Ok, I know its a simple interface, but this is an opensource project so I figure best to get the dev mailing list a little bit more active :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers |
From: Allan W. <al...@wi...> - 2002-02-28 16:40:16
|
Arch4J Full Build SourceRoss, There are properties in the build.xml file that need to be set for the = j2ee and junit installs. These you have to install on your own and = point the build to them. I believe you cannot re-distribute the j2skdee = jar files. For Junit this is done so that you only have the junit jar = files in one place. Allan ----- Original Message -----=20 From: Ross Greinke=20 To: 'arc...@li...'=20 Sent: Wednesday, February 27, 2002 7:44 PM Subject: [Arch4j-developers] Arch4J Full Build Source The full build source (arch4j-1.0-src.zip) doesn't contain all of the = files in the root directory, namely those files to build another = release. My intention with the 0.9.x releases was that the full source = distribution contained everything you needed to completely rebuild each = of the distributions (src, bin, doc). Does that still hold true?=20 Ross=20 |
From: RefuX Z. <re...@ya...> - 2002-02-28 16:03:48
|
For the Lunch-o-Matic example I've been working on, I created an ID Generator Service for generating Primary Key IDs. I'm thinking I should probably add it into the main Arch4J. Here the current interface, how does it look? /** Service for generating IDs to be used as primary keys for the DB. * @author Jroome */ public interface IDGeneratorService { /** Get the next id * @return the next id * @param key Key to be used in generating the next id. For example the key could be a table name. Thus person table and location table could have the same ids as their primary keys. */ public IdentifierDomain getID( String key ); } Ok, I know its a simple interface, but this is an opensource project so I figure best to get the dev mailing list a little bit more active :) __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com |
From: Ross G. <rgr...@sp...> - 2002-02-28 01:44:47
|
The full build source (arch4j-1.0-src.zip) doesn't contain all of the files in the root directory, namely those files to build another release. My intention with the 0.9.x releases was that the full source distribution contained everything you needed to completely rebuild each of the distributions (src, bin, doc). Does that still hold true? Ross |
From: Allan W. <al...@wi...> - 2002-02-15 15:34:13
|
The assert has been removed since version 0.9.4 when I upgraded to = latest version of JUnit... However, it looks like there are a couple of other things that JDK1.4 = causes some other issues in the base code that James will be = addressing... -Al ----- Original Message -----=20 From: Nathan Longley=20 To: arc...@li...=20 Sent: Thursday, February 14, 2002 1:56 PM Subject: [Arch4j-developers] assert Wondering if arch4j is going to be reworked to remove the new keyword = assert from its code base. This is a now a reserved word as of JDK1.4. Nathan Longley |
From: David C. <dco...@sp...> - 2002-02-15 15:10:03
|
Definitely - James is already on it. -----Original Message----- From: Nathan Longley To: arc...@li... Sent: 2/14/02 1:56 PM Subject: [Arch4j-developers] assert Wondering if arch4j is going to be reworked to remove the new keyword assert from its code base. This is a now a reserved word as of JDK1.4. Nathan Longley |
From: Nathan L. <nlo...@us...> - 2002-02-14 19:55:57
|
Wondering if arch4j is going to be reworked to remove the new keyword = assert from its code base. This is a now a reserved word as of JDK1.4. Nathan Longley |
From: RefuX Z. <re...@ya...> - 2002-02-06 23:31:23
|
Just finished adding JUNIT tests to the Ant scripts. A couple of Questions/Points 1. Allot of the unit tests require various property files in the Module property directory. Currently I just copy over the needed prop files, unit test and then delete them. However the problem is that changes to the generic property files can now break the unit tests. The solution is to store all the required properties in the module property dir, the bad side of that is if some property file format changes then there are lots of files that need to be updated! Anyways, its works fine the way it is. Just wondering if there is some consensus for doing it another way? 2. From running the Unit tests I found a problem in PropertyTreeManagerImpl. Basically it boils down to a inconsistency in how the Property directory is defined. With PropertyTreeManagerImpl the PropertyDir is set in the constructor, but in the BasicPropertyBuilder which PropertyTreeManagerImpl calls it was using the PropertyProvider to load the Properties, however PropertyProvider uses the System property "arch4j.property.directory" to look for Properties. So the BasicPropertyBuilder wasn't able to find the file referred to by PropertyTreeManagerImpl. This issue was easy enuf to fix/patch, however maybe thought needs to be given as to if PropertyTreeManagerImpl allows its dir to be set in the constructor. 3. For some reason with all the files in CVS, every single line is terminated with \r\r\n which basically gives double line spacing to every file when viewed in Netbeans and various merge tools. I wrote a little prog that strips out the \r\r and the files look fine. So I need to check in EVERYTHING (woo!). Should I be checking in under any specific branch or anything like that? I guess this is an Al question. Thats all folks! __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com |