svn commit: r370753 - /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java

[skitching]

Author: skitching
Date: Thu Jan 19 23:46:30 2006
New Revision: 370753

URL: http://svn.apache.org/viewcvs?rev=370753&view=rev
Log:
Fix comment only - HashMap *is* in java1.2

Modified:

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java

Modified: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java?rev=370753&r1=370752&r2=370753&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/PathableClassLoader.java
 Thu Jan 19 23:46:30 2006
@@ -22,7 +22,7 @@
 import java.net.URL;
 import java.net.URLClassLoader;
 
-// TODO: use HashTable instead of HashMap for java1.2 support
+// TODO: use HashTable instead of HashMap for java1.1 support
 import java.util.HashMap;
 import java.util.Iterator;
 import java.util.Map;



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370752 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

[skitching]

Author: skitching
Date: Thu Jan 19 23:45:22 2006
New Revision: 370752

URL: http://svn.apache.org/viewcvs?rev=370752&view=rev
Log:
Fix for java1.2: in that version, Boolean.valueOf(str) returns a new instance
each time, not one of Boolean.TRUE or Boolean.FALSE!

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=370752&r1=370751&r2=370752&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 Thu Jan 19 23:45:22 2006
@@ -409,7 +409,7 @@
 if (props != null) {
 String useTCCLStr = props.getProperty(TCCL_KEY);
 if (useTCCLStr != null) {
-if (Boolean.valueOf(useTCCLStr) == Boolean.FALSE) {
+if (Boolean.valueOf(useTCCLStr).booleanValue() == false) {
 // Don't use current context classloader when locating any
 // LogFactory or Log classes, just use the class that 
loaded
 // this abstract class. When this class is deployed in a 
shared



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL][logging] JCL 1.1

[Jörg Schaible]

+1, it's really overdue

robert burrell donkin wrote on Friday, January 20, 2006 12:26 AM:

> the last JCL release (1.0.4) was back in june 2004. since
> then a lot of
> work has been put in by the commons logging team analysing the
> limitations and deficiencies of that release and of the
> dynamic binding
> approach to bridging API's in general. it's taken some time
> but progress
> has been made and (as importantly) the theoretical limitations of this
> approach are now well understood.
> 
> a release is now well overdue. due to the significant
> improvements made,
> it is proposed that this release will be JCL 1.1. a release
> plan will be
> assembled on the wiki
> (http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePl
> an) and a
> release candidate cut once it has been prepared. i'm happy to
> volunteer to act as release manager.
> 
> here my +1
> 
> - robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38328] - commons-net telnet client not working well with Zirion Power Controller Model PSS-108MA

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38328





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 07:45 ---
I have used JRE 1.5.0_06 (The latest java build) in 
Linux 2.6.11-1.35_FC3smp #1 SMP Mon Jun 13 01:17:35 EDT 2005 i686 i686 i386
GNU/Linux.


-- 
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 38328] - commons-net telnet client not working well with Zirion Power Controller Model PSS-108MA

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38328





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 07:36 ---
Created an attachment (id=17467)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17467&action=view)
telnet dump trace at the time of issuing "*magic#POS" command with linux telnet
client


-- 
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 38328] - commons-net telnet client not working well with Zirion Power Controller Model PSS-108MA

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38328





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 07:35 ---
Created an attachment (id=17466)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17466&action=view)
telnet dump trace at the time of issuing "*magic#POS" command with commons-net
telnet client


-- 
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 38328] New: - commons-net telnet client not working well with Zirion Power Controller Model PSS-108MA

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38328

   Summary: commons-net telnet client not working well with Zirion
Power Controller Model PSS-108MA
   Product: Commons
   Version: 4.0
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P5
 Component: Net
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Description:

When I used commons-net telnet client to get the power status of the ports in
Zirion Power controller (Model: PSS-108MA), I am not getting the output
immediately after the command "*magic#POS" is typed. Instead I get the output
after another command is typed. Please have a look below to understand well:

Actual Result: 
java -classpath commons-net-1.3.0-dev.jar examples.TelnetClientExample
192.168.11.203 8000

TelnetClientExample
Type AYT to send an AYT telnet command
Type OPT to print a report of status of options (0-24)
Type REGISTER to register a new SimpleOptionHandler
Type UNREGISTER to unregister an OptionHandler
Type SPY to register the spy (connect to port  to spy)
Type UNSPY to stop spying the connection
 220 192.168.11.203 RCON server (ZIRION v1.1) ready.
Received DO for option code 1

*magic#POS
 *magic#exit

 221 Goodbye.


Expected Result:

When I used Linux telnet client to connect to the above controller, the Linux
telnet client is working fine.

telnet 192.168.11.203 8000
Trying 192.168.11.203...
Connected to 192.168.11.203 (192.168.11.203).
Escape character is '^]'.
 220 192.168.11.203 RCON server (ZIRION v1.1) ready.
*magic#POS
 (Comment:we r getting O/P imediately after issuing command)
*magic#exit
 221 Goodbye.
Connection closed by foreign host.

I have tcp dump traces for linux telnet client and commons-net telnet client
which say that the data is sitting on the kernel which is not read by the
commons-net telnet client. I am attaching the tcpdump traces both for Linux
telnet client (tcp_linux_telnet.txt) and commons-net telnet
client(tcp_commons_net.txt). You can view 4 telnet packet dump using the command
"tcpdump -r  -xx -s 1500" or ethereal. I have taken telnet dump at the
time of issuing the command "*magic#POS".

Build Date & Platform:

I have build "commons-net-1.3.0-dev.jar" from the cvs HEAD of jakarta-commons. I
also used latest commons-net-1.4.1.tar.gz, but even then the same problem 
persists.

-- 
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: r370739 - in /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet: ./ BasicServletTestCase.java

[skitching]

Author: skitching
Date: Thu Jan 19 21:54:27 2006
New Revision: 370739

URL: http://svn.apache.org/viewcvs?rev=370739&view=rev
Log:
Add unit tests for ServletContextCleaner class.

Added:

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
   (with props)

Added: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java?rev=370739&view=auto
==
--- 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
 (added)
+++ 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
 Thu Jan 19 21:54:27 2006
@@ -0,0 +1,71 @@
+/*
+ * Copyright 2006 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.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */ 
+
+package org.apache.commons.logging.log4j.log4j12;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+
+import org.apache.commons.logging.PathableClassLoader;
+import org.apache.commons.logging.PathableTestSuite;
+import org.apache.commons.logging.impl.ServletContextCleaner;
+
+
+/**
+ * Tests for ServletContextCleaner utility class.
+ */
+
+public class BasicServletTestCase extends TestCase {
+
+/**
+ * Return the tests included in this test suite.
+ */
+public static Test suite() throws Exception {
+// LogFactory in parent
+// LogFactory in child (loads test)
+// LogFactory in tccl
+//
+// Having the test loaded via a loader above the tccl emulates the 
situation
+// where a web.xml file specifies ServletContextCleaner as a listener, 
and
+// that class is deployed via a shared classloader.
+
+PathableClassLoader parent = new PathableClassLoader(null);
+parent.useSystemLoader("junit.");
+parent.addLogicalLib("commons-logging");
+parent.addLogicalLib("servletapi");
+
+PathableClassLoader child = new PathableClassLoader(parent);
+child.setParentFirst(false);
+child.addLogicalLib("commons-logging");
+child.addLogicalLib("testclasses");
+
+PathableClassLoader tccl = new PathableClassLoader(child);
+tccl.setParentFirst(false);
+tccl.addLogicalLib("commons-logging");
+
+Class testClass = 
child.loadClass(BasicServletTestCase.class.getName());
+return new PathableTestSuite(testClass, tccl);
+}
+
+/**
+ * Test that calling ServletContextCleaner.contextDestroyed doesn't crash.
+ * Testing anything else is rather difficult...
+ */
+public void testBasics() {
+ServletContextCleaner scc = new ServletContextCleaner();
+scc.contextDestroyed(null);
+}
+}

Propchange: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
--
svn:eol-style = native

Propchange: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/servlet/BasicServletTestCase.java
--
svn:keywords = Author Date Id Revision



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370738 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java

[skitching]

Author: skitching
Date: Thu Jan 19 21:53:42 2006
New Revision: 370738

URL: http://svn.apache.org/viewcvs?rev=370738&view=rev
Log:
Added comments only.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java?rev=370738&r1=370737&r2=370738&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/ServletContextCleaner.java
 Thu Jan 19 21:53:42 2006
@@ -68,6 +68,33 @@
 // Walk up the tree of classloaders, finding all the available
 // LogFactory classes and releasing any objects associated with
 // the tccl (ie the webapp).
+//
+// When there is only one LogFactory in the classpath, and it
+// is within the webapp being undeployed then there is no problem;
+// garbage collection works fine.
+//
+// When there are multiple LogFactory classes in the classpath but
+// parent-first classloading is used everywhere, this loop is really
+// short. The first instance of LogFactory found will
+// be the highest in the classpath, and then no more will be found.
+// This is ok, as with this setup this will be the only LogFactory
+// holding any data associated with the tccl being released.
+//
+// When there are multiple LogFactory classes in the classpath and
+// child-first classloading is used in any classloader, then multiple
+// LogFactory instances may hold info about this TCCL; whenever the
+// webapp makes a call into a class loaded via an ancestor classloader
+// and that class calls LogFactory the tccl gets registered in
+// the LogFactory instance that is visible from the ancestor
+// classloader. However the concrete logging library it points
+// to is expected to have been loaded via the TCCL, so the 
+// underlying logging lib is only initialised/configured once.
+// These references from ancestor LogFactory classes down to
+// TCCL classloaders are held via weak references and so should
+// be released but there are circumstances where they may not.
+// Walking up the classloader ancestry ladder releasing
+// the current tccl at each level tree, though, will definitely
+// clear any problem references.
 ClassLoader loader = tccl;
 while (loader != null) {
 // Load via the current loader. Note that if the class is not 
accessable



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370737 - /jakarta/commons/proper/logging/trunk/build.xml

[skitching]

Author: skitching
Date: Thu Jan 19 21:53:20 2006
New Revision: 370737

URL: http://svn.apache.org/viewcvs?rev=370737&view=rev
Log:
Expose servletapi.jar as a "logical lib" for unit tests

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=370737&r1=370736&r2=370737&view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Thu Jan 19 21:53:20 2006
@@ -194,6 +194,7 @@
   
   
   
+  
   
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38310] - [betwixt] Add a configuration option to ignore all BeanInfo

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38310


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #17447|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 05:03 ---
Created an attachment (id=17465)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17465&action=view)
Added unit test

Same as the earlier, but with a unit test.

-- 
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: r370721 - /jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt

[skitching]

Author: skitching
Date: Thu Jan 19 19:45:27 2006
New Revision: 370721

URL: http://svn.apache.org/viewcvs?rev=370721&view=rev
Log:
Add info about removal of deprecated classes.

Modified:
jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt

Modified: jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt?rev=370721&r1=370720&r2=370721&view=diff
==
--- jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt Thu Jan 19 19:45:27 
2006
@@ -115,6 +115,9 @@
 
 All changes to JCL configuration are backwards compatible.
 
+Classes Log4JCategoryLog and Log4jFactory have been removed; these were both
+deprecated in the 1.0.3 release (April 2003).
+
 For code that extends the JCL LogFactoryImpl class, the isXXXAvailable methods
 in org.apache.commons.logging.impl.LogFactoryImpl are no longer called during
 discovery by that class. Therefore classes which subclass LogFactoryImpl and



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] clirr report for 1.1 release

[Simon Kitching]

Hi,

I've run clirr to check for any binary incompatibilities between 1.0.4
and 1.1. It did pick up one corner case that I've committed a patch for
(though it was extremely unlikely to bite anyone).

Here's the report if anyone's interested.

http://people.apache.org/~skitching/clirr-logging-104-110.txt


The two incompatibilities reported re "removed classes" are for classes
deprecated in the 1.0.3 release (April 2003 I believe).

Regards,

Simons


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370718 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

[skitching]

Author: skitching
Date: Thu Jan 19 19:38:04 2006
New Revision: 370718

URL: http://svn.apache.org/viewcvs?rev=370718&view=rev
Log:
Add 2-param version of newFactory method for backwards compatibility. As 
described in the
javadoc, it could only ever be invoked by a very weird custom subclass of 
LogFactory but
it was technically an incompatibility so it's now fixed.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java?rev=370718&r1=370717&r2=370718&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java
 Thu Jan 19 19:38:04 2006
@@ -937,6 +937,26 @@
 }
 
 /**
+ * Method provided for backwards compatibility; see newFactory version that
+ * takes 3 parameters.
+ * 
+ * This method would only ever be called in some rather odd situation.
+ * Note that this method is static, so overriding in a subclass doesn't
+ * have any effect unless this method is called from a method in that
+ * subclass. However this method only makes sense to use from the
+ * getFactory method, and as that is almost always invoked via
+ * LogFactory.getFactory, any custom definition in a subclass would be
+ * pointless. Only a class with a custom getFactory method, then invoked
+ * directly via CustomFactoryImpl.getFactory or similar would ever call
+ * this. Anyway, it's here just in case, though the "managed class loader"
+ * value output to the diagnostics will not report the correct value.
+ */
+protected static LogFactory newFactory(final String factoryClass,
+   final ClassLoader classLoader) {
+   return newFactory(factoryClass, classLoader, null);
+}
+
+/**
  * Implements the operations described in the javadoc for newFactory.
  * 
  * @param factoryClass



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370705 - /jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt

[skitching]

Author: skitching
Date: Thu Jan 19 18:43:28 2006
New Revision: 370705

URL: http://svn.apache.org/viewcvs?rev=370705&view=rev
Log:
More 1.1 updates (still a work-in-progress)

Modified:
jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt

Modified: jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt?rev=370705&r1=370704&r2=370705&view=diff
==
--- jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/logging/trunk/RELEASE-NOTES.txt Thu Jan 19 18:43:28 
2006
@@ -22,6 +22,7 @@
 Version 1.1.0
 Release Notes
 
+Last updated: 2005-01-20
 
 INTRODUCTION:
 
@@ -104,6 +105,8 @@
 * The log4j logging adapter now supports the TRACE level (added to log4j 
1.2.12).
   Formerly, any calls to log.trace were output at the log4j debug level.
 
+* Better behaviour for systems with null classloaders (generally embedded 
systems).
+
 == Incompatibilities ==
 
 There are no changes for code that calls LogFactory or Log methods. This means
@@ -119,11 +122,51 @@
 unusual thing to do, so it isn't expected that any apps will actually be
 affected by this.
 
+== Dependencies ==
+
+Commons-logging has no mandatory dependencies.
+
+Java 1.2 and later are supported. It may be possible to recompile the source 
for
+use with java 1.1 but this has not been tested.
+
+== Distributed jarfiles ==
+
+File commons-logging-nn.jar is the one most people will want. It provides the
+base implementation and adapters to a number of popular logging libraries.
+
+File commons-logging-adapters-nn.jar includes only the adapters to various
+concrete logging libraries. When commons-logging-nn.jar or
+commons-logging-api-nn.jar is deployed in a container classpath, then this
+adapters-only jarfile should be deployed in the webapp, not the complete JCL
+distribution. This ensures that the core Log/LogFactory classes are only
+deployed via one classloader, thus avoiding "Log4JLogger does not implement 
Log"
+and similar problems.
+
+File commons-logging-minimal-nn.jar provides no adapters to external logging
+libraries, just the internally implemented SimpleLog and NoOpLog classes. This
+jarfile may be used as a declared dependency for projects that care about
+"transitive dependencies" and can't handle jarfiles such as 
commons-logging-nn.jar
+which have "optional" dependencies depending on how they are used. In addition,
+this jarfile can be useful for "rebundlers" of JCL who recompile the 
source-code
+but who may not be able to recompile against the full set of supported 
adapters;
+such projects should be able to at least recreate an equivalent of this 
jarfile.
+
+File commons-logging-api-nn.jar was created with the same goals as 
commons-logging-minimal,
+but unforunately included the Jdk14Logger implementation from the start. For 
backwards
+compatibility this same jarfile is provided but should be treated as 
deprecated, in
+favour of the "minimal" jarfile.
+
 == General Notes ==
 
 Log4J 1.3 is expected to include a binary-incompatible change from the 1.2 
series that 
 unfortunately makes it impossible for a single adapter class to support both.
 This release does not include support for Log4J 1.3. 
+
+The jakarta commons project has migrated to the Subversion version control 
system
+(previously, CVS was used). There should be no effect on users of the JCL
+library, but obviously the process of examining the latest source code, and of
+creating patches for JCL has now changed. Please see the jakarta commons
+website for details (http://jakarta.apache.org/commons).
 
 == Bugs Fixed ==
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370702 - /jakarta/commons/proper/logging/trunk/build.xml

[skitching]

Author: skitching
Date: Thu Jan 19 18:40:39 2006
New Revision: 370702

URL: http://svn.apache.org/viewcvs?rev=370702&view=rev
Log:
Fixes for javadoc building.
Add build instructions.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=370702&r1=370701&r2=370702&view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Thu Jan 19 18:40:39 2006
@@ -19,6 +19,11 @@
 
-  
+  
   
   
-  
-  
+  
+  
   
 
 
@@ -173,6 +178,12 @@
 
   
 
+  
+  
+
+
+  
+
   
   
 
@@ -551,7 +562,7 @@
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.-->'>
-  
+  
 
   
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370701 - /jakarta/commons/proper/logging/trunk/build.properties.sample

[skitching]

Author: skitching
Date: Thu Jan 19 18:39:24 2006
New Revision: 370701

URL: http://svn.apache.org/viewcvs?rev=370701&view=rev
Log:
Tweaks to use libs downloaded via newish "ant getlibs" target.

Modified:
jakarta/commons/proper/logging/trunk/build.properties.sample

Modified: jakarta/commons/proper/logging/trunk/build.properties.sample
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.properties.sample?rev=370701&r1=370700&r2=370701&view=diff
==
--- jakarta/commons/proper/logging/trunk/build.properties.sample (original)
+++ jakarta/commons/proper/logging/trunk/build.properties.sample Thu Jan 19 
18:39:24 2006
@@ -13,26 +13,26 @@
 # limitations under the License.
 
 # Apache Log4j 1.2.x series
-log4j12.jar=/java/log4j/log4j-1.2.9.jar
+log4j12.jar=lib/log4j-1.2.6.jar
 
 # Apache Log4j 1.3.x series
-log4j13.jar=/java/log4j/log4j-1.3.0.jar
+log4j13.jar=lib/log4j-1.3.0.jar
 
 # logkit.jar - Avalon LogKit classes (see http://jakarta.apache.org/avalon)
-logkit.jar=/java/logkit/logkit.jar
+logkit.jar=lib/logkit-1.0.1.jar
 
 # Avalon framework - used for wrapper for avalon framework logger
-avalon-framework.jar=../../Avalon-4.1.4/avalon-framework-4.1.4.jar
+avalon-framework.jar=lib/avalon-framework-4.1.3.jar
 
 # ServletApi - used to build ServletContextCleaner class
-servletapi.jar=/java/servletapi/servletapi.jar
+servletapi.jar=lib/servletapi-2.3.jar
 
 #
 # if you want to run the test cases, junit needs to be in the classpath.
 # the build.xml uses a default value so you might not need to set this 
property.
 # Note that version junit 3.8 is required and 3.8.1 recommended.
 # 
-# junit.jar=../../jakarta-velocity/build/lib/junit-3.8.1.jar
+junit.jar=lib/junit-3.8.1.jar
 
 # Maven properties (for web site build)
 # Those committers using agents may like to use



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370699 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

[skitching]

Author: skitching
Date: Thu Jan 19 18:29:48 2006
New Revision: 370699

URL: http://svn.apache.org/viewcvs?rev=370699&view=rev
Log:
Fixed javadoc warnings: @param did not match real param name.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java?rev=370699&r1=370698&r2=370699&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 Thu Jan 19 18:29:48 2006
@@ -101,8 +101,8 @@
 * @param t log this cause
 * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
-public void debug(Object o, Throwable t) {
-if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o), 
t);
+public void debug(Object message, Throwable t) {
+if (getLogger().isDebugEnabled()) 
getLogger().debug(String.valueOf(message), t);
 }
 
 /**
@@ -112,8 +112,8 @@
  * @param message to log.
  * @see org.apache.commons.logging.Log#debug(Object)
  */
-public void debug(Object o) {
-if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o));
+public void debug(Object message) {
+if (getLogger().isDebugEnabled()) 
getLogger().debug(String.valueOf(message));
 }
 
 /**
@@ -124,8 +124,8 @@
  * @param t log this cause
  * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
-public void error(Object o, Throwable t) {
-if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o), 
t);
+public void error(Object message, Throwable t) {
+if (getLogger().isErrorEnabled()) 
getLogger().error(String.valueOf(message), t);
 }
 
 /**
@@ -135,8 +135,8 @@
  * @param message to log
  * @see org.apache.commons.logging.Log#error(Object)
  */
-public void error(Object o) {
-if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o));
+public void error(Object message) {
+if (getLogger().isErrorEnabled()) 
getLogger().error(String.valueOf(message));
 }
 
 /**
@@ -147,8 +147,8 @@
  * @param t log this cause.
  * @see org.apache.commons.logging.Log#fatal(Object, Throwable)
  */
-public void fatal(Object o, Throwable t) {
-if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(o), t);
+public void fatal(Object message, Throwable t) {
+if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(message), t);
 }
 
 /**
@@ -158,8 +158,8 @@
  * @param message to log
  * @see org.apache.commons.logging.Log#fatal(Object)
  */
-public void fatal(Object o) {
-if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(o));
+public void fatal(Object message) {
+if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(message));
 }
 
 /**
@@ -170,8 +170,8 @@
  * @param t log this cause
  * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
-public void info(Object o, Throwable t) {
-if (getLogger().isInfoEnabled()) getLogger().info(String.valueOf(o), 
t);
+public void info(Object message, Throwable t) {
+if (getLogger().isInfoEnabled()) 
getLogger().info(String.valueOf(message), t);
 }
 
 /**
@@ -181,8 +181,8 @@
  * @param message to log
  * @see org.apache.commons.logging.Log#info(Object)
  */
-public void info(Object o) {
-if (getLogger().isInfoEnabled()) getLogger().info(String.valueOf(o));
+public void info(Object message) {
+if (getLogger().isInfoEnabled()) 
getLogger().info(String.valueOf(message));
 }
 
 /**
@@ -247,8 +247,8 @@
  * @param t log this cause.
  * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
-public void trace(Object o, Throwable t) {
-if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o), 
t);
+public void trace(Object message, Throwable t) {
+if (getLogger().isDebugEnabled()) 
getLogger().debug(String.valueOf(message), t);
 }
 
 /**
@@ -258,8 +258,8 @@
  * @param message to log
  * @see org.apache.commons.logging.Log#trace(Object)
  */
-public void trace(Object o) {
-if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o));
+public void trace(Object message) {
+if (getLogger().isDebugEnabled()) 
getLogger().debug(String.valueOf(message));
 }
 
 /**
@@ -270,8 +270,8 @@
  * @param t

DO NOT REPLY [Bug 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 03:21 ---
(In reply to comment #5)
> I made the change, but added documentation.

I read your documentation but it raises a question.  Are you meaning to suggest
that the RIGHT way to do this is to overwrite _connectAction_()?


-- 
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 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 02:29 ---
I made the change, but added documentation.

-- 
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: r370688 - /jakarta/commons/proper/net/trunk/xdocs/changes.xml

[dfs]

Author: dfs
Date: Thu Jan 19 17:28:12 2006
New Revision: 370688

URL: http://svn.apache.org/viewcvs?rev=370688&view=rev
Log:
Logged PR 38309 action.

Modified:
jakarta/commons/proper/net/trunk/xdocs/changes.xml

Modified: jakarta/commons/proper/net/trunk/xdocs/changes.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/xdocs/changes.xml?rev=370688&r1=370687&r2=370688&view=diff
==
--- jakarta/commons/proper/net/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/net/trunk/xdocs/changes.xml Thu Jan 19 17:28:12 2006
@@ -23,6 +23,13 @@
 


+   
+   Exposed control connection of FTP
+   class via _controlInput_ and _controlOutput_
+   protected member variables in response
+   to PR 38309 reported by
+   <[EMAIL PROTECTED]>.
+   

Reverted PR 32859 patch to TFTPClient
because it caused final packets to not



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370687 - /jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java

[dfs]

Author: dfs
Date: Thu Jan 19 17:22:14 2006
New Revision: 370687

URL: http://svn.apache.org/viewcvs?rev=370687&view=rev
Log:
Made controlInput and controlOutput protected in response to issue #38309.

Modified:

jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java

Modified: 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java?rev=370687&r1=370686&r2=370687&view=diff
==
--- 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java 
(original)
+++ 
jakarta/commons/proper/net/trunk/src/java/org/apache/commons/net/ftp/FTP.java 
Thu Jan 19 17:22:14 2006
@@ -224,14 +224,30 @@
 
 private StringBuffer __commandBuffer;
 
-BufferedReader _controlInput;
-BufferedWriter _controlOutput;
 int _replyCode;
 Vector _replyLines;
 boolean _newReplyString;
 String _replyString;
 String _controlEncoding;
 
+/**
+ * Wraps SocketClient._input_ to facilitate the writing of text
+ * to the FTP control connection.  Do not access the control
+ * connection via SocketClient._input_.  This member starts
+ * with a null value, is initialized in [EMAIL PROTECTED] 
#_connectAction_},
+ * and set to null in [EMAIL PROTECTED] #disconnect}.
+ */
+protected BufferedReader _controlInput_;
+
+/**
+ * Wraps SocketClient._output_ to facilitate the reading of text
+ * from the FTP control connection.  Do not access the control
+ * connection via SocketClient._output_.  This member starts
+ * with a null value, is initialized in [EMAIL PROTECTED] 
#_connectAction_},
+ * and set to null in [EMAIL PROTECTED] #disconnect}.
+ */
+protected BufferedWriter _controlOutput_;
+
 /***
  * A ProtocolCommandSupport object used to manage the registering of
  * ProtocolCommandListeners and te firing of ProtocolCommandEvents.
@@ -261,7 +277,7 @@
 _newReplyString = true;
 _replyLines.setSize(0);
 
-String line = _controlInput.readLine();
+String line = _controlInput_.readLine();
 
 if (line == null)
 throw new FTPConnectionClosedException(
@@ -292,7 +308,7 @@
 {
 do
 {
-line = _controlInput.readLine();
+line = _controlInput_.readLine();
 
 if (line == null)
 throw new FTPConnectionClosedException(
@@ -322,14 +338,17 @@
 "FTP response 421 received.  Server closed connection.");
 }
 
-// initiates control connections and gets initial reply
+/**
+ * Initiates control connections and gets initial reply.
+ * Initializes [EMAIL PROTECTED] #_controlInput_} and [EMAIL PROTECTED] 
#_controlOutput_}.
+ */
 protected void _connectAction_() throws IOException
 {
 super._connectAction_();
-_controlInput =
+_controlInput_ =
 new BufferedReader(new InputStreamReader(getInputStream(),
  getControlEncoding()));
-_controlOutput =
+_controlOutput_ =
 new BufferedWriter(new OutputStreamWriter(getOutputStream(),
   getControlEncoding()));
 __getReply();
@@ -389,14 +408,15 @@
  * some internal data so that the memory may be reclaimed by the
  * garbage collector.  The reply text and code information from the
  * last command is voided so that the memory it used may be reclaimed.
+ * Also sets [EMAIL PROTECTED] #_controlInput_} and [EMAIL PROTECTED] 
#_controlOutput_} to null.
  * 
  * @exception IOException If an error occurs while disconnecting.
  ***/
 public void disconnect() throws IOException
 {
 super.disconnect();
-_controlInput = null;
-_controlOutput = null;
+_controlInput_ = null;
+_controlOutput_ = null;
 _replyLines.setSize(0);
 _newReplyString = false;
 _replyString = null;
@@ -438,8 +458,8 @@
 __commandBuffer.append(SocketClient.NETASCII_EOL);
 
 try{
-   _controlOutput.write(message = __commandBuffer.toString());
-_controlOutput.flush();
+   _controlOutput_.write(message = __commandBuffer.toString());
+_controlOutput_.flush();
 }
 catch (SocketException e)
 {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] minimal jar vs api jar

[Simon Kitching]

Re the proposed "minimal" jarfile:

What exactly are the differences between this and the existing
commons-logging-api jarfile?

As far as I can see, commons-logging-api.jar has the Jdk14Logger class
in it, but otherwise is dependency-free.

I vaguely remember comments about api "being a mistake because it's not
usable out of the box" (I may have that quote wrong). However it looks
ok to me. Here's the contents from release 1.0.3:

[EMAIL PROTECTED]:~/apache/commons-logging-1.0.3$ jar tf
commons-logging-api.jar
META-INF/
META-INF/MANIFEST.MF
org/
org/apache/
org/apache/commons/
org/apache/commons/logging/
org/apache/commons/logging/impl/
org/apache/commons/logging/impl/Jdk14Logger.class
org/apache/commons/logging/impl/LogFactoryImpl$1.class
org/apache/commons/logging/impl/LogFactoryImpl.class
org/apache/commons/logging/impl/NoOpLog.class
org/apache/commons/logging/impl/SimpleLog$1.class
org/apache/commons/logging/impl/SimpleLog.class
org/apache/commons/logging/Log.class
org/apache/commons/logging/LogFactory$1.class
org/apache/commons/logging/LogFactory$2.class
org/apache/commons/logging/LogFactory$3.class
org/apache/commons/logging/LogFactory.class
org/apache/commons/logging/LogConfigurationException.class
org/apache/commons/logging/LogSource.class
META-INF/LICENSE.txt

The only differences I can see between this and the proposed "minimal"
are:
 * add WeakHashtable
 * remove Jdk14Logger

Can't we just make those changes to the api jar?

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[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 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 01:55 ---
Jose, you misunderstood me.  I was asking if you would be willing to submit your
FTPSClient as a patch.  It would have been a nice extension to commons-net if it
worked out.  

But I should have read your submission more carefully.  I didn't realize that
UFSC was another open source project.  I don't know what the licensing issues
would be, but it's likely to be a nightmare.

So, back to you, Daniel.  Do you have any objections to Jose's patch.






-- 
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: r370685 - /jakarta/commons/proper/logging/trunk/build.xml

[skitching]

Author: skitching
Date: Thu Jan 19 16:39:11 2006
New Revision: 370685

URL: http://svn.apache.org/viewcvs?rev=370685&view=rev
Log:
Remove WeakHashtable classes from the commons-logging-adapters jarfile.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=370685&r1=370684&r2=370685&view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Thu Jan 19 16:39:11 2006
@@ -431,6 +431,7 @@
   
   
   
+  
 
   
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] log4j transition

[Andy McBride]

> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: 20 January 2006 00:05
> To: 'Jakarta Commons Developers List'
> Subject: RE: [logging] log4j transition
 
> From memory the problem is the inverting of the Priority and Level
> classes. In 1.2, Priority extends Level while in 1.3 Level was to extend
> Priority or somesuch. This works in a compatible manner for most
> methods, but not the Logger.log(FQDN, level, msg, t) method - which JCL
> uses. That's from memory many months old now, so may not be 100%
> correct.

I think a couple weeks ago Level was 'restored' to extend Priority whereas
it had been made a top level class before so maybe the problem has gone
away.  

> 
> I discussed this issue with them last year and they were determined to
> push on with their plan. They do have to get rid of the old stuff
> eventually, but it's very interesting that they are now considering
> holding off on that until a 2.0 release. I'll try to find time to talk
> to them about that but I don't think it affects the proposed JCL 1.1
> release.

No affect on JCL 1.1 at all, +1 to that. 

Just hopeful that you won't need a 1.1.x release of JCL just to support
log4j1.3 when it is released :-)

Regards

Andy




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] log4j transition

[Simon Kitching]

On Thu, 2006-01-19 at 23:27 +, Andy McBride wrote:

> The log4j team now appear intent on restoring binary compatibility in the
> 1.3 codebase and are attempting to defer breaking changes to a later 2.0
> release.   

Thanks for the info.

> I'm not sure which incompatible changes in log4j forced you to implement the
> Log4J13Logger class but I wondered if they could now be resolved there,
> negating any future problem with using JCL1.1.x with log4j1.3 ? 

>From memory the problem is the inverting of the Priority and Level
classes. In 1.2, Priority extends Level while in 1.3 Level was to extend
Priority or somesuch. This works in a compatible manner for most
methods, but not the Logger.log(FQDN, level, msg, t) method - which JCL
uses. That's from memory many months old now, so may not be 100%
correct.

I discussed this issue with them last year and they were determined to
push on with their plan. They do have to get rid of the old stuff
eventually, but it's very interesting that they are now considering
holding off on that until a 2.0 release. I'll try to find time to talk
to them about that but I don't think it affects the proposed JCL 1.1
release.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL][logging] JCL 1.1

[Dennis Lundberg]

robert burrell donkin wrote:

the last JCL release (1.0.4) was back in june 2004. since then a lot of
work has been put in by the commons logging team analysing the
limitations and deficiencies of that release and of the dynamic binding
approach to bridging API's in general. it's taken some time but progress
has been made and (as importantly) the theoretical limitations of this
approach are now well understood. 


a release is now well overdue. due to the significant improvements made,
it is proposed that this release will be JCL 1.1. a release plan will be
assembled on the wiki
(http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan) and a
release candidate cut once it has been prepared. i'm happy to volunteer
to act as release manager.  


here my +1

- robert



+1

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370675 - /jakarta/commons/proper/logging/trunk/project.xml

[skitching]

Author: skitching
Date: Thu Jan 19 15:57:04 2006
New Revision: 370675

URL: http://svn.apache.org/viewcvs?rev=370675&view=rev
Log:
Added Brian Stansberry to developers list, as he did much work on 1.1 release
and is officially a committer but isn't around to add himself right now.

Modified:
jakarta/commons/proper/logging/trunk/project.xml

Modified: jakarta/commons/proper/logging/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.xml?rev=370675&r1=370674&r2=370675&view=diff
==
--- jakarta/commons/proper/logging/trunk/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/project.xml Thu Jan 19 15:57:04 2006
@@ -169,6 +169,10 @@
   [EMAIL PROTECTED]
   Apache Software Foundation
 
+
+  Brian Stansberry
+  bstansberry
+
   
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370674 - /jakarta/commons/proper/logging/trunk/build.xml

[skitching]

Author: skitching
Date: Thu Jan 19 15:55:30 2006
New Revision: 370674

URL: http://svn.apache.org/viewcvs?rev=370674&view=rev
Log:
Fixes due to Log4J12Logger being renamed back to Log4JLogger
and Log4J13Logger being removed.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=370674&r1=370673&r2=370674&view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Thu Jan 19 15:55:30 2006
@@ -266,7 +266,7 @@
   
 
 *** WARNING ***
-Log4j 1.2 not found: Cannot Build Log4J12Logger
+Log4j 1.2 not found: Cannot Build Log4JLogger
 
   
   
@@ -363,7 +363,7 @@
  
   
 
-  
 
   
@@ -383,6 +383,11 @@
  
   
 
+
   
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370673 - in /jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable: ChildFirstTestCase.java ParentFirstTestCase.java

[skitching]

Author: skitching
Date: Thu Jan 19 15:53:55 2006
New Revision: 370673

URL: http://svn.apache.org/viewcvs?rev=370673&view=rev
Log:
Fixes due to renaming of Log4J12Logger back to Log4JLogger

Modified:

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java

jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ParentFirstTestCase.java

Modified: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java?rev=370673&r1=370672&r2=370673&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ChildFirstTestCase.java
 Thu Jan 19 15:53:55 2006
@@ -145,8 +145,8 @@
 
 // jcl adapter classes should be visible via both parent and child. 
However
 // as the classloaders are child-first we should see the child one.
-Class log4jClass = 
contextLoader.loadClass("org.apache.commons.logging.impl.Log4J12Logger");
-assertSame("Log4J12Logger not loaded via child", 
+Class log4jClass = 
contextLoader.loadClass("org.apache.commons.logging.impl.Log4JLogger");
+assertSame("Log4JLogger not loaded via child", 
 log4jClass.getClassLoader(), thisLoader);
 
 // test classes should be visible via the child only
@@ -193,9 +193,9 @@
 // to the child should be returned. The URL returned will be of form
 //  jar:file:/x/y.jar!path/to/resource. The filename part should 
include the jarname
 // of form commons-logging-adapters-.jar, not 
commons-logging-.jar
-resource = 
childLoader.getResource("org/apache/commons/logging/impl/Log4J12Logger.class");
-assertNotNull("Unable to locate Log4J12Logger.class resource", 
resource);
-assertTrue("Incorrect source for Log4J12Logger class",
+resource = 
childLoader.getResource("org/apache/commons/logging/impl/Log4JLogger.class");
+assertNotNull("Unable to locate Log4JLogger.class resource", resource);
+assertTrue("Incorrect source for Log4JLogger class",
 resource.toString().indexOf("/commons-logging-adapters-1.") > 
0);
 }
 
@@ -237,9 +237,9 @@
 // is still (parent-resources, child-resources). This test verifies 
the expected
 // behaviour - even though it's not the desired behaviour.
 
-resources = 
childLoader.getResources("org/apache/commons/logging/impl/Log4J12Logger.class");
+resources = 
childLoader.getResources("org/apache/commons/logging/impl/Log4JLogger.class");
 urls = toURLArray(resources);
-assertEquals("Unexpected number of Log4J12Logger.class resources 
found", 2, urls.length);
+assertEquals("Unexpected number of Log4JLogger.class resources found", 
2, urls.length);
 
 // There is no gaurantee about the ordering of results returned from 
getResources
 // To make this test portable across JVMs, sort the string to give 
them a known order
@@ -247,9 +247,9 @@
 urlsToStrings[0] = urls[0].toString();
 urlsToStrings[1] = urls[1].toString();
 Arrays.sort(urlsToStrings);
-assertTrue("Incorrect source for Log4J12Logger class",
+assertTrue("Incorrect source for Log4JLogger class",
 urlsToStrings[0].indexOf("/commons-logging-1.") > 0);
-assertTrue("Incorrect source for Log4J12Logger class",
+assertTrue("Incorrect source for Log4JLogger class",
 urlsToStrings[1].indexOf("/commons-logging-adapters-1.") > 0);
 }
 

Modified: 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ParentFirstTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ParentFirstTestCase.java?rev=370673&r1=370672&r2=370673&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ParentFirstTestCase.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/test/org/apache/commons/logging/pathable/ParentFirstTestCase.java
 Thu Jan 19 15:53:55 2006
@@ -142,8 +142,8 @@
 
 // jcl adapter classes should be visible via both parent and child. 
However
 // as the classloaders are parent-first we should see the parent one.
-Class log4jClass = 
contextLoader.loadClass("org.apache.commons.logging.impl.Log4J12Logger");
-assertSame("Log4J12Logger not loaded via parent", 
+Class log4jClass = 
contextLoader.loa

svn commit: r370672 - in /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl: Log4J12Logger.java Log4J13Logger.java Log4JLogger.java LogFactoryImpl.java

[skitching]

Author: skitching
Date: Thu Jan 19 15:52:23 2006
New Revision: 370672

URL: http://svn.apache.org/viewcvs?rev=370672&view=rev
Log:
Remove Log4J13Logger; log4j 1.3 is not yet released.
Rename Log4J12Logger back to old name of Log4JLogger.

Added:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java
  - copied, changed from r370667, 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java
Removed:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java
Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java

Copied: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java
 (from r370667, 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java)
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java?p2=jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java&p1=jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java&r1=370667&r2=370672&rev=370672&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4JLogger.java
 Thu Jan 19 15:52:23 2006
@@ -46,12 +46,12 @@
  * @version $Id$
  */
 
-public class Log4J12Logger implements Log, Serializable {
+public class Log4JLogger implements Log, Serializable {
 
 // - Attributes
 
-/** The fully qualified name of the Log4J12Logger class. */
-private static final String FQCN = Log4J12Logger.class.getName();
+/** The fully qualified name of the Log4JLogger class. */
+private static final String FQCN = Log4JLogger.class.getName();
 
 /** Log to this logger */
 private transient Logger logger = null;
@@ -96,21 +96,21 @@
 
 //  Constructor
 
-public Log4J12Logger() {
+public Log4JLogger() {
 }
 
 
 /**
  * Base constructor.
  */
-public Log4J12Logger(String name) {
+public Log4JLogger(String name) {
 this.name = name;
 this.logger = getLogger();
 }
 
 /** For use with a log4j factory.
  */
-public Log4J12Logger(Logger logger ) {
+public Log4JLogger(Logger logger ) {
 this.name = logger.getName();
 this.logger=logger;
 }

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java?rev=370672&r1=370671&r2=370672&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogFactoryImpl.java
 Thu Jan 19 15:52:23 2006
@@ -149,8 +149,7 @@
  * but broken/unusable for some reason.
  */
 private static final String[] classesToDiscover = {
-"org.apache.commons.logging.impl.Log4J13Logger",
-"org.apache.commons.logging.impl.Log4J12Logger",
+"org.apache.commons.logging.impl.Log4JLogger",
 "org.apache.commons.logging.impl.Jdk14Logger",
 "org.apache.commons.logging.impl.Jdk13LumberjackLogger",
 "org.apache.commons.logging.impl.SimpleLog"



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Using maven-changes-plugin to track issues?

[Dennis Lundberg]

Simon Kitching wrote:

On Fri, 2006-01-20 at 00:21 +0100, Dennis Lundberg wrote:

Simon Kitching wrote:

On Thu, 2006-01-19 at 23:34 +0100, Dennis Lundberg wrote:

Hello

Would anyone object if I add the maven-changes-plugin [1] to track 
resolved issues in commons-logging? Today resolved issues are entered 
into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
all text in that section with a pointer to the report on the web.


The plugin produces a nice report [2] with all the resolved issues for 
every release. It requires that the file xdocs/changes.xml is added. 
It's already in use by most of the commons components.



[1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
[2] http://jakarta.apache.org/commons/validator/changes-report.html


Does that mean we need to re-enter info on all the fixed bugs into the
changes.xml file manually? I'm not wildly interested in doing that task
myself...

Yes it does. I'm willing to do it.


For the release after this one, I'd like to move to maven2, so there's
not much point in doing too much work on tidying up the existing build
setup unless it adds value for *this* release.
The added value for this release is a nice report that commons-logging 
users can look at on the commons-logging site, if they are interested in 
what has changed since the last release. They can do this without having 
to downloading commons-logging, extracting its contents to read 
RELEASE-NOTES.TXT.


Moving to Maven 2 will not affect this. Maven 2 also has a changes 
plugin that uses the same format for the changes.xml file as Maven 1 does.




Ok, go for it.


Will do.


On the subject of the RELEASE-NOTES.txt, though, I would like to have
that available directly from the website, so people can see the release
notes without downloading the release. The commons-digester
site does this, for example:
http://jakarta.apache.org/commons/digester/commons-digester-1.7
http://jakarta.apache.org/commons/digester/commons-digester-1.7/RELEASE-NOTES.txt


I'll see if I can set this up for commons-logging as well.

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL][logging] JCL 1.1

[Torsten Curdt]

On 20.01.2006, at 10:40, Simon Kitching wrote:

On Thu, 2006-01-19 at 23:26 +, robert burrell donkin wrote:
the last JCL release (1.0.4) was back in june 2004. since then a  
lot of

work has been put in by the commons logging team analysing the
limitations and deficiencies of that release and of the dynamic  
binding
approach to bridging API's in general. it's taken some time but  
progress
has been made and (as importantly) the theoretical limitations of  
this

approach are now well understood.

a release is now well overdue. due to the significant improvements  
made,

it is proposed that this release will be JCL 1.1.


big +1! hurray :)

cheers
--
Torsten




PGP.sig
Description: This is a digitally signed message part

Re: [logging] Using maven-changes-plugin to track issues?

[Simon Kitching]

On Fri, 2006-01-20 at 00:21 +0100, Dennis Lundberg wrote:
> Simon Kitching wrote:
> > On Thu, 2006-01-19 at 23:34 +0100, Dennis Lundberg wrote:
> >> Hello
> >>
> >> Would anyone object if I add the maven-changes-plugin [1] to track 
> >> resolved issues in commons-logging? Today resolved issues are entered 
> >> into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
> >> all text in that section with a pointer to the report on the web.
> >>
> >> The plugin produces a nice report [2] with all the resolved issues for 
> >> every release. It requires that the file xdocs/changes.xml is added. 
> >> It's already in use by most of the commons components.
> >>
> >>
> >> [1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
> >> [2] http://jakarta.apache.org/commons/validator/changes-report.html
> >>
> > 
> > Does that mean we need to re-enter info on all the fixed bugs into the
> > changes.xml file manually? I'm not wildly interested in doing that task
> > myself...
> 
> Yes it does. I'm willing to do it.
> 
> > For the release after this one, I'd like to move to maven2, so there's
> > not much point in doing too much work on tidying up the existing build
> > setup unless it adds value for *this* release.
> 
> The added value for this release is a nice report that commons-logging 
> users can look at on the commons-logging site, if they are interested in 
> what has changed since the last release. They can do this without having 
> to downloading commons-logging, extracting its contents to read 
> RELEASE-NOTES.TXT.
> 
> Moving to Maven 2 will not affect this. Maven 2 also has a changes 
> plugin that uses the same format for the changes.xml file as Maven 1 does.
> 

Ok, go for it.

On the subject of the RELEASE-NOTES.txt, though, I would like to have
that available directly from the website, so people can see the release
notes without downloading the release. The commons-digester
site does this, for example:
http://jakarta.apache.org/commons/digester/commons-digester-1.7
http://jakarta.apache.org/commons/digester/commons-digester-1.7/RELEASE-NOTES.txt

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL][logging] JCL 1.1

[Simon Kitching]

On Thu, 2006-01-19 at 23:26 +, robert burrell donkin wrote:
> the last JCL release (1.0.4) was back in june 2004. since then a lot of
> work has been put in by the commons logging team analysing the
> limitations and deficiencies of that release and of the dynamic binding
> approach to bridging API's in general. it's taken some time but progress
> has been made and (as importantly) the theoretical limitations of this
> approach are now well understood. 
> 
> a release is now well overdue. due to the significant improvements made,
> it is proposed that this release will be JCL 1.1. a release plan will be
> assembled on the wiki
> (http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan) and a
> release candidate cut once it has been prepared. i'm happy to volunteer
> to act as release manager.  
> 
> here my +1

+1

Note also that there are a few minor incompatibilities between the
proposed 1.1 and the former 1.0.4 for code that *extends*
commons-logging classes hence the minor number change is probably
necessary. For most users, though, the current SVN head code is a
compatible upgrade.

Note also that this release would clear the way for potentially more
significant rearchitecture of Logging; a number of ideas have been
floated based particularly around distributing a separate jar for each
supported library ("static binding"). However before getting started on
this it seems a good idea to release a less ambitious update containing
the accumulated fixes to the existing design.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38323] - [fileupload] FileUpload 2 gig File Size Limitation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38323





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 00:31 ---
(In reply to comment #1)
> It's not quite that simple. The content length provided by the container 
> (either
> servlet or portlet) is also an integer, so there is a limitation in the
> containers themselves. (See Request.getContentLength and
> ActionRequest.getContentLength.)

Wow, I guess I never noticed that that Request.getContentLength returns an
integer. Still, the spec allows for getContentLength to return -1 (unknown
length) therefore the length of the content sent can be greater than 2 gig.

-- 
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: [all] Dependencies on Maven plugins for building sites

[Dennis Lundberg]

Martin Cooper wrote:

On 1/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Is there a policy for adding dependencies on specific versions of
maven-plugins to a commons component? A quick look in SVN tells me that
8 components in commons proper such dependencies.



I think this is as close to "policy" as we get:

https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt

I know that's not what you're asking, but I'd suggest not explicitly adding
the ones that are already listed in that file.


Thanks Martin

I cannot find maven-jxr-plugin in that list. The reason for using a 
newer version, than the one that comes in the Maven 1.0.2 distribution, 
is to not get broken links in the generated site. This is something that 
all commons components would benefit from.


Should I add maven-jxr-plugin to the list?



I'd like to add the usual site generation plugins: site and xdoc, and

also maven-jxr-plugin-1.4.3. The 1.4.3 version solves broken links such
as the one after the "package" keyword found at the top of this file:

http://jakarta.apache.org/commons/logging/xref-test/org/apache/commons/logging/SimpleLogTestCase.html

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] log4j transition

[Andy McBride]

Hi,

> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: 19 January 2006 05:31
 
> The name-change will break any config files that explicitly specify that
> logger name. That breakage will have to occur eventually as long as the
> log4j team keep to their plan of making a binary-incompatible release.

The log4j team now appear intent on restoring binary compatibility in the
1.3 codebase and are attempting to defer breaking changes to a later 2.0
release.   

> However I think we've got enough in this release without buying into
> that issue too. In addition, I hate guessing the future on this; if we
> release a Log4J13Logger class and then it doesn't work with the real
> log4j13 that would be embarrassing.
> 
> Any objections to reverting to the old naming and removing Log4J13Logger
> for now? [NB: I wrote it :-].

+1

I'm not sure which incompatible changes in log4j forced you to implement the
Log4J13Logger class but I wondered if they could now be resolved there,
negating any future problem with using JCL1.1.x with log4j1.3 ? 

Regards

Andy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL][logging] JCL 1.1

[robert burrell donkin]

the last JCL release (1.0.4) was back in june 2004. since then a lot of
work has been put in by the commons logging team analysing the
limitations and deficiencies of that release and of the dynamic binding
approach to bridging API's in general. it's taken some time but progress
has been made and (as importantly) the theoretical limitations of this
approach are now well understood. 

a release is now well overdue. due to the significant improvements made,
it is proposed that this release will be JCL 1.1. a release plan will be
assembled on the wiki
(http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan) and a
release candidate cut once it has been prepared. i'm happy to volunteer
to act as release manager.  

here my +1

- robert


signature.asc
Description: This is a digitally signed message part

Re: [logging] Using maven-changes-plugin to track issues?

[Dennis Lundberg]

Simon Kitching wrote:

On Thu, 2006-01-19 at 23:34 +0100, Dennis Lundberg wrote:

Hello

Would anyone object if I add the maven-changes-plugin [1] to track 
resolved issues in commons-logging? Today resolved issues are entered 
into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
all text in that section with a pointer to the report on the web.


The plugin produces a nice report [2] with all the resolved issues for 
every release. It requires that the file xdocs/changes.xml is added. 
It's already in use by most of the commons components.



[1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
[2] http://jakarta.apache.org/commons/validator/changes-report.html



Does that mean we need to re-enter info on all the fixed bugs into the
changes.xml file manually? I'm not wildly interested in doing that task
myself...


Yes it does. I'm willing to do it.


For the release after this one, I'd like to move to maven2, so there's
not much point in doing too much work on tidying up the existing build
setup unless it adds value for *this* release.


The added value for this release is a nice report that commons-logging 
users can look at on the commons-logging site, if they are interested in 
what has changed since the last release. They can do this without having 
to downloading commons-logging, extracting its contents to read 
RELEASE-NOTES.TXT.


Moving to Maven 2 will not affect this. Maven 2 also has a changes 
plugin that uses the same format for the changes.xml file as Maven 1 does.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38323] - [fileupload] FileUpload 2 gig File Size Limitation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38323





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 00:20 ---
Created an attachment (id=17461)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17461&action=view)
total variable type changed from int to long

Here is a patch that that resolves the limitation (I think). This patch simply
changes type of the total variable from int to long.

-- 
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: [logging] 1.1 release manager?

[robert burrell donkin]

On Fri, 2006-01-20 at 12:07 +1300, Simon Kitching wrote:
> On Thu, 2006-01-19 at 23:02 +, robert burrell donkin wrote:
> > we should really start talking about electing an official release
> > manager about now. 
> > 
> > simon - do you think you'll have the time for this (over the next month
> > or so) or would you be happier driving the actual work with me
> > performing the official role?
> 
> As you've done JCL releases before, I'm very happy for you to do this if
> you've got time.
> 
> I'm going to be away on holiday between 27 jan and 6 feb, hopefully
> after a first RC has been done for people to evaluate. It would be nice
> to have a release manager around over that period which also suggests
> that it might be better for you to do that.
> 
> However I know you're pretty busy. I did do the last digester release,
> so I don't mind taking on this JCL release if you've got too much on at
> the moment. I expect to be busyish but not completely overloaded in the
> next month or so, so I can find the time somewhere.

for me, it's more a question of priorities (than simply being busy). it
sounds like it makes sense for me to cut this one so i'll shuffle stuff
around so that this release is towards the top.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370667 - /jakarta/commons/proper/logging/trunk/project.xml

[dennisl]

Author: dennisl
Date: Thu Jan 19 15:06:22 2006
New Revision: 370667

URL: http://svn.apache.org/viewcvs?rev=370667&view=rev
Log:
Adding myself as a developer.

Modified:
jakarta/commons/proper/logging/trunk/project.xml

Modified: jakarta/commons/proper/logging/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.xml?rev=370667&r1=370666&r2=370667&view=diff
==
--- jakarta/commons/proper/logging/trunk/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/project.xml Thu Jan 19 15:06:22 2006
@@ -163,6 +163,12 @@
   [EMAIL PROTECTED]
   Apache Software Foundation
 
+
+  Dennis Lundberg
+  dennisl
+  [EMAIL PROTECTED]
+  Apache Software Foundation
+
   
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] 1.1 release manager?

[Simon Kitching]

On Thu, 2006-01-19 at 23:02 +, robert burrell donkin wrote:
> we should really start talking about electing an official release
> manager about now. 
> 
> simon - do you think you'll have the time for this (over the next month
> or so) or would you be happier driving the actual work with me
> performing the official role?

As you've done JCL releases before, I'm very happy for you to do this if
you've got time.

I'm going to be away on holiday between 27 jan and 6 feb, hopefully
after a first RC has been done for people to evaluate. It would be nice
to have a release manager around over that period which also suggests
that it might be better for you to do that.

However I know you're pretty busy. I did do the last digester release,
so I don't mind taking on this JCL release if you've got too much on at
the moment. I expect to be busyish but not completely overloaded in the
next month or so, so I can find the time somewhere.

Cheers,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38323] - [fileupload] FileUpload 2 gig File Size Limitation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38323





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 00:01 ---
It's not quite that simple. The content length provided by the container (either
servlet or portlet) is also an integer, so there is a limitation in the
containers themselves. (See Request.getContentLength and
ActionRequest.getContentLength.)

-- 
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: [logging] Using maven-changes-plugin to track issues?

[Simon Kitching]

On Thu, 2006-01-19 at 23:34 +0100, Dennis Lundberg wrote:
> Hello
> 
> Would anyone object if I add the maven-changes-plugin [1] to track 
> resolved issues in commons-logging? Today resolved issues are entered 
> into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
> all text in that section with a pointer to the report on the web.
> 
> The plugin produces a nice report [2] with all the resolved issues for 
> every release. It requires that the file xdocs/changes.xml is added. 
> It's already in use by most of the commons components.
> 
> 
> [1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
> [2] http://jakarta.apache.org/commons/validator/changes-report.html
> 

Does that mean we need to re-enter info on all the fixed bugs into the
changes.xml file manually? I'm not wildly interested in doing that task
myself...

For the release after this one, I'd like to move to maven2, so there's
not much point in doing too much work on tidying up the existing build
setup unless it adds value for *this* release.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] 1.1 release manager?

[robert burrell donkin]

we should really start talking about electing an official release
manager about now. 

simon - do you think you'll have the time for this (over the next month
or so) or would you be happier driving the actual work with me
performing the official role?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[robert burrell donkin]

On Fri, 2006-01-20 at 11:03 +1300, Simon Kitching wrote:



> The bit that bothers me is that inner classes can only access parameters
> that are declared final. Why is this, if the binary code generated is
> *exactly* the same whether the parameter is final or not? I can't see
> the reason and that makes me feel a little nervous...

AIUI inner classes are actually fudged by the compiler (rather than
being first class constructs in the bytecode)

(people who are more authoritative on this stuff should feel to jump in
here)

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Using maven-changes-plugin to track issues?

[robert burrell donkin]

On Thu, 2006-01-19 at 23:34 +0100, Dennis Lundberg wrote:
> Hello
> 
> Would anyone object if I add the maven-changes-plugin [1] to track 
> resolved issues in commons-logging? Today resolved issues are entered 
> into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
> all text in that section with a pointer to the report on the web.
> 
> The plugin produces a nice report [2] with all the resolved issues for 
> every release. It requires that the file xdocs/changes.xml is added. 
> It's already in use by most of the commons components.
> 
> 
> [1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
> [2] http://jakarta.apache.org/commons/validator/changes-report.html

i have no objections to the addition of the report but i'd prefer to
keep the text section in the release notes as well (at least for this
release). 

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Dependencies on Maven plugins for building sites

[Martin Cooper]

On 1/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>
> Is there a policy for adding dependencies on specific versions of
> maven-plugins to a commons component? A quick look in SVN tells me that
> 8 components in commons proper such dependencies.


I think this is as close to "policy" as we get:

https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt

I know that's not what you're asking, but I'd suggest not explicitly adding
the ones that are already listed in that file.

--
Martin Cooper


I'd like to add the usual site generation plugins: site and xdoc, and
> also maven-jxr-plugin-1.4.3. The 1.4.3 version solves broken links such
> as the one after the "package" keyword found at the top of this file:
>
> http://jakarta.apache.org/commons/logging/xref-test/org/apache/commons/logging/SimpleLogTestCase.html
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [logging] Bug 38174 and JCL 1.1

[robert burrell donkin]

On Thu, 2006-01-19 at 20:23 +, robert burrell donkin wrote:
> On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> > Hello,
> > 
> > Simon Kitching wrote:
> > >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> > >>> weekend and hold a vote on creating the first RC.
> > >> Please check to put the patch in bug 38174 into RC. Even if you decide
> > >> against the logic in the new "doLog" methods, it would be nice to have 
> > >> the other cleanup (javadoc, same null behaviour for all classes).
> > >
> > > Please check my comments on that bugzilla entry.
> > >
> > 
> > I have read your comments and opinions in the bugzilla entry[1].
> > As I do not want to put so much time in a more or less boring task
> > (improving the JavaDoc and care for doLog single method logic is a lot of
> > copy and correct paste) I have removed anything of the exception behaviour.
> > I have also removed the String.valueOf when the underlying logger accepts
> > objects as message.
> > 
> > Every file has single patch. With accident cause I did an format after
> > removing the exception handling - sorry for that, it will cause more diff
> > than is really different.
> > 
> > Please consider again to put this into release.
> 
> i'm going through the patches (by hand) now. 

i've applied the javadoc changes. i may review the other bits later (if
time allows) but that's about it for me for tonight. i'm unlikely to be
online tomorrow. i plan to try to write some documentation on saturday. 

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38323] New: - [fileupload] FileUpload 2 gig File Size Limitation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38323

   Summary: [fileupload] FileUpload 2 gig File Size Limitation
   Product: Commons
   Version: 1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: File Upload
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Looking through the FileUpload 1.1 code it looks like there is a limitation on
how big of a file can be received and processed. If you look at the readBodyData
method of the MultipartStream class you'll notice that an integer is being used
to keep a tally of the total number of bytes received when processing an
encapsulation. I recommend changing the type of the variable "total" to a long
in the readBodyData and wherever a tally of bytes received is done.

-- 
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: r370659 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 14:48:16 2006
New Revision: 370659

URL: http://svn.apache.org/viewcvs?rev=370659&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java?rev=370659&r1=370658&r2=370659&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/AvalonLogger.java
 Thu Jan 19 14:48:16 2006
@@ -94,62 +94,100 @@
 }
 
 /**
- * @see org.apache.commons.logging.Log#debug(java.lang.Object, 
java.lang.Throwable)
+* Logs a message with
+* org.apache.avalon.framework.logger.Logger.debug.
+* 
+* @param message to log
+* @param t log this cause
+* @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object o, Throwable t) {
 if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o), 
t);
 }
 
 /**
- * @see org.apache.commons.logging.Log#debug(java.lang.Object)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.debug.
+ * 
+ * @param message to log.
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object o) {
 if (getLogger().isDebugEnabled()) getLogger().debug(String.valueOf(o));
 }
 
 /**
- * @see org.apache.commons.logging.Log#error(java.lang.Object, 
java.lang.Throwable)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.error.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object o, Throwable t) {
 if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o), 
t);
 }
 
 /**
- * @see org.apache.commons.logging.Log#error(java.lang.Object)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.error.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object o) {
 if (getLogger().isErrorEnabled()) getLogger().error(String.valueOf(o));
 }
 
 /**
- * @see org.apache.commons.logging.Log#fatal(java.lang.Object, 
java.lang.Throwable)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.fatalError.
+ * 
+ * @param message to log.
+ * @param t log this cause.
+ * @see org.apache.commons.logging.Log#fatal(Object, Throwable)
  */
 public void fatal(Object o, Throwable t) {
 if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(o), t);
 }
 
 /**
- * @see org.apache.commons.logging.Log#fatal(java.lang.Object)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.fatalError.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Object)
  */
 public void fatal(Object o) {
 if (getLogger().isFatalErrorEnabled()) 
getLogger().fatalError(String.valueOf(o));
 }
 
 /**
- * @see org.apache.commons.logging.Log#info(java.lang.Object, 
java.lang.Throwable)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.info.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object o, Throwable t) {
 if (getLogger().isInfoEnabled()) getLogger().info(String.valueOf(o), 
t);
 }
 
 /**
- * @see org.apache.commons.logging.Log#info(java.lang.Object)
+ * Logs a message with
+ * org.apache.avalon.framework.logger.Logger.info.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object o) {
 if (getLogger().isInfoEnabled()) getLogger().info(String.valueOf(o));
 }
 
 /**
+ * Is logging to 
+ * org.apache.avalon.framework.logger.Logger.debug enabled?
  * @see org.apache.commons.logging.Log#isDebugEnabled()
  */
 public boolean isDebugEnabled() {
@@ -157,6 +195,8 @@
 }
 
 /**
+ * Is logging to 
+ * org.apache.avalon.framework.logger.Logger.error enabled?
  * @see org.apache.commons.logging.Log#isErrorEnabled()
  */
 public boolean isErrorEnabled() {
@@ -164,6 +204,8 @@
 }
 
 /**
+ * Is logging to 
+ * org.apache.avalon.framework.logger.Logger.fatalError 
enabled?
  

[all] Dependencies on Maven plugins for building sites

[Dennis Lundberg]

Is there a policy for adding dependencies on specific versions of 
maven-plugins to a commons component? A quick look in SVN tells me that 
8 components in commons proper such dependencies.


I'd like to add the usual site generation plugins: site and xdoc, and 
also maven-jxr-plugin-1.4.3. The 1.4.3 version solves broken links such 
as the one after the "package" keyword found at the top of this file:

http://jakarta.apache.org/commons/logging/xref-test/org/apache/commons/logging/SimpleLogTestCase.html

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Maven generated site

[robert burrell donkin]

On Fri, 2006-01-20 at 11:04 +1300, Simon Kitching wrote:
> On Thu, 2006-01-19 at 22:49 +0100, Dennis Lundberg wrote:
> > Hi
> > 
> > I'm testing the Maven generated site for logging and have found some 
> > broken links, that I'd like to fix. Just checking to see if that's OK.
> > 
> 
> Go for it! Tidying the site stuff is on my list but not started yet, so
> you're very welcome to take that on :-)

+1

dive in :)

remember to add your name to the list of committers in the project.xml
(traditionally, this is a good first commit). you might find that your
commit messages need to be moderated through (the first time).

please try to create good commit messages (it's also best to double
check them since (at the ASF) commit messages become part of the public
record and typos can be a little embarrassing)

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] Using maven-changes-plugin to track issues?

[Dennis Lundberg]

Hello

Would anyone object if I add the maven-changes-plugin [1] to track 
resolved issues in commons-logging? Today resolved issues are entered 
into the section "Bugs Fixed" in RELEASE-NOTES.TXT. I'd like to replace 
all text in that section with a pointer to the report on the web.


The plugin produces a nice report [2] with all the resolved issues for 
every release. It requires that the file xdocs/changes.xml is added. 
It's already in use by most of the commons components.



[1] http://maven.apache.org/maven-1.x/reference/plugins/changes/
[2] http://jakarta.apache.org/commons/validator/changes-report.html

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 23:33 ---
(In reply to comment #1)
> What do you think of this, Daniel?  Is there a good reason NOT to make these
> data members protected or provide setters/getters for them?
> 
> An alternative idea, if Jose is willing, might be for Jose to make local
> modifications and then, once he's gotten his FTPSClient working, submit it as 
> a
> patch to be added to commons-net.

I submit the patch. 
Thanks for your time and attention.

-- 
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 38309] - [net] How to implent FTPS extending FTPClient, from a diferente package...

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38309





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 23:31 ---
Created an attachment (id=17460)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17460&action=view)
Patch to solve the problem of extension FTP to other protocol...

This is the patch that make the variables, protected, this is the only thing i
need, to extends FTPClient to FTPSClient, in other package...

-- 
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: r370654 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 14:31:02 2006
New Revision: 370654

URL: http://svn.apache.org/viewcvs?rev=370654&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java?rev=370654&r1=370653&r2=370654&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
 Thu Jan 19 14:31:02 2006
@@ -134,7 +134,10 @@
 }
 
 /**
- * Log a message with debug log level.
+ * Logs a message with java.util.logging.Level.FINE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object message) {
 log(Level.FINE, String.valueOf(message), null);
@@ -142,7 +145,11 @@
 
 
 /**
- * Log a message and exception with debug log level.
+ * Logs a message with java.util.logging.Level.FINE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object message, Throwable exception) {
 log(Level.FINE, String.valueOf(message), exception);
@@ -150,7 +157,10 @@
 
 
 /**
- * Log a message with error log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object message) {
 log(Level.SEVERE, String.valueOf(message), null);
@@ -158,7 +168,11 @@
 
 
 /**
- * Log a message and exception with error log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object message, Throwable exception) {
 log(Level.SEVERE, String.valueOf(message), exception);
@@ -166,7 +180,10 @@
 
 
 /**
- * Log a message with fatal log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Object)
  */
 public void fatal(Object message) {
 log(Level.SEVERE, String.valueOf(message), null);
@@ -174,7 +191,11 @@
 
 
 /**
- * Log a message and exception with fatal log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#fatal(Object, Throwable)
  */
 public void fatal(Object message, Throwable exception) {
 log(Level.SEVERE, String.valueOf(message), exception);
@@ -193,7 +214,10 @@
 
 
 /**
- * Log a message with info log level.
+ * Logs a message with java.util.logging.Level.INFO.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object message) {
 log(Level.INFO, String.valueOf(message), null);
@@ -201,7 +225,11 @@
 
 
 /**
- * Log a message and exception with info log level.
+ * Logs a message with java.util.logging.Level.INFO.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object message, Throwable exception) {
 log(Level.INFO, String.valueOf(message), exception);
@@ -257,7 +285,10 @@
 
 
 /**
- * Log a message with trace log level.
+ * Logs a message with java.util.logging.Level.FINEST.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object)
  */
 public void trace(Object message) {
 log(Level.FINEST, String.valueOf(message), null);
@@ -265,7 +296,11 @@
 
 
 /**
- * Log a message and exception with trace log level.
+ * Logs a message with java.util.logging.Level.FINEST.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public void trace(Object message, Throwable exception) {
 log(Level.FINEST, String.valueOf(message), exception);
@@ -273,7 +308,10 @@
 
 
 /**
- * Log a message with warn log level.
+ * Logs a message with java.util.logging.Level.WARNING.
+ *
+ * @param message to log
+   

svn commit: r370652 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 14:23:48 2006
New Revision: 370652

URL: http://svn.apache.org/viewcvs?rev=370652&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java?rev=370652&r1=370651&r2=370652&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Jdk14Logger.java
 Thu Jan 19 14:23:48 2006
@@ -104,7 +104,10 @@
 }
 
 /**
- * Log a message with debug log level.
+ * Logs a message with java.util.logging.Level.FINE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object message) {
 log(Level.FINE, String.valueOf(message), null);
@@ -112,7 +115,11 @@
 
 
 /**
- * Log a message and exception with debug log level.
+ * Logs a message with java.util.logging.Level.FINE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object message, Throwable exception) {
 log(Level.FINE, String.valueOf(message), exception);
@@ -120,7 +127,10 @@
 
 
 /**
- * Log a message with error log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object message) {
 log(Level.SEVERE, String.valueOf(message), null);
@@ -128,7 +138,11 @@
 
 
 /**
- * Log a message and exception with error log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object message, Throwable exception) {
 log(Level.SEVERE, String.valueOf(message), exception);
@@ -136,7 +150,10 @@
 
 
 /**
- * Log a message with fatal log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Object)
  */
 public void fatal(Object message) {
 log(Level.SEVERE, String.valueOf(message), null);
@@ -144,7 +161,11 @@
 
 
 /**
- * Log a message and exception with fatal log level.
+ * Logs a message with java.util.logging.Level.SEVERE.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#fatal(Object, Throwable)
  */
 public void fatal(Object message, Throwable exception) {
 log(Level.SEVERE, String.valueOf(message), exception);
@@ -163,7 +184,10 @@
 
 
 /**
- * Log a message with info log level.
+ * Logs a message with java.util.logging.Level.INFO.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object message) {
 log(Level.INFO, String.valueOf(message), null);
@@ -171,7 +195,11 @@
 
 
 /**
- * Log a message and exception with info log level.
+ * Logs a message with java.util.logging.Level.INFO.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object message, Throwable exception) {
 log(Level.INFO, String.valueOf(message), exception);
@@ -227,7 +255,10 @@
 
 
 /**
- * Log a message with trace log level.
+ * Logs a message with java.util.logging.Level.FINEST.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object)
  */
 public void trace(Object message) {
 log(Level.FINEST, String.valueOf(message), null);
@@ -235,7 +266,11 @@
 
 
 /**
- * Log a message and exception with trace log level.
+ * Logs a message with java.util.logging.Level.FINEST.
+ *
+ * @param message to log
+ * @param exception log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public void trace(Object message, Throwable exception) {
 log(Level.FINEST, String.valueOf(message), exception);
@@ -243,7 +278,10 @@
 
 
 /**
- * Log a message with warn log level.
+ * Logs a message with java.util.logging.Level.WARNING.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#warn(Objec

svn commit: r370651 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 14:12:10 2006
New Revision: 370651

URL: http://svn.apache.org/viewcvs?rev=370651&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java?rev=370651&r1=370650&r2=370651&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J12Logger.java
 Thu Jan 19 14:12:10 2006
@@ -135,9 +135,12 @@
 
 
 /**
- * Log a message to the Log4j Logger with TRACE priority.
+ * Logs a message with org.apache.log4j.Priority.TRACE.
  * When using a log4j version that does not support the TRACE
  * level, the message will be logged at the DEBUG level.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object)
  */
 public void trace(Object message) {
 getLogger().log(FQCN, traceLevel, message, null );
@@ -145,9 +148,13 @@
 
 
 /**
- * Log an error to the Log4j Logger with TRACE priority.
+ * Logs a message with org.apache.log4j.Priority.TRACE.
  * When using a log4j version that does not support the TRACE
  * level, the message will be logged at the DEBUG level.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public void trace(Object message, Throwable t) {
 getLogger().log(FQCN, traceLevel, message, t );
@@ -155,14 +162,21 @@
 
 
 /**
- * Log a message to the Log4j Logger with DEBUG priority.
+ * Logs a message with org.apache.log4j.Priority.DEBUG.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object message) {
 getLogger().log(FQCN, Priority.DEBUG, message, null );
 }
 
 /**
- * Log an error to the Log4j Logger with DEBUG priority.
+ * Logs a message with org.apache.log4j.Priority.DEBUG.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object message, Throwable t) {
 getLogger().log(FQCN, Priority.DEBUG, message, t );
@@ -170,7 +184,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with INFO priority.
+ * Logs a message with org.apache.log4j.Priority.INFO.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object message) {
 getLogger().log(FQCN, Priority.INFO, message, null );
@@ -178,7 +195,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with INFO priority.
+ * Logs a message with org.apache.log4j.Priority.INFO.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object message, Throwable t) {
 getLogger().log(FQCN, Priority.INFO, message, t );
@@ -186,7 +207,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with WARN priority.
+ * Logs a message with org.apache.log4j.Priority.WARN.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#warn(Object)
  */
 public void warn(Object message) {
 getLogger().log(FQCN, Priority.WARN, message, null );
@@ -194,7 +218,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with WARN priority.
+ * Logs a message with org.apache.log4j.Priority.WARN.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#warn(Object, Throwable)
  */
 public void warn(Object message, Throwable t) {
 getLogger().log(FQCN, Priority.WARN, message, t );
@@ -202,7 +230,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with ERROR priority.
+ * Logs a message with org.apache.log4j.Priority.ERROR.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object message) {
 getLogger().log(FQCN, Priority.ERROR, message, null );
@@ -210,7 +241,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with ERROR priority.
+ * Logs a message with org.apache.log4j.Priority.ERROR.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object message, Throwable

svn commit: r370649 - /jakarta/commons/proper/logging/tags/2005-01-20/

[skitching]

Author: skitching
Date: Thu Jan 19 14:07:37 2006
New Revision: 370649

URL: http://svn.apache.org/viewcvs?rev=370649&view=rev
Log:
Tag before deleting Log4J13Logger class

Added:
jakarta/commons/proper/logging/tags/2005-01-20/
  - copied from r370648, jakarta/commons/proper/logging/trunk/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] ServletContextCleaner

[robert burrell donkin]

On Thu, 2006-01-19 at 21:43 +0100, Dennis Lundberg wrote:
> robert burrell donkin wrote:



> > BTW dennis should have an apache account by now
> 
> Yep I'm here, with a fresh account. I have time to spare on JCL right now.

great

if you like, add yourself to
http://jakarta.apache.org/site/whoweare.html. 

(you should have jakarta-site karma, if not then ask on the general
list.)

- robert



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Maven generated site

[Simon Kitching]

On Thu, 2006-01-19 at 22:49 +0100, Dennis Lundberg wrote:
> Hi
> 
> I'm testing the Maven generated site for logging and have found some 
> broken links, that I'd like to fix. Just checking to see if that's OK.
> 

Go for it! Tidying the site stuff is on my list but not started yet, so
you're very welcome to take that on :-)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[Simon Kitching]

On Thu, 2006-01-19 at 22:46 +0100, Jörg Schaible wrote:
> Boris Unckel wrote:
> 
> > Hello Robert,
> > 
> > robert burrell donkin wrote:

> >> i notice that a lot of the parameters are now declared final (which is -
> >> usually - good). i would have expected that this should not effect
> >> binary compatibility but unfortunately, i can't find anywhere in the JLS
> >> where this is definitely specified. i'm very reluctant to add any
> >> changes which risk (at all) binary compatibility issues.
> >>
> >> anyone know of a definitive reference?
> > 
> > First my apologies to not mention it in the patch description - I am used
> > to final the parameters, so I did not recognize it actively.
> > I cannot cite a spec or a similiar document. After your mail I just used
> > JAD to decompile a class again.
> > The final before the parameters is not part of the decompiled class.
> > 
> > I know that this is not a proove, but a hint.
> > If this is going to be a show stopper, the final should be removed.
> 
> It has no effect on the binary output, otherwise you could not overwrite 
> methods and change this modifier for the parameters. For parameters it is 
> just a hint for the compiler and prevents accidental assignment.

The bit that bothers me is that inner classes can only access parameters
that are declared final. Why is this, if the binary code generated is
*exactly* the same whether the parameter is final or not? I can't see
the reason and that makes me feel a little nervous...

Regards,

Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] ServletContextCleaner

[Simon Kitching]

On Thu, 2006-01-19 at 21:43 +0100, Dennis Lundberg wrote:
> robert burrell donkin wrote:
> > On Wed, 2006-01-18 at 18:01 +1300, Simon Kitching wrote:
> > 
> > BTW dennis should have an apache account by now
> 
> Yep I'm here, with a fresh account. I have time to spare on JCL right now.

Fantastic. We may just have critical mass for a release!!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Log4JLogger thread safety issue

[Simon Kitching]

On Thu, 2006-01-19 at 20:04 +, robert burrell donkin wrote:

> i was wondering whether a logger could be partially constructed and if
> so what the likely effect would be (thread A enters getLogger() and
> starts the construction of the logger but is not finished before thread
> B enters the method and finds logger has been assigned (so not null) but
> not completed constructed.) i'm unsure whether this scenario is allowed
> by the java language and virtual machine specifications. a few similarly
> unintuitive ones are.

For the code
   logger = Logger.getLogger(name)
the assignment won't happen until the object returned by
Logger.getLogger is 100% complete. There's no way to get access to a
partially-initialised object here. 

There is a window in which two threads can both see logger==null, but as
described in the earlier email that causes no problems. The first thread
returns a reference to object X which it assigns to logger, then the
second thread returns a reference to object X which it uses to overwrite
the previous one. No problem.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] Maven generated site

[Dennis Lundberg]

Hi

I'm testing the Maven generated site for logging and have found some 
broken links, that I'd like to fix. Just checking to see if that's OK.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[Jörg Schaible]

Boris Unckel wrote:

> Hello Robert,
> 
> robert burrell donkin wrote:
>> i'm going through the patches (by hand) now.
>>
>> i notice that a lot of the parameters are now declared final (which is -
>> usually - good). i would have expected that this should not effect
>> binary compatibility but unfortunately, i can't find anywhere in the JLS
>> where this is definitely specified. i'm very reluctant to add any
>> changes which risk (at all) binary compatibility issues.
>>
>> anyone know of a definitive reference?
> 
> First my apologies to not mention it in the patch description - I am used
> to final the parameters, so I did not recognize it actively.
> I cannot cite a spec or a similiar document. After your mail I just used
> JAD to decompile a class again.
> The final before the parameters is not part of the decompiled class.
> 
> I know that this is not a proove, but a hint.
> If this is going to be a show stopper, the final should be removed.

It has no effect on the binary output, otherwise you could not overwrite 
methods and change this modifier for the parameters. For parameters it is 
just a hint for the compiler and prevents accidental assignment.

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[Simon Kitching]

I've read through this reference, and it doesn't mention final qualifier
on parameters.

I also *think* this is safe, and that final is just a compile-time
constraint. However I'm not 100% sure, so would prefer to not make that
change here.

Section D.1.2 of this document suggests final is ok, but this info is a
little out-of-date:
  http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html

However in the end, this "final" thing isn't going to improve the
efficiency of the code, and carries a small chance of breaking things so
I'd suggest not applying it.

Regards,

Simon

On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:
> Hi robert,
> 
> See 13.4.8 final Fields and Constants at 
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
> 
> Short answer : yes and no :)
> 
> Mvgr,
> Martin
> 
> robert burrell donkin wrote:
> > 
> > i notice that a lot of the parameters are now declared final (which is -
> > usually - good). i would have expected that this should not effect
> > binary compatibility but unfortunately, i can't find anywhere in the JLS
> > where this is definitely specified. i'm very reluctant to add any
> > changes which risk (at all) binary compatibility issues.
> > 
> > anyone know of a definitive reference?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[Martin van den Bemt]

The only thing I can think of based on that document that the method signature stays the same and if 
the field is incorrecly modified you get the IllegalAccessException.

Although I would definitely test with some tool to make sure :)

Mvgr,
Martin

robert burrell donkin wrote:

On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:


Hi robert,

See 13.4.8 final Fields and Constants at 
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html



oops sorry - should have been more specific

i meant parameters (not fields or constants). these are briefly covered
in 13.4.12. 


for example, is changing

public void foo(Bar bar) {...}

to

public void foo(final Bar bar) {...}

a binary-preserving transformation?

- robert


-
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]

[Jakarta-commons Wiki] Update of "Logging/1.1.0ReleasePlan" by DennisLundberg

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
for change notification.

The following page has been changed by DennisLundberg:
http://wiki.apache.org/jakarta-commons/Logging/1%2e1%2e0ReleasePlan

--
  
  == Bug Review ==
  
-  * Bug 31286 ''[logging] Memory leaks in JBoss due to Log``Factory cache''
-  * Bug 32618 ''[logging] Enterprise Commons Logging : Globalization & more''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=31286 31286] 
''[logging] Memory leaks in JBoss due to Log``Factory cache'' '''FIXED'''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 32618] 
''[logging] Enterprise Commons Logging : Globalization & more''
 * IBM's (through Richard) proposal which seems too much for this release.
-  * Bug 35774 ''[logging] TCCL problem in J2EE Container''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=35774 35774] 
''[logging] TCCL problem in J2EE Container''
-  * Bug 36041 ''[logging] Include class loader information when 
Log``Factory``Impl throws Log``Configuration``Exception.''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36041 36041] 
''[logging] Include class loader information when Log``Factory``Impl throws 
Log``Configuration``Exception.'' '''FIXED'''
 * Reporter has been asked if it's OK to close this issue.
-  * Bug 36062 ''[logging] extended API: getChildLogger(String)''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36062 36062] 
''[logging] extended API: getChildLogger(String)''
 * The two Joergs have said on the dev-list that they are willing to wait 
until a later release with this one.
-  * Bug 36927 ''[logging] Disabling of TCCL''
-  * Bug 37067 ''[logging] enhancement : add support for ant task logger''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36927 36927] 
''[logging] Disabling of TCCL'' '''Implemented, needs testing'''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37067 37067] 
''[logging] enhancement : add support for ant task logger''
 * Waiting for someone to create a patch.
-  * Bug 37420 ''[logging] Online JCL 1.0.4 API Javadoc missing''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37420 37420] 
''[logging] Online JCL 1.0.4 API Javadoc missing''
-* This is a website issue. Someone needs to change a link. The process of 
copying the api-docs for a previous release should be documented, if it isn't 
already.
+* This is a website issue. Someone needs to change a link. The process of 
copying the api-docs for a previous release should be documented, if it isn't 
already. '''FIXED'''
-  * Bug 37427 ''[logging] Redirect stdout and stderr to logging system''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37427 37427] 
''[logging] Redirect stdout and stderr to logging system''
-* Simon and Robert agrees that this should not go into commons logging.
+* Simon and Robert agrees that this should not go into commons logging. 
'''WONTFIX'''
-  * Bug 37484 ''[logging] call to getClassLoader() in Log``Factory``Impl not 
checked for null''
+  * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37484 37484] 
''[logging] call to getClassLoader() in Log``Factory``Impl not checked for 
null''
 * Might have been solved already.
  
  == Bug Fixes ==
@@ -46, +46 @@

   * Sort out whether we split Log4JLogger into two classes or not. If we 
choose two classes, how should we name them?
 1. Rename Log4``J12``Logger.java back to Log4JLogger.java. That would make 
the upgrade transparent for the previous use-case. But there is the chance that 
this will not work at all for a user that is currently using JCL 1.0.4 together 
with log4jalpha-something and a configuration file stating that Log4JLogger 
should be used.
 1. Users who configure JCL to use Log4JLogger might reasonably expect JCL 
to guess the log4j version and use the correct logger. so, perhaps one option 
would be to create a delegating implementation. 
- 
+1. Same as #1 but kick out Log4``J13``Logger, because Log4``J 1.3 has not 
been released.
   * Decide our jar distribution strategy (in particular, whether we ship the 
optional jar or not).
  
   * How do we give downstream packagers and users a fair view of the actual 
JCL dependencies?
@@ -56, +56 @@

   * eliminate optional jar '''DONE''' 
  
  ''sub-components don't work very well. in particular, i think too
- many users are going to get too confused by yet another jar. WeakHashMap
+ many users are going to get too confused by yet another jar. Weak``Hash``Map
  will go into the base distribution, other classes will be moved into
  contrib. perhaps another component (logging-extras) would be good or
  perhaps moving them off shore.''
@@ -75, +75 @@

  
  ''log4j 1.3 is still not released. the new JCL release cannot depend on
  unreleased code. the 1.3 implementation will be moved in

Re: [logging] MANIFEST.MF

[Simon Kitching]

On Thu, 2006-01-19 at 19:30 +0100, Boris Unckel wrote:
> Hello Simon,
> 
> please change
> /jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF
> to correct 1.1RC for the RC distribution.
> Currently it states a 1.0.5 version.

I've updated this to 1.1. Thanks for the reminder.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370635 - /jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF

[skitching]

Author: skitching
Date: Thu Jan 19 13:16:47 2006
New Revision: 370635

URL: http://svn.apache.org/viewcvs?rev=370635&view=rev
Log:
Update version to 1.1 in MANIFEST.MF

Modified:
jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF

Modified: jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF?rev=370635&r1=370634&r2=370635&view=diff
==
--- jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF (original)
+++ jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF Thu Jan 19 
13:16:47 2006
@@ -2,4 +2,4 @@
 Specification-Vendor: Apache Software Foundation
 Specification-Version: 1.0
 Implementation-Vendor: Apache Software Foundation
-Implementation-Version: 1.0.5
+Implementation-Version: 1.1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370633 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 12:59:36 2006
New Revision: 370633

URL: http://svn.apache.org/viewcvs?rev=370633&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java?rev=370633&r1=370632&r2=370633&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/Log4J13Logger.java
 Thu Jan 19 12:59:36 2006
@@ -98,7 +98,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with TRACE priority.
+ * Logs a message with org.apache.log4j.Level.TRACE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object)
  */
 public void trace(Object message) {
 getLogger().log(FQCN, Level.TRACE, message, null );
@@ -106,7 +109,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with TRACE priority.
+ * Logs a message with org.apache.log4j.Level.TRACE.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public void trace(Object message, Throwable t) {
 getLogger().log(FQCN, Level.TRACE, message, t );
@@ -114,14 +121,21 @@
 
 
 /**
- * Log a message to the Log4j Logger with DEBUG priority.
+ * Logs a message with org.apache.log4j.Level.DEBUG.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object message) {
 getLogger().log(FQCN, Level.DEBUG, message, null );
 }
 
 /**
- * Log an error to the Log4j Logger with DEBUG priority.
+ * Logs a message with org.apache.log4j.Level.DEBUG.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object message, Throwable t) {
 getLogger().log(FQCN, Level.DEBUG, message, t );
@@ -129,7 +143,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with INFO priority.
+ * Logs a message with org.apache.log4j.Level.INFO.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object message) {
 getLogger().log(FQCN, Level.INFO, message, null );
@@ -137,7 +154,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with INFO priority.
+ * Logs a message with org.apache.log4j.Level.INFO.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object message, Throwable t) {
 getLogger().log(FQCN, Level.INFO, message, t );
@@ -145,7 +166,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with WARN priority.
+ * Logs a message with org.apache.log4j.Level.WARN.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#warn(Object)
  */
 public void warn(Object message) {
 getLogger().log(FQCN, Level.WARN, message, null );
@@ -153,7 +177,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with WARN priority.
+ * Logs a message with org.apache.log4j.Level.WARN.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#warn(Object, Throwable)
  */
 public void warn(Object message, Throwable t) {
 getLogger().log(FQCN, Level.WARN, message, t );
@@ -161,7 +189,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with ERROR priority.
+ * Logs a message with org.apache.log4j.Level.ERROR.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object message) {
 getLogger().log(FQCN, Level.ERROR, message, null );
@@ -169,7 +200,11 @@
 
 
 /**
- * Log an error to the Log4j Logger with ERROR priority.
+ * Logs a message with org.apache.log4j.Level.ERROR.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object message, Throwable t) {
 getLogger().log(FQCN, Level.ERROR, message, t );
@@ -177,7 +212,10 @@
 
 
 /**
- * Log a message to the Log4j Logger with FATAL priority.
+ * Logs a message with org.apache.log4j.Level.FATAL.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Ob

Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar <[EMAIL PROTECTED]> wrote:

> On 1/19/06, Peter Costa <[EMAIL PROTECTED]> wrote:
> > I am new to the list
> 
> > and would like to get involved in
> > this project.
> 
> 
> We're always looking for help :-)
> 
> 
> > I was wondering if you could tell me
> > where to get more information SCXML other than the
> > website.  Are there any other docs out there?  I would
> > like to know what you want me to do to get started on
> > this project.
> >

Understand this Working Draft from the W3C: 
http://www.w3.org/TR/2005/WD-scxml-20050705/

Probably the most valuable thing you could do at the moment would be to give 
some scrutiny to what
Rahul has come up with and understand SCXML.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370631 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 12:50:46 2006
New Revision: 370631

URL: http://svn.apache.org/viewcvs?rev=370631&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java?rev=370631&r1=370630&r2=370631&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/LogKitLogger.java
 Thu Jan 19 12:50:46 2006
@@ -85,15 +85,22 @@
 
 
 /**
- * Log message to LogKit logger with DEBUG 
priority.
- */
+ * Logs a message with org.apache.log.Priority.DEBUG.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object)
+*/
 public void trace(Object message) {
 debug(message);
 }
 
 
 /**
- * Log error to LogKit logger with DEBUG 
priority.
+ * Logs a message with org.apache.log.Priority.DEBUG.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public void trace(Object message, Throwable t) {
 debug(message, t);
@@ -101,7 +108,10 @@
 
 
 /**
- * Log message to LogKit logger with DEBUG 
priority.
+ * Logs a message with org.apache.log.Priority.DEBUG.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public void debug(Object message) {
 if (message != null) {
@@ -111,7 +121,11 @@
 
 
 /**
- * Log error to LogKit logger with DEBUG 
priority.
+ * Logs a message with org.apache.log.Priority.DEBUG.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public void debug(Object message, Throwable t) {
 if (message != null) {
@@ -121,7 +135,10 @@
 
 
 /**
- * Log message to LogKit logger with INFO 
priority.
+ * Logs a message with org.apache.log.Priority.INFO.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public void info(Object message) {
 if (message != null) {
@@ -131,7 +148,11 @@
 
 
 /**
- * Log error to LogKit logger with INFO priority.
+ * Logs a message with org.apache.log.Priority.INFO.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public void info(Object message, Throwable t) {
 if (message != null) {
@@ -141,7 +162,10 @@
 
 
 /**
- * Log message to LogKit logger with WARN 
priority.
+ * Logs a message with org.apache.log.Priority.WARN.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#warn(Object)
  */
 public void warn(Object message) {
 if (message != null) {
@@ -151,7 +175,11 @@
 
 
 /**
- * Log error to LogKit logger with WARN priority.
+ * Logs a message with org.apache.log.Priority.WARN.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#warn(Object, Throwable)
  */
 public void warn(Object message, Throwable t) {
 if (message != null) {
@@ -161,7 +189,10 @@
 
 
 /**
- * Log message to LogKit logger with ERROR 
priority.
+ * Logs a message with org.apache.log.Priority.ERROR.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public void error(Object message) {
 if (message != null) {
@@ -171,7 +202,11 @@
 
 
 /**
- * Log error to LogKit logger with ERROR 
priority.
+ * Logs a message with org.apache.log.Priority.ERROR.
+ * 
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public void error(Object message, Throwable t) {
 if (message != null) {
@@ -181,7 +216,10 @@
 
 
 /**
- * Log message to LogKit logger with FATAL_ERROR 
priority.
+ * Logs a message with org.apache.log.Priority.FATAL_ERROR.
+ * 
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Object)
  */
 public void fatal(Object message) {
 if (message != null) {
@@ -191,7 +229,11 @@
 
 
 /**
- * Log error to LogKit logger with FATAL_ERROR 
priority.
+ * Logs a message with org.apache.log.Priority.FATAL_ERROR.
+ * 
+ * @param message to log
+

Re: [logging] log4j transition

[Dennis Lundberg]

Simon Kitching wrote:

Hi,

Given that log4j 1.3 still hasn't released, I would like to revert the
name of the log4J12Logger back to Log4JLogger for the 1.1 release, and
remove the Log4J13Logger.


+1


The name-change will break any config files that explicitly specify that
logger name. That breakage will have to occur eventually as long as the
log4j team keep to their plan of making a binary-incompatible release.
However I think we've got enough in this release without buying into
that issue too. In addition, I hate guessing the future on this; if we
release a Log4J13Logger class and then it doesn't work with the real
log4j13 that would be embarrassing.

Any objections to reverting to the old naming and removing Log4J13Logger
for now? [NB: I wrote it :-].


Anything that makes upgrading as easy as possible for JCL users is a 
good thing.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[robert burrell donkin]

On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:
> Hi robert,
> 
> See 13.4.8 final Fields and Constants at 
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html

oops sorry - should have been more specific

i meant parameters (not fields or constants). these are briefly covered
in 13.4.12. 

for example, is changing

public void foo(Bar bar) {...}

to

public void foo(final Bar bar) {...}

a binary-preserving transformation?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] ServletContextCleaner

[Dennis Lundberg]

robert burrell donkin wrote:

On Wed, 2006-01-18 at 18:01 +1300, Simon Kitching wrote:

Hi,

When I first proposed the ServletContextCleaner class be bundled with
JCL, there was some opposition. 


I was finally convinced this wasn't a good idea by one particular
argument: that it's difficult for rebundlers (eg creating .rpm packages
with the code compiled via gcj) because the servlet library may not be
compilable with the same tools. Anyway, having this class in the
documentation or on a wiki is also reasonably convenient for users.

However I now see on the wiki that this "will ship".
  http://wiki.apache.org/jakarta-commons/Logging/1.1.0ReleasePlan
Does anyone have more information about this decision?


yep - that was me trying to get some release preparations started last
month (but things got a little sidetracked...)

a couple of observations:

1 none of the current artifacts are really particularly suitable for
rebundlers
2 some downstream rebundlers incorrectly declare a dependency on the
full commons-logging and of the rest, many cut their own from the
source.

my proposal was to address rebundlers by adding a separate minimal build
into the ant file (no dependencies) and then documenting some
guidelines. if this is done then IMO there's no reason not to ship
cleaner.


NB: I'm hoping to knock JCL1.1 into releasable state over the coming
weekend and hold a vote on creating the first RC. Robert/Brian are you
out there??


out there but less active than i'd like to be on commons stuff. lots of
apache stuff blew up at the foundation level recently :-/

but if you've got some time over the next week or two, i'll make some
JCL time. one job that i'd really like to do before shipping 1.1 is to
finish a comprehensive troubleshooting guide. 


IIRC you created a best practise document on the wiki. do you know what
happened to it?

BTW dennis should have an apache account by now


Yep I'm here, with a fresh account. I have time to spare on JCL right now.

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[Boris Unckel]

Hello Robert,

robert burrell donkin wrote:
> i'm going through the patches (by hand) now. 
>
> i notice that a lot of the parameters are now declared final (which is -
> usually - good). i would have expected that this should not effect
> binary compatibility but unfortunately, i can't find anywhere in the JLS
> where this is definitely specified. i'm very reluctant to add any
> changes which risk (at all) binary compatibility issues.
>
> anyone know of a definitive reference?

First my apologies to not mention it in the patch description - I am used to
final the parameters, so I did not recognize it actively.
I cannot cite a spec or a similiar document. After your mail I just used JAD
to decompile a class again.
The final before the parameters is not part of the decompiled class.

I know that this is not a proove, but a hint.
If this is going to be a show stopper, the final should be removed.

Regards
Boris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38075] - [configuration] add new config.subsets() method to return multiple SubsetConfigurationS

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38075





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 21:35 ---
Yes, this sounds reasonable.

When working on the refactoring of the internal node structures used by
HierarchicalConfiguration I had the idea of a different Configuration class,
which is very similar to SubsetConfiguration, but more light weight.

The subset() method in HierarchicalConfiguration as it is implemented ATM is not
really efficient because it involves copying of whole sub trees. For the special
case that the subset contains only a single node (which would be the case for
this use case: a list of subset configurations, each of which represents one
configuration node), a specialized SubnodeConfiguration could be used. This
class would wrap a (sub) node of a parent configuration and would perform all of
its operations directly on this node and its children. So manipulations at the
SubnodeConfiguration or its parent would directly be visible to each other.

I will do some experiments with this idea. But whatever the outcome is, this
feature request in any case makes sense.

-- 
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: [logging] Bug 38174 and JCL 1.1

[James Carman]

Parameters are neither fields nor constants.  There's a section below that
dealing with method/constructor parameters.  It doesn't mention anything
about making them final breaking binary compatibility.  I would seriously
doubt that it does, especially since it's call by value (value of a
reference or value of a primitive).  The only code that can change the value
of the reference (not the object pointed to by the reference) is the code
inside the method (this is all moot for primitive parameters).  So, it
should be okay, I would think.

-Original Message-
From: Martin van den Bemt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 19, 2006 3:26 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] Bug 38174 and JCL 1.1

Hi robert,

See 13.4.8 final Fields and Constants at 
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html

Short answer : yes and no :)

Mvgr,
Martin

robert burrell donkin wrote:
> On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> 
>>Hello,
>>
>>Simon Kitching wrote:
>>
>NB: I'm hoping to knock JCL1.1 into releasable state over the coming
>weekend and hold a vote on creating the first RC.

Please check to put the patch in bug 38174 into RC. Even if you decide
against the logic in the new "doLog" methods, it would be nice to have 
the other cleanup (javadoc, same null behaviour for all classes).
>>>
>>>Please check my comments on that bugzilla entry.
>>>
>>
>>I have read your comments and opinions in the bugzilla entry[1].
>>As I do not want to put so much time in a more or less boring task
>>(improving the JavaDoc and care for doLog single method logic is a lot of
>>copy and correct paste) I have removed anything of the exception
behaviour.
>>I have also removed the String.valueOf when the underlying logger accepts
>>objects as message.
>>
>>Every file has single patch. With accident cause I did an format after
>>removing the exception handling - sorry for that, it will cause more diff
>>than is really different.
>>
>>Please consider again to put this into release.
> 
> 
> i'm going through the patches (by hand) now. 
> 
> i notice that a lot of the parameters are now declared final (which is -
> usually - good). i would have expected that this should not effect
> binary compatibility but unfortunately, i can't find anywhere in the JLS
> where this is definitely specified. i'm very reluctant to add any
> changes which risk (at all) binary compatibility issues.
> 
> anyone know of a definitive reference?
> 
> - robert
> 
> 
> -
> 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]

svn commit: r370618 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java

[rdonkin]

Author: rdonkin
Date: Thu Jan 19 12:32:32 2006
New Revision: 370618

URL: http://svn.apache.org/viewcvs?rev=370618&view=rev
Log:
Javadoc improvements. Contributed by Boris Unckel. Issue #38174.

Modified:

jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java

Modified: 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java?rev=370618&r1=370617&r2=370618&view=diff
==
--- 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
 (original)
+++ 
jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/impl/SimpleLog.java
 Thu Jan 19 12:32:32 2006
@@ -360,7 +360,11 @@
 
 
 /**
- *  Log a message with debug log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_DEBUG.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#debug(Object)
  */
 public final void debug(Object message) {
 
@@ -371,7 +375,12 @@
 
 
 /**
- *  Log an error with debug log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_DEBUG.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#debug(Object, Throwable)
  */
 public final void debug(Object message, Throwable t) {
 
@@ -382,7 +391,11 @@
 
 
 /**
- *  Log a message with trace log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_TRACE.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public final void trace(Object message) {
 
@@ -393,7 +406,12 @@
 
 
 /**
- *  Log an error with trace log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_TRACE.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#trace(Object, Throwable)
  */
 public final void trace(Object message, Throwable t) {
 
@@ -404,7 +422,11 @@
 
 
 /**
- *  Log a message with info log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_INFO.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#info(Object)
  */
 public final void info(Object message) {
 
@@ -415,7 +437,12 @@
 
 
 /**
- *  Log an error with info log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_INFO.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#info(Object, Throwable)
  */
 public final void info(Object message, Throwable t) {
 
@@ -426,7 +453,11 @@
 
 
 /**
- *  Log a message with warn log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_WARN.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#warn(Object)
  */
 public final void warn(Object message) {
 
@@ -437,7 +468,12 @@
 
 
 /**
- *  Log an error with warn log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_WARN.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#warn(Object, Throwable)
  */
 public final void warn(Object message, Throwable t) {
 
@@ -448,7 +484,11 @@
 
 
 /**
- *  Log a message with error log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_ERROR.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#error(Object)
  */
 public final void error(Object message) {
 
@@ -459,7 +499,12 @@
 
 
 /**
- *  Log an error with error log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_ERROR.
+ *
+ * @param message to log
+ * @param t log this cause
+ * @see org.apache.commons.logging.Log#error(Object, Throwable)
  */
 public final void error(Object message, Throwable t) {
 
@@ -470,7 +515,11 @@
 
 
 /**
- *  Log a message with fatal log level.
+ * Log a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_FATAL.
+ *
+ * @param message to log
+ * @see org.apache.commons.logging.Log#fatal(Object)
  */
 public final void fatal(Object message) {
 
@@ -481,7 +530,12 @@
 
 
 /**
- *  Log an error with fatal log level.
+ * Logs a message with 
+ * org.apache.commons.logging.impl.SimpleLog.LOG_LEVEL_FATAL.
+ *
+ * @param message to log
+ * 

RE: [logging] Bug 38174 and JCL 1.1

[James Carman]

http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html

-Original Message-
From: robert burrell donkin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 19, 2006 3:23 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] Bug 38174 and JCL 1.1

On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> Hello,
> 
> Simon Kitching wrote:
> >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> >>> weekend and hold a vote on creating the first RC.
> >> Please check to put the patch in bug 38174 into RC. Even if you decide
> >> against the logic in the new "doLog" methods, it would be nice to have 
> >> the other cleanup (javadoc, same null behaviour for all classes).
> >
> > Please check my comments on that bugzilla entry.
> >
> 
> I have read your comments and opinions in the bugzilla entry[1].
> As I do not want to put so much time in a more or less boring task
> (improving the JavaDoc and care for doLog single method logic is a lot of
> copy and correct paste) I have removed anything of the exception
behaviour.
> I have also removed the String.valueOf when the underlying logger accepts
> objects as message.
> 
> Every file has single patch. With accident cause I did an format after
> removing the exception handling - sorry for that, it will cause more diff
> than is really different.
> 
> Please consider again to put this into release.

i'm going through the patches (by hand) now. 

i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere in the JLS
where this is definitely specified. i'm very reluctant to add any
changes which risk (at all) binary compatibility issues.

anyone know of a definitive reference?

- robert


-
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: [logging] Bug 38174 and JCL 1.1

[Martin van den Bemt]

Hi robert,

See 13.4.8 final Fields and Constants at 
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html


Short answer : yes and no :)

Mvgr,
Martin

robert burrell donkin wrote:

On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:


Hello,

Simon Kitching wrote:


NB: I'm hoping to knock JCL1.1 into releasable state over the coming
weekend and hold a vote on creating the first RC.


Please check to put the patch in bug 38174 into RC. Even if you decide
against the logic in the new "doLog" methods, it would be nice to have 
the other cleanup (javadoc, same null behaviour for all classes).


Please check my comments on that bugzilla entry.



I have read your comments and opinions in the bugzilla entry[1].
As I do not want to put so much time in a more or less boring task
(improving the JavaDoc and care for doLog single method logic is a lot of
copy and correct paste) I have removed anything of the exception behaviour.
I have also removed the String.valueOf when the underlying logger accepts
objects as message.

Every file has single patch. With accident cause I did an format after
removing the exception handling - sorry for that, it will cause more diff
than is really different.

Please consider again to put this into release.



i'm going through the patches (by hand) now. 


i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere in the JLS
where this is definitely specified. i'm very reluctant to add any
changes which risk (at all) binary compatibility issues.

anyone know of a definitive reference?

- robert


-
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: [Jakarta-commons Wiki] Update of "SCXML/SCXMLFaq" by TimObrien

[Rahul Akolkar]

On 1/14/06, Apache Wiki <[EMAIL PROTECTED]> wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" 
> for change notification.
>
> The following page has been changed by TimObrien:
> http://wiki.apache.org/jakarta-commons/SCXML/SCXMLFaq
>


Tim -

Thanks for getting this going. I plan to move any questions as and
when they get answered to this page:

http://wiki.apache.org/jakarta-commons/SCXML/FrequentlyAskedQuestions

When all are answered the page you created will just point to the one
above. Trying to consolidate all Commons SCXML FAQ together.

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Bug 38174 and JCL 1.1

[robert burrell donkin]

On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> Hello,
> 
> Simon Kitching wrote:
> >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> >>> weekend and hold a vote on creating the first RC.
> >> Please check to put the patch in bug 38174 into RC. Even if you decide
> >> against the logic in the new "doLog" methods, it would be nice to have 
> >> the other cleanup (javadoc, same null behaviour for all classes).
> >
> > Please check my comments on that bugzilla entry.
> >
> 
> I have read your comments and opinions in the bugzilla entry[1].
> As I do not want to put so much time in a more or less boring task
> (improving the JavaDoc and care for doLog single method logic is a lot of
> copy and correct paste) I have removed anything of the exception behaviour.
> I have also removed the String.valueOf when the underlying logger accepts
> objects as message.
> 
> Every file has single patch. With accident cause I did an format after
> removing the exception handling - sorry for that, it will cause more diff
> than is really different.
> 
> Please consider again to put this into release.

i'm going through the patches (by hand) now. 

i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere in the JLS
where this is definitely specified. i'm very reluctant to add any
changes which risk (at all) binary compatibility issues.

anyone know of a definitive reference?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38319] - [configuration] NullPointerException when no absolute path was specified

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38319


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
Summary|NullPointerException when no|[configuration]
   |absolute path was specified |NullPointerException when no
   ||absolute path was specified




--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 21:17 ---
>From the line numbers in the stack trace you provide in your error description 
>I
assume that you use an older version of Commons Configuration. The line numbers
don't match the source files of the 1.2 version.

Could you please try again with the 1.2 release, or ensure that there is no
older version somewhere in your classpath? I remember there was an issue with
NullPointerExceptions when the file to load does not exist, but this was fixed
in 1.2.

Thanks.

-- 
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: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar]

On 1/19/06, Tim OBrien <[EMAIL PROTECTED]> wrote:
>

>
> Even if a state is associated with a context it doesn't necessary mean that 
> there needs to be a
> relationship with an actual context item.
>
> I guess this is a case of "wellwouldn't it be helpful to be able to 
> participate in that
> Working Group".  :-)
>
> The thing that I think is important for the SCXML working group to know is 
> that for some
> applications to be feasible a state machine must be efficient, not tied to 
> execution context and
> able to be shared at runtime by "possibly" thousands of instances.  Maybe 
> putting it in Voice
> terms might make it more relevant to that specific working group, if I'm 
> trying to model the state
> of ten thousand simultaneous conversations, I'd start to care whether or not 
> I'd would have to
> replicate the entire model or representation of the state machine.
>


My previous post didn't come out right, this "decoupling" is ofcourse
needed in the current implementation, which is why this thread exists
:-)

In terms of feedback to the WG, there are public mailing lists at the
W3C per WG where feedback can be posted, though I doubt they need any
convincing on this aspect. And for better participation, we should
push here on making the ASF a member as well.

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar]

On 1/19/06, Peter Costa <[EMAIL PROTECTED]> wrote:
> I am new to the list


Welcome!


> and would like to get involved in
> this project.


We're always looking for help :-)


> I was wondering if you could tell me
> where to get more information SCXML other than the
> website.  Are there any other docs out there?  I would
> like to know what you want me to do to get started on
> this project.
>


One of the challenges of being an active developer, especially with
unreleased projects, is to be able to cope with lack of documentation,
and even more valuably, to be able to help improve the documentation
along the way. To that end, it is useful to just grab the code and
increase your familiarity with it, start using it and fix things that
bother you.

You can even start by answering these questions on the wiki:

http://wiki.apache.org/jakarta-commons/SCXML/SCXMLFaq

You'll find many answers in the code and the Javadocs.

You should also get familiar (if you're not already) with creating
patches, submitting them for consideration in Bugzilla, and ofcourse,
participate in discussions on the mailing lists. Some "how things
work" links that may be useful are (depending on your experience):

http://jakarta.apache.org/site/understandingopensource.html
http://wiki.apache.org/jakarta-commons/GettingInvolved
http://jakarta.apache.org/site/cvsindex.html

For SCXML resources, we basically have:

 * http://wiki.apache.org/jakarta-commons/SCXML (wiki)

 * http://jakarta.apache.org/commons/sandbox/scxml/ (website)

 * http://svn.apache.org/viewcvs/jakarta/commons/sandbox/scxml/trunk/
(repository trunk)

 * http://www.w3.org/TR/scxml/ (specification)

The first three are actively discussed on this mailing list.

-Rahul


> Peter Costa
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38174] - [logging][PATCH] Improvements to wrapper classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38174


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 21:07 ---
Thanks for the revised patches.

I'll go through them now. 

Robert

-- 
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 35753] - [configuration] Missing useful functionality of XPath in HierarchicalConfiguration

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=35753


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 21:06 ---
The user guide was updated to cover the new features. So marking this issue as
fixed. If you encounter problems with the new classes, please file new
(specific) bug reports.

Thanks.

-- 
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: [logging] ServletContextCleaner

[robert burrell donkin]

On Thu, 2006-01-19 at 17:25 +1300, Simon Kitching wrote:
> On Wed, 2006-01-18 at 21:02 +, robert burrell donkin wrote:
> > my proposal was to address rebundlers by adding a separate minimal build
> > into the ant file (no dependencies) and then documenting some
> > guidelines. if this is done then IMO there's no reason not to ship
> > cleaner.
> 
> You mean create a commons-logging-minimal-1.1.jar, containing just the
> core stuff (LogFactory, LogFactoryImpl, Log, etc) + SimpleLog and
> NoOpLog? I guess we can do that.

+1

plus some recommendations about understanding the dependencies when
rebundling. i'll try to pull together a draft document ASAP.

> > > NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> > > weekend and hold a vote on creating the first RC. Robert/Brian are you
> > > out there??
> > 
> > out there but less active than i'd like to be on commons stuff. lots of
> > apache stuff blew up at the foundation level recently :-/
> > 
> > but if you've got some time over the next week or two, i'll make some
> > JCL time. one job that i'd really like to do before shipping 1.1 is to
> > finish a comprehensive troubleshooting guide. 
> 
> I'm between contracts at the moment and my girlfriend is away overseas.
> So I've got more time available than I've had in a while :-). This only
> lasts another 6 days though.
>
> I think we're very close to an RC state, so would like to spend some of
> that available time pushing on to that state. If you can make some time
> for this it would be great.

cool

> > BTW dennis should have an apache account by now
> 
> Sorry, which Dennis? 

Lundberg

> Perhaps you mean Brian?

IIRC the last time i heard from brian he was busy in china...

shame it took *so* long to get the account created :-/

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] Log4JLogger thread safety issue

[robert burrell donkin]

On Thu, 2006-01-19 at 17:17 +1300, Simon Kitching wrote:
> On Wed, 2006-01-18 at 22:18 +, robert burrell donkin wrote:
> > on the subject of thread safety, there is a potential issue with
> > Log4JLogger - take a look at getLogger(). i'd like a second opinion (and
> > a third and a forth, if possible) so i'll post this now before i analyse
> > it.
> > 
> > (see
> > http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200511.mbox/[EMAIL
> >  PROTECTED])
> > 
> 
> I don't think this is valid. Yes there is a race condition but it's
> harmless.



> NB: the synchronized keyword also ensures that CPU caches are correctly
> synchronized. However even taking this into account I can't see a
> situation where anything bad can happen.

i was wondering whether a logger could be partially constructed and if
so what the likely effect would be (thread A enters getLogger() and
starts the construction of the logger but is not finished before thread
B enters the method and finds logger has been assigned (so not null) but
not completed constructed.) i'm unsure whether this scenario is allowed
by the java language and virtual machine specifications. a few similarly
unintuitive ones are.

finding out the answer would probably require spending a good few hours
analysing the specifications. i'm not sure that this is a priority for
me right now (since i suspect that this would have been reported had it
been a practical scenario). any volunteers?

if this is a real problem then it could be fixed by assigning to a
temporary variable:

public Logger getLogger() {
Logger logger = this.logger;
if (logger == null) {
logger = Logger.getLogger(name);
}
this.logger = logger;
return (this.logger);
}

but it's probably best to err on the side of inertia if we aren't sure
that the issue is real...

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370588 - /jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml

[oheger]

Author: oheger
Date: Thu Jan 19 12:02:08 2006
New Revision: 370588

URL: http://svn.apache.org/viewcvs?rev=370588&view=rev
Log:
Update xml howto to cover the new expression engines

Modified:
jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml

Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml?rev=370588&r1=370587&r2=370588&view=diff
==
--- jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/howto_xml.xml Thu Jan 19 
12:02:08 2006
@@ -1,6 +1,6 @@
 
 

[logging] MANIFEST.MF

[Boris Unckel]

Hello Simon,

please change
/jakarta/commons/proper/logging/trunk/src/conf/MANIFEST.MF
to correct 1.1RC for the RC distribution.
Currently it states a 1.0.5 version.

Regards
Boris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] Bug 38174 and JCL 1.1

[Boris Unckel]

Hello,

Simon Kitching wrote:
>>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
>>> weekend and hold a vote on creating the first RC.
>> Please check to put the patch in bug 38174 into RC. Even if you decide
>> against the logic in the new "doLog" methods, it would be nice to have 
>> the other cleanup (javadoc, same null behaviour for all classes).
>
> Please check my comments on that bugzilla entry.
>

I have read your comments and opinions in the bugzilla entry[1].
As I do not want to put so much time in a more or less boring task
(improving the JavaDoc and care for doLog single method logic is a lot of
copy and correct paste) I have removed anything of the exception behaviour.
I have also removed the String.valueOf when the underlying logger accepts
objects as message.

Every file has single patch. With accident cause I did an format after
removing the exception handling - sorry for that, it will cause more diff
than is really different.

Please consider again to put this into release.

Thanks!

Regards
Boris

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=38174

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]