Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
in case of jdbc-drivers you could try to pack your jdbc-driver in a zip
file and then add it calling "unopkg add yourzipfile" ... unopkg might
complain that the zip doesn't contain a uno-package, but as far as I
know will copy the jar-file and adjust the classpath, so that the driver
should work.
On CWS sb36, targeting "OOo Later," I changed the loading of Java UNO
components to no longer use the global Java classpath, so that the above
hack will no longer work there. (IIRC, the way new database drivers are
integrated into OOo will change then, too; Ocke or Frank on
dev@dba.openoffice.org should know more.)
Hmm. What we will do in DBA is that instead of using the office-wide
classpath (Tools|Options|Java|Classpath), we will allow to have a
per-database classpath.
Yes, part of which will be the JavaDriverClassPath property alreday
added to connectivity on CWS sb36 (I just could not remember the
details, and had to look this up again).
> However, users will still expect that the
Tools|Options classpath does work, too. (As they will expect that the
system's class path does work, which unfortunately isn't the case even
today.)
Anything added to the Tools|Options classpath will continue to be
available to all Java code in OOo (as the Tools|Options classpath is
added to the JVM's classpath when the JVM is started from within OOo).
I don't know which changes exactly you plan, but will a UNO component
(e.g. database driver) loading a (arbitrary, non-UNO) Java class still
use the Tools|Options (or perhaps even the system's) classpath? This is
desirable since there might be multiple JDBC-based databases using the
same Java class, and of course user's don't want to enter the same
classpath again and again.
Again, if you put some Java classes into the Tools|Options classpath, a
Java UNO component will find them. However, a Java UNO component itself
will no longer end up on the JVM's classpath, so classes from one Java
UNO component will no longer be visible to other Java UNO components.
Also, even if what Stephan describes is a hack, it sounds like a
convenient way to deploy a Java class into a OOo installation. Shouldn't
we continue to offer this convenience, the one way or the other?
Especially in the context of UNO components, yes, we will have to think
about how to handle the dependencies of a UNO component---dependencies
on other UNO components as well as dependencies on other kinds of
entities like dynamic libraries or JAR files. Expect something for post
OOo 2.0 in this area...
-Stephan
The more since programmatic manipulation of the office-wide classpath is
not possible, since no API (not even configuration API) exists for it.
This means that in order to deploy a Java class into a office
installation, users would be required to manually add this class to the
class path of all of it's clients (which as said could be multiple
databases), instead of simply announcing the class *once* to the office
installation as a whole.
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
