Don,
on a first glance I can see nothing wrong in your usage of the
configuration API (besides the fact that you declare the config variable
twice: once as static field and once as local variable).
Which version of [configuration] do you use?
Oh, and remember to prefix the subjects of your
The lead developer Rodney Waldorf has rather disappeared from the commons
list, thusthe project never proceeded to a release. I would not incorporate
this code in [collections] as collections is already at about its maximum
viable size.
Stephen
- Original Message -
From: Brian Lee
It seems to me that you wouldn't want to transfer files of that size
via http in any case. It makes more sense to segment the files and
then reassemble them later. That would lessen the chances of corrupted
data, loss of connection or any other network related problems. Just
an opinion.
Folks,
for anyone interested this is the current status report of commons transaction:
1.1 heading to beta1
--
Concerning my work the API extensions for 1.1 have been finished. Same
thing for new features like
- deadlock detection (hopefully, this was a major pain in
sigh One should make sure they have the most current jar before they
start coding for that jar/sigh
In this particular project I had configuration 1 instead of 2
When I substituted a properties file for the xml file everything worked
so I knew it was finding the files ok.
I put the new jar
Still another thought: Might be the best idea to store even locks into
the file system and not having them in memory. This way changes to the
file resource manager would be minimal. This would, however, require a
lock manager that saves to disk - not to difficult and certainly a
funny thing.
