Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java
Folks! Thanks for caring that much and sorry for me being quiet until now as I am the guilty person. The design we are talking about actually is quite weird as it is a stub of a former implementation. There is this interface and there is *exactly* one implementation for that interface and IMHO there will be no - reasonable - further implementation at any time. Thus it is alright to extend the interface. Even if you do not agree we should at least add the additional methods to the implementation, leaving the interface untouched, breaking nothing! OK? Cheers and have a nice weekend Oliver 2007/1/11, Simon Kitching [EMAIL PROTECTED]: On Wed, 2007-01-10 at 14:12 -0500, Rahul Akolkar wrote: On 1/10/07, Joerg Heinicke [EMAIL PROTECTED] wrote: Rahul Akolkar rahul.akolkar at gmail.com writes: Generally speaking, an interface-compatible change will at most change the private interface of a component, or simply add classes, methods and attributes whose use is optional to both internal and external interface clients. And this is not. In which way is it different from simply add [..] methods [..] whose use is optional to both internal and external interface clients. ?? Even simply replacing the former jar with the next version should work as the client does not know about the new methods. Only recompilation of implementations need adaptions before but that's not what I consider a use or a client. snip/ I suspect that bit is talking about Java classes (rather than interfaces), though I haven't tried to hunt it down in the guide. I flagged what I thought would lead to a versioning discussion at 1.2 voting time. There is a section in the java specification that defines precisely what binary compatibility involves, and adding a method to an interface definitely breaks it. This is an *object oriented* library we are talking about here, so use includes implementing any public interfaces, subclassing any non-final classes and overriding any public or protected methods. Unless explicitly documented, we cannot assume that users of an open-source library restrict themselves to just calling the existing classes. If the interfaces had been explicitly documented as being not intended for user implementation then this might be ok. Or if they had been placed in a special package, as Eclipse does, to explicitly separate internal from external apis. However if neither of these have been done, then I would personally expect these APIs to be binary-compatible, *at least* without a major version number update. In the branch for digester 2.x, I explicitly indicated the binary stability expectations for the Action interface: http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java Note that this is still experimental work, and I haven't received feedback from the commons community on whether this sort of comment would be considered adequate to allow an interface change in a minor release, but IMO without an indication of this sort an API really shouldn't change (without a major release at least). Ideally, existing public interfaces should not be changed *at all*, eg by introducing a new interface rather than changing the existing one. In cases where an application uses two different libraries that both depend on a commons lib, the existence of different versions of the commons lib with the same package names but different APIs can cause major headaches. As Rahul says this situation may well draw -1 votes at release time. We all want commons projects to have a good reputation for API stability. There have been mistakes made in the past, causing a lot of negative user feedback. Yes, it can be a hassle for development. However the reason that commons is a good place to host libraries is because commons is trusted, and that's because the software development processes here are reasonably strict. Writing libraries is hard - and quite different from writing full applications (eg tomcat, ant) or frameworks. Regards, Simon - 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: [VOTE] Promote commons-site to proper and release it
+1 to both, assuming the project documentation on the main site has nothing to do with the skin, since I think we don't want that menu on the main site. Mvgr, Martin Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
+1 to both Oleg On Sat, 2007-01-13 at 02:16 +0100, Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [x] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [x] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
Just one question: I noticed that the links to the Cobertura report open an empty site for some components (did not check all). Is there a problem? (I am asking because I had some trouble when playing with the maven 2 cobertura plug-in a while ago.) Otherwise I am +1 for both. Oliver Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
Martin van den Bemt wrote: +1 to both, assuming the project documentation on the main site has nothing to do with the skin, since I think we don't want that menu on the main site. The skin is only about looks. It couldn't care less about the content ;) I'll start a thread about menus, links and content shortly. Mvgr, Martin Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - 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: [VOTE] Promote commons-site to proper and release it
Oliver Heger wrote: Just one question: I noticed that the links to the Cobertura report open an empty site for some components (did not check all). Is there a problem? (I am asking because I had some trouble when playing with the maven 2 cobertura plug-in a while ago.) There are 2 things that can cause this: 1. It's a multi module build. Cobertura does not support aggregated reports yet, so components like jci will not get any report on the top level. 2. The tests for some sandbox components will not run in Surefire out of the box, so I have disabled the tests in some of them. This leads to no tests for Cobertura to check. The problems are usually class loader related. But, this has nothing to do with the skin itself. This has to do with the build and the reports, which I will start a another discussion about. Otherwise I am +1 for both. Oliver Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - 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: [VOTE] Promote commons-site to proper and release it
+1/+1 :) Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r495918 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/ java/org/apache/commons/configuration/event/ test/org/apache/commons/configuration/even
Author: oheger
Date: Sat Jan 13 08:33:02 2007
New Revision: 495918
URL: http://svn.apache.org/viewvc?view=revrev=495918
Log:
CONFIGURATION-245: Added support for ConfigurationErrorListeners to EventSource
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/event/TestEventSource.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java?view=diffrev=495918r1=495917r2=495918
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
Sat Jan 13 08:33:02 2007
@@ -168,7 +168,6 @@
{
BaseConfiguration copy = (BaseConfiguration) super.clone();
copy.store = (Map) ConfigurationUtils.clone(store);
-copy.clearConfigurationListeners();
return copy;
}
catch (CloneNotSupportedException cex)
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java?view=diffrev=495918r1=495917r2=495918
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
Sat Jan 13 08:33:02 2007
@@ -699,7 +699,6 @@
CloneVisitor v = new CloneVisitor();
getRootNode().visit(v);
copy.setRootNode(v.getClone());
-copy.clearConfigurationListeners();
return copy;
}
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java?view=diffrev=495918r1=495917r2=495918
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
Sat Jan 13 08:33:02 2007
@@ -50,8 +50,17 @@
* events will be received. Note that the number of received detail events may
* differ for different configuration implementations.
* code[EMAIL PROTECTED]
org.apache.commons.configuration.HierarchicalConfiguration
HierarchicalConfiguration}/code
- * for instance has a custom implementation of codesetProperty()/code,
which
- * does not generate any detail events.
+ * for instance has a custom implementation of codesetProperty()/code,
+ * which does not generate any detail events.
+ * /p
+ * p
+ * In addition to quot;normalquot; events, error events are supported. Such
+ * events signal an internal problem that occurred during access of properties.
+ * For them a special listener interface exists:
+ * code[EMAIL PROTECTED] ConfigurationErrorListener}/code. There is
another set of
+ * methods dealing with event listeners of this type. The
+ * codefireError()/code method can be used by derived classes to send
+ * notifications about errors to registered observers.
* /p
*
* @author a
@@ -65,6 +74,9 @@
/** A collection for the registered event listeners. */
private Collection listeners;
+/** A collection for the registered error listeners.*/
+private Collection errorListeners;
+
/** A counter for the detail events. */
private int detailEvents;
@@ -73,7 +85,7 @@
*/
public EventSource()
{
-clearConfigurationListeners();
+initListeners();
}
/**
@@ -83,14 +95,7 @@
*/
public void addConfigurationListener(ConfigurationListener l)
{
-if (l == null)
-{
-throw new IllegalArgumentException(Listener must not be null!);
-}
-synchronized (listeners)
-{
-listeners.add(l);
-}
+
svn commit: r495926 - in /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event: ConfigurationErrorEvent.java ConfigurationErrorListener.java
Author: oheger
Date: Sat Jan 13 09:06:29 2007
New Revision: 495926
URL: http://svn.apache.org/viewvc?view=revrev=495926
Log:
CONFIGURATION-245: New event and listener classes for configuration errors
Added:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorEvent.java
(with props)
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorListener.java
(with props)
Added:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorEvent.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorEvent.java?view=autorev=495926
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorEvent.java
(added)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/ConfigurationErrorEvent.java
Sat Jan 13 09:06:29 2007
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You 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.configuration.event;
+
+/**
+ * p
+ * An event class that is used for reporting errors that occurred while
+ * processing configuration properties.
+ * /p
+ * p
+ * Some configuration implementations (e.g.
+ * code[EMAIL PROTECTED]
org.apache.commons.configuration.DatabaseConfiguration}/code
+ * or code[EMAIL PROTECTED]
org.apache.commons.configuration.JNDIConfiguration}/code
+ * use an underlying storage that can throw an exception on each property
+ * access. In earlier versions of this library such exceptions were logged and
+ * then silently ignored. This makes it impossible for a client to find out
that
+ * something went wrong.
+ * /p
+ * p
+ * To give clients better control over the handling of errors that occur during
+ * access of a configuration object a new event listener mechanism specific for
+ * exceptions is introduced: Clients can register itself at a configuration
+ * object as an emerror listener/em and are then notified about all
+ * internal errors related to the source configuration object.
+ * /p
+ * p
+ * By inheriting from codeConfigurationEvent/code this event class
+ * supports all properties that describe an operation on a configuration
+ * instance. In addition a codeThrowable/code object is available
+ * representing the occurred error. The event's type determines the operation
+ * that caused the error. Note that depending on the event type and the
occurred
+ * exception not all of the other properties (e.g. name of the affected
property
+ * or its value) may be available.
+ * /p
+ *
+ * @author a
+ *
href=http://jakarta.apache.org/commons/configuration/team-list.html;Commons
+ * Configuration team/a
+ * @version $Id$
+ * @since 1.4
+ * @see ConfigurationEvent
+ */
+public class ConfigurationErrorEvent extends ConfigurationEvent
+{
+/**
+ * The serial version UID.
+ */
+private static final long serialVersionUID = -7433184493062648409L;
+
+/** Stores the exception that caused this event. */
+private Throwable cause;
+
+/**
+ * Creates a new instance of codeConfigurationErrorEvent/code and
+ * initializes it.
+ *
+ * @param source the event source
+ * @param type the event's type
+ * @param propertyName the name of the affected property
+ * @param propertyValue the value of the affected property
+ * @param cause the exception object that caused this event
+ */
+public ConfigurationErrorEvent(Object source, int type,
+String propertyName, Object propertyValue, Throwable cause)
+{
+super(source, type, propertyName, propertyValue, true);
+this.cause = cause;
+}
+
+/**
+ * Returns the cause of this error event. This is the
codeThrowable/code
+ * object that caused this event to be fired.
+ *
+ * @return the cause of this error event
+ */
+public Throwable getCause()
+{
+return cause;
+}
+}
Propchange:
[jira] Commented: (CONFIGURATION-215) Using relative URLs
[
https://issues.apache.org/jira/browse/CONFIGURATION-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464489
]
Michiel Kalkman commented on CONFIGURATION-215:
---
My apologies for not reacting sooner. This item did get less relevant for me
and it escaped from my todo list somehow.
However, I think the item could pop up again in the (near) future, so the item
might get relevant for me again.
The solution you suggest definitely seems okay to me - it would resolve the
original issue I had.
Using relative URLs
---
Key: CONFIGURATION-215
URL: https://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Issue Type: Improvement
Reporter: Michiel Kalkman
Priority: Minor
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] additions
Matt Benson wrote: What's the current status of collections? It needs to be broken into smaller pieces before any more weight can be added? Yes, I believe thats a good approach. And the Java 5 branch needs finshing. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
For help!
Hello,every one.I'm a graduate studying Automation in China. Now I'm trying to find out how to interpete an execute a xml script and wish to borrow ideas from jelly.I want to understand how jelly interprte the xml script and execute.I have read some of the codes. Now I have some qustions: Is there any design documents for jelly?Where could I get? Is it neccessary before executing? What's the rough progress of the excuting? What's the diffrence between them? Thanks for any hints to above. Best regards! ___ 抢注雅虎免费邮箱-3.5G容量，20M附件！ http://cn.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r495952 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ src/test/org/apache/commons/configuration/ xdocs/
Author: oheger
Date: Sat Jan 13 11:37:34 2007
New Revision: 495952
URL: http://svn.apache.org/viewvc?view=revrev=495952
Log:
AbstractConfiguration now supports setting a specific logger for a
configuration instance. Derived classes were updated to use this logger. This
update is related to CONFIGURATION-3
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/JNDIConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diffrev=495952r1=495951r2=495952
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Sat Jan 13 11:37:34 2007
@@ -32,6 +32,8 @@
import org.apache.commons.lang.BooleanUtils;
import org.apache.commons.lang.text.StrLookup;
import org.apache.commons.lang.text.StrSubstitutor;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.impl.NoOpLog;
/**
* pAbstract configuration class. Provides basic functionality but does not
@@ -113,6 +115,17 @@
/** Stores a reference to the object that handles variable interpolation.*/
private StrSubstitutor substitutor;
+/** Stores the logger.*/
+private Log log;
+
+/**
+ * Creates a new instance of codeAbstractConfiguration/code.
+ */
+protected AbstractConfiguration()
+{
+setLogger(null);
+}
+
/**
* For configurations extending AbstractConfiguration, allow them to change
* the listDelimiter from the default comma (,). This value will be used
@@ -292,6 +305,32 @@
}
});
return interpol;
+}
+
+/**
+ * Returns the logger used by this configuration object.
+ *
+ * @return the logger
+ * @since 1.4
+ */
+public Log getLogger()
+{
+return log;
+}
+
+/**
+ * Allows to set the logger to be used by this configuration object. This
+ * method makes it possible for clients to exactly control logging
behavior.
+ * Per default a logger is set that will ignore all log messages. Derived
+ * classes that want to enable logging should call this method during their
+ * initialization with the logger to be used.
+ *
+ * @param log the new logger
+ * @since 1.4
+ */
+public void setLogger(Log log)
+{
+this.log = (log != null) ? log : new NoOpLog();
}
/**
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java?view=diffrev=495952r1=495951r2=495952
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
Sat Jan 13 11:37:34 2007
@@ -34,7 +34,6 @@
import org.apache.commons.configuration.reloading.InvariantReloadingStrategy;
import org.apache.commons.configuration.reloading.ReloadingStrategy;
import org.apache.commons.lang.StringUtils;
-import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
@@ -95,9 +94,6 @@
/** Holds a reference to the reloading strategy.*/
protected ReloadingStrategy strategy;
-/** The logger.*/
-private Log log = LogFactory.getLog(getClass());
-
/** A lock object for protecting reload operations.*/
private Object reloadLock = new Object();
@@ -118,6 +114,7 @@
public AbstractFileConfiguration()
{
initReloadingStrategy();
+setLogger(LogFactory.getLog(getClass()));
}
/**
@@ -304,7 +301,7 @@
}
catch (IOException e)
{
-log.warn(Could not close input stream, e);
+
svn commit: r496002 - in /jakarta/commons/proper/logging/trunk: pom.xml src/assembly/ src/assembly/assembly.xml
Author: dennisl Date: Sat Jan 13 15:35:57 2007 New Revision: 496002 URL: http://svn.apache.org/viewvc?view=revrev=496002 Log: Add a combined source and binary assembly. It differs from the one produced by Ant in these areas: - the docs folder is called site - the complete src/ directory is included, not just src/java/ - all files necessary to build the product using Ant, Maven 1 and Maven 2 are included - the *-ide.zip file is not created or included Added: jakarta/commons/proper/logging/trunk/src/assembly/ jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml (with props) Modified: jakarta/commons/proper/logging/trunk/pom.xml Modified: jakarta/commons/proper/logging/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/pom.xml?view=diffrev=496002r1=496001r2=496002 == --- jakarta/commons/proper/logging/trunk/pom.xml (original) +++ jakarta/commons/proper/logging/trunk/pom.xml Sat Jan 13 15:35:57 2007 @@ -304,11 +304,12 @@ plugin artifactIdmaven-assembly-plugin/artifactId -!-- configuration - descriptorsrc/maven/assembly/bin-distro.xml/descriptor + descriptors +descriptorsrc/assembly/assembly.xml/descriptor + /descriptors + tarLongFileModegnu/tarLongFileMode /configuration --- /plugin /plugins Added: jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml?view=autorev=496002 == --- jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml (added) +++ jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml Sat Jan 13 15:35:57 2007 @@ -0,0 +1,54 @@ +?xml version=1.0? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You 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. +-- + +assembly + id/id + formats +formattar.gz/format +formatzip/format + /formats + !-- The generated documentation -- + includeSiteDirectorytrue/includeSiteDirectory + fileSets +fileSet + includes +includebuild.properties.sample/include +includebuild.xml/include +includecheckstyle.xml/include +includelicense-header.txt/include +includeLICENSE.txt/include +includemaven.xml/include +includeNOTICE.txt/include +includeproject.properties/include +includeproject.xml/include +includepom.xml/include +includeRELEASE-NOTES.txt/include +!-- The source -- +includesrc//include + /includes +/fileSet +!-- All the jar files -- +fileSet + directorytarget/directory + outputDirectory/outputDirectory + includes +include*.jar/include + /includes +/fileSet + /fileSets +/assembly Propchange: jakarta/commons/proper/logging/trunk/src/assembly/assembly.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
