jmcnally2003/09/28 23:01:54
Modified:dbcp/src/java/org/apache/commons/dbcp/datasources
InstanceKeyObjectFactory.java
PerUserPoolDataSource.java
SharedPoolDataSource.java *
craigmcc2003/09/28 23:03:57
Removed: chain/src/java/org/apache/commons/chain/impl
ContextBaseAttributes.java
Log:
Forgot to delete a class that is now obsolete due to the has-a - is-a
transition for Context.
Because the introduction to HiveMind somewhere says that HiveMind is also a
sort of Singleton manager I'd like to suggest to document somewhere (may be
in the api-docs) that when a Service is gotten twice from the Registry - in
case of the deffered-service-type - the two returned instances are
Definately interested in a service such as you describe - life-cycle
events has been chucked around in the group for a bit and I think it would
be a valueable service.
Any chans of changing it [the interface] to (perhaps) 'Manageable' to
allow for future 'start' events too or would it be too
mturk 2003/09/29 01:51:52
Removed: daemon/src/native/nt/procrun/bin tomcat.exe tomcatw.exe
Log:
Remove the binaries. They will be maintained only for
Tomcat in j-t-c.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
mturk 2003/09/29 01:53:37
Removed: daemon/src/native/nt/procrun icoi.ico icos.ico icow.ico
splash.bmp tomcatp.ico tomcatr.ico tomcats.ico
Log:
Remove the TC specific resources. They are moved to j-t-c-/procrun.
mturk 2003/09/29 01:56:50
Modified:daemon/src/native/nt/procrun procgui.c procrun.c procrun.h
procrun.rc
Added: daemon/src/native/nt/procrun extend.h
Log:
Remove the TC specific code.
This code is moved to j-t-c-/procrun.
Revision Changes
mturk 2003/09/29 01:58:31
Added: daemon/src/native/nt/procrun/testchild testchild.dsp
Log:
Add the testchild dsp.
Revision ChangesPath
1.1
jakarta-commons/daemon/src/native/nt/procrun/testchild/testchild.dsp
Index: testchild.dsp
remm2003/09/29 02:59:11
Modified:daemon build.xml
Log:
- That directory doesn't exist anymore.
Revision ChangesPath
1.2 +1 -6 jakarta-commons/daemon/build.xml
Index: build.xml
===
On Sunday, September 28, 2003, at 11:38 PM, Simon Kitching wrote:
On Mon, 2003-09-29 at 03:40, robert burrell donkin wrote:
On Saturday, September 27, 2003, at 06:43 PM, Craig R. McClanahan wrote:
Simon Kitching wrote:
Hi,
The current Rules interface defines
public List match(String uri,
+1
my preferred solution would be to create a sophisticated conversion
component starting with new backwards compatibility issues and make the
conversion in beanutils pluggable. beanutils is going to need an 'optional'
package to allow additional non-core dependencies sooner or later. i'd
[EMAIL PROTECTED] wrote:
Initial phase of switching to Context is-a Map instead of
Context has-a Map. There are some pretty interesting intricacies
to implementing the entire Map contract.
I moved my current development over this morning. It seemed to go fine,
except that I had a isNew
Thank you for your intrest and the suggestion of 'Manageable'.
I agree with you that a `Manageable` Interface, which contains a pair
start/destroy would be cleaner. I did not add the start method because
there is the Initilizable Interface. As you said very precisily my service
is an event
i think that it's important that digester retains the smallest possible
set of core dependencies. but i'd like to be able to supply users (who
need this functionality) with more exotic toys such as regular expression
based pattern matchers based on ORO or regexp. i think that the best way
to
I'm thinking something like (let's figure out better names):
public interface Manageable
{
public void enlistService();
public void poolService();
public void shutdownService();
}
enlistService() -- invoked at creation, and as a pooled service instance is removed
from the pool
and
I think that's already in there; it's a minor detail and a minor optimization, though.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-Original
I'd prefer something where the core service instance implemented the interface, and
was registered
for the notification automatically, using logic similar to how Initializable is
recognized.
Actually, I'm more picturing this as the responsibility of the service extension point
to manage
(side
Howdy,
I'm not a committer for DBCP (although I'm an enthusiastic user -- good
job!), but still wanted to chime in:
- Version number: 2.0. I think either many changes OR major changes OR
significant time since last release is enough to merit a major version
number increase. In this case, 2 of
Hello Serge,
You have shell access to the ASF CVS server, so you can already do
backups of the repository.
I didn't know that. I checked, and yes, I can go in.
I suppose you could edit history files, but I really would
recommend against it.
I've done repository manipulation (moving files
[configuration] AbstractConfigurationKonstantin,
The changes look good. And I checked through the Turbine codebase, and the
changes you propose don't look like they will cause problems
Could you do me a favor and submit a patch file? Not sure what editor you
use, but Eclipse does a good
husted 2003/09/29 08:33:22
jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/config -
New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
husted 2003/09/29 08:34:45
Added: chain/src/java/org/apache/commons/chain/web/servlet/config
ChainServlet.java
Log:
Generic ChainSerlvet to allow loading a Catalog in any servlet environment.
Contributed by Matthew J. Sgarlata,
Revision Changes
husted 2003/09/29 08:35:48
Modified:chain/src/java/org/apache/commons/chain Catalog.java
Log:
Add convenience static for storing a default catalog attribute in some context.
Revision ChangesPath
1.2 +11 -4
Sgarlata Matt wrote:
Attached is a first cut at creating a ChainServlet. Committers,
please feel
free to add this to CVS (you'll need to add the license, version #s,
and change the package declaration), to modify it, or to tell me what
to do to modify it (and I will do so).
Can we change it to
hlship 2003/09/29 08:36:52
Modified:hivemind/framework/src/java/org/apache/commons/hivemind
ConfigurationPoint.java
hivemind/framework/src/java/org/apache/commons/hivemind/parse
ConfigurationPointDescriptor.java
husted 2003/09/29 08:38:36
Modified:chainPROPOSAL.html
Log:
Update regarding Commons Logging dependance.
Revision ChangesPath
1.7 +4 -1 jakarta-commons-sandbox/chain/PROPOSAL.html
Index: PROPOSAL.html
hlship 2003/09/29 08:39:49
Modified:hivemind/framework/src/java/org/apache/commons/hivemind
ServiceModel.java
Log:
Refactor the service extension point implementations into a single
ServiceExtensionPointImpl and multiple implementations of the new
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23469.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
husted 2003/09/29 08:44:40
Modified:chain/src/java/org/apache/commons/chain/impl
CatalogBase.java
Log:
Apply contributions by Matthew Sgarlata, #23469
Revision ChangesPath
1.4 +40 -6
You should create a bugzilla ticket under Struts for an enhancement to
the Standard Actions component and post this here.
I plan to adopt the ProcessAction in Scaffold to do this too, but that's
a more complex usage, so I think there would be room for a simple case too.
-Ted.
Sgarlata Matt
Craig R. McClanahan wrote:
- If a user attempts to remove() the key corresponding to a property,
throw IllegalArgumentException.
Can we make this an optional behavior?
The contact for Map.get and Map.remove says that they will return null
if the entry is not present or if the value is null.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23488.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
hlship 2003/09/29 09:16:06
Modified:hivemind/framework/src/java/org/apache/commons/hivemind/impl
ThreadedServiceModel.java
Log:
Refactor the service extension point implementations into a single
ServiceExtensionPointImpl and multiple implementations of the
hlship 2003/09/29 09:16:35
Modified:hivemind/xdocs index.xml multithreading.xml localization.xml
descriptor.xml override.xml ioc.xml case1.xml
configurations.xml bootstrap.xml services.xml
rules.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23488.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
This is a Apache 1.0 License, The give away is it mentions 'Apache Group'
[EMAIL PROTECTED] wrote:
husted 2003/09/29 08:34:45
Added: chain/src/java/org/apache/commons/chain/web/servlet/config
ChainServlet.java
Log:
Generic ChainSerlvet to allow loading a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23491.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23488.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Ted Husted wrote:
[EMAIL PROTECTED] wrote:
Initial phase of switching to Context is-a Map instead of
Context has-a Map. There are some pretty interesting intricacies
to implementing the entire Map contract.
I moved my current development over this morning. It seemed to go
fine, except
robert burrell donkin wrote:
i think that it's important that digester retains the smallest
possible set of core dependencies. but i'd like to be able to supply
users (who need this functionality) with more exotic toys such as
regular expression based pattern matchers based on ORO or regexp. i
[EMAIL PROTECTED] wrote:
husted 2003/09/29 08:44:40
Modified:chain/src/java/org/apache/commons/chain/impl
CatalogBase.java
Log:
Apply contributions by Matthew Sgarlata, #23469
Revision ChangesPath
1.4 +40 -6
Ted Husted wrote:
Craig R. McClanahan wrote:
- If a user attempts to remove() the key corresponding to a property,
throw IllegalArgumentException.
Can we make this an optional behavior?
Only if we make attribute-property transparency optional. That's what
the contract for
Ted Husted wrote:
Sgarlata Matt wrote:
Attached is a first cut at creating a ChainServlet. Committers,
please feel
free to add this to CVS (you'll need to add the license, version #s,
and change the package declaration), to modify it, or to tell me what
to do to modify it (and I will do so).
husted 2003/09/29 10:45:29
Modified:chain/src/java/org/apache/commons/chain/impl
CatalogBase.java
Log:
Replace rendundant Javadoc with reference to Interface.
Revision ChangesPath
1.5 +7 -19
On Mon, 29 Sep 2003, [iso-8859-1] Juancarlo Añez wrote:
I suppose you could edit history files, but I really would
recommend against it.
I've done repository manipulation (moving files around, basically) before
for what I think are valid reasons. I always do a full backup first.
In
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23498.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23498.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
dirkv 2003/09/29 12:47:07
Added: dbcp RELEASE_PLAN_1_1.txt
Removed: dbcp RELEASE_PLAN_2_0.txt
Log:
change version number to 1.1
Revision ChangesPath
1.1 jakarta-commons/dbcp/RELEASE_PLAN_1_1.txt
Index: RELEASE_PLAN_1_1.txt
dirkv 2003/09/29 12:47:29
Added: pool RELEASE_PLAN_1_1.txt
Removed: pool RELEASE_PLAN_2_0.txt
Log:
change version number to 1.1
Revision ChangesPath
1.1 jakarta-commons/pool/RELEASE_PLAN_1_1.txt
Index: RELEASE_PLAN_1_1.txt
husted 2003/09/29 13:02:08
Modified:chain/src/java/org/apache/commons/chain Context.java
Command.java Chain.java Catalog.java
Log:
License and Javadoc tweaks only. No code changes.
Revision ChangesPath
1.4 +13 -19
dirkv 2003/09/29 13:18:20
Modified:dbcp RELEASE_PLAN_1_1.txt
Log:
- shorten review period
- Release Candidate policy
- make clear the release vote will be held as soon as all issues are resolved
Revision ChangesPath
1.2 +8 -3
dirkv 2003/09/29 13:18:29
Modified:pool RELEASE_PLAN_1_1.txt
Log:
- shorten review period
- Release Candidate policy
- make clear the release vote will be held as soon as all issues are resolved
Revision ChangesPath
1.2 +9 -4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23498.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
OK, I will clean this class up and add to BugZilla sometime this week.
One question though is that I think it's important this class catch
exceptions and rethrow them as something that makes more sense (and also
throw new exceptions if configuration issues are detected). I defined a
hlship 2003/09/29 13:56:19
Modified:hivemind/framework/src/java/org/apache/commons/hivemind/service/impl
ThreadEventNotifierImpl.java
Added: hivemind/framework/src/test/hivemind/test/util
TestEventListenerList.java
dirkv 2003/09/29 14:08:09
Modified:dbcp/xdocs index.xml
Log:
added a reference to tomcat
added a reference to the James DBCP-Avalon integration
as suggested by Serge Knystautas
Revision ChangesPath
1.4 +13 -0 jakarta-commons/dbcp/xdocs/index.xml
I have added a reference to your work to the overview (index) page.
A more complete example would of course be usefull.
Thanks
Dirk
Serge Knystautas wrote:
Dirk,
I thought I'd link to the change since it was useful for me to review:
leosutic2003/09/29 14:17:08
Modified:attributes/api/src/java/org/apache/commons/attributes
Attributes.java CachedRepository.java
DefaultCachedRepository.java
I made the use of (multiple) Release Condidates more explicit in the
release plan.
Testing commons-pool standalone will be very usefull.
Be sure to try the performance test at:
commons-pool/src/test/org/apache/commons/pool/performance/PerformanceTest.java
Cheers
Dirk
Shapira, Yoav wrote:
Yes, change can be good, and deprecating and changing does happen. The
trouble with removing is that there is nowhere for users to go to. And we
just don't know who the users are.
There is some useful functionality here. Its a little odd, but perhaps in a
untyped system like [beanutils] or [el],
the difficult bit is working out the right abstraction for the strategy.
due to backwards compatibility issues, we'd want to get it right before
beanutils is released again. but this is actually a more general issue
which applies to all the new beans.
- robert
On Monday, September 29, 2003,
I'm not sure I understand your post.
It may be early to discuss an adapter between convert and beanutils because
convert isn't even in the sandbox yet, but here's what I was thinking.
Beanutils has a register(Converter, Class) method that gives each class a
converter. Convert would be defining
John,
Should the PerUserPoolDataSource and other dbcp/datasources/* be
included in the release?
You did a rather large commit today, is the implementation ready for
release or do you want to wait for next one.
Dirk
-
To
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23503.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Sunday, September 28, 2003, at 11:16 PM, Sgarlata Matt wrote:
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Sunday, September 28, 2003 4:43 PM
Subject: Re: [beanutils] some ideas
snip
Can anyone think of any
What do you think Phil, is a vote for deprecation with no replacement
desirable?
You're the one who sparked the discussion, I was just chiming in with
some general noise.
Stephen Colebourne wrote:
Yes, change can be good, and deprecating and changing does happen. The
trouble with removing
On Monday, September 29, 2003, at 06:56 PM, Henri Yandell wrote:
On Mon, 29 Sep 2003, [iso-8859-1] Juancarlo Añez wrote:
I suppose you could edit history files, but I really would
recommend against it.
I've done repository manipulation (moving files around, basically) before
for what I think are
I haven't noticed any problems. But I do have one question.
Why is this a 2.0 release instead of say a 1.1 release?
The changes don't warrant a major revision change to 2.0 IMHO.
Regards,
Glenn
Dirk Verbeeck wrote:
I'd like to propose a vote on the following release plan
for DBCP 2.0. This
I believe the Commons Lang implementation is equivalent:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/exception/NestableException.html
Sgarlata Matt wrote:
OK, I will clean this class up and add to BugZilla sometime this week.
One question though is that I think it's
scolebourne2003/09/29 15:02:34
Modified:collections/src/java/org/apache/commons/collections/iterators
IteratorChain.java FilterIterator.java
ProxyListIterator.java CollatingIterator.java
UniqueFilterIterator.java
+1, I have been running the latest from CVS on several test/dev systems.
No problems seen yet.
Glenn
Dirk Verbeeck wrote:
I'd like to propose a vote on the following release plan
for DBCP 2.0. This release plan can also be found
at:
On Mon, 2003-09-29 at 23:18, robert burrell donkin wrote:
i think that it's important that digester retains the smallest possible
set of core dependencies. but i'd like to be able to supply users (who
need this functionality) with more exotic toys such as regular expression
based pattern
On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
Well, I just want to note that the original reason I raised the
possibility of returning ListIterator for matches was to resolve a
problem I had with implementing a Plugins module. I have since had an
epiphany :-) and have found a
scolebourne2003/09/29 15:37:41
Modified:collections/src/java/org/apache/commons/collections/iterators
CollatingIterator.java EnumerationIterator.java
ArrayListIterator.java ArrayIterator.java
Log:
Javadoc and Code tidy
Revision
It seems to me that this sort of thing should be able to be handled by
lazy consensus. From Stephen's remarks, it appears that he is -1 to
deprecation without replacement, which means to me that there is no
consensus on deprecation without replacement, so we should either leave
it alone (which
Mike,
I believe this problem has nothing to do with 'connection: close' header. The
force-close flag must be explicitly set by invoking
HttpMethodBase#setConnectionCloseForced(boolean). There are only two invocations of
this method in our code. None of them should have been triggered by the
I've been working with HttpClient for the past few days and have it just
about working to my liking. I must say I really like how it's designed!
However there's one bit that still bugs me...authentication of proxy and web
servers (response codes 401 and 407). Basically, what I'd like to do is
Hi,
Today I cannot find the web page for our httpclient project. The
apache homepage links to commons.apache.org, which does not have any
information. What happened? Where can I find the httpclient web page?
Thank you.
Yue
I don't think commons.apache.org is actually used.
Try jakarta.apache.org/commons
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
79 matches
Mail list logo
