RE: [VOTE] Lang 2.3 RC1

2007-02-02 Thread Jörg Schaible
Hi Hen,

Henri Yandell wrote on Thursday, February 01, 2007 9:33 PM:

[snip]

 Minor: I understand that the proposal is a historical document, but
 it claims that c-lang is build on top of JDK 1.2 ... that might be
 confusing. 
 
 What do people think - update PROPOSALs or delete them?

IMHO update is better (maybe with a special remark for the updated parts). What 
I like in the proposal is that is explains the focus of the library.

- Jörg

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



Re: [VOTE] Lang 2.3 RC1

2007-02-02 Thread Niall Pemberton

On 2/1/07, Henri Yandell [EMAIL PROTECTED] wrote:

Might have to stop the vote anyway as it looks like the refactoring to
Entities.java undid an optimisation issue.

On 2/1/07, Jörg Schaible [EMAIL PROTECTED] wrote:
 Correction: Tests did *not* run:
 Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest):
 FAILED
 It's the part of the fixture that tests the JDK ... maybe this should not be
 asserted and better be replaced by a simple sysout? In the end you cannot
 know what was changed/fixed by Sun in which JDK version (and if the
 assumption is valid for other JDKs) and it does not make sense to rely our
 tests on such a behavior.

How depressing. Yeah I think the best thing to do here is to test and
then print a WARNING rather than having JUnit fail.

 Jörg Schaible wrote:

  +1
 
  Rebuild from the src package with Sun JDK 5 under Linux.
 
  Minor: I understand that the proposal is a historical document, but it
  claims that c-lang is build on top of JDK 1.2 ... that might be confusing.

What do people think - update PROPOSALs or delete them?


Neither - leave it unchanged. It is historical and I think it is
obvious it is, many (most?) components have them and I've never seen
it raised as a cause for confusion.

Niall


Hen


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



[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file

2007-02-02 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469731
 ] 

Oliver Heger commented on CONFIGURATION-252:


Wouldn't it make sense if getFile() always checked whether the passed in 
fileName is an absolute file, no matter of the protocol? If this is the case, 
this file must be returned.

 Detection of absolute fileNames when configuration sources are defined in a 
 JAR file
 

 Key: CONFIGURATION-252
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Linux
Reporter: Heiko Seebach
 Attachments: support-for-jar-protocol.patch.txt


 When using several configuration sources, the sources are defined in a an xml 
 attribute like 
 fileName=usergui.properties
 The method org.apache.commons.configuration.ConfigurationUtils.getFile(String 
 basePath, String fileName) converts the basePath and fileName into a File.
 The JavaDoc says: The parameter strings can be relative files, absolute 
 files and URLs as well.
 The file containing the definition of the configuration sources will become 
 the basePath of this method.
 After a log of debugging I found, that if the basePath start with jar: the 
 method assumes that the fileName is relative, evene if it's absolute. This 
 happens, because there's a ProtocolHandler for Jar files and jar: is a 
 valid protocol. So the statement new URL(new URL(basePath), fileName) 
 doesn't throw a MalformedUrlException.
 Since the URL is valid, it's never checked, if the fileName may be absolute. 
 Attention: this is only the case on Unix/Linux, since this is a valid URL
 jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties
 while under Windows, a MalformedUrlException will be thrown, when the 
 fileName is absolute: 
 jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties
 I attached a patch that checks, whether the URL protocol is jar and the 
 fileName is absolute. If so, the absolute file will be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



DO NOT REPLY [Bug 14520] - empty host header with ip address

2007-02-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=14520.
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=14520


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-02-02 05:26 ---
*** Bug 41519 has been marked as a duplicate of this bug. ***

-- 
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: [VOTE] Lang 2.3 RC1

2007-02-02 Thread Rahul Akolkar

On 2/2/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 2/1/07, Henri Yandell [EMAIL PROTECTED] wrote:

snip/


 What do people think - update PROPOSALs or delete them?

Neither - leave it unchanged. It is historical and I think it is
obvious it is, many (most?) components have them and I've never seen
it raised as a cause for confusion.


snap/

Archival is good, I read proposals. But from trunk. One way to avoid
potential confusion is to not make it part of the distros, if indeed
it is added there.

-Rahul



Niall

 Hen



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



[Jakarta-commons Wiki] Update of Chain by JohnMunsch

2007-02-02 Thread 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 JohnMunsch:
http://wiki.apache.org/jakarta-commons/Chain

--
  The Gang of Four's Chain of Responsibility (COR) behavioral design pattern is 
interesting and commonly used to model a set of operations. Each operation 
needs to be modeled as a command object and linked to others to form a chain. 
The command objects act upon some data and indicate whether the control should 
get passed to the next command in the chain. The benefit is that an operation 
can be added or removed easily without changing code. The complete article can 
be found here http://www.devx.com/Java/Article/29392/0/page/4
  
+ A fairly comprehensive pair of articles which focus __only__ on the Commons 
Chain is at O'Reilly's OnJava site:
+ [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html ONJava.com 
-- A Look at Commons Chain, Part 1]
+ [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html ONJava.com 
-- A Look at Commons Chain, Part 2]
+ 

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



[Jakarta-commons Wiki] Trivial Update of Chain by JohnMunsch

2007-02-02 Thread 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 JohnMunsch:
http://wiki.apache.org/jakarta-commons/Chain

--
  The Gang of Four's Chain of Responsibility (COR) behavioral design pattern is 
interesting and commonly used to model a set of operations. Each operation 
needs to be modeled as a command object and linked to others to form a chain. 
The command objects act upon some data and indicate whether the control should 
get passed to the next command in the chain. The benefit is that an operation 
can be added or removed easily without changing code. The complete article can 
be found here http://www.devx.com/Java/Article/29392/0/page/4
  
- A fairly comprehensive pair of articles which focus __only__ on the Commons 
Chain is at O'Reilly's OnJava site:
+ A fairly comprehensive pair of articles which focus __only__ on the Commons 
Chain are at O'Reilly's OnJava site:
- [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html ONJava.com 
-- A Look at Commons Chain, Part 1]
+  * [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html 
ONJava.com -- A Look at Commons Chain, Part 1]
- [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html ONJava.com 
-- A Look at Commons Chain, Part 2]
+  * [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html 
ONJava.com -- A Look at Commons Chain, Part 2]
  

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



svn commit: r502647 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java

2007-02-02 Thread rolandw
Author: rolandw
Date: Fri Feb  2 08:22:54 2007
New Revision: 502647

URL: http://svn.apache.org/viewvc?view=revrev=502647
Log:
JavaDoc fix

Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java?view=diffrev=502647r1=502646r2=502647
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/multipart/MultipartRequestEntity.java
 Fri Feb  2 08:22:54 2007
@@ -58,7 +58,7 @@
  * pThis entity is designed to be used in conjunction with the 
  * [EMAIL PROTECTED] org.apache.commons.httpclient.methods.PostMethod post 
method} to provide
  * multipart posts.  Example usage:/p
- * code
+ * pre
  *  File f = new File(/path/fileToUpload.txt);
  *  PostMethod filePost = new PostMethod(http://host/some_path;);
  *  Part[] parts = {
@@ -70,7 +70,7 @@
  *  );
  *  HttpClient client = new HttpClient();
  *  int status = client.executeMethod(filePost);
- * /code
+ * /pre
  * 
  * @since 3.0
  */



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



[Jakarta-commons Wiki] Update of Chain by JohnMunsch

2007-02-02 Thread 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 JohnMunsch:
http://wiki.apache.org/jakarta-commons/Chain

--
- The Gang of Four's Chain of Responsibility (COR) behavioral design pattern is 
interesting and commonly used to model a set of operations. Each operation 
needs to be modeled as a command object and linked to others to form a chain. 
The command objects act upon some data and indicate whether the control should 
get passed to the next command in the chain. The benefit is that an operation 
can be added or removed easily without changing code. The complete article can 
be found here http://www.devx.com/Java/Article/29392/0/page/4
+ The Gang of Four's Chain of Responsibility (COR) behavioral design pattern is 
interesting and commonly used to model a set of operations. Each operation 
needs to be modeled as a command object and linked to others to form a chain. 
The command objects act upon some data and indicate whether the control should 
get passed to the next command in the chain. The benefit is that an operation 
can be added or removed easily without changing code. Jakarta Commons Chain 
models this design pattern as a reusable library. 
+ 
+ You only need to provide individual objects which implement the Command 
interface and which make use of a Context object passed to each command in 
order to access shared data between commands. You can use a XML file to 
describe sequences of commands (i.e. a Chain) and assign them a name in order 
to invoke them easily or use them as individual commands within other chains.
+ 
+ Note: Chain is not a full workflow system. It does not have sophisticated 
flow of control between branches of chains or looping. However, it is also 
easier to get started with than most workflow systems and you can easily 
refactor existing code to fit within it. Editing the XML file to change the 
sequence of commands or alter the parameters passed to a command is also well 
within the realm of what many end users can do themselves without minimal 
instruction.
+ 
+ A Devx article with a simple one page overview of Chain is available here:
+  * http://www.devx.com/Java/Article/29392/0/page/4
  
  A fairly comprehensive pair of articles which focus __only__ on the Commons 
Chain are at O'Reilly's OnJava site:
   * [http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html 
ONJava.com -- A Look at Commons Chain, Part 1]

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



[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file

2007-02-02 Thread Heiko Seebach (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469791
 ] 

Heiko Seebach commented on CONFIGURATION-252:
-

Well, how to determine if a file is absolute?
Since it even depends on the OS, it's not that easy.

Scenario:
basePath=http://aconfigserver/configSources/config.xml
and 
fileName=/configSources/config.properties

What could be the intention of it and what would others think, if they see it 
defined like that?

The properties files could reside at
http://aconfigserver/configSources/config.properties
or
http://aconfigserver/configSources/configSources/config.properties
or
file:///configSources/config.properties

I think, a good definition of the meaning and interpretation of the fileName 
(regarding the File.isAbsolute() concern) would help.

Maybe defining something simple like the definition before plus
- If fileName starts with / it's always interpreted as absolute. -
would help?


 Detection of absolute fileNames when configuration sources are defined in a 
 JAR file
 

 Key: CONFIGURATION-252
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Linux
Reporter: Heiko Seebach
 Attachments: support-for-jar-protocol.patch.txt


 When using several configuration sources, the sources are defined in a an xml 
 attribute like 
 fileName=usergui.properties
 The method org.apache.commons.configuration.ConfigurationUtils.getFile(String 
 basePath, String fileName) converts the basePath and fileName into a File.
 The JavaDoc says: The parameter strings can be relative files, absolute 
 files and URLs as well.
 The file containing the definition of the configuration sources will become 
 the basePath of this method.
 After a log of debugging I found, that if the basePath start with jar: the 
 method assumes that the fileName is relative, evene if it's absolute. This 
 happens, because there's a ProtocolHandler for Jar files and jar: is a 
 valid protocol. So the statement new URL(new URL(basePath), fileName) 
 doesn't throw a MalformedUrlException.
 Since the URL is valid, it's never checked, if the fileName may be absolute. 
 Attention: this is only the case on Unix/Linux, since this is a valid URL
 jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties
 while under Windows, a MalformedUrlException will be thrown, when the 
 fileName is absolute: 
 jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties
 I attached a patch that checks, whether the URL protocol is jar and the 
 fileName is absolute. If so, the absolute file will be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



Re: [net] Latest 2.0 RC Ready

2007-02-02 Thread Jörg Schaible
Rory Winston wrote:

 Hi Jörg
 
 Thanks for the info about the Maven repo - I'm a bit confused with this
 one however, as when I leave out the snapshot repo that I have defined,
 it cant find the Maven changes plugin. Possibly I need to define a
 different repo? I'll need to check.

For the release you may not even use the SNAPSHOT parent. Keep in mind, that
the release plugin will ensure, that you do not!

 As far as docs are concerned, [net] 
 has never been too docs-heavy, but they were never really needed - usage
 is relatively basic. However, it may be a good idea to add a getting
 started page or such to the docs/site.

Yeah. Definitely.

- Jörg


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



[jira] Created: (IO-111) FileSystemUtils.freeDiskSpaceUnix does not work if df is not in the shell path

2007-02-02 Thread Xavier Soudan (JIRA)
FileSystemUtils.freeDiskSpaceUnix does not work if df is not in the shell path
--

 Key: IO-111
 URL: https://issues.apache.org/jira/browse/IO-111
 Project: Commons IO
  Issue Type: Bug
Affects Versions: 1.3, 1.2
 Environment: Solaris
Reporter: Xavier Soudan
Priority: Minor


if the df command is not in the path, the method freeSpaceUnix throws an 
exception:

java.io.IOException: df: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.init(UNIXProcess.java:53)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at java.lang.Runtime.exec(Runtime.java:464)
at 
org.apache.commons.io.FileSystemUtils.openProcessStream(FileSystemUtils.java:357)
at 
org.apache.commons.io.FileSystemUtils.freeSpaceUnix(FileSystemUtils.java:298)

Rather than expecting df is in the path, it should be searched in the following 
standard location:
/usr/bin/df
/usr/sbin/df
/bin/df
/sbin/df
/usr/ucb/df
/usr/xpg4/bin/df



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file

2007-02-02 Thread Oliver Heger (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469842
 ] 

Oliver Heger commented on CONFIGURATION-252:


So, would it be okay to always check for an absolute file name first (by using 
File.isAbsolute()) and pointing this out in the Javadoc of getFile()?

 Detection of absolute fileNames when configuration sources are defined in a 
 JAR file
 

 Key: CONFIGURATION-252
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Linux
Reporter: Heiko Seebach
 Attachments: support-for-jar-protocol.patch.txt


 When using several configuration sources, the sources are defined in a an xml 
 attribute like 
 fileName=usergui.properties
 The method org.apache.commons.configuration.ConfigurationUtils.getFile(String 
 basePath, String fileName) converts the basePath and fileName into a File.
 The JavaDoc says: The parameter strings can be relative files, absolute 
 files and URLs as well.
 The file containing the definition of the configuration sources will become 
 the basePath of this method.
 After a log of debugging I found, that if the basePath start with jar: the 
 method assumes that the fileName is relative, evene if it's absolute. This 
 happens, because there's a ProtocolHandler for Jar files and jar: is a 
 valid protocol. So the statement new URL(new URL(basePath), fileName) 
 doesn't throw a MalformedUrlException.
 Since the URL is valid, it's never checked, if the fileName may be absolute. 
 Attention: this is only the case on Unix/Linux, since this is a valid URL
 jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties
 while under Windows, a MalformedUrlException will be thrown, when the 
 fileName is absolute: 
 jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties
 I attached a patch that checks, whether the URL protocol is jar and the 
 fileName is absolute. If so, the absolute file will be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Resolved: (CONFIGURATION-181) [configuration] Conditional directives in property files

2007-02-02 Thread Oliver Heger (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-181.


   Resolution: Won't Fix
Fix Version/s: 1.4

This issue has been hanging around for a long time now. Committers seem to 
agree that the proposed addition should not be added to Commons Configuration, 
so I am closing this ticket as wont' fix.

 [configuration] Conditional directives in property files
 

 Key: CONFIGURATION-181
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-181
 Project: Commons Configuration
  Issue Type: Improvement
 Environment: Operating System: other
 Platform: Other
Reporter: Bogdan Calmac
Priority: Minor
 Fix For: 1.4

 Attachments: conditional_properties.patch


 This patch adds conditional directives to property files similar to C macros:
 %if, %elseif, %else, %end. 
 To illustrate the necessity and the syntax I will take as example a section of
 my hibernate configuration file. Switching between databases normally requires
 to comment/uncomment a lot of properties, and more importantly, cannot be done
 automatically at runtime.
 ## JNDI Datasource
 #hibernate.connection.datasource = jdbc/test
 #hibernate.connection.username = db2
 #hibernate.connection.password = db2
 ## HypersonicSQL
 hibernate.dialect = net.sf.hibernate.dialect.HSQLDialect
 hibernate.connection.driver_class = org.hsqldb.jdbcDriver
 hibernate.connection.username = sa
 hibernate.connection.url = jdbc:hsqldb:hsql://localhost
 ## PostgreSQL
 #hibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect
 #hibernate.connection.driver_class = org.postgresql.Driver
 #hibernate.connection.url = jdbc:postgresql:template1
 #hibernate.connection.username = pg
 #hibernate.connection.password
 ## JTA transactions
 #hibernate.transaction.factory_class =
 net.sf.hibernate.transaction.JTATransactionFactory
 #jta.UserTransaction = jta/usertransaction
 #jta.UserTransaction = javax.transaction.UserTransaction
 #jta.UserTransaction = UserTransaction
 ## JDBC transactions
 hibernate.transaction.factory_class =
 net.sf.hibernate.transaction.JDBCTransactionFactory
 Here is now how it would look like with conditional directives. The only thing
 to change now is the property at the top of the file (which could be defined 
 as
 a system property if you don't want to touch the file at all). Note that it 
 uses
 nested directives.
 db = jndi
 %if db = jndi 
 ## JNDI Datasource
 hibernate.connection.datasource = jdbc/test
 hibernate.connection.username = db2
 hibernate.connection.password = db2
 ## JTA transactions
 hibernate.transaction.factory_class =
 net.sf.hibernate.transaction.JTATransactionFactory
 jta.UserTransaction = jta/usertransaction
 jta.UserTransaction = javax.transaction.UserTransaction
 jta.UserTransaction = UserTransaction
 %else
 ## JDBC transactions
 hibernate.transaction.factory_class =
 net.sf.hibernate.transaction.JDBCTransactionFactory
 %if db = hypersonic
 ## HypersonicSQL
 hibernate.dialect = net.sf.hibernate.dialect.HSQLDialect
 hibernate.connection.driver_class = org.hsqldb.jdbcDriver
 hibernate.connection.username = sa
 hibernate.connection.url = jdbc:hsqldb:hsql://localhost
 %elseif db = postgres
 ## PostgreSQL
 hibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect
 hibernate.connection.driver_class = org.postgresql.Driver
 hibernate.connection.url = jdbc:postgresql:template1
 hibernate.connection.username = pg
 hibernate.connection.password
 %end
 %end
 The directives used are:
 %if condition
 %elseif condition
 %else
 %end 
 The condition can be:
 property (true if the property is defined)
 property = value (values are interpolated)
 property != value
 For the implementation, I've replaced in PropertiesConfiguration.java the call
 to read a line from the file with  a new getNextLine() method which processes
 the conditional directives and returns the next property line. The method is
 noop unless the line starts with '%', so it should work just fine with files
 that do not use the directives.
 I've also added the TestPropertiesConfiguration.testConditionalDirectives() 
 unit
 test which uses properties added at the end of test.properties.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



[jira] Resolved: (CONFIGURATION-196) [configuration] Tools for code generation of configuration properties

2007-02-02 Thread Oliver Heger (JIRA)

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-196.


   Resolution: Won't Fix
Fix Version/s: 1.4

I am still on the opinion that this suggestion is out of scope for Commons 
Configuration. No other committer chimed in, so I am closing this ticket as 
won't fix.

If you are still interested in this topic, maybe you can start a project 
elsewhere (e.g. sourceforge) that builds upon Commons Configuration. In any 
case thanks for your interest.

 [configuration] Tools for code generation of configuration properties
 -

 Key: CONFIGURATION-196
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-196
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: Operating System: other
 Platform: Other
Reporter: David Leal
Priority: Minor
 Fix For: 1.4


 I would like to just suggest a kind of code generation from a defined 
 properties/xml file, so the user can avoid the use of string representing the 
 properties on whole source code. For example if I have the following property:
 ftpServer.login = anonymous
 in order to get the value of such property, instead of:
 getProperty(ftpServer.login);
 to have an equivalente class representation, like this:
 getFtpServer().getLogin();
 or just:
 ftpServer().getLogin();
 with this solution, you avoid miss-spelling of the property name (for 
 example: 
 instead of ftpServer.loging, ftpserver.login), because you will get a 
 compiler error.
 in order to get this target we need a kind of code generation of the 
 corresponding classes. Like any other generation tools it should be a mapping 
 file for configuring the way the properties/subproperties/nodes could be 
 mapped, for example tomorrows I would like to map: ftpServer.login to getServe
 ().getLogin(). With the default configuration the mapping will be the same.
 It could be just and ant-taks for doing this, probably with velocity would be 
 easy to implement.
 Thanks in advance,
 David Leal
 [EMAIL PROTECTED]
 (If you want I could colaborate)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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



svn commit: r502705 - in /jakarta/commons/proper/configuration/trunk: ./ src/test/org/apache/commons/configuration/ src/test/org/apache/commons/configuration/tree/xpath/

2007-02-02 Thread oheger
Author: oheger
Date: Fri Feb  2 11:55:37 2007
New Revision: 502705

URL: http://svn.apache.org/viewvc?view=revrev=502705
Log:
Make unit tests running under maven 2

Added:

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/AbstractXPathTest.java
  - copied, changed from r492941, 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/XPathTest.java
Removed:

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/XPathTest.java
Modified:
jakarta/commons/proper/configuration/trunk/build.xml
jakarta/commons/proper/configuration/trunk/project.xml

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/TestConfigurationIteratorAttributes.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/TestConfigurationNodeIteratorChildren.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/TestConfigurationNodePointer.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/TestConfigurationNodePointerFactory.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/TestXPathExpressionEngine.java

Modified: jakarta/commons/proper/configuration/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/build.xml?view=diffrev=502705r1=502704r2=502705
==
--- jakarta/commons/proper/configuration/trunk/build.xml (original)
+++ jakarta/commons/proper/configuration/trunk/build.xml Fri Feb  2 11:55:37 
2007
@@ -159,7 +159,7 @@
   /exclude
   exclude name=**/TestAbstractConfiguration.java
   /exclude
-  exclude name=**/XPathTest.java
+  exclude name=**/AbstractXPathTest.java
   /exclude
   exclude name=**/AbstractCombinerTest.java/
   exclude name=**/AbstractTestConfigurationEvents.java/

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diffrev=502705r1=502704r2=502705
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Fri Feb  2 11:55:37 
2007
@@ -498,7 +498,7 @@
 exclude**/TestBasePropertiesConfiguration.java/exclude
 exclude**/NonStringTestHolder.java/exclude
 exclude**/TestAbstractConfiguration.java/exclude
-exclude**/XPathTest.java/exclude
+exclude**/AbstractXPathTest.java/exclude
 exclude**/AbstractCombinerTest.java/exclude
 exclude**/AbstractTestConfigurationEvents.java/exclude
 exclude**/AbstractTestFileConfigurationEvents.java/exclude

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java?view=diffrev=502705r1=502704r2=502705
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestConfigurationUtils.java
 Fri Feb  2 11:55:37 2007
@@ -195,7 +195,8 @@
 {
 Thread.currentThread().setContextClassLoader(null);
 assertNull(ConfigurationUtils.locate(abase, aname));
-assertNotNull(ConfigurationUtils.locate(test.xml));
+// This assert fails when maven 2 is used, so commented out
+//assertNotNull(ConfigurationUtils.locate(test.xml));
 }
 finally
 {

Copied: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/AbstractXPathTest.java
 (from r492941, 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/XPathTest.java)
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/AbstractXPathTest.java?view=diffrev=502705p1=jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/XPathTest.javar1=492941p2=jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/tree/xpath/AbstractXPathTest.javar2=502705

svn commit: r502708 - in /jakarta/commons/proper/configuration/trunk: pom.xml xdocs/changes.xml

2007-02-02 Thread oheger
Author: oheger
Date: Fri Feb  2 11:58:27 2007
New Revision: 502708

URL: http://svn.apache.org/viewvc?view=revrev=502708
Log:
Added a pom for maven 2

Added:
jakarta/commons/proper/configuration/trunk/pom.xml   (with props)
Modified:
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml

Added: jakarta/commons/proper/configuration/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/pom.xml?view=autorev=502708
==
--- jakarta/commons/proper/configuration/trunk/pom.xml (added)
+++ jakarta/commons/proper/configuration/trunk/pom.xml Fri Feb  2 11:58:27 2007
@@ -0,0 +1,366 @@
+?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.
+--
+!-- = --
+!-- $Id$ --
+!-- = --
+project
+xmlns=http://maven.apache.org/POM/4.0.0;
+xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;
+  parent
+groupIdorg.apache.commons/groupId
+artifactIdcommons-parent/artifactId
+version1/version
+  /parent
+  modelVersion4.0.0/modelVersion
+  groupIdcommons-configuration/groupId
+  artifactIdcommons-configuration/artifactId
+  version1.4-SNAPSHOT/version
+  nameCommons Configuration/name
+
+  inceptionYear2001/inceptionYear
+description
+Tools to assist in the reading of configuration/preferences files in
+various formats
+/description
+
+  urlhttp://jakarta.apache.org/commons/configuration//url
+
+  issueManagement
+systemjira/system
+urlhttp://issues.apache.org/jira/browse/CONFIGURATION/url
+  /issueManagement
+
+  scm
+
connectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk/connection
+
developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk/developerConnection
+
urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/url
+  /scm
+
+developers
+developer
+  nameDaniel Rall/name
+  iddlr/id
+  emaildlr@finemaltcoding.com/email
+  organizationCollabNet, Inc./organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameJason van Zyl/name
+  idjvanzyl/id
+  email[EMAIL PROTECTED]/email
+  organizationZenplex/organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameMartin Poeschl/name
+  idmpoeschl/id
+  email[EMAIL PROTECTED]/email
+  organizationtucana.at/organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  namedIon Gillard/name
+  iddion/id
+  email[EMAIL PROTECTED]/email
+  organizationMultitask Consulting/organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameHenning P. Schmiedehausen/name
+  idhenning/id
+  email[EMAIL PROTECTED]/email
+  organizationINTERMETA - Gesellschaft fuer Mehrwertdienste 
mbH/organization
+  timezone2/timezone
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameEric Pugh/name
+  idepugh/id
+  email[EMAIL PROTECTED]/email
+  organizationupstate.com/organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameBrian E. Dunbar/name
+  idbdunbar/id
+  email[EMAIL PROTECTED]/email
+  organizationdunbarconsulting.org/organization
+  roles
+roleJava Developer/role
+  /roles
+/developer
+
+developer
+  nameEmmanuel Bourg/name
+  idebourg/id
+  email[EMAIL PROTECTED]/email
+  roles
+  

DO NOT REPLY [Bug 14520] - empty host header with ip address

2007-02-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=14520.
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=14520


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|2.0 milestone 2 |---




--- Additional Comments From [EMAIL PROTECTED]  2007-02-02 12:36 ---
This issue is no longer handled in Bugzilla.
It is now in JIRA at this address:
https://issues.apache.org/jira/browse/HTTPCLIENT-125

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



[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file

2007-02-02 Thread Heiko Seebach (JIRA)

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469899
 ] 

Heiko Seebach commented on CONFIGURATION-252:
-

Yes, I think that's fine. Maybe the JavaDoc could remind the the user that 
new File(/file.properties).isAbsolute() is false under Windows but true under 
Unix

 Detection of absolute fileNames when configuration sources are defined in a 
 JAR file
 

 Key: CONFIGURATION-252
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Linux
Reporter: Heiko Seebach
 Attachments: support-for-jar-protocol.patch.txt


 When using several configuration sources, the sources are defined in a an xml 
 attribute like 
 fileName=usergui.properties
 The method org.apache.commons.configuration.ConfigurationUtils.getFile(String 
 basePath, String fileName) converts the basePath and fileName into a File.
 The JavaDoc says: The parameter strings can be relative files, absolute 
 files and URLs as well.
 The file containing the definition of the configuration sources will become 
 the basePath of this method.
 After a log of debugging I found, that if the basePath start with jar: the 
 method assumes that the fileName is relative, evene if it's absolute. This 
 happens, because there's a ProtocolHandler for Jar files and jar: is a 
 valid protocol. So the statement new URL(new URL(basePath), fileName) 
 doesn't throw a MalformedUrlException.
 Since the URL is valid, it's never checked, if the fileName may be absolute. 
 Attention: this is only the case on Unix/Linux, since this is a valid URL
 jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties
 while under Windows, a MalformedUrlException will be thrown, when the 
 fileName is absolute: 
 jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties
 I attached a patch that checks, whether the URL protocol is jar and the 
 fileName is absolute. If so, the absolute file will be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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