Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 86884 invoked from network); 10 Aug 2007 20:42:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Aug 2007 20:42:30 -0000 Received: (qmail 97272 invoked by uid 500); 10 Aug 2007 20:42:20 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 97209 invoked by uid 500); 10 Aug 2007 20:42:20 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 97182 invoked by uid 99); 10 Aug 2007 20:42:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 13:42:20 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [213.46.255.22] (HELO viefep15-int.chello.at) (213.46.255.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 20:42:20 +0000 Received: from [192.168.0.4] (really [84.113.196.60]) by viefep15-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070810204156.GKDX20781.viefep15-int.chello.at@[192.168.0.4]> for ; Fri, 10 Aug 2007 22:41:56 +0200 Subject: [orchestra] ConnectionManagerDataSource and java1.6 From: simon To: dev@myfaces.apache.org Content-Type: text/plain Date: Fri, 10 Aug 2007 22:41:27 +0200 Message-Id: <1186778487.6088.48.camel@simon-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, ConnectionManagerDataSource doesn't compile with java1.6, because Sun added a new ancestor interface ("Wrapper") to DataSource:-(. The new methods are isWrapperFor and unwrap. I think the best solution is just to add stub implementations of the new methods that throw UnsupportedOperationException. On JVMs earlier than 1.6 they will obviously never be called, so no problem. And there is no need for these new methods to actually be called by users AFAIK, so an exception sounds ok. The alternative is for our implementations to use reflection on the underlying DataSource object to determine whether the methods are there at runtime, and if so then forward the call to the underlying datasource. This is quite doable, but probably not necessary. Thoughts? Simon