Awesome Patrick!  My program is now working against 5.18.1...

% perl --version
This is perl 5, version 18, subversion 1 (v5.18.1) built for darwin-thread-multi-2level
...

% cat derbytestdb.props
JDBC_CLASSPATH=/Users/russt/proj/rttl/devtools/tl/src/cmn/sqlpj/regress/drivers/derby.jar
JDBC_DRIVER_CLASS=org.apache.derby.jdbc.EmbeddedDriver
JDBC_URL=jdbc:derby:testDB;create=true
JDBC_USER=test
JDBC_PASSWORD=test

% sqlpj -props derbytestdb.props
studying classes
running
derbydb> show conn
getURL()                                                 jdbc:derby:testDB
getUserName()                                            test
getDriverName() Apache Derby Embedded JDBC Driver
getDriverVersion()                                       10.9.1.0 - (1344872)
getDatabaseProductName()                                 Apache Derby
getDatabaseProductVersion()                              10.9.1.0 - (1344872)

Based on this comment re: the "mro" pragma introduced in perl 5.10.0:

Also, the cache *::ISA::CACHE:: no longer exists; to force reset the @ISA cache, you now need to use the mro API, or more simply to assign to @ISA (e.g. with @ISA = @ISA ).

I tried this alternate fix and it works as well (tested against 5.8.9 and 5.18.1):

$ diff -c JDBC.pm.installed lib/myJDBC.pm
*** JDBC.pm.installed   2014-01-05 08:04:52.000000000 -0800
--- lib/myJDBC.pm       2014-01-05 08:05:14.000000000 -0800
***************
*** 106,111 ****
--- 106,113 ----
  warn "studying classes\n" if $debug;
  study_classes(\@classes, 'main');

+ @ISA = @ISA;
+
  # Driver => java.sql.Driver, RowSet => javax.sql.RowSet etc
  my %class_base   = map { m/^(.*\.(\w+))$/ or die; (  $2  => $1) } @classes;

Tim, any chance of getting a cpan update with a patch for JDBC.pm?

This would allow bug https://rt.cpan.org/Public/Bug/Display.html?id=50307 to be closed.

Patrick, might be worth a usage note for Inline::Java.
The obscurity of this problem could make such a note quite valuable.

best,
-Russ


At 10:02 PM -0500 1/4/14, Patrick LeBoutillier wrote:
Russ,

With that info I was able to reproduce the problem:

[patrickl@pc259 JDBC-0.01]$ perl -Mblib t/01-driver.t
1..4
CLASSPATH=/tmp/JDBC-0.01/drivers/db-derby-10.1.1.0.jar
ok 1 - driver class loaded
Can't locate object method "__validate_prototype" via package "JDBC" at (eval 31) line 344, <GEN6> line 5.
# Looks like you planned 4 tests but ran 1.
# Looks like your test exited with 255 just after 1.


To answer your question, the __validate_prototype is part of the Inline::Java::Object class, which JDBC derives via
java::sql::DriverManager.

Anyway, here's a quick patch to JDBC that fixes the problem:

--- JDBC.pm.ori 2014-01-04 21:55:24.845018833 -0500
+++ JDBC.pm     2014-01-04 21:55:49.782943330 -0500
@@ -43,8 +43,6 @@

 =cut

-our @ISA = qw(Exporter java::sql::DriverManager);
-
 {   # the Inline package needs to be use'd in main in order to
     # get the studied classes to be rooted in main
     package main;
@@ -106,6 +104,9 @@
 warn "studying classes\n" if $debug;
 study_classes(\@classes, 'main');

+
+our @ISA = qw(Exporter java::sql::DriverManager);
+
 # Driver => java.sql.Driver, RowSet => javax.sql.RowSet etc
 my %class_base   = map { m/^(.*\.(\w+))$/ or die; (  $2  => $1) } @classes;


It seems like initialising the @ISA array later (once the Java methods are loaded) fixes the problem.

After some poking around, I found that there was some changes in Perl 5.10 regarding multiple inheritance (see <http://perldoc.perl.org/perl5100delta.html>http://perldoc.perl.org/perl5100delta.html). I believe something changed in that release with the way some of
this stuff is handled. Just a theory...

Patrick





On Thu, Jan 2, 2014 at 7:06 PM, Russ Tremain <<mailto:ru...@releasetools.org>ru...@releasetools.org> wrote:

Hi Patrick,

To add to the discussion, I ran a modified version of JDBC.pm using DEBUG => 4 setting, first under perl 5.8.9, and under perl 5.18.1

I also ran under perl 5.12.4 and got the same error as 5.18.1.

There is a bug report filed for JDBC.pm: <https://rt.cpan.org/Public/Bug/Display.html?id=50307>https://rt.cpan.org/Public/Bug/Display.html?id=50307 Also a note to perl-monks: <http://www.perlmonks.org/?node_id=505979>http://www.perlmonks.org/?node_id=505979 but it is a different error.

It seems to initialize fine, but then aborts with an error as Inline tries to match the first call to jdbc.

Here are some diffs for the debug output (truncated for clarity) - 5.18.1 on the left, 5.8.9 on the right:

[perl][3] perl doesn't know about 'org.apache.derby.jdbc.EmbeddedDriver' ('main::o [perl][3] perl doesn't know about 'org.apache.derby.jdbc.EmbeddedDriver' ('main::o [perl][2] creating object in java (main::org::apache::derby::jdbc::EmbeddedDriver): [perl][2] creating object in java (main::org::apache::derby::jdbc::EmbeddedDriver): sqlpj::sqlpjImpl::sql_init_connection[738]: eval FAILED: Can't locate object method | [perl][3] matching arguments to getConnection(java.lang.String)

| [perl][3] error trying to fit args to prototype: Wrong number of arguments at /usr sqlpj::sqlpjImpl::sqlsession[254]: cannot get a database connection: ABORT | [perl][3] matching arguments to getConnection(java.lang.String, java.lang.String, [perl][1] killed by natural death. | [perl][3] match successful: score is 6


the full error I get back from my eval is:

[perl][3] perl doesn't know about 'org.apache.derby.jdbc.EmbeddedDriver' ('main::org::apache::derby::jdbc::EmbeddedDriver') [perl][2] creating object in java (main::org::apache::derby::jdbc::EmbeddedDriver):

sqlpj::sqlpjImpl::sql_init_connection[738]: eval FAILED: Can't locate object method "__validate_prototype" via package "JDBC" at (eval 41) line 206, <GEN8> line 5.

sqlpj::sqlpjImpl::sqlsession[254]: cannot get a database connection: ABORT
    [perl][1] killed by natural death.
      [perl][1] JVM owner exiting...

JDBC.pm is a pretty simple module that basically just maps java.sql.* classes into the JDBC namespace:

        our @ISA = qw(Exporter java::sql::DriverManager);

       {   # the Inline package needs to be use'd in main in order to
      # get the studied classes to be rooted in main
          package main;
           use Inline ( Java => q{ }, AUTOSTUDY => 1, DEBUG => 4 );
    }

       use Inline::Java qw(cast caught study_classes);

our @EXPORT_OK = qw(cast caught study_classes);

our $debug = $ENV{PERL_JDBC_DEBUG} || 0;

        #java.sql.ParameterMetaData
     my @classes = (qw(
          java.sql.Array
          java.sql.BatchUpdateException
           java.sql.Blob
            java.sql.CallableStatement
        ...
        ));

     warn "studying classes\n" if $debug;
    study_classes(\@classes, 'main');

Any ideas?  Possible it is something to do with a namespace mismatch?
Is __validate_prototype a symbol that is supposed to be injected by Inline::Java?

-Russ

P.S. I can get the Inline::Java module tests to pass as well, but not the JDBC tests. P.P.S. Error is not peculiar to Derby db, it happens with any driver I've tried.

At 9:30 PM -0500 12/16/13, Patrick LeBoutillier wrote:

Hi,

I just ran the tests without issues on Fedora 17, Perl 5.14 and Java 1.7.0.

There's really not much in Inline::Java that is dependant on the perl version.

Patrick



On Mon, Dec 16, 2013 at 9:08 PM, Russ Tremain <<mailto:ru...@releasetools.org>ru...@releasetools.org> wrote:

Well, I'm using JDBC.pm to access the inline::Java stuff, and I could never get it to work with >5.8.9, and never got any response from Tim Bunce or Patrick, so I eventually gave up on it.


It is possible that JDBC is doing something different, but I doubt it, as it is a very simple module. It basically does a lot of runtime "studying" in order to add all the java.sql classes to main:: to make it easier to call.


Best you can do is to write some tests and try the later environment.


I could not get the JDBC tests to run in a later env, and the tests have been broken on CPAN testers for a long time.


-Russ



At 4:40 PM -0800 12/16/13, David Wang wrote:

Hi Russ


So I got the Inline:Java including JAXB to work on my v5.8.8 perfectly . Then, I remember you mentioned that you never got it/Java to work on any Perl version later than 5.8.9 . Now, I am starting to worry since my deploy machine uses v5.10.0 . The Inline version I use is Inline-0.53 . Can someone confirm if this will or will not work on Perl version v5.10.0?


Thanks


David



From: Russ Tremain <<mailto:ru...@releasetools.org>ru...@releasetools.org>
To: David Wang <<mailto:kuoweiw...@yahoo.com>kuoweiw...@yahoo.com>
Cc: David Mertens <<mailto:dcmertens.p...@gmail.com>dcmertens.p...@gmail.com>; "<mailto:inline@perl.org>inline@perl.org" <<mailto:inline@perl.org>inline@perl.org>
Sent: Thursday, December 12, 2013 5:05 PM
Subject: Re: New to Inline::Java and a quick question


#yiv1198785418 #yiv1198785418 -- blockquote, #yiv1198785418 dl, #yiv1198785418 ul, #yiv1198785418 ol, #yiv1198785418 li {padding-top:0;padding-bottom:0;} #yiv1198785418 Re: New to Inline::Java and a quick question

one thing I can tell you is I have never gotten Inline::Java to work with any perl later than 5.8.9.

I have used it extensively with JDBC.pm.  Example of this can be found here:


        <https://github.com/russt/sqlpj>https://github.com/russt/sqlpj


best of luck!

-Russ



At 4:57 PM -0800 12/12/13, David Wang wrote:

Thanks


I am not sure if anybody has any experience with perl Inline::Java to call Java JAXB . Basically, I have added some code in my perl script to call some of my Java API that calls JAXB.


System.out.println("before·");

JAXBContext context = JAXBContext.newInstance("SomeXMLPackage");

System.out.println("after·");


and it fails on the JAXB statement above. I then added Debug and AUTOSTUDY option in perl like below


use Inline (

    Java => 'DATA',

    J2SDK => $ENV{JAVA_HOME},

    CLASSPATH => 'classes',

    AUTOSTUDY => 1,

    DEBUG => 4,

);


then I see

[java][3]   packet sent is ok java_object:1:1:javax.xml.bind.JAXBException

[perl][3]   packet recv is ok java_object:1:1:javax.xml.bind.JAXBException

[perl][3]   checking if stub is array...

[perl][3] perl doesn't know about 'javax.xml.bind.JAXBException' ('perlAPI::javax::xml::bind::JAXBException')

[perl][2]  autostudying javax.xml.bind.JAXBException...

[perl][3] perl doesn't know about 'javax.xml.bind.JAXBException' ('perlAPI::javax::xml::bind::JAXBException')

[perl][3]   reporting on javax.xml.bind.JAXBException


I hope perl inline works with JAXB . BTW, my Java API works fine meaning I use a Java main to call this

API and the xml file is loaded without problem.


thanks,


David






From: David Mertens <<mailto:dcmertens.p...@gmail.com>dcmertens.p...@gmail.com>
To: David Wang <<mailto:kuoweiw...@yahoo.com>kuoweiw...@yahoo.com>
Cc: "<mailto:inline@perl.org>inline@perl.org" <<mailto:inline@perl.org>inline@perl.org>
Sent: Thursday, December 12, 2013 5:37 AM
Subject: Re: New to Inline::Java and a quick question


Yep, as a rule, if you need to install a Perl module, a simple "cpan Module::Name" should do it. If you are on a Unixish system, you may have installation permission issues, in which case there are known work-arounds. But I'm sure you'll ask when you come to those. :-)

Good luck, and don't be afraid to ask more questions as they come up!

David



On Wed, Dec 11, 2013 at 7:38 PM, David Wang <<mailto:kuoweiw...@yahoo.com>kuoweiw...@yahoo.com> wrote:

Ok, I figured it out. Hope it can be documented somewhere.


Download Inline-0.53


go to the dir

cpan Inline::Java  << was instructed by some nice guy


Thanks


David




From: David Wang <<mailto:kuoweiw...@yahoo.com>kuoweiw...@yahoo.com>
To: "<mailto:inline@perl.org>inline@perl.org" <<mailto:inline@perl.org>inline@perl.org>
Sent: Wednesday, December 11, 2013 4:25 PM
Subject: New to Inline::Java and a quick question


Hi


I am very new to this stuff, just started to hear about it today. I looked around the web and I find the installation


instructions for inline::c like the following


perl Makefile.PL;

make;

make test;

make install;


But I can't find anywhere else that tells us how to install inline::Java ? BTW, I found the latest Inline is Inline-0.53.tar.gz and I use Redhat 5


Thanks


David








--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan





--
=====================
Patrick LeBoutillier
Rosemère, Québec, Canada





--
=====================
Patrick LeBoutillier
Rosemère, Québec, Canada

Reply via email to