Sorry, using rc1 does not help. The script fails at a position where a
stylesheet var is accessed which obviously is null. Are there any files
missing in the transaction package?
Oliver
Dirk Verbeeck wrote:
I'm still using rc1. It works for me and it seems the best release
candidate, both rc2
For commons packages everything works fine, but for commons sandbox
packages maven site fails...
Oliver Zeigermann wrote:
Sorry, using rc1 does not help. The script fails at a position where a
stylesheet var is accessed which obviously is null. Are there any files
missing in the transaction
Can't you send us (maven-users) the log for your problem.
We will try to help us.
Arnaud
-Message d'origine-
De : Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 27 mai 2004 12:39
À : Jakarta Commons Developers List
Objet : Re: [transaction] website
Sorry, using
Here it is (this was generated using Maven 1.0-rc1):
xdoc:jelly-transform:
[echo] Generating
E:/workspace/jakarta-commons-sandbox/vfs/target/docs/changelog-report.html
from
E:\workspace\jakarta-commons-sandbox\vfs\target\generated-xdocs\changelog-report.xml
BUILD FAILED
File..
Do you have the same error with RC3 ??
I think that this problem was an known bug resolved in the RC3.
http://jira.codehaus.org/browse/MPXDOC-93
http://jira.codehaus.org/browse/MPXDOC-84
Arnaud.
-Message d'origine-
De : Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Envoyé : jeudi
Craig R. McClanahan wrote:
Noel J. Bergman wrote:
The upcoming version 1.0.4 of commons-logging has an AvalonLogger
So we create an AvalonLogger around our component's logger, and pass
that to any object that uses commons-logging.
I'm travelling and away from my CVS sources for [logging], but
Do you have the following directory structure
E:/workspace/jakarta-commons/commons-build
E:/workspace/jakarta-commons-sandbox/commons-build
E:/workspace/jakarta-commons-sandbox/transaction
E:/workspace/jakarta-commons-sandbox/vfs
project.properties refers to
The problem you have is that in your project.properties you have :
maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl
Maven doesn't find this file.
You must have something like :
maven.xdoc.jsl=../sandbox-build/commons-site.jsl
Or
Aaaah, thanks a lot that fixed it...
Cheers,
Oliver
Dirk Verbeeck wrote:
Do you have the following directory structure
E:/workspace/jakarta-commons/commons-build
E:/workspace/jakarta-commons-sandbox/commons-build
E:/workspace/jakarta-commons-sandbox/transaction
ozeigermann2004/05/27 07:10:18
Modified:transaction project.properties
Log:
Fixed path
Revision ChangesPath
1.2 +1 -1 jakarta-commons-sandbox/transaction/project.properties
Index: project.properties
Thanks for your help! Dirk already pointed me in that direction...
Cheers,
Oliver
Heritier Arnaud wrote:
The problem you have is that in your project.properties you have :
maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl
Maven doesn't find this file.
You must have something
Some points:
1. The classloader for any thread in a servlet container is guarnteed to
be unique per Web Application (context). Each Web Application has it's
own classloader, which is part of the servlet spec. I'm not sure i
understand
what your saying here.
2. I wouldn't be using
As stated in another posting, there would be no dependency.
The discovery involves about 2 - 3 methods of small to medium
length, and would reside directly in the commons-logging code.
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 26, 2004 5:17 PM
here's the general idea:
public interface LogProvider {
Log createLog(String name);
Log createLog(Class clazz);
}
These instances would be discovered the first time a log
was asked for. After determining which LogProvider to use,
it would simply call the createLog method when a new
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=23229.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Has anyone read my latest comment regarding the ComplexFormat issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29000? I never saw
a message come across the mailing list. Anyway, I was waiting for
some feedback before I proceeded.
Brent Worden
http://www.brent.worden.org/
imario 2004/05/27 12:09:37
Modified:vfs/src/java/org/apache/commons/vfs/provider/http
HttpFileProvider.java HttpFileSystem.java
vfs/src/java/org/apache/commons/vfs Resources.properties
imario 2004/05/27 13:06:56
Modified:vfs/src/java/org/apache/commons/vfs/example
ShowProperties.java
Log:
show the first 5 children-names of an folder
Revision ChangesPath
1.4 +11 -2
some input for further io development.
http://www.freeroller.net/page/fate/20040527#commons_io_by_retards_for
4 points I think:
1) Writer doesn't like true/false filters. basically the Null pattern.
Nothing bad here I reckon.
2) Writer doesn't like the And/Or lego style of filters. I like
imario 2004/05/27 13:15:28
Modified:vfs/src/java/org/apache/commons/vfs/provider/ftp
FtpFileObject.java
Log:
transparently handle symbolic links, beside the file-type (which was the case
currently) now
content size
modification date
and children
Hello !
I implemented the handlink of symbolic links on an ftp-server.
Those links are now transparently handeled:
Type:
*) content size
*) modification date
*) and children
are automatically fetched from the link destination.
My first try was to introduce a new FileType (FileType.LINK), but this
Date: 2004-05-27T13:31:56
Editor: 216.26.136.155
Wiki: Jakarta Commons Wiki
Page: TheSandbox
URL: http://wiki.apache.org/jakarta-commons/TheSandbox
no comment
Change Log:
--
@@ -11,7 +11,7 @@
*
Date: 2004-05-27T13:33:19
Editor: 216.26.136.155
Wiki: Jakarta Commons Wiki
Page: TheSandbox
URL: http://wiki.apache.org/jakarta-commons/TheSandbox
no comment
Change Log:
--
@@ -11,7 +11,7 @@
*
On 27 May 2004, at 14:58, Noel J. Bergman wrote:
Craig R. McClanahan wrote:
Noel J. Bergman wrote:
The upcoming version 1.0.4 of commons-logging has an AvalonLogger
So we create an AvalonLogger around our component's logger, and pass
that to any object that uses commons-logging.
I'm travelling and
JRCS now lives outside of Jakarta and I don't believe we had any interest
in maintaining/developing our version at all as the primary (only)
developer is with the one outside of Jakarta.
Can we kill the version in the sandbox somehow, and does anyone have any
good ideas on the best way to kill
Date: 2004-05-27T13:57:24
Editor: 217.42.133.87
Wiki: Jakarta Commons Wiki
Page: TheSandbox
URL: http://wiki.apache.org/jakarta-commons/TheSandbox
no comment
Change Log:
--
@@ -1,12 +1,14 @@
=
Date: 2004-05-27T14:04:07
Editor: 216.26.136.155
Wiki: Jakarta Commons Wiki
Page: TheSandbox
URL: http://wiki.apache.org/jakarta-commons/TheSandbox
no comment
Change Log:
--
@@ -1,6 +1,6 @@
=
On 27 May 2004, at 15:29, Inger, Matthew wrote:
Some points:
1. The classloader for any thread in a servlet container is guarnteed
to
be unique per Web Application (context). Each Web Application has
it's
own classloader, which is part of the servlet spec. I'm not sure i
understand
On 27 May 2004, at 21:57, Henri Yandell wrote:
JRCS now lives outside of Jakarta and I don't believe we had any
interest
in maintaining/developing our version at all as the primary (only)
developer is with the one outside of Jakarta.
Can we kill the version in the sandbox somehow, and does
Date: 2004-05-27T14:42:40
Editor: 82.38.65.173
Wiki: Jakarta Commons Wiki
Page: Logging/1.0.4ReleasePlan
URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.4ReleasePlan
no comment
Change Log:
--
(please note that this is just the VOTE for the release plan, not the
VOTE for the release!)
the plan is in place for commons-logging 1.0.4 release
(http://wiki.apache.org/jakarta-commons/Logging/1_2e0_2e4ReleasePlan).
i'd like to propose i act as release manager for the 1.0.4 release and
Date: 2004-05-27T15:16:56
Editor: 217.42.133.87
Wiki: Jakarta Commons Wiki
Page: TheSandbox
URL: http://wiki.apache.org/jakarta-commons/TheSandbox
no comment
Change Log:
--
@@ -30,3 +30,8 @@
*
From: robert burrell donkin [EMAIL PROTECTED]
Can we kill the version in the sandbox somehow, and does anyone have
any
good ideas on the best way to kill said version?
AFAIK it's against policy to delete ASF copyright material.
we could remove the source from cvs (but not delete) but it
Okay, I'll make it so.
Hen
On Thu, 27 May 2004, Stephen Colebourne wrote:
From: robert burrell donkin [EMAIL PROTECTED]
Can we kill the version in the sandbox somehow, and does anyone have
any
good ideas on the best way to kill said version?
AFAIK it's against policy to delete
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29263.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
+1
On Thu, 27 May 2004 22:52:55 +0100, robert burrell donkin
[EMAIL PROTECTED] wrote:
(please note that this is just the VOTE for the release plan, not the
VOTE for the release!)
the plan is in place for commons-logging 1.0.4 release
I hope this is an approriate list for this question, if not, please
accept my apologies!
I'm running HttpClient 2.0 with j2sdk1.4.2_03.
I'm using HttpClient to access web pages via an http proxy server that
needs basic proxy authorization (note: it's the *proxy* that needs auth,
not the
Hello Alex,
HttpClient can send the authentication data automatically.
Use HttpMethod.setDoAuthentication(true) to tell it to.
You may want to set the credentials for the particular host
and port of the proxy, rather than as default credentials.
This will prevent them from being sent to the
Dear all,
Need help on using Httpclient 2.0. Currently, I have encountering a
random problem with sending xml over to a remote site. Here's the debug
log :
===
2004/05/26 20:09:50:290 SGT [DEBUG] EntityEnclosingMethod - -Request
body sent
Hi there
finally seem to find my problem: The IIS I want to request web pages from
uses NTLMv2 authentification. I guess, the httpclient only supports NTLMv1,
is that true? As the password hashes in v1 and v2 are different, the
handshake will fail.
Will v2 be implemented in short term?
Hi,
You could try this when setting the credentials, specify the hostname parameter :
client.getState().setCredentials( null, hostname, credentials );
client.getState().setAuthenticationPreemptive( true );
I use HttpClient with Slide project to connect to Exchange server in webdav and this
Alex Hunsley wrote:
My main question is: if I don't call setAuthenticationPreemptive(true),
and if HttpClient tries to use a proxy and receives an HTTP 403 (proxy
auth required) message back, will it transparently then give the proxy
auth that I have set, or will it just give me the 403 code
paul wrote:
2004/05/26 20:09:50:564 SGT [DEBUG] MultiThreadedHttpConnectionManager -
-Notifying no-one, there are no waiting threads
org.apache.commons.httpclient.HttpRecoverableException:
java.net.SocketException: Connection reset
at
Fuhrmann, Hauke wrote:
Hi there
finally seem to find my problem: The IIS I want to request web pages from
uses NTLMv2 authentification. I guess, the httpclient only supports NTLMv1,
is that true? As the password hashes in v1 and v2 are different, the
handshake will fail.
Will v2 be implemented in
Here's the wire log :
==
2004/05/26 20:09:50:262 SGT [DEBUG] MultiThreadedHttpConnectionManager -
-HttpConnectionManager.getConnection: config = HostConfiguration[hos
t=somewhere.com, protocol=https:443, port=443], timeout = 0
paul wrote:
2004/05/26 20:09:50:290 SGT [DEBUG] EntityEnclosingMethod - -Request
body sent
2004/05/26 20:09:50:562 SGT [DEBUG] HttpMethodBase - -Closing the
connection.
Why is the connection closed here? Who is doing this? The response has
not been read yet!
Could this be a threading issue?
Why is the connection closed here? Who is doing this? The response has
not been read yet!
This is because of the exception when writing the request.
HtttpMethodBase closes connections on exception.
Mike
-
To unsubscribe,
Paul,
The problem is obviously caused by the server's dropping connection right after
HttpClient is done sending the request. If you have access to the target server, check
the server logs to find out what prompted the server to do so.
I can think of two possibilities:
(1) The server did not
Hi Paul,
Two quick questions.
- Have you set
MultiThreadedHttpConnectionManager.setConnectionStaleCheckingEnabled()
to false? If so this could be causing the problem.
- It seems that the server is closing the request in mid stream. Have
you checked the IIS logs? There might be
Hello,
We are using HttpClient 2.0 within a local network to send XML files
between 2 servers. We send 4 XML documents in 4 separate requests, one
after the other. The problem we are seeing is that the 3rd request does
not get sent due to a ConnectionTimeoutException. We have set the
Ortwin Glück wrote:
Alex Hunsley wrote:
My main question is: if I don't call
setAuthenticationPreemptive(true), and if HttpClient tries to use a
proxy and receives an HTTP 403 (proxy auth required) message back,
will it transparently then give the proxy auth that I have set, or
will it just
Btw, is this mailing list protected against spam harvesters? I know the
archives are published online, are the email addresses in the messages
online protected in any way, or are they ripe for the harvesters?
alex
-
To
Alex Hunsley wrote:
Btw, is this mailing list protected against spam harvesters?
No, as far as I can see not. I complained about this issue when
Eyebrowse went online but my complaints were graciously ignored. Anybody
on the PMC who is responsible for that?
I know the
archives are published
Yes, I have set checking enabled to true.
As for the IIS , I will need to check the logs.
Is it possible to catch the HttpRecoverableException , and retry the Post
method again?
-Original Message-
From: Michael Becke [EMAIL PROTECTED]
To: Commons HttpClient Project commons-httpclient-
Thanks a lot, I will go and check with the server admin guys.
Its not a authentication issue as this problem happens randomly.
-Original Message-
From: Kalnichevski, Oleg [EMAIL PROTECTED]
To: Commons HttpClient Project commons-httpclient-
[EMAIL PROTECTED]
Date: Thu, 27 May 2004
Nicholas,
HttpClient 2.0 relies on a fairly ugly trick to be able to simulate connect timeout on
older JDKs (1.2.x, 1.3.x). HttpClient simply spawns a dedicated thread that attempts
to instantiate a socket. If the process of socket instantiation takes longer than the
specified limit,
Mike, Any idea why closed connection is considered stale?
snip protected boolean isStale() { boolean isStale = true; if
(isOpen) { // the connection is open, but now we have to see if we
can read it // assume the connection is not stale. isStale = false;
/snip
It's just poor logging.
public
I was wondering why this method was depricated, currently I use:
MultiThreadedHttpConnectionManager.getParams().setIntParameter(http.connect
ion-manager.max-per-host,20);
Which fairly un-intutive, as compared to the earlier method
setMaxConnectionsPerHost(20), which is depricated now.
Any
Mike,
I think this clearly needs to be fixed. At the very least the logging
need to be more selective. I would also advocate changing the isStale()
behavior in the CVS HEAD. I see no benefit in calling close on a closed
connection. What do you think?
Oleg
On Thu, 2004-05-27 at 19:16, Michael
Satya,
We still need to document the new preference architecture and explain
its benefits.
Firstly and most importantly the new preference architecture is
hierarchical in structure which enables the users to apply a particular
option at any specific level:
Global -
HttpClient (agent) -
After Calling
MultiThreadedHttpConnectionManager.closeIdleConnections(idleTime), the
timedout connections are closed, however, connectinon count does not
decrease.
Therefore, if I call
MultiThreadedHttpConnectionManager.getConnectionsInUse(), I still get the
same value as before calling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29265.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Christopher,
HttpClient.setTimeout() is what you are looking for.
Mike
On May 27, 2004, at 1:26 PM, Foran, Christopher wrote:
Is there a way of setting SO_TIMEOUT on the socket read? This his how
the previous connection class I was using simulated a roundtrip
timeout. Thanks.
[EMAIL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29062.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
64 matches
Mail list logo
