[logging] Static references to Log objects
From the thread Re: Idea: combine JCL 2.0 and UGLI in
Logging Services' CL2...
--- Simon Kitching [EMAIL PROTECTED] wrote:
snip
Remy Maucherat wrote:
(suggesting it is a good idea, on any logging
framework, to call
getLogger inside your app's critical path is quite
funny).
Really? When getLogger can return different Log
objects depending upon
the current context classloader? No class that could
be deployed via a
shared classloader should cache a Log object in a
static field...
Very true. And since the intended users of JCL are
reusable components that could be deployed in a shared
classloader, your statement implies that in the uses
for which JCL is intended, no static references to Log
objects should be kept.
I think this point certainly deserves mention in the
JCL user guide (I'll submit a patch).
This line of thought led me to reconsider an idea I'd
rejected a couple weeks back related to the JCL memory
leak problem. Basically the leak occurs if
LogFactoryImpl is defined by a parent classloader
while the class of one of its Log instances is defined
by a child loader. The chain of references from the
Log instance to its classloader will prevent gc of the
child loader on undeploy.
This chain could (potentially) be broken if
LogFactoryImpl only held WeakReferences to its Log
instances as follows:
public Log getInstance(String name) throws
LogConfigurationException {
-
-Log instance = (Log) instances.get(name);
-if (instance == null) {
- instance = newInstance(name);
- instances.put(name, instance);
+
+Log instance = null;
+WeakReference ref = (WeakReference)
instances.get(name);
+if (ref != null) {
+ instance = (Log) instances.get(name);
+ if (instance == null) {
+instance = newInstance(name);
+instances.put(name, new
WeakReference(instance));
+ }
}
return (instance);
I'd rejected this approach because:
1) It adds overhead to getInstance().
2) It adds a dependency on JDK 1.2 (although JCL has
others).
3) If calling code does not cache the Log object, it
may be recreated multiple times as the WeakReference
is cleared. Don't know if this is a serious issue in
the real world.
4) Most importantly, this approach is based on the
idea that all objects holding a hard reference to a
Log will be gc'ed on undeploy, allowing the
WeakReference to clear. This will fail if even 1
static reference to a Log whose class was defined by
the child loader is held somewhere.
So, negative performance implications + prone to not
working = bad idea. But, Simon's comment on caching
Log objects in static fields led me to reconsider
enough to throw the concept out to the community for
comment.
Or maybe it's just that the memory leak issue is what
led me to wander into JCL-land in the first place and
now it's become my great white whale...
Brian
__
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34291] - allow to change default string charset encoding to other than ISO-8859
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=34291.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34291
--- Additional Comments From [EMAIL PROTECTED] 2005-04-05 10:38 ---
see related bug in firefox https://bugzilla.mozilla.org/show_bug.cgi?id=289060
and RFE Bug 34297 (to gracefully handle the transition in struts-based
web-applications until all browsers do use the charset)
I order to be able to work with the existing struts.jar, on solution might be
1) create a UtilForm class that extends the ActionForm
2) the forms used in the application are an extension of this UtilForm
3) change method signature of validate to include the class itself
4) in UtilForm iterate through the fields of the calling class and do the
character encoding conversion of all string fields along the lines of
Field[] fields = callingForm.getClass().getDeclaredFields();
for (int i = 0; i fields.length; i++) {
Field field = fields[i];
field.setAccessible(true);
Object obj = new Object();
try {
obj = field.getType();
if (field.toString().indexOf(String) != -1) {
String methodName = get
+ field.getName().substring(0, 1)
.toUpperCase()
+ field.getName().substring(1);
Method getter = callingForm.getClass()
.getMethod(methodName, new Class[] {});
...
//now use that method to get the content of the field and in a similar way,
// write back the altered form with the correspondingly retrieved setter method
// only then, call super.validate(mapping, request);
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34291] - allow to change default string charset encoding to other than ISO-8859
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=34291. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34291 [EMAIL PROTECTED] changed: What|Removed |Added CC|dev@struts.apache.org | AssignedTo|commons-|dev@struts.apache.org |[EMAIL PROTECTED] | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34296] - [pool] Potential pool leak if _factory.makeObject() throws a Throwable
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=34296. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34296 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Potential pool leak if |[pool] Potential pool leak |_factory.makeObject() throws|if _factory.makeObject() |a Throwable |throws a Throwable -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32860] - [configuration] Save the changes made to a CompositeConfiguration
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=32860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32860 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows 2000|All Summary|[configuration] Saving back |[configuration] Save the |the changed configuration |changes made to a ||CompositeConfiguration -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-vfs (in module jakarta-commons-sandbox) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-vfs has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-vfs : Jakarta commons sandbox - excalibur-fortress-container-impl : Repository of reusable components. - excalibur-monitor : Repository of reusable components. - excalibur-sourceresolve : Repository of reusable components. - logging-log4j-chainsaw : Chainsaw log viewer Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-vfs/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-vfs-05042005.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-vfs/gump_work/build_jakarta-commons-sandbox_commons-vfs.html Work Name: build_jakarta-commons-sandbox_commons-vfs (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-vfs-05042005 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/vfs] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/vfs/target/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-05042005.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/compress/target/commons-compress-05042005.jar:/usr/local/gump/public/workspace/commons-httpclient-20-branch/dist/commons-httpclient-2.0-05042005.jar:/usr/local/gump/public/workspace/jakarta-commons/net/dist/commons-net-05042005.jar:/usr/local/gump/public/workspace/jakarta-slide/webdavclient/dist/lib/jakarta-slide-webdavlib-05042005.jar:/usr/local/gump/packages/jcifs/jcifs-0.8.1.jar:/usr/local/gump/packages/jsch-0.1.18/dist/lib/jsch-gump.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/target/lib get-deps: compile: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/target/classes [javac] Compiling 177 source files to /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/target/classes [javac] /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java:26: cannot resolve symbol [javac] symbol : class ZipFileName [javac] location: package zip [javac] import org.apache.commons.vfs.provider.zip.ZipFileName; [javac]^ [javac] /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java:24: cannot resolve symbol [javac] symbol : class ZipFileName [javac] location: package zip [javac] import org.apache.commons.vfs.provider.zip.ZipFileName; [javac]^ [javac] /home/gump/workspaces2/public/workspace/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/ftp/FTPClientWrapper.java:100: warning: listFiles(java.lang.String,java.lang.String) in org.apache.commons.net.ftp.FTPClient has been deprecated [javac] return getFtpClient().listFiles(key, relPath); [javac]^ [javac]
svn commit: r160160 - in jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/XMLConfiguration.java xdocs/changes.xml
Author: ebourg
Date: Tue Apr 5 04:32:14 2005
New Revision: 160160
URL: http://svn.apache.org/viewcvs?view=revrev=160160
Log:
Fixed XMLConfiguration to use the delimiter set by setDelimiter() instead of
the private ATTR_DELIMITER variable (thanks to Zsolt Koppany for spotting this
issue)
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java?view=diffr1=160159r2=160160
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
Tue Apr 5 04:32:14 2005
@@ -70,9 +70,6 @@
/** Constant for the default root element name. */
private static final String DEFAULT_ROOT_NAME = configuration;
-/** Delimiter character for attributes. */
-private static char ATTR_DELIMITER = ',';
-
private FileConfigurationDelegate delegate = new
FileConfigurationDelegate();
/** The document from this configuration's data source. */
@@ -288,7 +285,7 @@
if (w3cNode instanceof Attr)
{
Attr attr = (Attr) w3cNode;
-for (Iterator it = PropertyConverter.split(attr.getValue(),
ATTR_DELIMITER).iterator(); it.hasNext();)
+for (Iterator it = PropertyConverter.split(attr.getValue(),
getDelimiter()).iterator(); it.hasNext();)
{
Node child = new
XMLNode(ConfigurationKey.constructAttributeKey(attr.getName()), element);
child.setValue(it.next());
@@ -365,7 +362,19 @@
public void load(InputStream in) throws ConfigurationException
{
-delegate.load(in);
+try
+{
+DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
+Document newDocument = builder.parse(new InputSource(in));
+Document oldDocument = document;
+document = null;
+initProperties(newDocument, oldDocument == null);
+document = (oldDocument == null) ? newDocument : oldDocument;
+}
+catch (Exception e)
+{
+throw new ConfigurationException(e.getMessage(), e);
+}
}
public void load(InputStream in, String encoding) throws
ConfigurationException
@@ -782,7 +791,7 @@
{
if (buf.length() 0)
{
-buf.append(ATTR_DELIMITER);
+buf.append(getDelimiter());
}
buf.append(attr.getValue());
}
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffr1=160159r2=160160
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Tue Apr 5
04:32:14 2005
@@ -22,7 +22,10 @@
body
-release version=1.2-dev date=in CVS
+release version=1.2-dev date=in SVN
+ action dev=ebourg type=update due-to=Zsolt Koppany
+XMLConfiguration now uses the delimiter set by setDelimiter(char).
+ /action
/release
release version=1.1 date=2005-04-02
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r160161 - in jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/XMLConfiguration.java xdocs/changes.xml
Author: ebourg
Date: Tue Apr 5 04:49:27 2005
New Revision: 160161
URL: http://svn.apache.org/viewcvs?view=revrev=160161
Log:
XMLConfiguration now parse the configuration using the encoding declared in the
XML header instead of the OS default encoding.
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java?view=diffr1=160160r2=160161
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/XMLConfiguration.java
Tue Apr 5 04:49:27 2005
@@ -840,6 +840,11 @@
private class FileConfigurationDelegate extends AbstractFileConfiguration
{
+public void load(InputStream in) throws ConfigurationException
+{
+XMLConfiguration.this.load(in);
+}
+
public void load(Reader in) throws ConfigurationException
{
XMLConfiguration.this.load(in);
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffr1=160160r2=160161
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Tue Apr 5
04:49:27 2005
@@ -23,6 +23,10 @@
body
release version=1.2-dev date=in SVN
+ action dev=ebourg type=update due-to=Kunihara Tetsuya
issue=34204
+XMLConfiguration now parse the configuration using the encoding
+declared in the XML header instead of the OS default encoding.
+ /action
action dev=ebourg type=update due-to=Zsolt Koppany
XMLConfiguration now uses the delimiter set by setDelimiter(char).
/action
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34204] - [configuration] XMLConfiguration ignore a specific encoding in XML declaration
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=34204. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34204 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-04-05 13:52 --- You are right, I submitted a fix in the current SVN tree, let me know how it works for you. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r160163 - in jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider: compressed/CompressedFileFileProvider.java jar/JarFileProvider.java
Author: imario Date: Tue Apr 5 05:11:27 2005 New Revision: 160163 URL: http://svn.apache.org/viewcvs?view=revrev=160163 Log: removed unused/unresolvable imports Modified: jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java Modified: jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java?view=diffr1=160162r2=160163 == --- jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java (original) +++ jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/compressed/CompressedFileFileProvider.java Tue Apr 5 05:11:27 2005 @@ -23,7 +23,6 @@ import org.apache.commons.vfs.provider.AbstractLayeredFileProvider; import org.apache.commons.vfs.provider.FileProvider; import org.apache.commons.vfs.provider.LayeredFileName; -import org.apache.commons.vfs.provider.zip.ZipFileName; import java.util.Collection; Modified: jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java?view=diffr1=160162r2=160163 == --- jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java (original) +++ jakarta/commons/sandbox/vfs/trunk/src/java/org/apache/commons/vfs/provider/jar/JarFileProvider.java Tue Apr 5 05:11:27 2005 @@ -1,12 +1,12 @@ /* * Copyright 2002, 2003,2004 The Apache Software Foundation. - * + * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at - * + * * http://www.apache.org/licenses/LICENSE-2.0 - * + * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. @@ -21,9 +21,7 @@ import org.apache.commons.vfs.FileSystem; import org.apache.commons.vfs.FileSystemException; import org.apache.commons.vfs.FileSystemOptions; -import org.apache.commons.vfs.provider.zip.ZipFileName; import org.apache.commons.vfs.provider.zip.ZipFileProvider; -import org.apache.commons.vfs.provider.UriParser; import org.apache.commons.vfs.provider.LayeredFileName; import java.util.ArrayList; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] Jars in the repository
Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
James, we keep those dependencies in the repository to make them easily available. So users that want to check out and compile HttpClient don't have to worry about getting them from somewhere. Yes, there is Maven. That's fine as long as it works, but we do not like to be dependent on the availability of the Maven remote repository. I figure the JAR names should reflect the actual version of the component, however. James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? TIA Ortwin Glck, HttpClient project James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. -- _ NOSE applied intelligence ag ortwin glck [www] http://www.nose.ch software engineer hardturmstrasse 171 [pgp id] 0x81CF3416 8005 zrich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34306] New: - [chain] Decouple CatalogFactory lookup from LookupAction
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=34306. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34306 Summary: [chain] Decouple CatalogFactory lookup from LookupAction Product: Commons Version: 1.0 Final Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: chain AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] LookupAction currently uses the static CatalogFactory.getInstance() method to get a CatalogFactory; this interferes with catalog/command instantiation processes which don't register catalogs with the static instance. Rather than require all instantiation processes to use the static registration, LookupAction should be changed to have a CatalogFactory property which can be set by a Dependency Injection IoC framework like Spring. For backwards compatibility, the property can default to being set to the static singleton instance. I have this code mostly written, simply awaiting a bit of testing -- but we might as well get it in before the Chain 1.1 release, so I wanted to register it in Bugzilla. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34306] - [chain] Decouple CatalogFactory lookup from LookupAction
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=34306. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34306 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][patch] skip() support for CountingInputStream
Rob Oxspring wrote: I recently replaced the use of my own CountingInputStream with the commons-io and got burnt because io's CountingInputStream doesn't count skipped bytes. I have a patch with fix and patch if people are interested... or I could just commit it... Thoughts? I am not familiar with this class, but as a general rule, I would suggest that you either submit the class as an enhancement in Bugzilla, or add yourself to the committers list and commit it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][patch] skip() support for CountingInputStream
Whoops :) Definitely a bug, I'd not even bother to add yourself to the committer list if you didn't want to just commit away. Nice to add to bugzilla though and go through the motions so it can more easily appear in a release-notes. Especially if we're using the changes.xml bit. Hen On Apr 5, 2005 9:57 AM, matthew.hawthorne [EMAIL PROTECTED] wrote: Rob Oxspring wrote: I recently replaced the use of my own CountingInputStream with the commons-io and got burnt because io's CountingInputStream doesn't count skipped bytes. I have a patch with fix and patch if people are interested... or I could just commit it... Thoughts? I am not familiar with this class, but as a general rule, I would suggest that you either submit the class as an enhancement in Bugzilla, or add yourself to the committers list and commit it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
ok, these new patches make the failures go away in a bit cleaner manner,
by manipulating the default locale setting.
Also, I noticed that your java sources are in some strange encoding. If
I open those tests that use french letters in my Eclipse and save them
then they become corrupt and will fail.
My configuration assumes that all source files are in UTF8 and I think
that should be the most reasonable assumption, no?
Rgds,
Neeme
Steve Cohen wrote:
Okay, now that I understand the problem in general terms, can you
please provide stack traces or other information indicating where in
the code failures are happening? Your patches provide me with a
possible fix, but I need to understand fully the problem. Also if you
could tell me the locale and other jvm properties that would help.
I think there may be other, more standard fixes that I can apply, but
I need to understand the problem fully. It would probably be better,
if possible, if could provide a setUp() routine that puts the JVM into
the same locale-state anywhere that yours is in by default.
I will be non-responsive for several days, but will look at this when
I return later in the week.
Steve
Neeme Praks wrote:
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+ // assume we are FTPing a server in Chicago, two hours ahead of +
// L. A.
+ FTPClientConfig config = + new
FTPClientConfig(FTPClientConfig.SYST_UNIX);
+ config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+ config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+ // 2 hours difference
+ config.setServerTimeZoneId(America/Chicago);
+ parser.configure(config);
+ + SimpleDateFormat sdf = - new
SimpleDateFormat(parser.getRecentDateFormatString());
+ new SimpleDateFormat(parser.getRecentDateFormatString(),
parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of -
// L. A.
- FTPClientConfig config = - new
FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
- config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed = parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS, cal.getTime().getTime() -
parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that
should @@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+ Calendar cal = Calendar.getInstance();
+ cal.set(Calendar.YEAR, 2002);
+ cal.set(Calendar.MONTH, 1);
+ cal.set(Calendar.DAY_OF_MONTH, 22);
+ SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fv 22 2002);
+ parser.parseTimestamp(fv 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+ DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+ sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(dc 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+ sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 dc 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.french);
}
@@ -159,27 +168,28 @@
// this is the success case
}
try {
- parser.parseTimestamp(29 fv 2002);
+ parser.parseTimestamp(29 fv 2002);
fail(nonexistent.date);
} catch (ParseException e) {
// this
Re: [httpclient] Jars in the repository
James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. we keep those dependencies in the repository to make them easily available. So users that want to check out and compile HttpClient don't have to worry about getting them from somewhere. I don't really understand what you are saying here. How can someone be smart enough to either download a source distribution or checkout the project via svn, but too dumb or lazy to just download the dependent jars seperately. Sorry, that just doesn't make a lot of sense to me. Yes, there is Maven. That's fine as long as it works, but we do not like to be dependent on the availability of the Maven remote repository. You don't need Maven to use jars on ibiblio (or any one of the other repositories). In fact, I just modified the Ant build script that builds the Struts 1.2.x nightlies. The existing build.xml requires you to download and setup a build.properties that points to all the dependencies. For me, it is a waste of my time. Ant should be smart enough to do it for me. So that's what I did: http://svn.apache.org/viewcvs.cgi/struts/core/branches/STRUTS_1_2_BRANCH/build.xml?rev=160185view=markup Scroll down to the download-dependencies target. I figure the JAR names should reflect the actual version of the component, however. I agree. TIA Ortwin Glck, HttpClient project If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. If not, then sorry to bother you. Have a good one. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Static references to Log objects
--- Brian Stansberry [EMAIL PROTECTED]
wrote:
snip
This line of thought led me to reconsider an idea
I'd
rejected a couple weeks back related to the JCL
memory
leak problem. Basically the leak occurs if
LogFactoryImpl is defined by a parent classloader
while the class of one of its Log instances is
defined
by a child loader. The chain of references from the
Log instance to its classloader will prevent gc of
the
child loader on undeploy.
This chain could (potentially) be broken if
LogFactoryImpl only held WeakReferences to its Log
instances as follows:
public Log getInstance(String name) throws
LogConfigurationException {
-
-Log instance = (Log) instances.get(name);
-if (instance == null) {
- instance = newInstance(name);
- instances.put(name, instance);
+
+Log instance = null;
+WeakReference ref = (WeakReference)
instances.get(name);
+if (ref != null) {
+ instance = (Log) instances.get(name);
+ if (instance == null) {
+instance = newInstance(name);
+instances.put(name, new
WeakReference(instance));
+ }
}
return (instance);
Oops. Try:
public Log getInstance(String name) throws
LogConfigurationException {
-
-Log instance = (Log) instances.get(name);
-if (instance == null) {
- instance = newInstance(name);
- instances.put(name, instance);
+
+Log instance = null;
+WeakReference ref = (WeakReference)
instances.get(name);
+if (ref != null) {
+ instance = (Log) instances.get(name);
+}
+if (instance == null) {
+ instance = newInstance(name);
+ instances.put(name, new
WeakReference(instance));
+}
return (instance);
Brian
__
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
James Mitchell wrote: There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. Asking questions is not a crime, fortunately. Not even in any US state so far :-) If you come over one, just let me know. I don't really understand what you are saying here. How can someone be smart enough to either download a source distribution or checkout the project via svn, but too dumb or lazy to just download the dependent jars seperately. Sorry, that just doesn't make a lot of sense to me. It's not about smartness. But what are you gonna do if the dependend file on ibilio is removed or ibiblio is having a downtime? Your stuffed unless you have a local copy. You don't need Maven to use jars on ibiblio (or any one of the other repositories). In fact, I just modified the Ant build script that builds the Struts 1.2.x nightlies. The existing build.xml requires you to download and setup a build.properties that points to all the dependencies. For me, it is a waste of my time. Ant should be smart enough to do it for me. I don't see the point. Maven can do that already perfectly. Copying the knowledge about deps to the build.xml I consider a pitfal. We have all learned in kindergarten to have knowledge in *one* place, haven't we :-0 I figure the JAR names should reflect the actual version of the component, however. I agree. Kind regards Ortwin Glck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Tue, Apr 05, 2005 at 11:46:49AM -0400, James Mitchell wrote: James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. James, Please correct me if I am wrong there's nothing wrong about keeping a copy of ASLv2 licenced library in the source code repository. It's just sloppy. snip If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg If not, then sorry to bother you. Have a good one. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34310] New: - org.apache.commons.beanutils.ConvertUtils no Locale support.
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=34310. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34310 Summary: org.apache.commons.beanutils.ConvertUtils no Locale support. Product: Commons Version: unspecified Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Bean Utilities AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The bug is in the class org.apache.commons.beanutils.ConvertUtils. I was using struts for an application in germany, and we had a problem so i looked at the struts sources. So i found that the convert method parses a String to a double without taking in count the current Locale. So a double in german has the format 0,00 and thats why comes a mistake. Its on version 1.6.1 from common- beanutils. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Oleg Kalnichevski wrote: If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg Is that *necessary* for GUMP or anything else, Oleg? If not then I prefer not to have that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg On Tue, Apr 05, 2005 at 06:25:42PM +0200, Ortwin Gl?ck wrote: Oleg Kalnichevski wrote: If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg Is that *necessary* for GUMP or anything else, Oleg? If not then I prefer not to have that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34311] New: - CountingInputStream doesn't implement skip()
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=34311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34311 Summary: CountingInputStream doesn't implement skip() Product: Commons Version: 1.0 Final Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: IO AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The CountingInputStream doesn't count skipped bytes in it's count. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34311] - CountingInputStream doesn't implement skip()
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=34311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34311 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|commons-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-04-05 18:45 --- Created an attachment (id=14623) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14623action=view) Implements and tests the CountingInputStream.skip() method -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34310] - [beanutils] ConvertUtils has no Locale support.
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=34310. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34310 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows 2000|All Platform|PC |All Summary|org.apache.commons.beanutils|[beanutils] ConvertUtils has |.ConvertUtils no Locale |no Locale support. |support.| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][patch] skip() support for CountingInputStream
Ok, Am logging it in bugzilla but will commit shortly. Rob Henri Yandell wrote: Whoops :) Definitely a bug, I'd not even bother to add yourself to the committer list if you didn't want to just commit away. Nice to add to bugzilla though and go through the motions so it can more easily appear in a release-notes. Especially if we're using the changes.xml bit. Hen On Apr 5, 2005 9:57 AM, matthew.hawthorne [EMAIL PROTECTED] wrote: Rob Oxspring wrote: I recently replaced the use of my own CountingInputStream with the commons-io and got burnt because io's CountingInputStream doesn't count skipped bytes. I have a patch with fix and patch if people are interested... or I could just commit it... Thoughts? I am not familiar with this class, but as a general rule, I would suggest that you either submit the class as an enhancement in Bugzilla, or add yourself to the committers list and commit it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34311] - [io] CountingInputStream doesn't implement skip()
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=34311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34311 [EMAIL PROTECTED] changed: What|Removed |Added CC||commons- ||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
I now implemented support for FTPClientConfig in my local Ant ftp task, but somehow it still fails to parse this directory listing, although it parses the timestamp correctly (I tested that with jUnit). Is it because the parser assumes that the 3rd and 4th parameters (owner and group) are supposed to be numbers as opposed to names? -rw-r--r-- 1 neeme neeme 385 2005-03-21 14:26 about.vsp I used the following configuration for parsing: configuration defaultDateFormatStr=-MM-dd HH:mm serverTimeZoneId=Europe/Oslo shortMonthNames=01|02|03|04|05|06|07|08|09|10|11|12/ (and the system type defaults to Unix) Neeme Steve Cohen wrote: Wow! Thanks for showing us this. That's a format I've not seen before. Where did it come from? Is it by any chance a public site? In past experience, all unix ftp servers, which I presume this to be, have used abbreviations for the months. There IS a new system in the latest version of commons-net that would allow you to specify an alternate date format. I consider this a nice validation of the new design - it offers a way to work with a format we didn't even know existed. It's not hooked up to ant yet but that was always my intent. What say, other commons-net committers? Are we ready to build 1.4? Then I could add hooks for this new system in Ant. Steve Cohen smime.p7s Description: S/MIME Cryptographic Signature
svn commit: r160202 - in jakarta/commons/proper/io/trunk: project.xml src/java/org/apache/commons/io/input/CountingInputStream.java src/test/org/apache/commons/io/input/CountingInputStreamTest.java
Author: roxspring
Date: Tue Apr 5 10:22:21 2005
New Revision: 160202
URL: http://svn.apache.org/viewcvs?view=revrev=160202
Log:
CountingInputStream now implements skip(long) method.
PR: 34311
Modified:
jakarta/commons/proper/io/trunk/project.xml
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/CountingInputStreamTest.java
Modified: jakarta/commons/proper/io/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/project.xml?view=diffr1=160201r2=160202
==
--- jakarta/commons/proper/io/trunk/project.xml (original)
+++ jakarta/commons/proper/io/trunk/project.xml Tue Apr 5 10:22:21 2005
@@ -16,7 +16,7 @@
--
project
pomVersion3/pomVersion
-
+
nameIO/name
idcommons-io/id
currentVersion1.1-dev/currentVersion
@@ -26,7 +26,7 @@
Commons-IO contains utility classes, stream implementations, file
filters, and endian classes.
/description
logo/images/io-logo-white.png/logo
-
+
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
packageorg.apache.commons.${pom.artifactId.substring(8)}/package
@@ -43,18 +43,18 @@
distributionrepo/distribution
/license
/licenses
-
+
gumpRepositoryIdjakarta/gumpRepositoryId
issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
-
+
repository
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
/repository
-
+
mailingLists
mailingList
nameCommons Dev List/name
@@ -69,7 +69,7 @@
archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]/archive
/mailingList
/mailingLists
-
+
versions
version
id1.0/id
@@ -146,6 +146,15 @@
nameMartin Cooper/name
idmartinc/id
email[EMAIL PROTECTED]/email
+ organization/
+ roles
+roleJava Developer/role
+ /roles
+/developer
+developer
+ nameRob Oxspring/name
+ idroxspring/id
+ email[EMAIL PROTECTED]/email
organization/
roles
roleJava Developer/role
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java?view=diffr1=160201r2=160202
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java
Tue Apr 5 10:22:21 2005
@@ -71,6 +71,17 @@
this.count += (found = 0) ? 1 : 0;
return found;
}
+
+/**
+ * Increases the count by the number of skipped bytes.
+ *
+ * @see java.io.InputStream#skip(long)
+ */
+public long skip(final long length) throws IOException {
+final long skip = super.skip(length);
+this.count += skip;
+return skip;
+}
/**
* The number of bytes that have passed through this stream.
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/CountingInputStreamTest.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/CountingInputStreamTest.java?view=diffr1=160201r2=160202
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/CountingInputStreamTest.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/input/CountingInputStreamTest.java
Tue Apr 5 10:22:21 2005
@@ -17,6 +17,8 @@
package org.apache.commons.io.input;
import java.io.ByteArrayInputStream;
+import java.io.IOException;
+import java.util.Arrays;
import junit.framework.TestCase;
@@ -148,6 +150,21 @@
int found = cis.read(result, 0, 5);
assertEquals(2, found);
assertEquals(2, cis.getCount());
+}
+
+public void testSkipping() throws IOException {
+String text = Hello World!;
+byte[] bytes = text.getBytes();
+ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
+CountingInputStream cis = new CountingInputStream(bais);
+
+assertEquals(6,cis.skip(6));
+
DO NOT REPLY [Bug 34311] - [io] CountingInputStream doesn't implement skip()
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=34311. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34311 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-04-05 19:23 --- Committed revision 160202. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Tue, 2005-04-05 at 18:57 +0200, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. Explicit dependency management for one (for those who prefer Ant to Maven, like myself). 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. I see it differently, but as far as I am concerned this whole thing is a non-issue. Should James decide to submit a patch, I _personally_ will be quite happy to vote +1 for it. At the same time, I'll have no problems of what so ever to move on, should you veto it with -1. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. [quietly and humbly] I do. For such a simple-minded person like me, every Maven deployment should come with Dion included. [ducking and hiding] Anyways, I would rather see all this time and efforts spent on Jakarta Http(Client) API redesign Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. The Maven Ant Plugin makes it easy to create an Ant build script from a project.xml file. I made a patch for it to solve a problem [1] that Craig had, that is somewhat related to this issue. A released version of the plugin is not yet available, but a SNAPSHOT version (1.9-SNAPSHOT) is available. The patch makes it possible to have local copies of select jar-files. All you need to do is create a build.properties file of your own and point it to the your local copies of jar-files. If you don't supply a build.properties file the jar-files will be downloaded from ibiblio or whatever repository you have configured Maven to use. I am not sure that this will work for httpclient, but it is a way to benefit from both Ant and Maven without the need to define dependencies twice. Installation instructions for the SNAPSHOT version of the Ant plugin are available [2] in the JIRA issue. [1] http://jira.codehaus.org/browse/MPANT-20 [2] http://jira.codehaus.org/browse/MPANT-20#action_28915 -- Dennis Lundberg 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. Let's suppose for a minute that all Commons components stored their dependencies in SVN. And let's also suppose that they all required Commons Logging. We would have almost 90 copies of Commons Logging taking up space in the SVN repository. Even if only half of them use Commons Logging, that's still 45 copies. What's more, someone who checks out all of Commons is going to get all those copies of all those components taking up all their disk space, when all they really need is one copy of each. I don't know about you, but that seems like a really bad idea to me, and it's not going to make people happy when they discover they lost half their disk to dozens of copies of the same thing. -- Martin Cooper 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Martin Cooper wrote: On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. First, its important to point out that the ASF and Maven jar repositories (http://www.ibiblio.org/maven and http://apache_mirror/dist/java-repository) represent a stable tool for the development community to resolve dependencies against, ibiblio and ASF mirror servers are certainly stable enough to maintain this. If your a project developer you have to be more intelligent than your users, its important that you know how to manage your dependencies appropriately. The SRC/BIN distributions of your project are the appropriate places to include these dependencies, not the CMS. Those who make points on the list about replication of dependencies in the repo are correct in their argument, this is why we don't recommend it. I think you'll find the ant scripts generated by maven are reliable and not stupid at all in resolving this issue. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. Its there to provide the same functionality for developers who prefer to work directly with Ant and not Maven. Yes, its a duplication of the maven project xml. But you can regenerate it at any time using the 'maven ant' goal. Thus, you do not have to maintain both an ant build.xml and a project.xml. The ant build.xml is a derivative product of Maven that you store in your svn project (instead of megabytes of dependency jars). I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. As I said above, this is already is available in Maven, you don't need to write anything. Just call maven ant anytime you've altered the project.xml and commit the two together. Any error in our group have been minimal. Ant may be legacy, but Ant and Maven have a good relationship and incredibly, much of what Maven does is actually based on Ant Tasks. Ant is by no means past is prime. The entire rest of jakarta commons (among many other apache projects) have relied on this dualistic model without complaint. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) I think it totally defeats the general policy of external dependency resolution to allow jars into svn just because you want them to show up in your lib dir. -My $0.02 Mark Diggory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Martin Cooper wrote: On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. First, its important to point out that the ASF and Maven jar repositories (http://www.ibiblio.org/maven and http://apache_mirror/dist/java-repository) represent a stable tool for the development community to resolve dependencies against, ibiblio and ASF mirror servers are certainly stable enough to maintain this. If your a project developer you have to be more intelligent than your users, its important that you know how to manage your dependencies appropriately. The SRC/BIN distributions of your project are the appropriate places to include these dependencies, not the CMS. Those who make points on the list about replication of dependencies in the repo are correct in their argument, this is why we don't recommend it. I think you'll find the ant scripts generated by maven are reliable and not stupid at all in resolving this issue. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. Its there to provide the same functionality for developers who prefer to work directly with Ant and not Maven. Yes, its a duplication of the maven project xml. But you can regenerate it at any time using the 'maven ant' goal. Thus, you do not have to maintain both an ant build.xml and a project.xml. The ant build.xml is a derivative product of Maven that you store in your svn project (instead of megabytes of dependency jars). I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. As I said above, this is already is available in Maven, you don't need to write anything. Just call maven ant anytime you've altered the project.xml and commit the two together. Any error in our group have been minimal. Ant may be legacy, but Ant and Maven have a good relationship and incredibly, much of what Maven does is actually based on Ant Tasks. Ant is by no means past is prime. The entire rest of jakarta commons (among many other apache projects) have relied on this dualistic model without complaint. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) I think it totally defeats the general policy of external dependency resolution to allow jars into svn just because you want them to show up in your lib dir. -My $0.02 Mark Diggory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
