Re: transporting non-UNO Java interfaces via the Java UNO bridge

Frank Schönheit - Sun Microsystems Germany wrote:
> Hello Ray,
> 
>> java.sql.Connection           jj_cnct;
>> com.sun.star.sdbc.XConnection oo_cnct;
>> oo_cnct = ...;     // require *.odb ZIP
decompression
>> jj_cnct = UnoRuntime.queryInterface(
java.sql.Connection.class, oo_cnct
>> );
>> jj_cnct = oo_cnct.getJDBCconnection();
>> // Would the polymorphism notion work as an
alternative?
>> // do_universal_JDBC_SQL_processing( jj_cnct,
jdbc_cnct_1, jdbc_rdbms_2,
>> ... );
>> oo_cnct.close();   // require *.odb ZIP
compression
>>
>> Is there a way to accomplish this conversion?
> 
> 
> No there isn't at all.
> 
> The SDBC connections are C++ implementations which
implement some
> abstract UNO interfaces. Those interfaces are the only
concepts which
> have a counterpart in Java - if you have a
css.sdbc.XConnection in Java,
> this is merely a proxy (implementing a Java-equivalent
of this
> interface) to the "real" implementation on
the C++ side. Thus, you
> cannot cast to, or otherwise obtain, the
java.sql.Connection, since this
> interface is completely unknown to the bridge between
your Java UNO
> interfaces and the C++ UNO implementations.
> 
> At least this is my understanding. There might be ways
(I changed the
> summary to catch the attention of people with more
knowledge about
> Java/UNO), but I strongly suppose they would require
explicit coding on
> OOo side before they work - at least in the Base part,
perhaps also in
> the bridges.

The summary change did its job.    However,
I have a hard time 
understanding exactly what this thread is about.  Is the
problem the 
following?  On Java side you have a UNO XConnection
reference to an 
object implemented in C++, and from that reference want to
obtain a 
reference to a Java java.sql.Connection object?  Is that
object already 
instantiated (which seems odd to me given the relevant UNO
object is 
implemented in C++), and if yes where (in the same Java
environment 
where you have the UNO XConnection reference?), or would it
be part of 
this issue to instantiate it on the Java side (out of thin
air)?

> Also, we would need to think about which leaks we would
open with such
> an approach. Currently, the JDBC connection is wrapped
into its SDBC
> counterparts, and there might be scenarios where
modifying the former
> without the latter noticing it might be destructive. I
can't think of
> such scenarios at the moment, but this would need
closer examination.

-Stephan

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Hi Stephan,

> The summary change did its job.  

fine 

> However, I have a hard time 
> understanding exactly what this thread is about.  Is
the problem the 
> following?  On Java side you have a UNO XConnection
reference to an 
> object implemented in C++, and from that reference want
to obtain a 
> reference to a Java java.sql.Connection object?  Is
that object already 
> instantiated (which seems odd to me given the relevant
UNO object is 
> implemented in C++), and if yes where (in the same Java
environment 
> where you have the UNO XConnection reference?), or
would it be part of 
> this issue to instantiate it on the Java side (out of
thin air)?

The XConnection, implemented in C++, is a wrapper/extension
for a
java.sql.Connection. This JDBC connection is accessed via
JNI, the JVM
is loaded in-process of OOo.

What Ray wants to do is to access the JDBC connection object
in his Java
program, which knows the XConnection only.

But now that you asked for the "where" ... I
assume chances are really
low as long as Ray's program doesn't run in the same JVM,
right?

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org