On Mon, 21 Jul 2003, Davanum Srinivas wrote:
Costin,
Right now modeler just allows parameters that are listed in the supportedType method
when we use
introspection.
#1 - How difficult/easy is it to allow other data types? (Why is this list of items
limited?)
It's not difficult to add
On Mon, 21 Jul 2003, Costin Manolache wrote:
Date: Mon, 21 Jul 2003 22:28:45 -0700 (PDT)
From: Costin Manolache [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Davanum Srinivas [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [modeler] Introspection
The following issue has been updated:
Updater: Willie Vu (mailto:[EMAIL PROTECTED])
Date: Tue, 22 Jul 2003 2:57 AM
Comment:
A patch to the problem. Now ResourceBundle is loaded from JellyContext's class loader
Changes:
Attachment changed to
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-62
Here is an overview of the issue:
Serge,
1. Remove existing abandoned recovery attempt code.
2. Log when connections are abandoned and do not add them back into the
pool.
3. Optionally log stack trace of where abandoned connection was first
grabbed.
4. Provide some kind of extensible connection object that could allow
I think I would expect:
StringUtils.slice(foo, b) = foo
get everything before the last 'b'
StringUtils.sliceRemainder(foo, b) =
get everything after the last 'b'
StringUtils.sliceFirst(foo, b) =
get everything before the first 'b'
StringUtils.sliceFirstRemainder(foo, b) = foo
get everything
Serge et al,
Further to my suggestion about using the Observer pattern for event
notification w.r.t. point 4 (below) I forgot to mention that it also has the
benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test connections need
Craig,
If i hear you right...If the Java class is a well behaved JavaBean then we should not
need a
mbeans-descriptor.xml. Right? That was exactly my point :) I want to use modeler in
axis and was
wondering if i really needed the mbeans-descriptor.xml files.
Of course if the tool can generate
I do not think it is good idea to maintain any kind of public API for
abandoned connections, It is garbage,
If application or server is not broken, it doe's not need workarounds.
Workarounds can not help for broken applications any way, it is a useless
stuff and it infects code with Observers.
As
I'm still here. I'm currently drowning in work so I didn't have much
time for IO lately. But I guess that changes in a few days.
Please just throw your suggestions in. Any help is welcome.
On 22.07.2003 07:10:09 __matthewHawthorne wrote:
I'm interested in contributing to [io] project. I have a
Juozas,
I do not think it is good idea to maintain any kind of public API for
abandoned connections, It is garbage,
If application or server is not broken, it doe's not need workarounds.
It is easy for you to say this, but the fact remains that a number of people
are quite vocal in their
See attached a diff for both issues.
Thanks,
dims
PS: Shall i commit it?
--- Davanum Srinivas [EMAIL PROTECTED] wrote:
Craig,
If i hear you right...If the Java class is a well behaved JavaBean then we should
not need a
mbeans-descriptor.xml. Right? That was exactly my point :) I want
I would disagree on one point. The idea of logging when a connection is
closed due to garbage collection finalization strikes me as a good one
(assuming the pool used is using a weakly referenced mapping otherwise
garbage collection release of resources is going to be a real bummer).
this kind of
- Original Message -
From: Danny Angus [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 2:19 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas,
I do not think it is good idea to maintain any kind of public API for
Danny Angus wrote:
Serge et al,
Further to my suggestion about using the Observer pattern for event
notification w.r.t. point 4 (below) I forgot to mention that it also has the
benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test
Juozas,
I think I will leave commons and I will spend more my time on SF
with forked
code, if this kind of vote can win at apache.
My input is not a very big, but I will lose any energy to work for crap .
I think it is sad that you would rather leave than suggest any alternative.
It
--- Danny Angus [EMAIL PROTECTED] wrote:
Juozas,
I think I will leave commons and I will spend more my time on SF
with forked
code, if this kind of vote can win at apache.
My input is not a very big, but I will lose any energy to work for
crap .
I think it is sad that you would
David Graham wrote:
IMO, a design that allows users to plugin behaviors, be they connection
retrieval or otherwise, is the best solution. Then the question becomes
whether to include a connection retrieval behavior in the DBCP release. I
think that's far outside the scope of DBCP and encourages
- Original Message -
From: Danny Angus [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 3:18 PM
Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
Juozas,
I think I will leave commons and I will spend more my time on SF
--- Serge Knystautas [EMAIL PROTECTED] wrote:
David Graham wrote:
IMO, a design that allows users to plugin behaviors, be they
connection
retrieval or otherwise, is the best solution. Then the question
becomes
whether to include a connection retrieval behavior in the DBCP
release. I
FYI, There is no code in MbeansDescriptorsIntrospectionSource for adding
ConstructorInfo to
ManagedBean's.
-- dims
=
Davanum Srinivas - http://webservices.apache.org/~dims/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
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=21797.
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=21797.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stephen Colebourne wrote:
I think I would expect:
StringUtils.slice(foo, b) = foo
get everything before the last 'b'
StringUtils.sliceRemainder(foo, b) =
get everything after the last 'b'
StringUtils.sliceFirst(foo, b) =
get everything before the first 'b'
StringUtils.sliceFirstRemainder(foo,
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=21800.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 22 Jul 2003, Juozas Baliuka wrote:
Date: Tue, 22 Jul 2003 14:15:53 +0200
From: Juozas Baliuka [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: Re: [DBCP] AbandonedTrace - Connection Recovery
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=21801.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 22 Jul 2003, Davanum Srinivas wrote:
Date: Tue, 22 Jul 2003 03:45:15 -0700 (PDT)
From: Davanum Srinivas [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: Re:
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=21801.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 22 Jul 2003, Craig R. McClanahan wrote:
On Tue, 22 Jul 2003, Juozas Baliuka wrote:
Date: Tue, 22 Jul 2003 14:15:53 +0200
From: Juozas Baliuka [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
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=21801.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 22 Jul 2003, Davanum Srinivas wrote:
Date: Tue, 22 Jul 2003 05:44:08 -0700 (PDT)
From: Davanum Srinivas [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: Re:
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=21801.
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=21801.
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=21801.
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=21801.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 22 Jul 2003, Davanum Srinivas wrote:
Date: Tue, 22 Jul 2003 07:12:32 -0700 (PDT)
From: Davanum Srinivas [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [modeler] Instrospection does not fillup
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=21801.
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=21801.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
David Graham wrote:
--- Serge Knystautas [EMAIL PROTECTED] wrote:
David Graham wrote:
IMO, a design that allows users to plugin behaviors, be they
connection
retrieval or otherwise, is the best solution. Then the question
becomes
whether to include a connection retrieval behavior in the DBCP
dims2003/07/22 09:03:19
Modified:modeler STATUS.html
modeler/src/java/org/apache/commons/modeler/modules
MbeansDescriptorsIntrospectionSource.java
Log:
- Added myself to STATUS.html
- Introspection now allows all primitives listed in the
I submitted patches for some small changes, everything is in bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21801
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think you should not deprecate previous constructors.
And actually no reason to be deprecated as I see.
And about String boolean constructors,
1. JUST CONVENIENCE:
that's ok though... you'd better clear up some comments on the top of the class usage
as I see.
2. FOR REVOLUTION:
when
Yup, seen them. Will look at them on Thursday or Friday if nobody acts
sooner. But the rename will likely provoke some Gump failures. Do we
need to inform the dependant projects prior to the renaming or shall we
just make it happen and let the others sort it out (IO is not released)?
On
Ok, I'll say you're not gonna use char type as external interfaces...
It's not confined in constructors only...methods with char type arguments
and other classes like HttpURL...
(Actually, I think you should be interested in HttpURL... not only URI, I believe)
Please, take care of them also with
http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC
onnection.html
+1 to implement this interface, but I do not think it can help for broken
applications.
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL
I agree that this is an education/policy issue. But sometimes you need
a stop gap solution to keep something running while the customer fixes
the problem.
I would like to see this stop gap solution included with the DBCP release.
Along with quality docs on how to properly use a db
I downloaded the jelly src 1.0, and maven-1.0-beta-10.zip. When I build
I run maven or maven test I get these errors...
WARNING: Failed to download jdbc-2.0.jar.
Attempting to download jms-1.0.2b.jar.
Error retrieving artifact from
[http://www.ibiblio.org/maven/jms/jars/jms-1.0.2b
.jar]:
Dean Hiller wrote:
I downloaded the jelly src 1.0, and maven-1.0-beta-10.zip. When I build
I run maven or maven test I get these errors...
WARNING: Failed to download jdbc-2.0.jar.
Attempting to download jms-1.0.2b.jar.
Error retrieving artifact from
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=21815.
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=21797.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
OK, the current behaviour seems daft to me. Can anyone explain why this is
as it is?
StringUtils.sliceFirst(abc, ) = abc
StringUtils.sliceFirst(abc, d) =
StringUtils.sliceFirstRemainder(abc, ) =
StringUtils.sliceFirstRemainder(abc, d) = abc
I would expect the exact opposite:
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=21797.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi ,
I guess , when user calls method beanReader.parse(file) ,
the update of class org.apache.commons.betwixt._expression_.MethodUpdater gets
called.
I observed that if the data types are java.util.Date , int the
attributes are not getting converted to the required data type and
The following issue has been updated:
Updater: Willie Vu (mailto:[EMAIL PROTECTED])
Date: Tue, 22 Jul 2003 9:11 PM
Comment:
A patch to make all attributes accept expressions
Changes:
Attachment changed to EmailTag.java.patch.txt
mbecke 2003/07/22 18:20:32
Added: httpclient/src/java/org/apache/commons/httpclient/auth
CredentialsNotAvailableException.java
InvalidCredentialsException.java
Log:
Added exceptions missing from previous patch.
PR: 19868
mbecke 2003/07/22 18:28:02
Modified:httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
Log:
Added connection life-cycle debugging.
PR: 21788
Revision ChangesPath
1.21 +10 -4
On Tue, 2003-07-22 at 10:15, Juozas Baliuka wrote:
http://java.sun.com/products/jdbc/jdbc2_0_1-stdext-javadoc/javax/sql/PooledC
onnection.html
+1 to implement this interface, but I do not think it can help for broken
applications.
That is an interface to be implemented by a jdbc driver
mbecke 2003/07/22 18:47:20
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
MultiThreadedHttpConnectionManager.java
Log:
Added connection life-cycle debugging.
PR: 21788
Revision Changes
Must be linked to which method was which.
chomp x: cut off x and everything after it
prechomp x:cut off x and everything before it
getChomp x:return the inverse of chomp x
getPrechomp x: return the inverse of prechomp x
chomp - slice [chomp changed to meet perl chomp]
dgraham 2003/07/22 17:12:28
Modified:mapper/src/share/org/apache/commons/mapper/jdbc
JdbcHelper.java
Log:
Added executeUpdate() method that takes no replacement
parameters for executing things like DELETE FROM table_x.
Revision ChangesPath
1.7
A technique I have used is to deprecate the classes with a clear 'WILL BE
DELETED' message. Then delete them a couple of weeks later.
Stephen
- Original Message -
From: __matthewHawthorne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003
On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote:
I agree that this is an education/policy issue. But sometimes you need
a stop gap solution to keep something running while the customer fixes
the problem.
I would like to see this stop gap solution included with the DBCP release.
-Original Message-
From: John McNally [mailto:[EMAIL PROTECTED]
Why is this such a contentious issue?
FWIW, because some users have business experience, and some do not.
Those who do recognize that business *runs* on stopgap solutions. The
fewer of those stopgap solutions you have to
I have attached some minor changes to Algorithms. You may have already addressed
these.
1. The example in the class level java doc, the nested expression, had some
issues.
2. Tried to improve the class level javadoc a little.
3. The [EMAIL PROTECTED] javadoc references to Generator were pointing
Here are the changes I mentioned tar/gzipped. They didn't seem to make it as
flat files.
-jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- Laird J. Nelson [EMAIL PROTECTED] wrote:
-Original Message-
From: John McNally [mailto:[EMAIL PROTECTED]
Why is this such a contentious issue?
FWIW, because some users have business experience, and some do not.
Those who do recognize that business *runs* on stopgap
Henri Yandell wrote:
Must be linked to which method was which.
chomp x: cut off x and everything after it
prechomp x:cut off x and everything before it
getChomp x:return the inverse of chomp x
getPrechomp x: return the inverse of prechomp x
chomp - slice [chomp changed to
David Graham wrote:
This is absolutely not a DBCP code issue; it is a management issue.
Applications that leak resources should have their own separate connection
pool. When they run out of connections, only that app will break and
won't affect any other applications on the server. It will be
I like innovations, but try to implement and test it at home please.
I am sure there are not so many situations in the real world need this
feature.
It takes a few minutes to find connection leak and to fix it in any
applications, doe's not it ?
David Graham wrote:
This is absolutely not a
Juozas Baliuka wrote:
I like innovations, but try to implement and test it at home please.
I am sure there are not so many situations in the real world need this
feature.
It takes a few minutes to find connection leak and to fix it in any
applications, doe's not it ?
It does not.
I have 2 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=21819.
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=21819.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
This attitude is not very helpful. I don't see how dbcp supplying the
ability to configure a connection pool to reclaim connections is that
big of an issue.
Have you tried to solve problems this way ? Is it tested solution and can be
used for high quality software ?
Try to implement and
Here's an odd heads up for you. I've come across an IIS server which
doesn't like:
GET /eljconfig.xml HTTP/1.1
User-Agent: test
// Note the server interrupts at this point without waiting for the
rest of the request
Content-HTTP/1.1 500 Server Error
Server: Microsoft-IIS/5.0
Date: Tue, 22 Jul
Adrian Sutton wrote:
Odi,
We do need to improve tests, mostly in the area of keeping the
connection alive correctly, however we actually do have a test for this
particular case (and it passes). There's just something screwy going on
and we need to get the original exception out so we can try
Adrian Sutton wrote:
+if (!headers[i].getName().equals(Host)) {
Shouldn't this be equalsIgnoreCase() ?
regards,
Roland
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=21788.
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=19868.
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=19868.
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=21788.
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=16729.
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=16729.
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=21788.
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=17947.
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=10805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
ok with me
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947
Need setURI() methods in HttpMethod interface
--- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:15 ---
Any objections to committing this one?
Oleg
Adrian,
The actual stack trace is the following:
java.security.NoSuchAlgorithmException: Cannot find any provider supporting
DES/ECB/NoPadding
at javax.crypto.Cipher.getInstance(DashoA6275)
at org.apache.commons.httpclient.auth.NTLM.getCipher(NTLM.java:171)
at
Could it be a classloader issue? Are you experiencing this error when
running your app in an application server context, through Webstart etc.
but not when running it standalone?
Odi
Andre Augusto de Oliveira Aragao wrote:
Adrian,
The actual stack trace is the following:
Odi,
I just tested it standalone. I didn´t test it using an application server,
and my application doesn´t use any special classloader.
Andre
-Mensagem original-
De: Ortwin Glück [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 22 de julho de 2003 10:38
Para: Commons HttpClient Project
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=17947.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Well...
Hi...
I really had still not tested in REAL standalone mode... I was running it
inside Eclipse. I ran it outside Eclipse and it works... It seems to be
something related to Eclipse.
Sorry for bothering you.
Thanks!!!
Andre
-Mensagem original-
De: Andre Augusto de Oliveira
- Original Message -
--- Additional Comments From [EMAIL PROTECTED] 2003-07-17 15:12 ---
Claus,
This is a re-thrown exception from a URIException. The colon character (:) must
be escaped (%3a) as it delimits the protocol identifier from the host part in a
URL. HttpClient
As I see, in the HttpClient project, URI or HttpURL class doesn't apear as an object.
That means actually it's enough to ust use URIUtil class about all URI components, I
guess
- Original Message -
From: [EMAIL PROTECTED]
--- Additional Comments From [EMAIL PROTECTED]
Just for the records, when Eclipse detects the JRE, it includes
sunjce_provider.jar. Running the app with the default Eclipse JRE renders
JCE unusable. But, if you take sunjce_provider.jar out of the list, no
problem.
Andre
-Mensagem original-
De: Andre Augusto de Oliveira Aragao
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=21788.
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=19868.
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=17947.
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=16729.
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=16729.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
1 - 100 of 101 matches
Mail list logo
