tobrien 2003/02/28 00:22:51
Modified:digester project.xml
Log:
Maven builds do not like apstrophes in last names
Revision ChangesPath
1.9 +1 -1 jakarta-commons/digester/project.xml
Index: project.xml
tobrien 2003/02/28 00:23:31
Modified:digester project.properties
Log:
Maven development process link now points to Commons Charter
Revision ChangesPath
1.3 +1 -0 jakarta-commons/digester/project.properties
Index: project.properties
I am a newly-minted committer for the commons/net project.
Jeff Brekke suggested that my first commit be to change project.xml to put my name
among the developers section and remove it from the contributors section. I have done
so and committed the file.
The second action he asked me to take
I have tried supplying my username on the command line, via
build.properties, and while maven recognizes the username and tries
to pass it to the server, it will not let me connect.
I don't believe that maven is currently able to ask for an ssh password.
I have set up ssh keys on the server
In my build.properties, I have the line
maven.username=mbowler
...and this allows me to connect. I don't know if it makes a difference
but I'm using the latest version of maven out of cvs, not beta 8.
Steve Cohen wrote:
I can connect to the cvs server without a password using SSH. But with
Steve,
Can you connect directly to jakarta.apache.org:
ssh [EMAIL PROTECTED]
You may need to setup your public keys on this box also?
Steve Cohen [EMAIL PROTECTED] writes:
I can connect to the cvs server without a password using SSH. But
with Maven as I currently have it set up, this
No, I can't. I've tried that. I think that is the problem. How can I connect if it
won't accept my password? I don't even have access to install my ssh keys.
-Original Message-
From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED]
Sent: Fri 2/28/2003 7:57 AM
To: Jakarta Commons
One further thought, also fruitless - I tried connecting to jakarta.apache.org using
the original password that was communicated to me for cvs.apache.org. That also did
not work.
-Original Message-
From: Steve Cohen
Sent: Fri 2/28/2003 8:06 AM
To: Jakarta Commons Developers
Yea, I'm not sure how to go about getting an account there. Maybe email [EMAIL
PROTECTED] or Brian again?
jb
Steve Cohen [EMAIL PROTECTED] writes:
No, I can't. I've tried that. I think that is the problem. How can I connect if
it won't accept my password? I don't even have access to
Juozas Baliuka [EMAIL PROTECTED] writes:
Do you know some use case for this ?
As I understand it must look like this:
ResultSet last = null;
try{
if (pstmt.execute()) {//it can be update or select
do{
last =
I am working on a patch to allow listeners to be added to pools that
will receive notifications on various events. Does anyone object to
having this functionality included?
Here is the design -
I was thinking about adding support for a PoolListener interface for the
pool component. Object
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=17543.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Would it be better to use some type of action code instead?
For (a bad) example:
public final static int BORROW=0;
public final static int RETURN=1;
public final static int CREATE=2;
...
Then the event could be fired by:
listenEvent(int action, Object o) and the implementor can use a switch
I would make PoolListener more closely match the Java listener style. That
is:
1. PoolListener extends java.util.EventListener
2. The methods accept an event object that extends java.util.EventObject
(maybe call it PoolEvent).
3. The methods shouldn't throw Exception. They should throw
Actually four methods. There is also a remove event.
I generally don't care for switch statements either.
Another way to get the same effect would be to have four additional
interfaces that define the methods. Example:
Public interface PoolListener
{
}
Public interface PoolListenerOnBorrow
Also a PoolAdaptor.
On Fri, 28 Feb 2003, David Graham wrote:
I would make PoolListener more closely match the Java listener style. That
is:
1. PoolListener extends java.util.EventListener
2. The methods accept an event object that extends java.util.EventObject
(maybe call it PoolEvent).
I don't like that idea. 4 methods is a very small interface. You could
provide a PoolListenerAdaptor class that implements the interface and stubs
out all the methods for lazy people to extend ;-).
David
From: Quinton McCombs [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 1:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [POOL] Pool listeners
I would make PoolListener more closely match the Java
listener style. That
is:
1. PoolListener extends
I was just copying your idea of copying the JDK :)
Another one:
Make the Pool be the Source of the PoolEvent.
For certain events, I would expect to be able to also get the object
added, changed etc. I'm unsure about removed as that might cause issues
with the worry below.
One worry:
Good point. It could be part of the contract that the listener code
does not keep a reference to the event. I could also just remove the
option from the interface. Actually, I see very little value in the
onRemove event anyway. I mainly put it there for consistency.
-Original
They're both correct spelling.
There are 7 times as many google replies to Adapter than Adaptor, which I
know the Java i18n author suggests is the fair way to lookup which
spelling to use, but I suspect it's more likely that adaptor is the
UK/European spelling.
Hen
On Fri, 28 Feb 2003, Quinton
I don't think the jdk listeners throw exceptions. If the onBorrow (or any
other method) throws an exception, the pool will have to catch them and
handle them. I think it's best to let the interface implementations deal
with their own exceptions and not report them back to the pool.
David
In message [EMAIL PROTECTED], robert burre
ll donkin writes:
AFAIK jakarta.apache is www.apache.org which is daedelus. IIRC brian asked
that only people that really need daedelus accounts (eg release managers)
apply for them (since the server is overstretched). if you don't have an
account and
Forgive my ignorance... I am not sure that I understood what you meant.
Where you suggesting a default implementation of PoolListener called
PoolAdaptor?
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 2:20 PM
To: Jakarta Commons
Ah. My fault then. It's hard to over-write the lessons learned as a child
sometimes.
On Fri, 28 Feb 2003, David Graham wrote:
Yes, except the java adapters are spelled Adapter instead of Adaptor.
David
From: Quinton McCombs [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List
Sorry, this seems my fault. I told Steve to go ahead and perform his
first commit and publish the site. I was unaware of the limited
access to daedelus. I also agree that there are plenty of people to
push the site out.
So I pushed out the commons/net site with Steve's commiter status.
rwaldhoff2003/02/28 13:21:51
Modified:collections/src/java/org/apache/commons/collections/primitives/adapters
CollectionIntCollection.java
IntCollectionCollection.java IntListList.java
epugh 2003/02/28 12:22:10
Modified:configuration project.properties
Log:
Added cactus settings
Revision ChangesPath
1.5 +3 -1 jakarta-commons-sandbox/configuration/project.properties
Index: project.properties
epugh 2003/02/28 12:23:41
Added: configuration/src/java/org/apache/commons/configuration
CompositeConfiguration.java JNDIConfiguration.java
Log:
New Configuration types, JNDI and Composite!
Revision ChangesPath
1.1
epugh 2003/02/28 12:24:12
Added: configuration/src/test/org/apache/commons/configuration
TestCompositeConfiguration.java
TestDOM4JConfiguration.java
Log:
New Configuration types, JNDI and Composite! supporting tests
Revision
epugh 2003/02/28 12:25:00
Modified:configuration/src/test/org/apache/commons/configuration
TestConfigurationUtils.java
Log:
commented out tests, as they fail, and I can't figure out why.
Revision ChangesPath
1.2 +2 -2
epugh 2003/02/28 12:25:40
Modified:configuration/src/test/org/apache/commons/configuration
TestBaseConfiguration.java
Log:
remove extra printStackTrace.. makes you think it failed when it didn't!
Revision ChangesPath
1.6 +5 -6
epugh 2003/02/28 12:25:51
jakarta-commons-sandbox/configuration/src/test-cactus - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
epugh 2003/02/28 12:26:06
jakarta-commons-sandbox/configuration/src/test-cactus/org - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
epugh 2003/02/28 12:26:15
jakarta-commons-sandbox/configuration/src/test-cactus/org/apache - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
epugh 2003/02/28 12:28:08
Added: configuration/src/test-cactus/org/apache/commons/configuration
TestJNDIAndCompositeConfiguration.java
TestJNDIEnvironmentValues.java
Log:
new cactus tests for JNDI resources
Revision Changes
epugh 2003/02/28 12:30:18
jakarta-commons-sandbox/configuration/src/test-cactus/testapp - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
epugh 2003/02/28 12:34:20
Modified:configuration project.xml
Log:
Added new jars required. commented out testcase until I can get it to work.
Revision ChangesPath
1.22 +7 -3 jakarta-commons-sandbox/configuration/project.xml
Index: project.xml
rdonkin 2003/02/28 14:55:38
Modified:betwixt project.properties project.xml
Log:
Changed project.xml so that the repository setting is specified by a variable. This
means that the old setting is available (through an entry in project.properties) but i
can override this in my
costin 2003/02/28 15:39:21
Modified:modeler/src/java/org/apache/commons/modeler
BaseModelMBean.java
Log:
Fix weird bug ( that caused backward compat problems ).
Now commons-modeler works fine as a replacement in tomcat4.1.21 ( for example
if you use
rwaldhoff2003/02/28 16:47:29
Modified:collections/src/java/org/apache/commons/collections/primitives
AbstractRandomAccessIntList.java
collections/src/java/org/apache/commons/collections/primitives/adapters
rwaldhoff2003/02/28 16:48:26
Modified:collections .cvsignore
Log:
ignore some eclipse files
Revision ChangesPath
1.4 +2 -0 jakarta-commons/collections/.cvsignore
Index: .cvsignore
===
RCS
Steve,
I'm replying on the commons-dev list...
Steve Cohen [EMAIL PROTECTED] writes:
I began working on incorporating my changes to commons-net and came
fairly quickly to the first hurdle:
Many of my changes depend on jakarta-oro which is not now included
in the build process of the
Steve,
We came across the problem with OpenVMS's listings. Monday I'll get a
sample listing with an entry that spans two lines and add it to the
VMSFTPEntryParserTest.
Our idea was to let the regular expression handle parsing the entries
and not rely on the line endings.
I believe this is
ok, we will add this, I was not sure it can be usefull.
Do we need to call getMoreResults() before or affter getResultSet. As I
understand documentation
we must call getResultSet first (I have never used it in practice).
- Original Message -
From: george stewart [EMAIL PROTECTED]
To:
I have a question about using action objects in a loop, something
like:
...
panel name=libPanel var=libPanel
j:forEach var=item items=${manager.managedObjects}
j:set var=panelName value=${item.ID}IconPNL/
j:set var=buttonName value=${item.ID}IconBTN/
j:set var=buttonIcon
Agreed
(for once)
:-)
Oleg Kalnichevski wrote:
Laura
CPU-bound polling is needed only under fairly unusual circumstances. I
do think that any sort of thread based solution would be an overkill. I
did my best to explain the rationale for not using threads in the bug
report
Cheers
Oleg
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=10807.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Friday, February 28, 2003, at 01:51 AM, Dennis Cook wrote:
Here is the complete session:
[ ... ]
Jandalf 1) I'm kinka amazed that cross host redirects has been
absent for
so long. Its seems glaring.
[ ... ]
Indeed it is. A large amount of the redirects I see are cross-site
redirects. It
I like to send data already in memory as a byte-array in a multipart post.
In the package org.apache.commons.httpclient.methods.multipart I saw the
class ByteArrayPartSource but no corresponding ByteArrayPart class, to
use in MultipartPostMethod.addPart(Part part). Is there a special reason or
I am working on a project which uses HttpClient and plan on lurking here
to see how progress is going with HttpClient. I cannot find
commons-httpclient-user list. Am I correct that the user activity is
still on jakarta-commons-user?
-Tim
You want to use the FilePart. It accepts a PartSource in the
constructor, which ByteArrayPartSource implements.
Mike
On Friday, February 28, 2003, at 07:04 AM,
[EMAIL PROTECTED] wrote:
I like to send data already in memory as a byte-array in a multipart
post.
In the package
I admit this patch is nothing to be extremely proud of, but since it's been hanging in
the mailing list for quite a while and there have been no massive protests, I assume
it is more or less OK with everyone.
Jeff,
- Checked copywrite clause. It looks all right to me.
- Odi's name should not
There is no user list, everyone just works off of the dev list.
HttpClient is not an application, its a HTTP client site framework in
Java. Its by developers, for developers and such there is little need
for a user list at this time.
All HttpClient questions and discussion are best done here.
James,
The way I built my mental model, a multipart/form-data post consists
of two distinct kinds of parts, file parts, and string parts. The
fundamental distinction is one of binary versus text data, although
the distinction is, as always, somewhat arbitrary. I think the
nomenclature comes
55 matches
Mail list logo
