Re: [DBCP]

2017-03-29 Thread Matt Sicker 
Using a MethodHandle lookup ahead of time to create a fast invocation proxy
and using that where available would make sense. I don't like the idea of
catching errors like that.

On 29 March 2017 at 01:53, Gary Gregory  wrote:

> Hi All:
>
> The method:
>
> org.apache.commons.dbcp2.DelegatingConnection.isValid(int)
>
> delegates to a JDBC method that is marked "@since 1.6" in the JDBC Javadoc.
>
> I am dealing with an old JDBC driver that throws an AbstractMethodError
> when this method is called.
>
> How can I workaround this? Should we add some mode to DBCP2 to deal with
> pre-1.6 JDBC drivers? If so how? Catch the AME specifically and return...
> what?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker

Re: [DBCP]

2017-03-29 Thread Gary Gregory 
On Wed, Mar 29, 2017 at 8:28 AM, Matt Sicker  wrote:

> Using a MethodHandle lookup ahead of time to create a fast invocation proxy
> and using that where available would make sense. I don't like the idea of
> catching errors like that.
>

Hi Matt,

Thank you for the tip. Do you have an example handy? (short on time today,
scrambling like a madman, otherwise I'd hack around)

Gary


>
> On 29 March 2017 at 01:53, Gary Gregory  wrote:
>
> > Hi All:
> >
> > The method:
> >
> > org.apache.commons.dbcp2.DelegatingConnection.isValid(int)
> >
> > delegates to a JDBC method that is marked "@since 1.6" in the JDBC
> Javadoc.
> >
> > I am dealing with an old JDBC driver that throws an AbstractMethodError
> > when this method is called.
> >
> > How can I workaround this? Should we add some mode to DBCP2 to deal with
> > pre-1.6 JDBC drivers? If so how? Catch the AME specifically and return...
> > what?
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  > tl?ie=UTF8=1789=9325=1617290459&
> > linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
> >
> >  > 1617290459>
> > JUnit in Action, Second Edition
> >  > tl?ie=UTF8=1789=9325=1935182021&
> > linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de4
> 18%22
> > >
> >
> >  > 1935182021>
> > Spring Batch in Action
> >  > tl?ie=UTF8=1789=9325=1935182951&
> > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  > 1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [DBCP]

2017-03-29 Thread Matt Sicker 
MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodType mt = MethodType.methodType(boolean.class, int.class);
MethodHandle handle = lookup.findVirtual(Connection.class, "isValid", mt);

// ...

boolean isValid = (boolean) handle.invokeExact(connection, timeout);

The findVirtual() call above will throw NoSuchMethodException if it doesn't
exist. This is basically the same thing as traditional reflection, but more
direct.

On 29 March 2017 at 13:09, Gary Gregory  wrote:

> On Wed, Mar 29, 2017 at 8:28 AM, Matt Sicker  wrote:
>
> > Using a MethodHandle lookup ahead of time to create a fast invocation
> proxy
> > and using that where available would make sense. I don't like the idea of
> > catching errors like that.
> >
>
> Hi Matt,
>
> Thank you for the tip. Do you have an example handy? (short on time today,
> scrambling like a madman, otherwise I'd hack around)
>
> Gary
>
>
> >
> > On 29 March 2017 at 01:53, Gary Gregory  wrote:
> >
> > > Hi All:
> > >
> > > The method:
> > >
> > > org.apache.commons.dbcp2.DelegatingConnection.isValid(int)
> > >
> > > delegates to a JDBC method that is marked "@since 1.6" in the JDBC
> > Javadoc.
> > >
> > > I am dealing with an old JDBC driver that throws an AbstractMethodError
> > > when this method is called.
> > >
> > > How can I workaround this? Should we add some mode to DBCP2 to deal
> with
> > > pre-1.6 JDBC drivers? If so how? Catch the AME specifically and
> return...
> > > what?
> > >
> > > Gary
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > >  > > tl?ie=UTF8=1789=9325=1617290459&
> > > linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2
> b8>
> > >
> > >  > > 1617290459>
> > > JUnit in Action, Second Edition
> > >  > > tl?ie=UTF8=1789=9325=1935182021&
> > > linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de4
> > 18%22
> > > >
> > >
> > >  > > 1935182021>
> > > Spring Batch in Action
> > >  > > tl?ie=UTF8=1789=9325=1935182951&
> > > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> > >  > > 1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8=1789=9325=1617290459&
> linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8=1789=9325=1935182021&
> linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8=1789=9325=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker

Re: [DBCP] isValid replacement

2017-03-29 Thread Bernd Eckenfels 
You can run a verification SQL instead. So I guess doing nothing would be fine 
as well, as the verification SQL (on borrow) could be configured instead.

Other methods which do a round trip to the database can be used as well (for 
example setAutocommit() on some drivers).

Gruss
Bernd
--
http://bernd.eckenfels.net
_
From: Gary Gregory >
Sent: Mittwoch, März 29, 2017 8:53 AM
Subject: [DBCP]
To: Commons Developers List 
>


Hi All:

The method:

org.apache.commons.dbcp2.DelegatingConnection.isValid(int)

delegates to a JDBC method that is marked "@since 1.6" in the JDBC Javadoc.

I am dealing with an old JDBC driver that throws an AbstractMethodError
when this method is called.

How can I workaround this? Should we add some mode to DBCP2 to deal with
pre-1.6 JDBC drivers? If so how? Catch the AME specifically and return...
what?

Gary

--
E-Mail: garydgreg...@gmail.com | 
ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[DBCP]

2017-03-29 Thread Gary Gregory 
Hi All:

The method:

org.apache.commons.dbcp2.DelegatingConnection.isValid(int)

delegates to a JDBC method that is marked "@since 1.6" in the JDBC Javadoc.

I am dealing with an old JDBC driver that throws an AbstractMethodError
when this method is called.

How can I workaround this? Should we add some mode to DBCP2 to deal with
pre-1.6 JDBC drivers? If so how? Catch the AME specifically and return...
what?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[GitHub] commons-compress pull request #17: CPIO crc overflow resolved for large file...

2017-03-29 Thread dcollin 
GitHub user dcollin opened a pull request:

https://github.com/apache/commons-compress/pull/17

CPIO crc overflow resolved for large files

When unpacking a CPIO file containing a large file the crc check will
overflow and throw an IOException("CRC Error...").

Did not find a nice wa to test this since it requires a very lasrge
input file.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dcollin/commons-compress crc_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/17.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #17


commit dd1ec97f687c462f4225b5efb5f9a363d7281918
Author: dcollin 
Date:   2017-03-29T11:44:22Z

CPIO crc overflow resolved for large files

When unpacking a CPIO file containing a large file the crc check will
overflow and throw an IOException("CRC Error...").

Did not find a nice wa to test this since it requires a very lasrge
input file.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress issue #17: CPIO crc overflow resolved for large files

2017-03-29 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/17
  

[![Coverage 
Status](https://coveralls.io/builds/10826707/badge)](https://coveralls.io/builds/10826707)

Coverage increased (+0.001%) to 84.176% when pulling 
**dd1ec97f687c462f4225b5efb5f9a363d7281918 on dcollin:crc_fix** into 
**785233a6fe47009e8b92db72e778f7932db978cd on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress issue #17: CPIO crc overflow resolved for large files

2017-03-29 Thread bodewig 
Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/17
  
Great, many thanks,

I've just found 
https://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt states

> The CRC format is identical to the new ASCII format described in the 
previous section except that the magic field is set to ``070702'' and the check 
field is set to the sum of all bytes in the file data.  This sum is computed 
treating all bytes as unsigned values and using unsigned arithmetic.  Only the 
least-significant 32 bits of the sum are stored.

so your patch is certainly correct.

I'm afraid we've got the same bug when writing CPIO archives. I'll take 
care of it.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #17: CPIO crc overflow resolved for large file...

2017-03-29 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/17


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org