Issue 81899

mux2005: what about jvmfwk3rc/.ini?

That's what I do for the SDBC drivers packages in Debian:

UNO_JAVA_JFW_CLASSPATH_URLS=${${$ORIGIN/$UNO_SETTINGS:PKG_UserUnoFile}:UNO_JAVA_CLASSPATH}
${${$ORIGIN/$UNO_SETTINGS:PKG_SharedUnoFile}:UNO_JAVA_CLASSPATH}
$ORIGIN/classes/jurt.jar $ORIGIN/classes/ridl.jar $ORIGIN/classes/java_uno.jar
[...] file:///usr/share/java/mysql.jar file:///usr/share/java/sapdbc.jar
file:///usr/share/java/postgresql.jar

Note the last three.

Hacking a config file from a script is messy, especially under Windows, where
you don't always have tools like sed, perl, patch available. And then there's
the point that it increases the maintenance burden. When you already maintain a
.uno.pkg for the OOo configuration it's just easier and more natural to put your
Java classpath configuration in there, too. Ideally, it should be possible to
put the JDBC driver into the .uno.pkg, too, so that the same package can be used
to install the JDBC driver under Linux and Windows.

I'm not sure whether the latter - putting the JAR into the .oxt so that it is
automatically added to the classpath - is already possible. Stephan?

mux2005: I agree. I also agree that this doesn't scale and may make other
problems appear but I just wanted to mention it for completeness' sake.

@fs:  No, there is no mechanism available by which an OOo extension can make
available a jar outside the scope of the extension itself.

Hi,

I send this issue to jl for a general solution.

Bye Marc

JL->OJ: Maybe the DB code needs to use a class loader which evaluates
configuration data in order to find additional JDBC driver. What do you think?

qjl: Yes, this should be possible. We have a mechanism in the jdbc driver to
load from specific classpath. Thanks sb. :-) So to read from the config should
not be the problem.

Fixed in cws dba31a

You now have to add this in your DataAccess.xcu file

<node oor:name="JDBC">
    <node oor:name="DriverNames">
      <node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
        <prop oor:name="DriverName">
          <value>com.mysql.jdbc.Driver</value>
        </prop>
        <prop oor:name="Path">
         
<value>file:///d:/src/drv/mysql-connector-java-5.1.3-rc/mysql-connector-java-5.1.3-rc-bin.jar</value>
        </prop>
      </node>
    </node>
  </node>

re-opening.
While the configuration settings seems to work, there is (in a non-product
version) an assertion from connectivity/source/drivers/jdbc/tools.cxx, line 169,
saying that a parameter is passed as wrong type. Since this assertion does not
happen in an MWS build with the same database (and the driver added to
Tools/Options' class path), this sounds as if its related to the fix here.

fixed the assertion problem in dba31b

Note: the configuration path to configure the class path for a given driver is not
  org.openoffice.Office.DataAccess/JDBC/DriverNames
anymore, but
  org.openoffice.Office.DataAccess/JDBC/DriverClassPaths
Additionally, the unused DriverName node has been removed. So, oj's config
fragment from above transforms to 
  <node oor:name="JDBC">
    <node oor:name="DriverClassPaths">
      <node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
        <prop oor:name="Path">
          <value>url_to_jar_file</value>
        </prop>
      </node>
    </node>
  </node>
Multiple nodes can appear below the DriverClassPaths node, where the node name
specifies the driver class name for which the driver class path should be applied.

fs-> msc: please verify in CWS dba31a

verified in CWS dba31a

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba31a

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues

Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.

Set to state 'fixed'.

Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.

Please consider to reopen the issue.
The settings are ok with GUI, but not with API.
The following snippet has worked in 320m3 with the classpath settings via
OptionsDialog/Java:

mDBProperties(3).Name = "JavaDriverClass"
mDBProperties(3).Value = "oracle.jdbc.driver.OracleDriver"

oEnvironment = createUNOService("com.sun.star.sdbc.DriverManager")    
sDatabaseURL = "jdbc:oracle:thin:@" & ip & ":1521:" & sid
oConnection = oEnvironment.getConnectionWithInfo(sDatabaseURL,mDBProperties())
Now a message says, that the driver could not be loaded.
Set fs to cc, because he did the last changes
 

Peter, are you saying your code fragment worked with OOO320.m3, but not with
OOO320.m4 anymore?

no, the fragment works with manually setting the classpath via the OptionDialog,
which corresponds to the javasettings_*.xml.
After removing the classpath in the OptionsDialog and using the DataAccess.xcu
file, the connection can be established via GUI (with an odb-file), but not with
API.

ah .... Indeed, your code works on SDBC level, while the code for fixing this
issue has been added to the SDB level. In particular, the css.sdb.DataSource
implementation evaluates the configuration.

I don't see a reason why this code could not be in the SDBC/JDBC bridge, but
somehow I'd prefer a new issue over re-opening this one here.

Opened issue 106875 for it.

thanks

This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues  : 
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues