from:"JIRA"


[ 
https://issues.apache.org/jira/browse/JXPATH-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514680
 ] 

Matt Benson commented on JXPATH-97:
---

Sergey, could you resubmit your patch without all those formatting changes?  It 
makes it difficult to see where the meat of the change is.

Thanks,
Matt

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-23 Thread Oliver Zeigermann (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514700
]

Oliver Zeigermann commented on TRANSACTION-9:
-

Apart from the interface we need to define for the resource manager I was
thinking of the transactional strategy.

Currently I am favor of one that actually performs all operations and keeps an
undo log. Changes are protected from concurrent read using read/write locks.

Pros:
- Fail fast in case the destination files can not be modified for whatever
reasion
- You do not get into trouble with too long file names in temporary folders
- Implementation should be pretty simple
- Commit can not fail on destination folder (as it is no-op for that)

Cons:
- Direct access to the destination folders sees the changes immedeately
- Rollback might actually fail

What do you think?

[transaction] Add full file management capabilities to the FileResourceManager
--

Key: TRANSACTION-9
URL: https://issues.apache.org/jira/browse/TRANSACTION-9
Project: Commons Transaction
Issue Type: Improvement
Environment: Operating System: All
Platform: All
Reporter: Peter Fassev
Assignee: Oliver Zeigermann
Priority: Minor
Fix For: 2.0

Attachments: filemanager.zip

Hi,
As stated in the doc the FileResourceManager is:
A resource manager for streamable objects stored in a file system
I agree, that this is a resource manager, but it could be easily extended, to
support a full file management system. It will be very helpful to have
additional methods like renameResource(), getResourceSize(),
getResourceTime(),
setResourceTime() etc. This are common file operations, which should be
managed
by the FileResourceManager.
Further it will be very helpful to have (real) support for resource
collections
(folders). It will be necessary to distinguish between single resources
(files)
and collections (folders).
Together, this features will enable a transactional access to any file based
resources - for instance a document repository.
Are there plans for such extensions and if not, will they actually fit in the
goals of the transaction library?
If not, please open the underlying structure, like the inner class
TransactionContext, in order to add extensions the file management. For
instance, it will be good to have a separate factory method, which creates
the
context.
If you are interested in this proposal, I am ready to contribute to this
project. I consider myself as an experienced java developer and I will be
glad
to help you.
Best regards
Peter Fassev

--
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] Closed: (DBCP-194) BasicDataSource.setLogWriter should not do createDataSource


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

Dain Sundstrom closed DBCP-194.
---

Resolution: Fixed

Fixed some time ago.

 BasicDataSource.setLogWriter should not do createDataSource
 ---

 Key: DBCP-194
 URL: https://issues.apache.org/jira/browse/DBCP-194
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2
Reporter: Kees de Kooter
 Fix For: 1.3

 Attachments: AbandonedObjectPool.patch


 The code for setLogWriter is:
 public void setLogWriter(PrintWriter logWriter) throws SQLException {
 createDataSource().setLogWriter(logWriter);
 this.logWriter = logWriter;
 }
 This means that before a custom log writer is set a datasource is created. 
 Any logging happening while creating the datasource is directed to stdout / 
 stderr.
 I think the purpose of setting a log writer is to prevent this, at least that 
 is what I am trying to achieve.

-- 
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] Closed: (DBCP-102) [dbcp] setReadOnly setAutoCommit called too many times


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

Dain Sundstrom closed DBCP-102.
---

Resolution: Fixed

Fixed some time ago.

 [dbcp] setReadOnly  setAutoCommit called too many times
 

 Key: DBCP-102
 URL: https://issues.apache.org/jira/browse/DBCP-102
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Operating System: other
 Platform: Sun
Reporter: AC
 Fix For: 1.3


 In order to gain some processor time for my application that uses Hibernate, 
 I 
 looked with optimizeIt where it spends time. It seems that for a request on 
 the 
 database (Oracle 9) around 25% (!!?) is spent on getting the connection from 
 the DBCP pool, and this not only the first time!. The methods that provoke 
 this 
 loss of time are connection.setReadOnly and connection.setAutoCommit called 
 inside the method PoolableConnectionFactory.activateObject. Looking to the 
 stack, these calls translate to communication with the Oracle server. 
 The obvious thing to do is to check if read only and autocommit flags are 
 already set to the expected values. (Of course, Oracle could 've done this 
 too, 
 but I hope you'll have a faster response :) )
 Thank you very much for you help.

-- 
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] Closed: (DBCP-212) PoolingDataSource closes physical connections


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

Dain Sundstrom closed DBCP-212.
---

Resolution: Fixed

Fixed some time ago.

 PoolingDataSource closes physical connections
 -

 Key: DBCP-212
 URL: https://issues.apache.org/jira/browse/DBCP-212
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.2
 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, 
 jConnect 6.0.5 EBF 13862, Commons Pool 1.3
Reporter: Marcos Sanz
 Fix For: 1.3

 Attachments: DBCPtester.java, DBCPtester.java, output.txt


 By executing the attached program and monitoring the process id of the 
 physical connections at the database server, it is possible to demonstrate 
 that the connections are being actually physically closed and reopened by the 
 application at a very high rate.

-- 
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] Closed: (DBCP-97) setAutoCommit(true) when returning connection to the pool


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

Dain Sundstrom closed DBCP-97.
--

Resolution: Fixed

Fixed some time ago.

 setAutoCommit(true) when returning connection to the pool
 -

 Key: DBCP-97
 URL: https://issues.apache.org/jira/browse/DBCP-97
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Dirk Verbeeck
 Fix For: 1.3


 From the Struts user list: [OT] RE: Stackoverflow after DB inactivity 
 (MySQL reconnect problem)
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg70196.html
 Giving a hint to the database driver that you don't need long running
 transactions makes sense. 
 setAutoCommit(true) should be added to 
 PoolableConnectionFactory.passivateObject

-- 
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] Closed: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)


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

Dain Sundstrom closed DBCP-152.
---

Resolution: Won't Fix

 [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL 
 thread-safe)
 

 Key: DBCP-152
 URL: https://issues.apache.org/jira/browse/DBCP-152
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 An app that accesses 2 datasources at two different places with different
 security policies via SSL (different set of permitted ciphers) currently is 
 out
 of luck (http://lists.mysql.com/java/8689).
 The basic datasource should be enhanced with 
  
   String socketFactory = ;
 and the corresponding getter and setter method, etc.
 org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then
 hand-over this full className via its Properties argument to enable different
 SSL policies per datasource (so, since the application programmer doesn't have
 the thread under her control, I guess it should rather be called 
 dataSource-safe).
 The jdbc driver implementation can then use this to take the appropriate 
 socket
 factory when creating a connection.
 See also http://lists.mysql.com/java/8695

-- 
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] Closed: (DBCP-155) [dbcp] allow to set = 6 parameters to do non-global SSL


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

Dain Sundstrom closed DBCP-155.
---

Resolution: Won't Fix

 [dbcp] allow to set = 6 parameters to do non-global SSL
 

 Key: DBCP-155
 URL: https://issues.apache.org/jira/browse/DBCP-155
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html,
 it should be possible to call DriverManager.getConnection() with properties
 to replace the below 4:
 -Djavax.net.ssl.keyStore=path_to_keystore_file
 -Djavax.net.ssl.keyStorePassword=*
 -Djavax.net.ssl.trustStore=path_to_truststore_file
 -Djavax.net.ssl.trustStorePassword=* 
 futhermore, adding a property
 - useSSL and
 - requireSSL
 would also help.
 plus the socketFactory-Class I asked for before (COM-2747)

-- 
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: (DBCP-217) Closing of underlaying connection instead of the PoolGuardConnectionWrapper


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

Dain Sundstrom resolved DBCP-217.
-

Resolution: Fixed

Fixed as part of DBCP-11.

 Closing of underlaying connection instead of the PoolGuardConnectionWrapper
 ---

 Key: DBCP-217
 URL: https://issues.apache.org/jira/browse/DBCP-217
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Sebastian Mancke
 Fix For: 1.3

 Attachments: connectionCloseFix.patch


 Is state:
 If I obtain the Connection of a Statement (stmt.getConnection()), created 
 with dbcp,
 the returned Object is the underlaying pooled connection. 
 Closing this connection multiple times may close the connection of another 
 process.
 It should be:
 The Wrapper over the connection PoolGuardConnectionWrapper should be returned 
 instead.

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-23 Thread Peter Fassev (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514744
]

Peter Fassev commented on TRANSACTION-9:

Thinking about it, there is not so match difference between the two scenarios:

1) Work with the original files, which means creating undo copies - deleting
all undo files after commit
2) Work on the copies only, which means creating copies and working on them -
deleting the original files and moving/renaming the modified copies on commit

During the both scenarios we should make copies before each change, which I
think is the longest operation. Deleting and moving files are actually a very
fast. During the commit operation in the second scenario we also have a
uncomplete state of the original files.

The only advantage of scenario 1) is that on commit only the copies have to be
removed. BUT, some system may use distributed transactions (i.e.
synchronization with a DB-transaction), which means we have to think about
tryCommint, and rollback after tryCommit if the distribute transaction fails.
In such scenario, it is not acceptable, that the rollback fails.

The question is, why a rollback in scenario 1 can fail (which is the same for
commit in scenario 2)? As far as I can see, this could happen:

a) If there is not enough free space on the disk and if we are moving files,
this could happen only if the working temp directory is not on the same disk or
when the repository spans more than one disk.
b) If an external process (for instance a backup) is accessing the files
directly. That's why direct access should be somehow synchronized in both
scenarios.

If somebody is using distributed transactions, may be the scenario 2 has an
advantige. When the file transaction is committed as the last one in the queue.
If the DB-Transaction fails, we have to delete only the copies, the rollback
can not fail.

So I think it depends on the application and on the usage of the file
transactions. How about implementing both scenarios? For instance my
implementation (which is attached here) is using the second scenario, where the
actual file management actions are separated from the transaction facade. The
actions are very simple. I think it will be very easy to implement the scenario
1) in the same way under a different TransactionContext interface and let the
user decide, which one he wants to use.

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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] Updated: (JXPATH-97) Incomplete handling of undefined namespaces


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

Matt Benson updated JXPATH-97:
--

Comment: was deleted

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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: (JXPATH-97) Incomplete handling of undefined namespaces


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

Matt Benson resolved JXPATH-97.
---

Resolution: Fixed

This should work in trunk.  Thanks all!

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails

2007-07-23 Thread Jochen Wiedmann (JIRA)

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

Jochen Wiedmann resolved FILEUPLOAD-141.

Resolution: Won't Fix

You are free to overwrite the FileItemFactory to return an instance of
DiskFileItem, which overrides the method getTempFile() in that sense.

Apart from that, changing the current code in your sense would most possibly be
the cause of a lot of compatibility problems without gaining too much. I am
unaware of any actual FileUpload installation that considers hanging files a
real issue. This might be the case in your particular application, but then I
believe it's fine that you tune the code to meet your special requirements.

Remove FileItems if FileUploadBase.parseRequest() fails
---

--
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: (DBCP-150) [dbcp] BasicDataSource : setter for connectionProperties


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

Dain Sundstrom resolved DBCP-150.
-

Resolution: Fixed

Sendingsrc/java/org/apache/commons/dbcp/BasicDataSource.java
Sendingsrc/test/org/apache/commons/dbcp/TestBasicDataSource.java
Transmitting file data ..
Committed revision 558845.


 [dbcp] BasicDataSource : setter for connectionProperties
 

 Key: DBCP-150
 URL: https://issues.apache.org/jira/browse/DBCP-150
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: All
Reporter: Maarten Bosteels
Assignee: Dain Sundstrom
Priority: Minor
 Fix For: 1.3

 Attachments: DBCP-150.patch


 Adding a javabean-style setter for connectionProperties would certainly ease 
 the
 configuration of a BasicDataSource within a Dependency Injection framework (eg
 Spring).
 see: http://article.gmane.org/gmane.comp.java.springframework.user/6501/
 Thanks,
 Maarten

-- 
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: (DBCP-225) getConnection / borrowObject fails with NullPointerException


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

Dain Sundstrom resolved DBCP-225.
-

Resolution: Fixed

Sendingsrc/java/org/apache/commons/dbcp/PoolableConnectionFactory.java
Sending
src/java/org/apache/commons/dbcp/datasources/CPDSConnectionFactory.java
Sending
src/java/org/apache/commons/dbcp/datasources/KeyedCPDSConnectionFactory.java
Transmitting file data ...
Committed revision 558846.


 getConnection / borrowObject fails with NullPointerException
 

 Key: DBCP-225
 URL: https://issues.apache.org/jira/browse/DBCP-225
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1, 1.2.2
 Environment: Solaris 10, Oracle 10g RAC
Reporter: Alexei Samonov
Assignee: Dain Sundstrom
 Fix For: 1.3

 Attachments: DBCP-225.patch


 We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our 
 getConnection calls fail sporadically with the following stack trace (1.2.1)
 Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a 
 connection, pool exhausted
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 ... 24 more
 This is definitely not a pool exhausted situation, it is just being 
 reported as pool exhausted. Since NoSuchElementException that you use does 
 not allow cause, only Exception message (null) is being printed. With some 
 debugging I was able to recover the root exception:
 java.lang.NullPointerException
 at 
 org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
 at 
 org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ...
 Looks like it is trying to borrow/validate DelegatingConnection which 
 delegate is null.
 Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is 
 is an exception stack trace from 1.2.2:
 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
 error Could not create a validated object, cause: null
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
 ... 28 more
 We use the following dbcp properties:
 autoCommit=false
 readOnly=false
 maxActive=200
 maxIdle=20
 minIdle=10
 minEvictableIdleIime=30
 maxWait=200
 accessToUnderlyingConnectionAllowed=true
 validationQuery=SELECT 1 FROM DUAL
 ConnectionCachingEnabled=true
 FastConnectionFailoverEnabled=true
 I could not find the existing reported dbcp/object pool bug but I see similar 
  reports on the web, for example 
 http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915

-- 
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] Created: (DBCP-234) Only set configured default values for Connection

Only set *configured* default values for Connection
---

 Key: DBCP-234
 URL: https://issues.apache.org/jira/browse/DBCP-234
 Project: Commons Dbcp
  Issue Type: Improvement
Reporter: Dain Sundstrom
 Fix For: 1.3


All default values for connections (auto-commit, read-only, transaction 
isolation, etc) should be non-primitive types, so it can be determined if they 
were configured by the user.  Only default values configured by the user should 
be set on connections.  This will help to avoid problems where drivers don't 
support the invocation of methods like setReadOnly and lets driver default 
values pass through to the user.

-- 
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] Reopened: (JXPATH-97) Incomplete handling of undefined namespaces


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

Matt Benson reopened JXPATH-97:
---


reopening... elements still don't work apparently for prefixes that are _only_ 
declared externally?

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-23 Thread Oliver Zeigermann (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514764
]

Oliver Zeigermann commented on TRANSACTION-9:
-

I think implementing both strategies would be a good idea. I will try to come
forward with a prototypical proposal for (1) to validate the interfaces. I will
add a non transactional implementation for our resource manager.

Peter, maybe you would be willing to adapt your solution to the new 2.0 core
and give feedback to it as you go along? Would be cool :)

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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: (DBCP-207) DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...))


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

Dain Sundstrom resolved DBCP-207.
-

Resolution: Fixed

Committed a fix for this specific problem, and created a JIRA for converting 
all default values to non-primitive types.  This way only configured default 
values will be set.

Sending
src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java
Sending
src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java
Transmitting file data ..
Committed revision 558850.


 DBCP 1.2.1 incompatible with Informix (driver doesn't support 
 setReadOnly(...))
 ---

 Key: DBCP-207
 URL: https://issues.apache.org/jira/browse/DBCP-207
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: using the pooling driver component with an informix 
 driver
Reporter: Kimberly Baer
Assignee: Dain Sundstrom
 Fix For: 1.3

 Attachments: DBCP-207.patch


 I recieved an error using commons-dbcp-1.2.1.jar and ifxjdbc.jar for my 
 informix driver: 
 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
 exhausted 
 at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183) 
 at java.sql.DriverManager.getConnection(DriverManager.java:539) 
 at java.sql.DriverManager.getConnection(DriverManager.java:211) 
 at ConnectionPoolingTest.main(ConnectionPoolingTest.java:105) 
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: Read only mode not supported 
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
  
 at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) 
 I will look into the comment provided by Dirk in bug ID DBCP-127 (version 
 1.1), but it appears this bug still has an impact in the 1.2.1 version. If 
 anyone has any other suggestions, they would be greatly appreciated. 

-- 
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: (JXPATH-97) Incomplete handling of undefined namespaces

2007-07-23 Thread Sergey Vladimirov (JIRA)


[ 
https://issues.apache.org/jira/browse/JXPATH-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514774
 ] 

Sergey Vladimirov commented on JXPATH-97:
-

Matt,

sorry for the bad patch. But one of the main point is change in DOMNodePointer:

@@ -102,9 +107,12 @@
 return true;
 }
 
-if (wildcard
-|| testName.getName()
-.equals(DOMNodePointer.getLocalName(node))) {
+// the same as for attribute ( DOMAttributeIterator::testAttr() )
+if (equalStrings(nodePrefix, testPrefix)) {
+return true;
+}
+
+if (wildcard || testName.getName().equals(nodeLocalName)) {
 String nodeNS = DOMNodePointer.getNamespaceURI(node);
 return equalStrings(namespaceURI, nodeNS);
 }


 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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] Reopened: (DBCP-212) PoolingDataSource closes physical connections

2007-07-23 Thread Marcos Sanz (JIRA)


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

Marcos Sanz reopened DBCP-212:
--


Not really fixed. As Phil wrote: until pool is improved somehow to be more 
intelligent about destroying idle objects, dbcp is prone to this behavior.
I'd like to keep this open so as not to forget this. The question remains: Has 
PoolableConnectionFactory.makeObject() necessarily be synchronized?

 PoolingDataSource closes physical connections
 -

 Key: DBCP-212
 URL: https://issues.apache.org/jira/browse/DBCP-212
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.2
 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, 
 jConnect 6.0.5 EBF 13862, Commons Pool 1.3
Reporter: Marcos Sanz
 Fix For: 1.3

 Attachments: DBCPtester.java, DBCPtester.java, output.txt


 By executing the attached program and monitoring the process id of the 
 physical connections at the database server, it is possible to demonstrate 
 that the connections are being actually physically closed and reopened by the 
 application at a very high rate.

-- 
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: (JXPATH-97) Incomplete handling of undefined namespaces


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

Matt Benson resolved JXPATH-97.
---

Resolution: Fixed

elements handled.

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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: (DBCP-221) How to close the connection pool without shutting down the JVM while there are connections being used?

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

Dain Sundstrom resolved DBCP-221.
-

Resolution: Fixed
Assignee: Dain Sundstrom

BasicDataSource.close() now permanently marks the data source as closed. No
new connections can be obtained from a closed data source. At close all idle
connections are destroyed and the method returns. As existing active
connections are closed, they are destroyed.

How to close the connection pool without shutting down the JVM while there
are connections being used?
--

Key: DBCP-221
URL: https://issues.apache.org/jira/browse/DBCP-221
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Bill Liu
Assignee: Dain Sundstrom
Fix For: 1.3

Suppose there are several connections being used now by different servlets.
calling the basicDataSource,close() does not have any impact on the
connection pool. I expect that after these servlet return the connections the
pool should be shut down immediately. I also expect that any more requests to
borrow connections from the pool should not be fulfilled. However, my
experiment does not seem to support my expectations. Calling
basicDataSource.close() seems to be ignored while there are connections being
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] Created: (DBCP-235) accessToUnderlyingConnectionAllowed flag in ManagedConnection breaks equals, hashCode and toString

accessToUnderlyingConnectionAllowed  flag in ManagedConnection breaks equals, 
hashCode and toString
---

 Key: DBCP-235
 URL: https://issues.apache.org/jira/browse/DBCP-235
 Project: Commons Dbcp
  Issue Type: Bug
Reporter: Dain Sundstrom
 Fix For: 1.3


The accessToUnderlyingConnectionAllowed property ManageConnection disables the 
getInnerMostDelegate method used by DelegatingConnection equals, hashCode, and 
toString.

-- 
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: (DBCP-191) [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0

2007-07-23 Thread Michael Heuer (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514825
 ] 

Michael Heuer commented on DBCP-191:


Attached is a patch that allows commons-dbcp and its tests to compile under 
maven with jdk 1.6/JDBC 4.0.

A couple of potential gotchas:

 - boolean isClosed() is now a public method on DelegatingStatement, was 
protected

 - several JDBC interfaces now implement java.sql.Wrapper, which contains 
generics language features


and to-dos:

 - questionable implemention of boolean Wrapper.isWrapperFor(Class? iface) 
and T T Wrapper.unwrap(ClassT iface) in some classes (e.g. BasicDataSource 
has a dataSource but is it considered a wrapper?)

 - conditional compilation for /* JDBC_4_ANT_KEY... */ tags via the ant build

 - create a separate svn branch?

 [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
 --

 Key: DBCP-191
 URL: https://issues.apache.org/jira/browse/DBCP-191
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: $ java -version
 java version 1.6.0-rc
 Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
 Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)
 $ java -version
 java version 1.6.0-rc
 Java(TM) SE Runtime Environment (build 1.6.0-rc-b89)
 Java HotSpot(TM) Client VM (build 1.6.0-rc-b89, mixed mode, sharing)
Reporter: Michael Heuer
Priority: Minor
 Fix For: 1.3


 Just a heads up, [dbcp] does not compile under the latest unreleased jdk 1.6 
 / JDBC 4.0, even with maven.compile.source and maven.compile.target 
 properties set to something appropriate.
 $ maven java:compile
  __  __
 |  \/  |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
 |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
 java:prepare-filesystem:
 [mkdir] Created dir: working/commons-dbcp/target/classes
 java:compile:
 [echo] Compiling to working/commons-dbcp/target/classes
 [echo]
 ==
   NOTE: Targetting JVM 1.6, classes
   will not run on earlier JVMs
 ==
 [javac] Compiling 39 source files to working/commons-dbcp/target/classes
 working/commons-dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java:43:
  org.apache.commons.dbcp.BasicDataSource is not abstract and does not 
 override abstract method 
 TcreateQueryObject(java.lang.ClassT,javax.sql.DataSource) in 
 javax.sql.DataSource
 public class BasicDataSource implements DataSource {
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java:
  40: org.apache.commons.dbcp.cpdsadapter.ConnectionImpl is not abstract and 
 does not override abstract method 
 createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
 class ConnectionImpl implements Connection {
 ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PooledConnectionImpl.java:42:
  org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl is not abstract and 
 does not override abstract method 
 removeStatementEventListener(javax.sql.StatementEventListener) in 
 javax.sql.PooledConnection
 class PooledConnectionImpl
 ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java:50:
  org.apache.commons.dbcp.DelegatingConnection is not abstract and does not 
 override abstract method createStruct(java.lang.String,java.lang.Object[]) in 
 java.sql.Connection
 public class DelegatingConnection extends AbandonedTrace
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java:85:
  org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS is not abstract and 
 does not override abstract method getQueryObjectGenerator() in 
 javax.sql.CommonDataSource
 public class DriverAdapterCPDS
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:45:
  org.apache.commons.dbcp.DelegatingStatement is not abstract and does not 
 override abstract method isPoolable() in java.sql.Statement
 public class DelegatingStatement extends AbandonedTrace implements Statement {
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:130:
  isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement 
 isClosed() in java.sql.Statement; attempting to assign weaker access 
 privileges; was public
 protected boolean isClosed() {
   ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingPreparedStatement.java:49:
  org.apache.commons.dbcp.DelegatingPreparedStatement is not abstract and does 
 not override abstract method setCharacterStream(int,java.io.Reader,long) in 
 java.sql.PreparedStatement
 public class DelegatingPreparedStatement

[jira] Updated: (DBCP-191) [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0

2007-07-23 Thread Michael Heuer (JIRA)


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

Michael Heuer updated DBCP-191:
---

Attachment: patch.txt

patch against nightly for 23 July 2007, or in other words

$ svn co --revision '{2007-07-23}' ...
...
$ svn diff .  patch.txt

 [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
 --

 Key: DBCP-191
 URL: https://issues.apache.org/jira/browse/DBCP-191
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: $ java -version
 java version 1.6.0-rc
 Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
 Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)
 $ java -version
 java version 1.6.0-rc
 Java(TM) SE Runtime Environment (build 1.6.0-rc-b89)
 Java HotSpot(TM) Client VM (build 1.6.0-rc-b89, mixed mode, sharing)
Reporter: Michael Heuer
Priority: Minor
 Fix For: 1.3

 Attachments: patch.txt


 Just a heads up, [dbcp] does not compile under the latest unreleased jdk 1.6 
 / JDBC 4.0, even with maven.compile.source and maven.compile.target 
 properties set to something appropriate.
 $ maven java:compile
  __  __
 |  \/  |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
 |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
 java:prepare-filesystem:
 [mkdir] Created dir: working/commons-dbcp/target/classes
 java:compile:
 [echo] Compiling to working/commons-dbcp/target/classes
 [echo]
 ==
   NOTE: Targetting JVM 1.6, classes
   will not run on earlier JVMs
 ==
 [javac] Compiling 39 source files to working/commons-dbcp/target/classes
 working/commons-dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java:43:
  org.apache.commons.dbcp.BasicDataSource is not abstract and does not 
 override abstract method 
 TcreateQueryObject(java.lang.ClassT,javax.sql.DataSource) in 
 javax.sql.DataSource
 public class BasicDataSource implements DataSource {
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java:
  40: org.apache.commons.dbcp.cpdsadapter.ConnectionImpl is not abstract and 
 does not override abstract method 
 createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
 class ConnectionImpl implements Connection {
 ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PooledConnectionImpl.java:42:
  org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl is not abstract and 
 does not override abstract method 
 removeStatementEventListener(javax.sql.StatementEventListener) in 
 javax.sql.PooledConnection
 class PooledConnectionImpl
 ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java:50:
  org.apache.commons.dbcp.DelegatingConnection is not abstract and does not 
 override abstract method createStruct(java.lang.String,java.lang.Object[]) in 
 java.sql.Connection
 public class DelegatingConnection extends AbandonedTrace
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java:85:
  org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS is not abstract and 
 does not override abstract method getQueryObjectGenerator() in 
 javax.sql.CommonDataSource
 public class DriverAdapterCPDS
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:45:
  org.apache.commons.dbcp.DelegatingStatement is not abstract and does not 
 override abstract method isPoolable() in java.sql.Statement
 public class DelegatingStatement extends AbandonedTrace implements Statement {
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:130:
  isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement 
 isClosed() in java.sql.Statement; attempting to assign weaker access 
 privileges; was public
 protected boolean isClosed() {
   ^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingPreparedStatement.java:49:
  org.apache.commons.dbcp.DelegatingPreparedStatement is not abstract and does 
 not override abstract method setCharacterStream(int,java.io.Reader,long) in 
 java.sql.PreparedStatement
 public class DelegatingPreparedStatement extends DelegatingStatement
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/PoolablePreparedStatement.java:40:
  org.apache.commons.dbcp.PoolablePreparedStatement is not abstract and does 
 not override abstract method setCharacterStream(int,java.io.Reader,long) in 
 java.sql.PreparedStatement
 public class PoolablePreparedStatement extends DelegatingPreparedStatement 
 implements PreparedStatement {
^
 working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter

[jira] Created: (CLI-137) Change of behaviour 1.0 - 1.1

2007-07-22 Thread Russel Winder (JIRA)

Change of behaviour 1.0 - 1.1
--

 Key: CLI-137
 URL: https://issues.apache.org/jira/browse/CLI-137
 Project: Commons CLI
  Issue Type: Bug
 Environment: Ubuntu 7.04 Feisty Fawn (JDK 1.6.0) + Commons CLI 1.0 and 
1.1
Reporter: Russel Winder
Priority: Blocker


The code:
{code}
import org.apache.commons.cli.CommandLine ;
import org.apache.commons.cli.OptionBuilder ;
import org.apache.commons.cli.GnuParser ;
import org.apache.commons.cli.Option ;
import org.apache.commons.cli.Options ;
import org.apache.commons.cli.ParseException ;

public class Trial {
  private void execute (  final String[] commandLine ) throws ParseException {
final Options options = new Options ( ) ;
options.addOption ( OptionBuilder.withLongOpt ( flob ).hasArg ( ).create 
( 'F' ) ) ;
final CommandLine line = ( new GnuParser ( ) ).parse ( options , 
commandLine ) ;
String[] results =  line.getOptionValues ( 'F' ) ;
if ( results != null ) { for ( String s : results ) { System.out.println ( 
-F  + s ) ; } }
results =  line.getOptionValues ( flob ) ;
if ( results != null ) { for ( String s : results ) { System.out.println ( 
--blah  + s ) ; } }
String[] theRest = line.getArgs ( ) ;
for ( String s : theRest ) { System.out.print ( s +   ) ; }
System.out.println ( ) ;
  }
  public static void main ( final String[] args ) throws ParseException {
final Trial trial = new Trial ( ) ;
trial.execute ( new String[] { -F1 , -F3 , -Fbla , -F 76 , --flob 
, 54 } ) ;
  }
}
{code}
when compiled and executed under 1.0 produces:

trial:
 [java] -F 1
 [java] -F 3
 [java] -F bla
 [java] -F  76
 [java] -F 54
 [java] 

However, when compiled and executed under 1.1 produces:

trial:
 [java] -F 1
 [java] --blah 1
 [java] 3 bla  76 54 



-- 
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] Created: (TRANSACTION-20) Create a new type of lock manager

2007-07-22 Thread Oliver Zeigermann (JIRA)

Create a new type of lock manager
-

 Key: TRANSACTION-20
 URL: https://issues.apache.org/jira/browse/TRANSACTION-20
 Project: Commons Transaction
  Issue Type: New Feature
Affects Versions: 2.0
Reporter: Oliver Zeigermann
Assignee: Oliver Zeigermann


For the new implementations we need a new type of lock manager. We need 
something general that can be used for the file manager, the tx maps, and 
optionally can even be used in a general programming environment.

This is my proposal. It is meant to be used by one or more transactional 
resource managers:

public interface LockManagerK {
public void startWork(long timeout, TimeUnit unit);
public void endWork();
public void lock(K key, boolean exclusive) throws LockException;
}

Where startWork starts a block of work for which a certain set of locks is 
required and endWork ends it. Only in between these call one can use the 
lock method to lock resources denoted by the given key. 

The timeout is meant for the whole block of work and thus does not have to be 
passed with every lock request.

At the end of the working block all locks are released. 

The lock method throws an exception in case of timeout, interruption or 
deadlock.


-- 
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: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)

2007-07-22 Thread Ralf Hauser (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514474
 ] 

Ralf Hauser commented on DBCP-152:
--

Dain, 

thx for your explanations.

Unfortunately, it appears that JSR 221: JDBCTM 4.0 API Specification is final 
since only ~half a year and I fear that the community process will not be able 
to quickly pick this up.
Anyway, I drew the attention on the topic by sending mail to [EMAIL PROTECTED] 
and the listed sun employees.

In the meantime (probably months if not years), I guess it will be the 
challenge for dbcp to anticipate an approach with which you can easily support 
this already now and if the JDBC standard were to support this, minimize the 
migration effort for those using it/allow for easy backward compatibility.
Since most people and vendor's don't require this security yet, how about 
adding a thin interface and a default implementation that supports the mysql 
approach for now and if other vendor's have different approaches, do both i) 
add a switch to the default implementation (e.g. on the driver name) and ii) 
also provide the option to use an own interface implementation instead with a 
simple configuration step?

Rgds Ralf

 [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL 
 thread-safe)
 

 Key: DBCP-152
 URL: https://issues.apache.org/jira/browse/DBCP-152
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 An app that accesses 2 datasources at two different places with different
 security policies via SSL (different set of permitted ciphers) currently is 
 out
 of luck (http://lists.mysql.com/java/8689).
 The basic datasource should be enhanced with 
  
   String socketFactory = ;
 and the corresponding getter and setter method, etc.
 org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then
 hand-over this full className via its Properties argument to enable different
 SSL policies per datasource (so, since the application programmer doesn't have
 the thread under her control, I guess it should rather be called 
 dataSource-safe).
 The jdbc driver implementation can then use this to take the appropriate 
 socket
 factory when creating a connection.
 See also http://lists.mysql.com/java/8695

-- 
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] Closed: (TRANSACTION-2) [transaction] FileHelper is not thread safe

2007-07-22 Thread Oliver Zeigermann (JIRA)


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

Oliver Zeigermann closed TRANSACTION-2.
---


 [transaction] FileHelper is not thread safe
 ---

 Key: TRANSACTION-2
 URL: https://issues.apache.org/jira/browse/TRANSACTION-2
 Project: Commons Transaction
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Lukas Zapletal

 It uses STATIC member (buffer). Calling copy(...) method in parallel leads to
 thread errors.

-- 
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-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml

2007-07-22 Thread JIRA

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

Thorbjørn Ravn Andersen commented on CONFIGURATION-285:
---

Thank you for adding this extension.

I still believe that invalid subconfigurations should be treated differently
from optional, non-existant subconfigurations regardless of the invalidation
cause, and that the silent ignoring should be a switch that needs to be set,
similarly to the config-optional attribute. I.e. if an optional
subconfiguration is invalid, a configuration exception should be thrown.

I'd prefer not to use CVS-snapshots in production code - do you have a rough
estimate of when 1.5 will be released?

configuration fileName=local-configuration.xml config-optional=true /
does not report parsing errors in local-configuration.xml
-

Key: CONFIGURATION-285
URL: https://issues.apache.org/jira/browse/CONFIGURATION-285
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Thorbjørn Ravn Andersen
Assignee: Oliver Heger
Fix For: 1.5

I'm trying to build a configuration system to be shared between our Java
applications. I therefore want to have optional configurations included from
the main configuration file read by DefaultConfigurationBuilder
configuration fileName=local-configuration.xml config-optional=true /
I have found that if the sub-configuration file is invalid the error is
silently ignored. The same without config-options=true results in a
ConfigurationException to be thrown (which wraps a
ConfigurationRuntimeException which wraps the ConfigurationException which
wraps the SAXException).
I believe that the behaviour is incorrect. The sub-configuration file should
be skipped if not found, but any errors found when parsing the existing file
should be logged.

--
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: (POOL-97) EVICTION_TIMER is never cancelled.

2007-07-22 Thread Robert Burrell Donkin (JIRA)


[ 
https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514495
 ] 

Robert Burrell Donkin commented on POOL-97:
---

This fix breaks binary compatibility but only at package private level. 

One question which may need to investigated is whether any subtle concurrency 
issues are prevent by using a static instance. I've taken a look at the code 
and i can only see it being used to set up eviction timings. Not sure whether 
these are ever cleared out. So, the instance will ensure the pool remains in 
memory until the server is restarted. More eyes would be good since it's very 
easy to miss subtle concurrency issues.

I suppose that some benchmarks would be the right way to assess the performance 
impact of this patch. 

A more complex solution would be to create a private subclass of timer that 
does knows when to unschedule eviction tasks. The evictor would need to 
implement a package interface (unschedulable?) and then test for the pool being 
closed (or something like that). This would be quite a bit more effort with 
more to go wrong. 

 EVICTION_TIMER is never cancelled.
 --

 Key: POOL-97
 URL: https://issues.apache.org/jira/browse/POOL-97
 Project: Commons Pool
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Devendra Patil
 Fix For: 2.0

 Attachments: timer.patch


 The static EVICTION_TIMER (java.util.Timer) used in GenericObjectPool is 
 never cancelled (even after closing the pool). The GenericObjectPool.close() 
 method just cancels the _evictor (TimerTask). I agree this behaviour is ideal 
 if EVICTION_TIMER is to be used across multiple pools.
 But, In my case, the resources (i.e. jars) are dynamically deployed and 
 undeployed on remote grid-servers. If EVICTION_TIMER thread doesn't stop, the 
 grid-servers fails to undeploy (i.e. delete) the jars. The grid-server 
 doesn't restart during resource deployment/undeployment, so, setting 
 EVICTION_TIMER to daemon doesn't help me.

-- 
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: (POOL-97) EVICTION_TIMER is never cancelled.

2007-07-22 Thread Phil Steitz (JIRA)


[ 
https://issues.apache.org/jira/browse/POOL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514497
 ] 

Phil Steitz commented on POOL-97:
-

A more conservative solution would be to revert to the pool 1.2 setup where the 
Evictor is a thread.  This would also break backward compatibility at the 
package private level, but would revert to a well-tested solution with 
essentially the same scaling / perfornance challenges as the per instance Timer 
in the patch.  See POOL-56 or 1.2 sources for changes to revert.

 EVICTION_TIMER is never cancelled.
 --

 Key: POOL-97
 URL: https://issues.apache.org/jira/browse/POOL-97
 Project: Commons Pool
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Devendra Patil
 Fix For: 2.0

 Attachments: timer.patch


 The static EVICTION_TIMER (java.util.Timer) used in GenericObjectPool is 
 never cancelled (even after closing the pool). The GenericObjectPool.close() 
 method just cancels the _evictor (TimerTask). I agree this behaviour is ideal 
 if EVICTION_TIMER is to be used across multiple pools.
 But, In my case, the resources (i.e. jars) are dynamically deployed and 
 undeployed on remote grid-servers. If EVICTION_TIMER thread doesn't stop, the 
 grid-servers fails to undeploy (i.e. delete) the jars. The grid-server 
 doesn't restart during resource deployment/undeployment, so, setting 
 EVICTION_TIMER to daemon doesn't help me.

-- 
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-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml

2007-07-22 Thread Oliver Heger (JIRA)

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

Oliver Heger commented on CONFIGURATION-285:

I follow your argumentation in principle, but I don't see an easy (and generic)
way to find out when a subconfiguration is invalid. So the idea with the event
listener approach is to provide a way for implementing this decision yourself.

ATM there are no concrete plans for a 1.5 release yet. There are still some
JIRA tickets, which need to be addressed. So, unfortunately, I really cannot
anticipate a release date.

configuration fileName=local-configuration.xml config-optional=true /
does not report parsing errors in local-configuration.xml
-

--
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] Created: (VFS-171) How much time it will take to release new jar (commons-vfs-1.0.jar) that has support for webdev and smb because currently webdev and smb are in sandbox

2007-07-22 Thread vikas (JIRA)

How much time it will take to release new jar (commons-vfs-1.0.jar) that has 
support for webdev and smb because currently webdev and smb are in sandbox 


 Key: VFS-171
 URL: https://issues.apache.org/jira/browse/VFS-171
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.1
 Environment: java and window
Reporter: vikas
Priority: Critical


When r you going to release new jar (commons-vfs-1.0.jar) that has support for 
webdev and smb because currently webdev and smb are in sandbox .Pls inform me

-- 
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] Created: (JXPATH-97) Incomplete handling of undefined namespaces

2007-07-21 Thread Sergey Vladimirov (JIRA)

Incomplete handling of undefined namespaces
---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final, Nightly Builds
Reporter: Sergey Vladimirov
 Fix For: 1.3


Mcduffey, Joe [EMAIL PROTECTED]

Can someone tell me how to register namespaces so that attributes with 
namespaces does not cause the exception

org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
unknown namespace prefix: xsi

For example the following
ElementA  A:myAttr=Mytype
  B:ElementBMY VALUE/B:ElementB
/ElementA

Would result in the following exception:
org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
unknown namespace prefix: A

FYI: In this example there was a namespace decaration in the file and I also 
manually called the
registerNamespace(A,/http...);
registerNamespace(B,/http...);

There was no problem encountered for elements. Only attributes. Can someone 
help? Thanks.

-- 
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] Updated: (JXPATH-97) Incomplete handling of undefined namespaces

2007-07-21 Thread Sergey Vladimirov (JIRA)


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

Sergey Vladimirov updated JXPATH-97:


Attachment: patch.txt

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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] Updated: (JXPATH-97) Incomplete handling of undefined namespaces

2007-07-21 Thread Sergey Vladimirov (JIRA)


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

Sergey Vladimirov updated JXPATH-97:


Attachment: NamespacesTest.java

 Incomplete handling of undefined namespaces
 ---

 Key: JXPATH-97
 URL: https://issues.apache.org/jira/browse/JXPATH-97
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: Nightly Builds, 1.2 Final
Reporter: Sergey Vladimirov
 Fix For: 1.3

 Attachments: NamespacesTest.java, patch.txt


 Mcduffey, Joe [EMAIL PROTECTED]
 Can someone tell me how to register namespaces so that attributes with 
 namespaces does not cause the exception
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: xsi
 For example the following
 ElementA  A:myAttr=Mytype
   B:ElementBMY VALUE/B:ElementB
 /ElementA
 Would result in the following exception:
 org.apache.common.ri.model.dom.DOMNodePointer.createAttribute
 unknown namespace prefix: A
 FYI: In this example there was a namespace decaration in the file and I also 
 manually called the
 registerNamespace(A,/http...);
 registerNamespace(B,/http...);
 There was no problem encountered for elements. Only attributes. Can someone 
 help? Thanks.

-- 
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-284) ability to read OS environment variables

2007-07-21 Thread Oliver Heger (JIRA)


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

Oliver Heger commented on CONFIGURATION-284:


Vasily, many thanks for your contribution.

For the reasons outlined above I am still reluctant to add this feature to the 
code base. If you don't mind I would bring this topic again to the commons 
developer list and ask whether the opinion to support environment variables in 
one of the core libraries has changed in the mean time.

What we could do in any case is adding your code to the WIKI in our examples 
section:
http://wiki.apache.org/jakarta-commons/Configuration


 ability to read OS environment variables
 

 Key: CONFIGURATION-284
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
 Project: Commons Configuration
  Issue Type: New Feature
  Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
 Attachments: EnvironmentConfiguration.java


 suggestion:
 interpolation with system environment, i.e.
 ${sys:user.name} reads from systemproperties (as of today)
 ${sysenv:TEMP} reads from OS environment
 these can be parsed from a supported set of OS's - windows read from a set in 
 a cmd /c, unix/linux from an env etc. (just once on demand)

-- 
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] Updated: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml

2007-07-21 Thread Oliver Heger (JIRA)


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

Oliver Heger updated CONFIGURATION-285:
---

Fix Version/s: 1.5
 Assignee: Oliver Heger

 configuration fileName=local-configuration.xml config-optional=true / 
 does not report parsing errors in local-configuration.xml
 -

 Key: CONFIGURATION-285
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Thorbjørn Ravn Andersen
Assignee: Oliver Heger
 Fix For: 1.5


 I'm trying to build a configuration system to be shared between our Java 
 applications.  I therefore want to have optional configurations included from 
 the main configuration file read by DefaultConfigurationBuilder
 configuration fileName=local-configuration.xml config-optional=true /
 I have found that if the sub-configuration file is invalid the error is 
 silently ignored.  The same without config-options=true results in a 
 ConfigurationException to be thrown (which wraps a 
 ConfigurationRuntimeException which wraps the ConfigurationException which 
 wraps the SAXException).
 I believe that the behaviour is incorrect.  The sub-configuration file should 
 be skipped if not found, but any errors found when parsing the existing file 
 should be logged.

-- 
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: (DBCP-11) [dbcp] stmt.getConnection() != Connection used to create the statement


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

Phil Steitz resolved DBCP-11.
-

Resolution: Fixed

Patch applied.  Thanks.

 [dbcp] stmt.getConnection() != Connection used to create the statement
 --

 Key: DBCP-11
 URL: https://issues.apache.org/jira/browse/DBCP-11
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Operating System: other
 Platform: All
Reporter: Alexander Rupsch
 Fix For: 1.3

 Attachments: back-pointers.patch


 Hi,
 I'm not an expert in implementing connection pools or jdbc itself. But 
 shouldn't
 the following code work?
 Connection con = pool.getConnection()
 PreparedStatement ps = con.prepareStatement()
 con.equals(ps.getConnection) // returns false!
 Ok, I don't need it to be equal, but the following also does not work:
 ps.getConnection().close()
 con.isClosed() // is false!!!
 That means, if I have a Statment and want to close its connection, I have to
 remember the conncetion. Is that the requested behavior? Because of this my 
 pool
 is running over.
 The java.sql API says that Statment.getConnection() has to be the connection
 which created the statement.

-- 
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-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml

2007-07-21 Thread Oliver Heger (JIRA)

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

Oliver Heger resolved CONFIGURATION-285.

Resolution: Fixed

DefaultConfigurationBuilder now fires an error event when loading of an
optional configuration source fails.

If I understand this request correctly, you want to distinguish between cases
where an optional configuration cannot be found and where it is present, but
loading it causes an error. However this is not possible: Being present is
specific for file-based configurations, but an optional configuration could be
anything, e.g. a JNDI or database configuration. How could we decide, based on
the thrown exceptions, whether the current problem was caused by a
non-available configuration source or by a source that is available, but cannot
be accessed because of an internal error?

With the error listener mechanism you can hook into the process of loading the
declared configuration sources. If an error occurs, you are notified and can
make this decision yourself based on any criteria suitable for your concrete
application and use case.

configuration fileName=local-configuration.xml config-optional=true /
does not report parsing errors in local-configuration.xml
-

--
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: (POOL-94) GenericObjectPool allows checking in of previously checked in objects

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

Phil Steitz resolved POOL-94.
-

Resolution: Won't Fix

Javadoc has been updated to include a warning.

GenericObjectPool allows checking in of previously checked in objects
-

Key: POOL-94
URL: https://issues.apache.org/jira/browse/POOL-94
Project: Commons Pool
Issue Type: New Feature
Affects Versions: 1.3
Environment: JDK 1.4.2, web application running under Tomcat 5.0.25
Reporter: Tim McCollough
Priority: Minor

I am using GenericObjectPool to store a pool of socket connections. While
debugging the application I noticed that the result of GetNumActive() was
becoming more and more negative, while the GetNumIldle() count was ever
increasing. Further debug showed that my application was returning the same
connection more than once and the GenericObjectPool implementation accepted
the return silently and decremented the active count and incremented the idle
count.
I don't object to GenericObjectPool allowing multiple returns on the same
object, but the bookkeeping problem will lead to bad things happening in the
pool management code.
I am investigating what it would take to fix GenericObjectPool but since I am
inexperienced in these commons projects I don't know what I should do from
here.

--
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: (DBCP-232) maxWait = 0 waits indefinitely too, not only maxWait = -1


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

Phil Steitz resolved DBCP-232.
--

Resolution: Fixed

Javadoc fix committed in  r558394.  Thanks for reporting thi

 maxWait = 0  waits indefinitely too, not only maxWait = -1
 --

 Key: DBCP-232
 URL: https://issues.apache.org/jira/browse/DBCP-232
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: all
Reporter: Peter Welkenbach
Priority: Critical

 the documentation describes the maxWait property as:
 The maximum number of milliseconds that the pool will wait (when there are 
 no available connections) for a connection to be returned before throwing an 
 exception, or -1 to wait indefinitely.
 this seems to be wrong. Compared to the source code it should be
 for a connection to be returned before throwing an exception, or -1 or 0 to 
 wait indefinitely.  
 in the source code of class GenericObjectPool the comparison is  maxWait = 
 0

-- 
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-284) ability to read OS environment variables

2007-07-21 Thread Vasily Ivanov (JIRA)


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

Vasily Ivanov commented on CONFIGURATION-284:
-

Thanks Oliver, feel free to add that code anywhere you want.

 ability to read OS environment variables
 

 Key: CONFIGURATION-284
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
 Project: Commons Configuration
  Issue Type: New Feature
  Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
 Attachments: EnvironmentConfiguration.java


 suggestion:
 interpolation with system environment, i.e.
 ${sys:user.name} reads from systemproperties (as of today)
 ${sysenv:TEMP} reads from OS environment
 these can be parsed from a supported set of OS's - windows read from a set in 
 a cmd /c, unix/linux from an env etc. (just once on demand)

-- 
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: (MATH-167) ConvergenceException in normal CDF


[ 
https://issues.apache.org/jira/browse/MATH-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514453
 ] 

Phil Steitz commented on MATH-167:
--

Fixed for nomal distribution in r558450.
Leaving open because we should look at other distributions before closing.  

 ConvergenceException in normal CDF
 --

 Key: MATH-167
 URL: https://issues.apache.org/jira/browse/MATH-167
 Project: Commons Math
  Issue Type: Bug
Reporter: Mikko Kauppila
Priority: Minor
 Fix For: 1.2


 NormalDistributionImpl::cumulativeProbability(double x) throws 
 ConvergenceException
 if x deviates too much from the mean. For example, when x=+/-100, mean=0, 
 sd=1.
 Of course the value of the CDF is hard to evaluate in these cases,
 but effectively it should be either zero or one.

-- 
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] Updated: (MATH-167) ConvergenceException in normal CDF


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

Phil Steitz updated MATH-167:
-

Fix Version/s: 1.2

 ConvergenceException in normal CDF
 --

 Key: MATH-167
 URL: https://issues.apache.org/jira/browse/MATH-167
 Project: Commons Math
  Issue Type: Bug
Reporter: Mikko Kauppila
Priority: Minor
 Fix For: 1.2


 NormalDistributionImpl::cumulativeProbability(double x) throws 
 ConvergenceException
 if x deviates too much from the mean. For example, when x=+/-100, mean=0, 
 sd=1.
 Of course the value of the CDF is hard to evaluate in these cases,
 but effectively it should be either zero or one.

-- 
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: (DBCP-155) [dbcp] allow to set = 6 parameters to do non-global SSL

2007-07-20 Thread Ralf Hauser (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514125
 ] 

Ralf Hauser commented on DBCP-155:
--

I certainly agree that you should not break the standards. However, if you can 
offer a structure that can operate with global system properties (a blunt 
standard that has definitely almost outlived itself), but also allows to 
support thread-safe connection factories, I don't why you shouldn't do that see 
also DBCP-152.

 [dbcp] allow to set = 6 parameters to do non-global SSL
 

 Key: DBCP-155
 URL: https://issues.apache.org/jira/browse/DBCP-155
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html,
 it should be possible to call DriverManager.getConnection() with properties
 to replace the below 4:
 -Djavax.net.ssl.keyStore=path_to_keystore_file
 -Djavax.net.ssl.keyStorePassword=*
 -Djavax.net.ssl.trustStore=path_to_truststore_file
 -Djavax.net.ssl.trustStorePassword=* 
 futhermore, adding a property
 - useSSL and
 - requireSSL
 would also help.
 plus the socketFactory-Class I asked for before (COM-2747)

-- 
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: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)

2007-07-20 Thread Ralf Hauser (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514130
 ] 

Ralf Hauser commented on DBCP-152:
--

Allowing for a non-global SSL socket factory has nothing to do with mysql. Even 
if JDBC as a standard has not arrived there yet in their thinking, it it is 
relatively easy why not adding a concept that can support good security without 
jdbc. Socket security after all may well be considered as an orthogonal issue 
to both JDBC and RDBMs behind them.

Anyway, just because you personally don't have the time to contribute that (and 
neither do I for now unfortunately :(  ), I think it is a lame approach to 
resolve enhancement requests as won't fix since there may be someone else who 
has the time to do so.

see also DBCP-155

 [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL 
 thread-safe)
 

 Key: DBCP-152
 URL: https://issues.apache.org/jira/browse/DBCP-152
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 An app that accesses 2 datasources at two different places with different
 security policies via SSL (different set of permitted ciphers) currently is 
 out
 of luck (http://lists.mysql.com/java/8689).
 The basic datasource should be enhanced with 
  
   String socketFactory = ;
 and the corresponding getter and setter method, etc.
 org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then
 hand-over this full className via its Properties argument to enable different
 SSL policies per datasource (so, since the application programmer doesn't have
 the thread under her control, I guess it should rather be called 
 dataSource-safe).
 The jdbc driver implementation can then use this to take the appropriate 
 socket
 factory when creating a connection.
 See also http://lists.mysql.com/java/8695

-- 
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] Created: (NET-164) WhoisClient should not use the platform's default Encoding

2007-07-20 Thread Ulrich Mayring (JIRA)

WhoisClient should not use the platform's default Encoding
--

 Key: NET-164
 URL: https://issues.apache.org/jira/browse/NET-164
 Project: Commons Net
  Issue Type: Improvement
Reporter: Ulrich Mayring


Currently the WhoisClient is extending the FingerClient, which sends its 
request like so:

output = new DataOutputStream(new BufferedOutputStream(_output_, 1024));
output.writeBytes(__query.toString());

This obviously uses the platform's default encoding, which may be workable for 
Finger requests, but today's Whois services oftentimes support foreign 
characters via some IDN scheme and therefore usually run under utf-8. It should 
therefore either be configurable which encoding is used for the request, or, 
alternatively, the query interface should be changed to not accept strings, but 
only bytes. Then it's the client's responsibility to do the appropriate thing.

As it is now, there is no way to use this WhoisClient for IDN-aware Whois 
registries.

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-20 Thread Peter Fassev (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514170
]

Peter Fassev commented on TRANSACTION-9:

Regarding the JCR (Java Content Repository), I don't think we are doing the
same thing. Here is the short description from the JCP 170 Site:

A Content Repository is a high-level information management system that is a
superset of traditional data repositories. A content repository implements
content services such as: author based versioning, full textual searching,
fine grained access control, content categorization and content event
monitoring. It is these content services that differentiate a Content
Repository from a Data Repository.

The JCP is about content, and not just about transactional file system access.
The file access may be a part of such system, but I think there are also other
application areas. For instance, I don't like the Idea of saving and retrieving
2 GByte files in RDBS - I would prefer to manage them as pure files.

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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] Created: (NET-165) FTP: using stat to retrieve dirlisting over control connection

2007-07-20 Thread Stefan Tauner (JIRA)

FTP: using stat to retrieve dirlisting over control connection


 Key: NET-165
 URL: https://issues.apache.org/jira/browse/NET-165
 Project: Commons Net
  Issue Type: Wish
Reporter: Stefan Tauner
Priority: Minor


dirlisting over a data connection with list is usually quite slow in 
comparision with stat because the latter doesnt need to set up a data 
connection but gets all data back through the control connection.

the behaviour is defined in rfc 959 (_the_ ftp rfc) on page 33 (STATUS 
(STAT)).
i am new to commons net, so i am not sure whats the best way to implement this, 
but i think an option to turn the existing FTPClient.listFiles() methods into 
using stat instead of list would be the best option. that way it would not 
break any existing code and the upgrade would be easy too...

i am not sure how many server implementations are actually supporting this, but 
mine does and since it would be optional (and non default) behaviour, i dont 
think thats a problem anyway.

-- 
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] Updated: (DBCP-53) 'not supported' error given against Firebird DB

2007-07-20 Thread Henri Yandell (JIRA)


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

Henri Yandell updated DBCP-53:
--

Summary: 'not supported' error given against Firebird DB  (was: [dbcp] 
commons dbcp does not supports Firebird DB.)

 'not supported' error given against Firebird DB
 ---

 Key: DBCP-53
 URL: https://issues.apache.org/jira/browse/DBCP-53
 Project: Commons Dbcp
  Issue Type: Bug
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: DMoL
 Fix For: 1.3


 I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple 
 example
 not works. Here is the log output:
 15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory
 setProperty
 SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported
 by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS

-- 
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] Updated: (NET-164) WhoisClient should not use the platform's default Encoding

2007-07-20 Thread Ulrich Mayring (JIRA)

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

Ulrich Mayring updated NET-164:
---

Attachment: FingerClient.java

FingerClient can now accept encoding as additional parameter. Old method calls
new method with encoding parameter null, so old behavior remains unchanged.

WhoisClient should not use the platform's default Encoding
--

Key: NET-164
URL: https://issues.apache.org/jira/browse/NET-164
Project: Commons Net
Issue Type: Improvement
Reporter: Ulrich Mayring
Attachments: FingerClient.java

Currently the WhoisClient is extending the FingerClient, which sends its
request like so:
output = new DataOutputStream(new BufferedOutputStream(_output_, 1024));
output.writeBytes(__query.toString());
This obviously uses the platform's default encoding, which may be workable
for Finger requests, but today's Whois services oftentimes support foreign
characters via some IDN scheme and therefore usually run under utf-8. It
should therefore either be configurable which encoding is used for the
request, or, alternatively, the query interface should be changed to not
accept strings, but only bytes. Then it's the client's responsibility to do
the appropriate thing.
As it is now, there is no way to use this WhoisClient for IDN-aware Whois
registries.

--
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-20 Thread Oliver Zeigermann (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514215
]

Oliver Zeigermann commented on TRANSACTION-9:
-

Locking
===

I agree to what Peter says about locking of files/folders and locking in
general. What about a HierarchicalLockManager that takes care of all that stuff
for us? Might even be reuseable. I will add an empty impementation for us to
remember to later fill it.

Interfaces

I will add the interfaces to the SVN soon. Let us base further discussions on
what is in SVN from then on. That might make things a bit easier. I will also
propose a simple interceptor (instead of listener) concept that is inspired
by how it works in XA and Spring MVC.

Concerning Jörg's comments:
1. setProperty() is supposed to return the old value, but maybe that does not
make that much sense? WDYT?
2. append has been added to writeStream()
3. the filter thing sounds interesting: Do you have code for that?
4. I have no really elegant solution to the create-Problem. Distinguishing
between FileResource and DirectoryResource introduces many problems, some of
them requiring excessive casting. I have been there before. Currently I favor
the createAsFile/Directory() solution.

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)

[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514273
]

Dain Sundstrom commented on DBCP-152:
-

Ralf,

Security is a very important issue for me, so I'm not saying that I don't want
to support security features or that I don't want anyone to implement security
fixes.

You are requesting that we add a socketFactory factory property to DBCP, which
is about 7 lines of code. The problem is once we add this property, we have no
standard way to pass this information to the JDBC driver. One option, as you
have suggested, is to add the socketFactory property to the properties object
passed to driver.connect(url, properties). If that is your ultimate goal, we
already have a mechanism in DBCP to pass properties to the connection factory
addConnectionProperty(name, value). Additionally, since there is no standard
for this property, it is likely that any vendor that supported the property
chose a different name (e.g., socketFactoryName, sockteFactoryClass, etc.).

There are other databases that pass this type of connection security
information via the JDBC connect URL, which makes since since the security
properties apply to all connections and not just a single connection.
Unfortunately, there is no standard way to encode properties into a JDBC
connect URL. Fortunately, we have a standard set the connect URL setUrl(url).

To reiterate, security is very important to me, and if there were a standard
way to support this type of configuration, I would submit a patch. In this
specific case, I think there is any way to support your request without it
being vendor specific, and I do not want to see DBCP expanded with vendor
specific extensions.

I suggest that you make a request for enhancement with the JDBC expert group
(http://jcp.org/en/jsr/detail?id=221), and if they approve security
enhancements, we will support them.

[DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL
thread-safe)

Key: DBCP-152
URL: https://issues.apache.org/jira/browse/DBCP-152
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 1.2
Environment: Operating System: All
Platform: Other
Reporter: Ralf Hauser
Priority: Minor
Fix For: 1.3

An app that accesses 2 datasources at two different places with different
security policies via SSL (different set of permitted ciphers) currently is
out
of luck (http://lists.mysql.com/java/8689).
The basic datasource should be enhanced with

String socketFactory = ;
and the corresponding getter and setter method, etc.
org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then
hand-over this full className via its Properties argument to enable different
SSL policies per datasource (so, since the application programmer doesn't have
the thread under her control, I guess it should rather be called
dataSource-safe).
The jdbc driver implementation can then use this to take the appropriate
socket
factory when creating a connection.
See also http://lists.mysql.com/java/8695

--
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] Updated: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock


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

Dain Sundstrom updated DBCP-44:
---

Attachment: DBCP-44.patch

This is an architectural problem in commons-pool.  
GenericObjectPool.borrowObject() is synchronized so when it needs to make a new 
object, that method is called within a synchronized block.  Here are the stack 
traces of the deal lock in our case:

[EMAIL PROTECTED], priority=5, in group 'main', status: 'MONITOR'
 blocks [EMAIL PROTECTED]
 waiting for [EMAIL PROTECTED]
  borrowObject():781, GenericObjectPool.java
  connect():176, PoolingDriver.java
  getConnection():525, DriverManager.java
  getConnection():140, DriverManager.java
  main():107, Deadlock.java

[EMAIL PROTECTED] daemon, priority=5, in group 'main', status: 'MONITOR'
 blocks [EMAIL PROTECTED]
 waiting for [EMAIL PROTECTED]
  getConnection():138, DriverManager.java
  createConnection():68, DriverManagerConnectionFactory.java
  makeObject():329, PoolableConnectionFactory.java
  addObject():1059, GenericObjectPool.java
  ensureMinIdle():1040, GenericObjectPool.java
  access$100():128, GenericObjectPool.java
  run():1117, GenericObjectPool.java
  mainLoop():512, Timer.java
  run():462, Timer.java

This is a classic two lock dead lock.  The main thread acquires the locks on 
DriveManager then GenericObjectPool, and at the same time the timer thread 
attempts to acquire them in the opposite order GenericObjectPool and then 
DriveManger.

There are really only two ways to fix this 1) guarantee locks are always 
acquired in the same order or 2) eliminate one of the locks.  The first one is 
not really possible as both objects are generally publicly accessible, and the 
second fix will require a complex change to the GenericObjectPool code.  

Attached is a patch that adds the Deadlock class, which has a main method that 
causes the dead lock.The patch also fixes the synchronization in 
PoolableConnectionFactory.  I also added property to TesterDriver to cause the 
thread to sleep in getConnection so the dead lock can be reproduced.

I'm going to attempt to write a new pool using the Java5 concurrent code which 
doesn't call makeObject inside of a synchronized block.



 [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
 -

 Key: DBCP-44
 URL: https://issues.apache.org/jira/browse/DBCP-44
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Operating System: All
 Platform: All
Reporter: Eric Layton
 Fix For: 1.3

 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, 
 testConcurrency.java


 The GenericObjectPool Evictor thread can potentially cause a deadlock between
 its connection factory and java.sql.DriverManager.  The deadlock occurs when 
 the
 Evictor thread is trying to make enough connections to bring the pool's idle
 connections up to what's specified in minIdle, at the same time a connection 
 is
 being requested through DriverManager.getConnection().  See the attached stack
 trace dump:
 Found one Java-level deadlock:
 =
 Thread-0:
   waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
   which is held by main
 main:
   waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
 org.apache.commons.dbcp.PoolableConnectionFactory),
   which is held by Thread-0
  
 Java stack information for the threads listed above:
 ===
 Thread-0:
 at java.sql.DriverManager.getConnection(DriverManager.java:158)
 - waiting to lock 0x698c2b48 (a java.lang.Class)
 at
 org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - locked 0x65df7030 (a 
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
 at
 org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
 at
 org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
 at
 org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
 at java.lang.Thread.run(Thread.java:595)
 main:
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - waiting to lock 0x65df7030 (a
 org.apache.commons.dbcp.PoolableConnectionFactory

[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock

2007-07-20 Thread JIRA


[ 
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514358
 ] 

Holger Hoffstätte commented on DBCP-44:
---

Hi Dain, I agree that the evictor thread is problematic (it should go away 
and/or be replaced by a custom evictor thingy that gets scheduled externally), 
but it is not clear to me how you could make makeObject() non-synchronized. If 
you want to go for the usual create-and-CAS pattern you risk a potential double 
allocation, and pool is definitely used for situations where this would be 
*very* bad.
A multi-staged locking hierarchy (implemented with the new ReentrantReadWrite 
locks) could help us to the effect that you outlined wrt. the lock ordering. 
Entering readers (pool consumers) all would have to pass the global writer lock 
entrance; once someone is inside, the periodic evictor has to enqueue at the 
fron t door until he gets the write lock, and can proceed.
Completely concurrent (lock-free) eviction would be much harder.
A mutli-staged locking hierarchy would also enable us to properly decouple some 
of the other paths inside borrow/returnObject. For returnObject I have already 
submitted such a simple patch.


 [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
 -

 Key: DBCP-44
 URL: https://issues.apache.org/jira/browse/DBCP-44
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Operating System: All
 Platform: All
Reporter: Eric Layton
 Fix For: 1.3

 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, 
 testConcurrency.java


 The GenericObjectPool Evictor thread can potentially cause a deadlock between
 its connection factory and java.sql.DriverManager.  The deadlock occurs when 
 the
 Evictor thread is trying to make enough connections to bring the pool's idle
 connections up to what's specified in minIdle, at the same time a connection 
 is
 being requested through DriverManager.getConnection().  See the attached stack
 trace dump:
 Found one Java-level deadlock:
 =
 Thread-0:
   waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
   which is held by main
 main:
   waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
 org.apache.commons.dbcp.PoolableConnectionFactory),
   which is held by Thread-0
  
 Java stack information for the threads listed above:
 ===
 Thread-0:
 at java.sql.DriverManager.getConnection(DriverManager.java:158)
 - waiting to lock 0x698c2b48 (a java.lang.Class)
 at
 org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - locked 0x65df7030 (a 
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
 at
 org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
 at
 org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
 at
 org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
 at java.lang.Thread.run(Thread.java:595)
 main:
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - waiting to lock 0x65df7030 (a
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
 at 
 org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
 at java.sql.DriverManager.getConnection(DriverManager.java:525)
 - locked 0x698c2b48 (a java.lang.Class)
 at java.sql.DriverManager.getConnection(DriverManager.java:193)
 - locked 0x698c2b48 (a java.lang.Class)
 at Deadlock.main(Deadlock.java:83)
  
 Found 1 deadlock.
 The deadlock occurs when GenericObjectPool.addObject() calls synchronized 
 method
 PoolableConnectionFactory.makeObject(), meanwhile static synchronized
 DriverManager.getConnection() is called.  makeObject() waits for the lock on
 DriverManager to be released, whereas DriverManager waits for the lock on the
 PoolableConnectionFactory instance to be released.
 The Java program below, based on ManualPoolingDriverExample.java provided with
 DBCP, duplicates the deadlock for me within several seconds of being run:
 import java.sql.*;
 import org.apache.commons.pool.*;
 import org.apache.commons.pool.impl.*;
 import org.apache.commons.dbcp.*;
  
 /**
  * Duplicate DBCP pool deadlocking.
  *
  * Compile

[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock


[ 
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514362
 ] 

Dain Sundstrom commented on DBCP-44:


This will take experimentation, but off the top of my head, I'd do somthing 
like this:

while(true) {
  synchronized(idleCollection) {
if (!idleCollection.isEmpty()) {
  return idleCollection.removeFirst();
}
  }

  Future future = this.allocationFutureAtomic.get();
  if (allocationFuture == null) {
future = new AllocationFuture();
if  (this.allocationFutureAtomic.weakCompareAndSet(null, future)) {
   future.get();
}
  }
}

The AllocationFuture would create new connection(s), add them to the idle pool, 
and then clear the future atomic.  Of course this can be done with primitives, 
but it is more painful to code.  It would be cleaner to use an executor to 
process the future, so it can potentially be done on another thread which isn't 
holding locks, and if the makeObject() hangs you, don't have to interrupt an 
application thread.  All of this becomes more difficult when you try to 
implement a keyed pool due to double book keeping of a global count and per key 
count.

Anyway, I'll experiment with some implementations and if I come up with 
anything good, I'll post it.



 [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
 -

 Key: DBCP-44
 URL: https://issues.apache.org/jira/browse/DBCP-44
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Operating System: All
 Platform: All
Reporter: Eric Layton
 Fix For: 1.3

 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, 
 testConcurrency.java


 The GenericObjectPool Evictor thread can potentially cause a deadlock between
 its connection factory and java.sql.DriverManager.  The deadlock occurs when 
 the
 Evictor thread is trying to make enough connections to bring the pool's idle
 connections up to what's specified in minIdle, at the same time a connection 
 is
 being requested through DriverManager.getConnection().  See the attached stack
 trace dump:
 Found one Java-level deadlock:
 =
 Thread-0:
   waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
   which is held by main
 main:
   waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
 org.apache.commons.dbcp.PoolableConnectionFactory),
   which is held by Thread-0
  
 Java stack information for the threads listed above:
 ===
 Thread-0:
 at java.sql.DriverManager.getConnection(DriverManager.java:158)
 - waiting to lock 0x698c2b48 (a java.lang.Class)
 at
 org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - locked 0x65df7030 (a 
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
 at
 org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
 at
 org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
 at
 org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
 at java.lang.Thread.run(Thread.java:595)
 main:
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - waiting to lock 0x65df7030 (a
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
 at 
 org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
 at java.sql.DriverManager.getConnection(DriverManager.java:525)
 - locked 0x698c2b48 (a java.lang.Class)
 at java.sql.DriverManager.getConnection(DriverManager.java:193)
 - locked 0x698c2b48 (a java.lang.Class)
 at Deadlock.main(Deadlock.java:83)
  
 Found 1 deadlock.
 The deadlock occurs when GenericObjectPool.addObject() calls synchronized 
 method
 PoolableConnectionFactory.makeObject(), meanwhile static synchronized
 DriverManager.getConnection() is called.  makeObject() waits for the lock on
 DriverManager to be released, whereas DriverManager waits for the lock on the
 PoolableConnectionFactory instance to be released.
 The Java program below, based on ManualPoolingDriverExample.java provided with
 DBCP, duplicates the deadlock for me within several seconds of being run:
 import java.sql.*;
 import org.apache.commons.pool.*;
 import org.apache.commons.pool.impl.*;
 import

[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock


[ 
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514364
 ] 

Dain Sundstrom commented on DBCP-44:


BTW it isn't the evictor thread that is problematic per say (it could have 
other issues :)).  It is the fact that when generic object pool calls 
makeObject it is holding a lock on the whole pool.  This type of lock holding 
open out call is bound to cause dead locks.  The example in this issue is a 
dead lock between a thread using a DBCP pool to get a connection and a thread 
that goes directly to the DriveManager for a connection.  

 [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
 -

 Key: DBCP-44
 URL: https://issues.apache.org/jira/browse/DBCP-44
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Operating System: All
 Platform: All
Reporter: Eric Layton
 Fix For: 1.3

 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, 
 testConcurrency.java


 The GenericObjectPool Evictor thread can potentially cause a deadlock between
 its connection factory and java.sql.DriverManager.  The deadlock occurs when 
 the
 Evictor thread is trying to make enough connections to bring the pool's idle
 connections up to what's specified in minIdle, at the same time a connection 
 is
 being requested through DriverManager.getConnection().  See the attached stack
 trace dump:
 Found one Java-level deadlock:
 =
 Thread-0:
   waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
   which is held by main
 main:
   waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
 org.apache.commons.dbcp.PoolableConnectionFactory),
   which is held by Thread-0
  
 Java stack information for the threads listed above:
 ===
 Thread-0:
 at java.sql.DriverManager.getConnection(DriverManager.java:158)
 - waiting to lock 0x698c2b48 (a java.lang.Class)
 at
 org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - locked 0x65df7030 (a 
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
 at
 org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
 at
 org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
 at
 org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
 at java.lang.Thread.run(Thread.java:595)
 main:
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - waiting to lock 0x65df7030 (a
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
 at 
 org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
 at java.sql.DriverManager.getConnection(DriverManager.java:525)
 - locked 0x698c2b48 (a java.lang.Class)
 at java.sql.DriverManager.getConnection(DriverManager.java:193)
 - locked 0x698c2b48 (a java.lang.Class)
 at Deadlock.main(Deadlock.java:83)
  
 Found 1 deadlock.
 The deadlock occurs when GenericObjectPool.addObject() calls synchronized 
 method
 PoolableConnectionFactory.makeObject(), meanwhile static synchronized
 DriverManager.getConnection() is called.  makeObject() waits for the lock on
 DriverManager to be released, whereas DriverManager waits for the lock on the
 PoolableConnectionFactory instance to be released.
 The Java program below, based on ManualPoolingDriverExample.java provided with
 DBCP, duplicates the deadlock for me within several seconds of being run:
 import java.sql.*;
 import org.apache.commons.pool.*;
 import org.apache.commons.pool.impl.*;
 import org.apache.commons.dbcp.*;
  
 /**
  * Duplicate DBCP pool deadlocking.
  *
  * Compile with:
  * /usr/java/jdk1.5.0/bin/javac
  * -classpath 
 commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
  * Deadlock.java
  *
  * Run with:
  * /usr/java/jdk1.5.0/bin/java
  * -classpath
 commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
  * Deadlock
  *
  * Locks still occur when compiled and run with J2SDK 1.4.1_03.
  */
 public class Deadlock {
  
 private static final int ACTIVE = 10;
  
 private static void init() {
 System.out.println(Loading drivers);
  
 try

[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock


[ 
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514366
 ] 

Dain Sundstrom commented on DBCP-44:


Ok one more comment before I get lunch  My sample code above is bad.  It is 
a hard loop (duh).  Instead of hard looping, the second check on the 
idleCollection could wait for a item to become available (easy with a 
concurrent queue).  Which leave the possibility that someone sneaks  in and 
steals the new connection we were waiting for :(  As, I said it will take some 
experimentation to get this right, but that is the fun part.

 [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
 -

 Key: DBCP-44
 URL: https://issues.apache.org/jira/browse/DBCP-44
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: Operating System: All
 Platform: All
Reporter: Eric Layton
 Fix For: 1.3

 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, 
 testConcurrency.java


 The GenericObjectPool Evictor thread can potentially cause a deadlock between
 its connection factory and java.sql.DriverManager.  The deadlock occurs when 
 the
 Evictor thread is trying to make enough connections to bring the pool's idle
 connections up to what's specified in minIdle, at the same time a connection 
 is
 being requested through DriverManager.getConnection().  See the attached stack
 trace dump:
 Found one Java-level deadlock:
 =
 Thread-0:
   waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
   which is held by main
 main:
   waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
 org.apache.commons.dbcp.PoolableConnectionFactory),
   which is held by Thread-0
  
 Java stack information for the threads listed above:
 ===
 Thread-0:
 at java.sql.DriverManager.getConnection(DriverManager.java:158)
 - waiting to lock 0x698c2b48 (a java.lang.Class)
 at
 org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - locked 0x65df7030 (a 
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
 at
 org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
 at
 org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
 at
 org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
 at java.lang.Thread.run(Thread.java:595)
 main:
 at
 org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
 - waiting to lock 0x65df7030 (a
 org.apache.commons.dbcp.PoolableConnectionFactory)
 at
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
 at 
 org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
 at java.sql.DriverManager.getConnection(DriverManager.java:525)
 - locked 0x698c2b48 (a java.lang.Class)
 at java.sql.DriverManager.getConnection(DriverManager.java:193)
 - locked 0x698c2b48 (a java.lang.Class)
 at Deadlock.main(Deadlock.java:83)
  
 Found 1 deadlock.
 The deadlock occurs when GenericObjectPool.addObject() calls synchronized 
 method
 PoolableConnectionFactory.makeObject(), meanwhile static synchronized
 DriverManager.getConnection() is called.  makeObject() waits for the lock on
 DriverManager to be released, whereas DriverManager waits for the lock on the
 PoolableConnectionFactory instance to be released.
 The Java program below, based on ManualPoolingDriverExample.java provided with
 DBCP, duplicates the deadlock for me within several seconds of being run:
 import java.sql.*;
 import org.apache.commons.pool.*;
 import org.apache.commons.pool.impl.*;
 import org.apache.commons.dbcp.*;
  
 /**
  * Duplicate DBCP pool deadlocking.
  *
  * Compile with:
  * /usr/java/jdk1.5.0/bin/javac
  * -classpath 
 commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
  * Deadlock.java
  *
  * Run with:
  * /usr/java/jdk1.5.0/bin/java
  * -classpath
 commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
  * Deadlock
  *
  * Locks still occur when compiled and run with J2SDK 1.4.1_03.
  */
 public class Deadlock {
  
 private static final int ACTIVE = 10;
  
 private static void init() {
 System.out.println(Loading drivers);
  
 try

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-19 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513844
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

Yes. Something like a select for update right? This could also be a means to 
reduce deadlock hazards.

unlock() certainly is not needed and even dangerous as no locks must not be 
released before the end of the transaction to ensure serializability.  

OK. What about that:

public interface Resource {
String getPath();
boolean isDirectory();
boolean isFile();
CollectionResource getChildren() throws IOException, LockException;
InputStream readStream() throws IOException, LockException;
OutputStream writeStream() throws IOException, LockException;
boolean delete() throws IOException, LockException;
boolean move(String destinationpath) throws IOException, LockException;
boolean copy(String destinationpath) throws IOException, LockException;

// plus more general properties
   // among them could be length, lastmodfied, etc.
MapString, Property getProperties();
void setProperties(MapString, Property newProperties);

// plus locking methods
void readLock();
void writeLock();
boolean tryReadLock();
boolean tryWriteLock();
} 

public interface Property {
   String getName();
   Object getValue();
   Object setValue(Object newValue);
   Class getType(); 
}

Is that better? Still anything missing?

 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: https://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Assignee: Oliver Zeigermann
Priority: Minor
 Fix For: 2.0

 Attachments: filemanager.zip


 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-19 Thread JIRA

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513906
]

Jörg Heinicke commented on TRANSACTION-9:
-

There seems to be an inconsistency: How to lock a not-yet-existing physical
resource that is about to be created? We can follow the java.io.File
semantics here and allow Resource instantiation for non-existing physical
resources. Then Resource should have a create method as File has. Otherwise
lock methods should be moved to ResourceManager. I prefer the first one which
removes create* from ResourceManager.

I wonder if we need the generalization Property. Also, in which way is the key
in the map different from the name of the Property? If we do it the generalized
way I'd use getProperty(String) and setProperty(String, Object), maybe
additionally a getPropertyNames(). The Map is implementation. And always being
forced to set all properties at once using setProperties(Map) does not make
much sense IMO.

readStream() and writeStream() should be in Java Bean style with get.

What's the use of try*Lock()?

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-19 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513925
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

I do agree concerning properties and Resource vs. ResourceManager. This is my 
new proposal

public interface Resource {
String getPath();
boolean isDirectory();
boolean isFile();

CollectionResource getChildren() throws IOException, LockException;
Resource getParent() throws IOException, LockException;

InputStream readStream() throws IOException, LockException;
OutputStream writeStream() throws IOException, LockException;

boolean delete() throws IOException, LockException;
boolean move(String destinationpath) throws IOException, LockException;
boolean copy(String destinationpath) throws IOException, LockException;
boolean exists();
void createDirectory() throws IOException, LockException;
void createFile() throws IOException, LockException;

// plus more general properties
   // among them could be length, lastmodfied, etc.
Object getProperty(String name);
Object setProperty(String name, Object newValue);

// plus locking methods
void readLock();
void writeLock();
boolean tryReadLock();
boolean tryWriteLock();
}

public interface FileResourceManager {
   Resource getResource(String path) throws IOException, LockException;
   void addResourceListener(ResourceListener listener);
   void removeResourceListener(ResourceListener listener);
 } 

However, I do not agree to use bean style here, as this is no bean. This is an 
interface. It should not have bean style getters/setters.

Concerning try*Lock(): These methods are fail fast version of the lock*() ones 
which can be used to check whether you *could* acqurie a lock or not. They make 
sense if you just want to know.



 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: https://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Assignee: Oliver Zeigermann
Priority: Minor
 Fix For: 2.0

 Attachments: filemanager.zip


 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
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] Created: (BEANUTILS-290) Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project

Merge Bean-Collections back into core BeanUtils and remove Bean-Collections 
sub-project
---

 Key: BEANUTILS-290
 URL: https://issues.apache.org/jira/browse/BEANUTILS-290
 Project: Commons BeanUtils
  Issue Type: Task
  Components: Bean-Collections
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


This issue has been discussed in the following thread: http://tinyurl.com/2xdpku

For BeanUtils 1.7.0 the following classes which had a dependency on Commons 
Collections were split into a separate bean-collections sub-module:
BeanComparator.java
BeanMap.java
BeanPredicate.java
BeanPropertyValueChangeClosure.java
BeanPropertyValueEqualsPredicate.java
BeanToPropertyValueTransformer.java

Three flavours of jars were released in 1.7.0

   commons-beanutils.jar - containing all BeanUtils classes, including above 
bean-collections ones
   commons-beanutils-bean-collections.jar - containing just the above  
bean-collections classes
   commons-beanutils-core.jar - containing BeanUtils classes excluding above 
bean-collections ones

BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the 
above artifacts were manually created - unfortunately with mistakes:

1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections 
dependency (which it has for the bean-collections classes)
2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections 
dependency (which it doesn't actually have)

The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge 
the bean-collections classes back into core BeanUtils and get rid of the 
bean-collections sub-module - releasing just a single jar for BeanUtils and 
marking the Commons Collections dependency as optional in the maven pom (see 
http://tinyurl.com/2nm2bu).

-- 
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: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes

2007-07-19 Thread Rahul Akolkar (JIRA)


[ 
https://issues.apache.org/jira/browse/DIGESTER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513979
 ] 

Rahul Akolkar commented on DIGESTER-115:


But a tighter ArrayStack wouldn't work (given fix version is 1.8.1). In the 
longer run, I agree, we should wean [digester] off of the [collections] version 
of ArrayStack (doing what you suggest or just using java.util.Stack or some 
such so we will have one less class to maintain).


 Digester depends on BeanUtils copies of Collections classes
 ---

 Key: DIGESTER-115
 URL: https://issues.apache.org/jira/browse/DIGESTER-115
 Project: Commons Digester
  Issue Type: Bug
Affects Versions: 1.8
Reporter: Niall Pemberton
 Fix For: 1.8.1


 This is related to issue# BEANUTILS-278
 Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) 
 from commons BeanUtils which were copied from Commons Collections and 
 BEANUTILS-278 proposes removing them.
 ArrayStack.java
 Buffer.java
 BufferUnderflowException.java

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-19 Thread Peter Fassev (JIRA)

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513982
]

Peter Fassev commented on TRANSACTION-9:

Yes, tryLock make sense when locking a set of arbitrary resources prior to any
operation on it, and as Oliver said, it reduces the chance of a deadlock.

And I think it is possible to lock a not existing resource, because the locking
does not depend from the underlying file system. It all about Ids, and a not
created resource has an Id. Again, if you want to create a set of resource at
once, you may try to lock them first, and than execute the creation method
independently.

Sorry, for my insistence here, but I am talking about a resource management
systems in a multi user environment. Such scenarios are very common there. For
instance, think about of uploading a directory structure as a large ZIP-Archive
and than extracting all of it files. Or what about downloading a whole
directory structure as a ZIP-Archive...

One thought about directories: Adding a file to, renaming a file or deleting a
file from, or even changing a file in a directory actually changes the
structure of the directory. Before committing such changes, read lock on the
directory is not sufficient for this operation. The directory should have a
write lock, because somebody may try to read the children during the committing
operation (i.e. during the changes) and may become a inconsistent state of it.

So my attached implementation here is not quite gut on this point.

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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: (DBCP-209) Is DataSource.getConnection(user, pass) working the way it is suppose to?

[
https://issues.apache.org/jira/browse/DBCP-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514033
]

Dain Sundstrom commented on DBCP-209:
-

I believe that Michael should be using either the SharedPoolDataSource or the
PerUserPoolDataSource which support the getConnection(user, pass) method. This
pool keeps track of connection credentials, so when a connection is created, it
can locate a connection authorized for the specified user.

I think this issue should be closed as invalid.

Is DataSource.getConnection(user, pass) working the way it is suppose to?
-

Key: DBCP-209
URL: https://issues.apache.org/jira/browse/DBCP-209
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Michael Remijan
Fix For: 1.3

In Tomcat's server.xml, I create a DataSource resource using the FACTORY
org.apache.commons.dbcp.BasicDataSourceFactory and I also provide a URL and
a DRIVERCLASSNAME. However I do not provide USERNAME or PASSWORD because I
want to use DataSource.getConnection(user, pass) in my application. When I
call DataSource.getConnection(user, pass) I get the following exception,
java.sql.SQLException: invalid arguments in call, which was unexpected. I
dug into the source code for BasicDataSource and I found what I think is the
source of the problem. First, the method getConnection(user, pass) call the
createDataSource() method. The createDataSource() method creates a
Properties object and tries to put the username and password into the
properties object. However, because the server.xml file does contain a
username or password, this Properties object (named connectionProperties in
the code) is empty. The createDataSource() the proceeds to call the
validateConnectionFactory() method. This method then tries to get a
Connection object!! This attempt fails because the Properties object has no
username or password in it hence the Oracle driver complains about being
passed invalid arguments. My question is why is the code working this way?
Why does the createDataSource() and validateConnectionFactory() methods
assume the username and password have been set in server.xml and then attempt
to try to return a Connection object with the username and password passed to
the getConnection(user, pass) method? It would seem to me the
createDataSource() and validateConnectionFactory() methods should be aware of
the username and password passed to the getConnection(user, pass) if this
method is 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: (BEANUTILS-290) Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project


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

Niall Pemberton resolved BEANUTILS-290.
---

Resolution: Fixed

I have merged the classes and unit tests back into core BeanUtils and removed 
the bean-collections sub-module. Ant, Maven1 and Maven2 builds all work.

 Merge Bean-Collections back into core BeanUtils and remove Bean-Collections 
 sub-project
 ---

 Key: BEANUTILS-290
 URL: https://issues.apache.org/jira/browse/BEANUTILS-290
 Project: Commons BeanUtils
  Issue Type: Task
  Components: Bean-Collections
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


 This issue has been discussed in the following thread: 
 http://tinyurl.com/2xdpku
 For BeanUtils 1.7.0 the following classes which had a dependency on Commons 
 Collections were split into a separate bean-collections sub-module:
 BeanComparator.java
 BeanMap.java
 BeanPredicate.java
 BeanPropertyValueChangeClosure.java
 BeanPropertyValueEqualsPredicate.java
 BeanToPropertyValueTransformer.java
 Three flavours of jars were released in 1.7.0
commons-beanutils.jar - containing all BeanUtils classes, including above 
 bean-collections ones
commons-beanutils-bean-collections.jar - containing just the above  
 bean-collections classes
commons-beanutils-core.jar - containing BeanUtils classes excluding above 
 bean-collections ones
 BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the 
 above artifacts were manually created - unfortunately with mistakes:
 1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections 
 dependency (which it has for the bean-collections classes)
 2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections 
 dependency (which it doesn't actually have)
 The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge 
 the bean-collections classes back into core BeanUtils and get rid of the 
 bean-collections sub-module - releasing just a single jar for BeanUtils and 
 marking the Commons Collections dependency as optional in the maven pom 
 (see http://tinyurl.com/2nm2bu).

-- 
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: (DBCP-53) [dbcp] commons dbcp does not supports Firebird DB.


[ 
https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514039
 ] 

Dain Sundstrom commented on DBCP-53:


I don't think this is a DBCP issue.  My guess is your torque configuration is 
wrong, but I'm not torque expert.  The 
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS class has the following 
method:

public void setDriver(String v) throws ClassNotFoundException {
assertInitializationAllowed();
this.driver = v;
// make sure driver is registered
Class.forName(v);
}

Which can fail for two reasons.  First, if any connections have already been 
allocated from the data source, the assertInitializationAllowed method will 
throw and IllegalStateException because the data source is already actively 
creating connections for a data base.  The second place this method can fail is 
the call to Class.forName.  In either case, I don't think it is a DBCP issue.

I think we should close this as invalid, and if Torque team find a bug in DBCP, 
they can open a new issue.


 [dbcp] commons dbcp does not supports Firebird DB.
 --

 Key: DBCP-53
 URL: https://issues.apache.org/jira/browse/DBCP-53
 Project: Commons Dbcp
  Issue Type: Bug
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: DMoL
 Fix For: 1.3


 I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple 
 example
 not works. Here is the log output:
 15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory
 setProperty
 SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported
 by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS

-- 
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: (DBCP-209) Is DataSource.getConnection(user, pass) working the way it is suppose to?

2007-07-19 Thread Phil Steitz (JIRA)

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

Phil Steitz resolved DBCP-209.
--

Resolution: Invalid

I agree with Dain. For BasicDataSource, the username and password are pool
properties.

Is DataSource.getConnection(user, pass) working the way it is suppose to?
-

Key: DBCP-209
URL: https://issues.apache.org/jira/browse/DBCP-209
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Michael Remijan
Fix For: 1.3

--
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: (DBCP-97) setAutoCommit(true) when returning connection to the pool


[ 
https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514044
 ] 

Dain Sundstrom commented on DBCP-97:


Yes, this is correct.  When auto commit is off, you have an open transaction 
with the database, so leaving auto commit off while a connection is idle in the 
pool is a bad idea.

One note.  The current passivate code has the following block:

conn.clearWarnings();
if(!conn.getAutoCommit()) {
conn.setAutoCommit(true);
}

Do we want the clearWarnings() after the potential autocommit change?

 setAutoCommit(true) when returning connection to the pool
 -

 Key: DBCP-97
 URL: https://issues.apache.org/jira/browse/DBCP-97
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Dirk Verbeeck
 Fix For: 1.3


 From the Struts user list: [OT] RE: Stackoverflow after DB inactivity 
 (MySQL reconnect problem)
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg70196.html
 Giving a hint to the database driver that you don't need long running
 transactions makes sense. 
 setAutoCommit(true) should be added to 
 PoolableConnectionFactory.passivateObject

-- 
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] Updated: (BEANUTILS-280) Check binary compatibility is still good


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

Niall Pemberton updated BEANUTILS-280:
--

Attachment: (was: CLIRR.txt)

 Check binary compatibility is still good
 

 Key: BEANUTILS-280
 URL: https://issues.apache.org/jira/browse/BEANUTILS-280
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
 Fix For: 1.8.0

 Attachments: CLIRR.txt


 Clirr/jardiff/whatever.

-- 
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] Updated: (BEANUTILS-280) Check binary compatibility is still good


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

Niall Pemberton updated BEANUTILS-280:
--

Attachment: CLIRR.txt

Attach latest CLIRR report showing BeanUtils trunk is binary compatible with 
version 1.7.0

 Check binary compatibility is still good
 

 Key: BEANUTILS-280
 URL: https://issues.apache.org/jira/browse/BEANUTILS-280
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
 Fix For: 1.8.0

 Attachments: CLIRR.txt


 Clirr/jardiff/whatever.

-- 
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: (DBCP-155) [dbcp] allow to set = 6 parameters to do non-global SSL


[ 
https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514053
 ] 

Dain Sundstrom commented on DBCP-155:
-

DBCP has support for JDBC connection properties.  The JSSE properties you list 
above are not JDBC properties, and must be set as Java system properties.  
Unfortunately, that is how the JSSE specification works.  Any changes to JSSE 
are beyond the scope of DBCP.

I suggest we close this as won't fix.

 [dbcp] allow to set = 6 parameters to do non-global SSL
 

 Key: DBCP-155
 URL: https://issues.apache.org/jira/browse/DBCP-155
 Project: Commons Dbcp
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html,
 it should be possible to call DriverManager.getConnection() with properties
 to replace the below 4:
 -Djavax.net.ssl.keyStore=path_to_keystore_file
 -Djavax.net.ssl.keyStorePassword=*
 -Djavax.net.ssl.trustStore=path_to_truststore_file
 -Djavax.net.ssl.trustStorePassword=* 
 futhermore, adding a property
 - useSSL and
 - requireSSL
 would also help.
 plus the socketFactory-Class I asked for before (COM-2747)

-- 
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: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)


[ 
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514054
 ] 

Dain Sundstrom commented on DBCP-152:
-

DBCP supports JDBC standard properties, so if mysql ssl can be configured via 
JDBC properties, this already works.  Unfortunately, it appears mysql ssl can 
not be configured this way, and this is effectively request for mysql specific 
features which are beyond the scope of DBCP.

I suggest we close this as won't fix.

 [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL 
 thread-safe)
 

 Key: DBCP-152
 URL: https://issues.apache.org/jira/browse/DBCP-152
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: Other
Reporter: Ralf Hauser
Priority: Minor
 Fix For: 1.3


 An app that accesses 2 datasources at two different places with different
 security policies via SSL (different set of permitted ciphers) currently is 
 out
 of luck (http://lists.mysql.com/java/8689).
 The basic datasource should be enhanced with 
  
   String socketFactory = ;
 and the corresponding getter and setter method, etc.
 org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then
 hand-over this full className via its Properties argument to enable different
 SSL policies per datasource (so, since the application programmer doesn't have
 the thread under her control, I guess it should rather be called 
 dataSource-safe).
 The jdbc driver implementation can then use this to take the appropriate 
 socket
 factory when creating a connection.
 See also http://lists.mysql.com/java/8695

-- 
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] Updated: (DBCP-110) [dbcp] DBCP removeAbandoned not working


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

Dain Sundstrom updated DBCP-110:


Summary: [dbcp] DBCP removeAbandoned not working  (was: [dbcp] Problem 
reported at forum.java.sun.com)

 [dbcp] DBCP removeAbandoned not working
 ---

 Key: DBCP-110
 URL: https://issues.apache.org/jira/browse/DBCP-110
 Project: Commons Dbcp
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: David Smiley
Priority: Minor
 Fix For: 1.3


 Read the details at the URL.  It includes a fix, I think.
 http://forum.java.sun.com/thread.jspa?threadID=658047tstart=0
 I think I've run across this bug too, a couple days ago.  I'm not sure if it 
 exactly the same issue but I got 
 the same underlying exception: java.util.NoSuchElementException: Timeout 
 waiting for idle object
 I'm using Atlantassian Confluence which is using DBCP.

-- 
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] Updated: (DBCP-207) DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...))


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

Dain Sundstrom updated DBCP-207:


Attachment: DBCP-207.patch

Already fixed for PoolingDataSource, but PerUserDataSource and 
SharedPoolDataSource still always set this value.  These data sources use a 
primitives for the read only,  transaction isolation and auto commit default 
values so there is not way to see if the value was not set.  This patch checks 
if the read-only and auto-commit values are already set before changing them 
which should setReadOnly from being called. 

 DBCP 1.2.1 incompatible with Informix (driver doesn't support 
 setReadOnly(...))
 ---

 Key: DBCP-207
 URL: https://issues.apache.org/jira/browse/DBCP-207
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1
 Environment: using the pooling driver component with an informix 
 driver
Reporter: Kimberly Baer
 Fix For: 1.3

 Attachments: DBCP-207.patch


 I recieved an error using commons-dbcp-1.2.1.jar and ifxjdbc.jar for my 
 informix driver: 
 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
 exhausted 
 at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183) 
 at java.sql.DriverManager.getConnection(DriverManager.java:539) 
 at java.sql.DriverManager.getConnection(DriverManager.java:211) 
 at ConnectionPoolingTest.main(ConnectionPoolingTest.java:105) 
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: Read only mode not supported 
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
  
 at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) 
 I will look into the comment provided by Dirk in bug ID DBCP-127 (version 
 1.1), but it appears this bug still has an impact in the 1.2.1 version. If 
 anyone has any other suggestions, they would be greatly appreciated. 

-- 
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: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2007-07-19 Thread JIRA

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514060
]

Jörg Heinicke commented on TRANSACTION-9:
-

Actually I'm not very keen to these lock methods at all, but if you think it's
better to have them I'm ok with it.

The only thing we should have in mind is to not invent a second JCP 170 aka JCR
(Content Repository for Java). Actually I wonder how the JCR implementations do
transactional file system access.

Regarding the interface proposal:
1. setProperty() is probably supposed to return void.
2. Thinking about it a bit more I agree on read/writeStream(). Using those in
bean style makes not much sense.
3. writeStream() should probably have boolean parameter append again.
4. I still don't like the createFile/Directory() stuff. Sounds like creating
sub resources, so it should be at least createAsFile/Directory(). But having
both makes not much sense. Isn't it more a question of implementation, e.g.
FileResource and DirectoryResource. Then create() would be sufficient.
Question: How to decide whether to create a directory or a file then? Might be
moved to ResourceManager then. What about getResource() with additional enum
type parameter? Or getDirectoryResource() and getFileResource()? Moving that
difference to the ResourceManager increases the usability IMHO. WDYT?
5. Just an idea: getChildren() matches listFiles() in File - the latter
providing filter mechanism. What about that? If we have Resource instead of
File we would also have Resource(NameFilter) - and could provide default
adapter implementation for File(Name)Filter.

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

--
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] Updated: (DBCP-150) [dbcp] BasicDataSource : setter for connectionProperties


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

Dain Sundstrom updated DBCP-150:


Attachment: DBCP-150.patch

Implementation, java doc and test case

 [dbcp] BasicDataSource : setter for connectionProperties
 

 Key: DBCP-150
 URL: https://issues.apache.org/jira/browse/DBCP-150
 Project: Commons Dbcp
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: Operating System: All
 Platform: All
Reporter: Maarten Bosteels
Priority: Minor
 Fix For: 1.3

 Attachments: DBCP-150.patch


 Adding a javabean-style setter for connectionProperties would certainly ease 
 the
 configuration of a BasicDataSource within a Dependency Injection framework (eg
 Spring).
 see: http://article.gmane.org/gmane.comp.java.springframework.user/6501/
 Thanks,
 Maarten

-- 
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] Updated: (DBCP-225) getConnection / borrowObject fails with NullPointerException


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

Dain Sundstrom updated DBCP-225:


Attachment: DBCP-225.patch

This patch checks for null returned from connection factory and throws an 
IllegalStateException.  We may want to go with a SQLException instead.

I don't think this will fix Alexei's problem, but at least will cause a fast 
failure instead of getting a strange hollow connection.  Alternatively, if we 
just need to ask Oracle again for a connection, we could put a retry loop in 
the connection factory.

 getConnection / borrowObject fails with NullPointerException
 

 Key: DBCP-225
 URL: https://issues.apache.org/jira/browse/DBCP-225
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1, 1.2.2
 Environment: Solaris 10, Oracle 10g RAC
Reporter: Alexei Samonov
 Fix For: 1.3

 Attachments: DBCP-225.patch


 We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our 
 getConnection calls fail sporadically with the following stack trace (1.2.1)
 Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a 
 connection, pool exhausted
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 ... 24 more
 This is definitely not a pool exhausted situation, it is just being 
 reported as pool exhausted. Since NoSuchElementException that you use does 
 not allow cause, only Exception message (null) is being printed. With some 
 debugging I was able to recover the root exception:
 java.lang.NullPointerException
 at 
 org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
 at 
 org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ...
 Looks like it is trying to borrow/validate DelegatingConnection which 
 delegate is null.
 Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is 
 is an exception stack trace from 1.2.2:
 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
 error Could not create a validated object, cause: null
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
 ... 28 more
 We use the following dbcp properties:
 autoCommit=false
 readOnly=false
 maxActive=200
 maxIdle=20
 minIdle=10
 minEvictableIdleIime=30
 maxWait=200
 accessToUnderlyingConnectionAllowed=true
 validationQuery=SELECT 1 FROM DUAL
 ConnectionCachingEnabled=true
 FastConnectionFailoverEnabled=true
 I could not find the existing reported dbcp/object pool bug but I see similar 
  reports on the web, for example 
 http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915

-- 
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: (BEANUTILS-280) Check binary compatibility is still good