On Jul 19, 2006, at 10:12 AM, Robert Hicks wrote:
Sorry I took so long getting back. What I mean is can I use
Inline::Java to setup a database connection and then pass that
connection off to the Perl side so I don't need to have the Oracle
client installed. I am thinking probably not.
As long as you're not passing a process boundary or something, it
should work. I've done similar things with ejbs. The down side is
that you'll be writing some very java looking code (creating
iterators, etc). JDBC isn't DBI. Other than that, once you have a
reference to an object, calls to that object should work as you'd
expect.
To illustrate, here's some pseudocode that would make a java call and
get a java.langList and return something that behaved like a
traditional perl array:
my @list;
my $jlist = $self->getBean->getSomeList($id);
my $iteratorClass = $jlist->iterator;
my $iterator = cast('java.util.Iterator',$iteratorClass);
tie (@list,"MyListWrapper",$jlist,$iterator);
return @list;
package MyListWrapper;
.... define needed list interfaces to make @list behave like a perl
list. I just needed TIEARRAY, FETCH, FETCHSIZE and SHIFT for my
purposes.
Your jdbc idea should work similarly, you just cant masquerade its
type as easily. Just make the usual jdbc style calls, unmarshall what
it returns and use eval as your try. If it were me, I'd just create a
perl object that wrapped the reference and stub out the functionality
I need. It'd centralize the marshaling/unmarshaling of datatypes as
well as error detection.
Wherever possible I wrap all calls to the jvm in library code that
returns perl friendly objects. If you don't, you bleed java style api
calls all over your codebase which only amplifies maintenance issues.
Then again, I'm working on a fairly large codebase written in perl
thats interfacing with several java apps. I wound up creating a
library of support code for the app to use when talking to the jvm
just to centralize things. The rest of the app uses those objects.
My 2 bits.
--
J.
