Which OS do you use?
If you use Linux, which distribution?

Where do you get OpenOffice.org? Is it a distribution version?

Please answer _all_ questions.

Mechtilde

Linux / ArchLinux.
No, it's not a distribution build. It's a home build using system hsqldb (same
one used in 2.2.1).

I add Rene as CC

We both discuss this problem yesterday.

confirmed. Already in m222, too.

More infos:
- happens also with internal hsqldb
- happens on gcj and ecj builds, and even with IBM JDK 1.4, too (There's no Sun
for ppc). Regardless of the build, on runtime it doesn't work with *any* JDK
(tried on i386 using gij, Sun 5, Some OpenJDK 7 b, and gij, IBM 1.4 on ppc)
- happens on both ppc and i386 (the archs I tested so far)
- on the console it prints out ClasssNotFoundException
- the jar accessed before this is juh.jar, which *is* there, but maybe something
inside javaunohelper broke,.

(my theory from yesterday didn't hold yet, need to try again with a fresh
build/install, info added here it it proved)

Setting target to 2.3, as this must be fixed for 2.3...

This is more than P3, Base is unusable with this.

reassign to someone sensible (not dbaneedsconfirm)

msc: This is the issue you so unfriendly rushed away with "Base works. Point".
Obviously I am neither the only person having this and ht990332 is building
vanillla, OOo, so..

Adding you to Cc

Ccing sb/kr, as this seems to be a jvmfwk/javaunohelper-Problem.

As juh seems to be involved, I checked my Java settings and came to jvmfwk3rc:

This is my current one:

$ cat /usr/lib/openoffice/program/jvmfwk3rc
[Bootstrap]
BaseInstallation=${$ORIGIN/bootstraprc:BaseInstallation}
UserInstallation=${$ORIGIN/bootstraprc:UserInstallation}
UNO_JAVA_JFW_USER_DATA=$UserInstallation/user/config/javasettings_${_OS}_${_ARCH}.xml
UNO_JAVA_JFW_SHARED_DATA=$BaseInstallation/share/config/javasettings_${_OS}_${_ARCH}.xml
UNO_JAVA_JFW_VENDOR_SETTINGS=$BaseInstallation/share/config/javavendors.xml
UNO_SETTINGS=unorc
UNO_JAVA_JFW_CLASSPATH_URLS= file:///usr/share/java/bsh.jar
file:///usr/share/java/hsqldb.jar file:///usr/share/java/xercesImpl.jar
file:///usr/share/java/xalan2.jar file:///usr/share/java/serializer.jar
file:///usr/share/java/mysql.jar file:///usr/share/java/sapdbc.jar
file:///usr/share/java/postgresql.jar

which worked fine so far. The last three entries are added manually by me
for adding the JDBC MySQL/PoistgreSQL and SAP DB Drivers to the classpath when
installed. The other ones are added directly by the build when you use
those Java libs from external (--with-system-bsh, --with-system-hsqldb).

I tried around a bit and noticed that when removing the bsh, hsqldb, mysql,
postgresql and sapdbc entries it works (I have a hsqldb.jar symlink in classes/,
too, otherwise it'd not find hsqldb.jar - which is the whole purpose of adding
this entry).

Now let's look at those files in detail; 

1 mysql.jar, postgresql.jar and sapdbc.jar are not existing on the fs because 
  not installed. This was working on 2.2.1, though, and this makes sense when
  you want to pre-register them so they get in effect if someoone just installs  
  one of those drivers without the driver package having to fiddle with OOos 
  "private" configs

2 bsh.jar and hsqldb.jar are symlinks:
  $ ls -l /usr/share/java/bsh.jar /usr/share/java/hsqldb.jar
lrwxrwxrwx 1 root root 13 2007-08-03 18:21 /usr/share/java/bsh.jar -> bsh-2.0b4.jar
lrwxrwxrwx 1 root root 18 2007-08-03 18:21 /usr/share/java/hsqldb.jar ->
hsqldb-1.8.0.7.jar

3  xercesImpl.jar, xalan2.jar, serializer.jar are "normal" jar files of xalan 
   and xerces:

$ ls -l /usr/share/java/xalan2.jar /usr/share/java/xercesImpl.jar
/usr/share/java/serializer.jar
-rw-r--r-- 1 root root  194508 2007-07-16 15:41 /usr/share/java/serializer.jar
-rw-r--r-- 1 root root 3199127 2007-07-16 15:41 /usr/share/java/xalan2.jar
-rw-r--r-- 1 root root 1230728 2007-07-03 20:22 /usr/share/java/xercesImpl.jar

Now, as said, when removing the non-existing files and the symlinked files there
it magically works (given that bsh.jar and hsqldb.jar also exist as symlinks in
classes, which appears to still work).

"OK, no non-existing files or symlinks" then I thought and removed the
non-existing files from there and changed those entries to reference the "real" jar.
-> Still failed. I can't explain this given that it works with real jars in
xalan etc., Maybe because of the additional dots?

OK, then my last try was to change it back to hsqldb.jar and bsh.jar but copy
the real jars to there, replacing those symlinks.
-> intrestingly, still fails. although xalan etc. work!

It only works for me, If I remove the entries from jvfmfwk. The xalan/xerces
ones can stay there, but the bsh/hsqldb need to go to make it work for me...

cc'ing jl, too - he's the master of the JVM config stuff, IIRC. Also adding oj.

asssigning to SB. Stephan, there's two reasons for this: 1) you're probably much
faster than me in finding out what happens here 2) I'm on vacation currently,
will be without any internet access starting soon, and the issue sounds pressing
enough with target 2.3.

The only thing I tried to far is installing an ordinary developer snapshot 224
on one of our usual developer machines, and there the problem did not occur.

fs->rene: The class not found error you talked about - is there a mention of the
class which has not been found (I suppose you would have said so then, but ...)?

fs: exactly. it just prints out "ClassNotFoundException" on the console. Nothing
more.

.

hmm, with system hsqldb .... if that's really the (only) difference ... rene,
could you please check whether reverting to revision 1.22 of
connectivity/source/drivers/hsqldb/HDriver.cxx solves the problem? If so (I
suppose it does), then we need to make the changes which happened in rev. 1.23
depend on !SYSTEM_HSQLDB. Stephan should be able to tell whether there are more
changes which need this dependency.

fs: no, fails also with 1.22

How to reproduce with Sun-built unxlngi6.pro SRC680m224 OpenOffice.org:

1  Add the following line to program/jvmfwk3rc (which should not yet have any
line starting with UNO_JAVA_JFW_CLASSPATH_URLS):

  UNO_JAVA_JFW_CLASSPATH_URLS=$ORIGIN/classes/hsqldb.jar

2  Start program/soffice, then "File - New - Database", in the first pane of
"Database Wizard" dialolg click "Next >>" and on the second pane check "Create
tables using the table wizard" and click "Finish".  In the "Save as" dialog
click "Save":  "ClassNotFoundException" on stdout and "The connection to the
data source could not be established." error box (clicking "OK" then gives the
"com.sun.star.sdbc.SQLException: General error: java.lang.NullPointerException"
stack trace on stderr).

The problem is that in line 222 of
hsqldb/unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/Database.jar

  Class zclass = Class.forName(fileaccess_class_name);

fileaccess_class_name is com.sun.star.sdbcx.comp.hsqldb.StorageFileAccess.  The
application class loader that loaded Database.jar does not know that class.

@sb: When you replace the line
UNO_JAVA_JFW_CLASSPATH_URLS=$ORIGIN/classes/hsqldb.jar
with
UNO_JAVA_JFW_CLASSPATH_URLS=$ORIGIN/classes/hsqldb.jar;$ORIGIN/classes/sdbc_hsqldb.jar

everything works. It seems that this line overwrites existing jar files.

@oj:  "It seems that this line overwrites existing jar files."  No, that line
specifies the JVM's classpath.  With a standard, Sun-built OOo, the JVM
classpath is empty (so the line is missing entirely).  With a build that is
configured --with-system-hsqldb, the JVM classpath contains hsqldb.jar (in some
system location), but not sdbc_hsqldb.jar.  However, with the current code, code
from hsqldb.jar tries to load a class from sdbc_hsqldb.jar with Class.forName. 
That only works if the code from hsqldb.jar has been loaded with a classloader
that is a (reflexive, transitive) child of a classloader able to load from
sdbc_hsqldb.jar.  The assumption that this works is broken when configuring OOo
--with-system-hsqldb: hsqldb.jar is loaded by the JVM's application classloader
(as it is on the classpath), whereas sdbc_hsqldb.jar is only known to some more
specific classloader that is a (transitive) child of the application
classloader.  So, the current code is broken.

I can think of several ways how to fix that:

1  In Database.java from above, instead of only passing a fileaccess_class_name
property, also pass information where that class can be found (e.g., a URL with
which an appropriate classloader can be created; caveat: that could result in
the StorageFileAccess class being loaded multiple times by different,
incompatible classloaders).

2  In Database.java from above, instead of Class.forName use
Thread.getContextClassLoader to load the class, and at some appropriate place
down the call stack set an appropriate context classloader.

3  As a quick hack, at scp2/source/ooo/profileitem_ooo.scp:1.49 l. 874--876 also
add (the OOo-local program/classes/...) sdbc_hsqldb.jar to
UNO_JAVA_JFW_CLASSPATH_URLS if SYSTEM_HSQLDB is defined.

[Suggestions 1 and 2 above would of course imply a fix to the hsqldb sources and
not OOo, and OOo's configure --with-system-hsqldb would need to be adapted to
require an appropriately recent system hsqldb.jar version (and the hsqldb
version included in the OOo sources would need to be updated as well).]

the fix should be self-contained in OOo imho. so if 1 and 2 need a patch for
hsqldb, I'd vote for 3...

@rene It's not that easily possible to fix this issue without changing the
hsqldb sources. For 2.3 I vote for "removing SYSTEM_HSQLDB" from the configure
script. I just looked at the patch file for hsqldb and it's already really large
and many things won't be working as expected. And the horrible thing for me is
that someone will notice it too late and he may already have a data loss :-(

oj: ... except when you get your hsqldb package maintainer to add the bugfixes
from the OOo tree. (Which I am trying). But I simply doubt he will add stuff like
for 1 and 2.

If 3 works (as sb says, didn't try it yet), why not use this as a workaround?

Suggestion 3 above turned out to not work: the wizard dialog to create tables
does not appear.  The reason seems to be that sdbc_hsqldb.jar has in its
META-INF/MANIFEST.MF Class-Path dependencies on jurt.jar and unoil.jar, and for
some reason (which is not obvious to me at the moment) it does not work to load
(part of) the Java UNO runtime with the application classloader instead of the
UnoClassLoader.  (That oj's direct modification of UNO_JAVA_JFW_CLASSPATH_URLS
seemed to work was pure coincidence; those URLs need to be separated by spaces
instead of semicolons.)

"which is not obvious to me at the moment":  Obvious now, see issue 80383.

> I just looked at the patch file for hsqldb and it's already really large

All patches are part of HSQLDB-HEAD, i.e. will be in 1.8.0.8 (which according to
Fred Toussi is nearly ready to be released, we planned to integrate it for
2.3.1). The only exception is a small build-related patch with 2 lines or so.

Also, the patch file can at any time easily be regenerated: All patches which we
currently apply to HSQL are in hsqldb/patches. hsqldb/patches/index.txt explains
which patches are applied why. Every new patch added should definitely be part
of the patches/* stuff, else it will get lost over time. On the other hand, if
it *is* part of the patches/* stuff, it probably won't get lost ...

In general, I think since 3 has been named a workaround, I am not sure I like
this or a similar option. We should strive for a complete solution which lasts a
while without breaking next month.

Ocke, can you discuss this with Fred? I am not sure I understand the caveat
Stephan mentioned for 1., and its possible consequences, so I don't have an
opinion whether I like 1. or 2. better ...

@rene: I have to patch the hsqldb sources to fix this issue. As sb already
mentioned solution 3 doesn't work. 
So to make things work on your side you have to patch your system hsqldb. But
this only helps all OOo users which know the same maintainer. My personal
opinion is the SYSTEM_HSQLDB is currently not working as expected. It will work
when our patches get integrated into a hsqldb release. Frank mentioned release
1.8.0.8 where we also have to include the patch for this issue of course to make
things work. Do you think that it would be possible to set the target to 2.4 due
to the fact that a patch of the hsqldb sources is necessary?

if hsqldb 1.8.0.8 will fix it, yes. (Or I can persuade my hsqldb maintainer to
add the path himself to 1.8.0.7, depending on how long 1.8.0.7 takes). But I do
have my workaround already anyway....

"But this only helps all OOo users which know the same maintainer."

... or use a release of a distro containing 1.8.0.8 and OOo depending on that
version :). Nothing for users to care about in this case :)

We then of course need to change the configure check to check for the change, too.

But, assuming you have the patch already, I'd still vote for 2.3 for the reason
that the patch in the source is there then can be used as reference. (Or attach
it to this issue)

fs: When is 1.8.0.8s release due? "nearly ready" is not that concrete for
plannig ;-)

@rene: As others doesn't have such a friendly maintainer, I will fix the issue
in that way that I remove SYSTEM_HSQLDB from the configure script and we will
first reintegrate it when we have a version of hsqldb which includes all patches
we need. Otherwise I have no possibility to figure out if the patch I need
exists. Which of course would lead to an installation set which doesn't work.

oj: uh, no. please don't.

system-hsqldb works when you have hsqldb.jar in classes and apply the workaround.
system-hsqldb will work when you do it with a newer hsqldb.
I still rely on it. I still use it (with the workaround to remove the
file://usr/share/java/hsqldb.jar etc. from jvmfwk3rc)

I agree that it's broken out of the box right now and that it needs fixed/worked
around currently, but that's *no* argument to remove the *complete* check from
configure. If your patch makes it into hsqldb 1.8.0.8, it will work again and we
can improve the check later to check for the right version.

Anyone else will find this issue and know what to do. system-hsqldb is mainly
used by packagers anyway, and they should know where to look (here). Users
normally don't build their OOo on their own and if they do they normally don't
use system-hsqldb. Exceptions prove the rule, but those people should be able to
find this issue, too (summary and description imho is clear enough to find it
via IZ).

Don't break distris packages which can work around it/don't break stuff which
magically will be fixed with a new hsqldb in whatever distro for this..

@rene: But the problem still remains. Distros which use the patches for hsqldb
will create a OpenOffice.org installation which won't work out of the box. And
most users even know what issue zilla is. Later on we introduce the define
SYSTEM_HSQLDB again. When we know that all fixes we need are in a hsqldb
milestone we can check.

Why not just make the configure script check that system hsqldb is >= 1.8.0.8?
Is hsqldb 1.8.0.8 expected to be out before 2.3.0 official release? If so, it
should be safe to make the change from now, right?

> When is 1.8.0.8s release due?

We (Fred and /me) talked about releasing it about 10 days ago, to hit the 2.3
timeline. Unfortunately, we did not have QA resources on OOo side anymore for a
full-blown QA cycle (though smaller cycles before suggested there wouldn't be
any problems), so we shifted this.

If nothing changed on HSQL side, Fred should be able to release 1.8.0.8
immediately (ideally with Ocke's patch included, of course). Ocke, can you
negotiate this with Fred?

Could someone test this patch file. Thanks.

Created attachment 47380 [details]
HSQLDB_JAR

Re the attached i80338.patch:

1 In HDriver.cxx, something like

  #ifdef SYSTEM_HSQLDB
  aConvertedProperties[nPos++].Value <<=
::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(HSQLDB_JAR "
vnd.sun.star.expand:$ORIGIN/classes/sdbc_hsqldb.jar"));
  #else

or

  aConvertedProperties[nPos++].Value <<=
::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(
  #ifdef SYSTEM_HSQLDB
    HSQLDB_JAR
  #else
    "vnd.sun.star.expand:$ORIGIN/classes/hsqldb.jar"
  #endif
    " vnd.sun.star.expand:$ORIGIN/classes/sdbc_hsqldb.jar"));

would probably be simpler.

2 Remember to remove the hsqldb.jar entry from
scp2/source/ooo/profileitem_ooo.scp:1.49.

Help:

Could anyone please modify the configure script in that way that the version
number must be >= 1.8.0.8 
I have no experience with that :-)

Hmm. the obvious place to check - MANIFEST.MF - only contains 1.8.0 in 1.8.0.7.

$ cat MANIFEST.MF:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 4.1.3 20070718 (prerelease) (Debian 4.1.2-14) (Free Softwa
 re Foundation, Inc.)
Specification-Title: HSQLDB
Specification-Version: 1.8.0
Specification-Vendor: The HSQLDB Development Group
Implementation-Title: Standard runtime
Implementation-Version: build-680m222(Build:9183)
Implementation-Vendor: OpenOffice.org
Main-Class: org.hsqldb.util.SqlTool

So this is not helpful. For Debian, looking at the link target is helpful, but
that doesn't help for other distris:
$ ls -l /usr/share/java/hsqldb.jar
lrwxrwxrwx 1 root root 18 2007-08-08 10:46 /usr/share/java/hsqldb.jar ->
hsqldb-1.8.0.7.jar

Maybe we should check for the patch present and not for the version?

For that, oj, I might need the patch for hsqldb itself, which you promised to
attach to this issue...
cmc: Do you have an idea how we can check this?

@rene: There is no patch for hsqldb :-) I solved it inside OOo.

ah, ok. :)

oj: wrt the configure check... If you get hsqldb to change its MANIFEST.MF so it
has the full version (1.8.0.8 instead of 1.8.0) we could look into that one. I
don't see an other general solution (the filename one is Debian-specific)

oj: if hsqldb did that, the attached patch would do it (+ running autoconf). Can
do that in dba23e after the new hsqldb is released.

Created attachment 47409 [details]
adapt configure check to require >= 1.8.0.8

I just the okay from hsqldb. The new version n the manifest file will be
1.8.0.8. Thanks and thanks for the dpatch file.

I commit the configure script and one change in
connectivity/source/drivers/hsqldb/HDriver.cxx and makefile.mk

@rene: Could you please verify this. Thanks.

I tried the patch
http://www.openoffice.org/nonav/issues/showattachment.cgi/47380/i80338.patch on
m225 with system hsqldb
It didn't fix it. I needed to make an additional change. 
I edited the installed jvmfwk3rc file and changed.

UNO_JAVA_JFW_CLASSPATH_URLS=file:///usr/share/java/hsqldb.jar
file:///usr/share/java/xml-apis.jar file:///usr/share/java/xercesImpl.jar
file:///usr/share/java/xalan.jar file:///usr/share/java/serializer.jar

to 

UNO_JAVA_JFW_CLASSPATH_URLS=file:///usr/share/java/hsqldb.jar;file:///usr/share/java/xml-apis.jar;file:///usr/share/java/xercesImpl.jar;file:///usr/share/java/xalan.jar;file:///usr/share/java/serializer.jar

replacing the spaces with semicolons. After that, openoffice base works fine.

@ht990332:  As I said at #desc33, what is currently found at
<http://www.openoffice.org/nonav/issues/showattachment.cgi/47380/i80338.patch>
(same as attached i80338.patch) is not enough.  Your "fix" of replacing spaces
with semicolons just happens to work for you, but does not fix the problem (see
getApplicationClassPath in jvmfwk/source/fwkbase.cxx:1.10 for how
UNO_JAVA_JFW_CLASSPATH_URLS is processed).

oj: given that hsqldb 1.8.0.8 is not out yet and the build now fails without it,
not necessarily ;-). But I can try whether the dba23e patch without the
configure check fixes the issue, yes... But not until tomorrow (my fast build
machine is down currently)

@ht990332: Did you rebuild cconnectivity with the corrected makefile.mk. To get
the correct patch please do cvs update -jCWS_SRC680_DBA23E_ANCHOR
-jcws_src680_dba23e in connectivity. But I also add the patch for it.

Created attachment 47456 [details]
patch for connectivity/source/drivers/hsqldb

verified that a build with the changed connectivity and scp2 bits (and therefore
resulting in jvmfwk3rc without the hsqldb entry) works.

Not setting to verfied yet, though because the hsqldb ceheck part youldn't yet
been checked as hsqldb 1.8.0.8 is not released yet.

@rene: You could change the manifest by hand to test it. I don't exactly when
hsqldb version 1.8.0.8 will be released and this issue should go into OOo 2.3 :-)

oj: this issue should *not* go into OOo 2.3 when it checks for a hsqldb not
available at the time OOo 2.3 is released (or when this dba23e gets integrated
into the master), sorry.

You wanted the check (I explained you that it's not stricly needed), now you
have to live with waiting for the check to actually work. And that is when
hsqldb 1.8.0.8 is there. Of course, you can speed it up by getting them to
release, but...

oj: Hmm, the check currently is broken anyway...

@rene: When this fix should be part of OOo 2.3, set the target correctly. As I
explained in IRC it is an error that SYSTEM_HSQLDB is defined without checking
for version 1.8.0.8 No offical release of hsqldb so far included all patches we
apply. It doesn't matter if a person could apply the same patches, fact is there
exists no link on the hsqldb site where you can download this version and this
must be the case.

oj: and I didn't deny checking for hsqldb 1.8.0.8. Just that it would be
immediately broken in the master when you check for something which doesn't even
exist.

As fs/you promised, hsqldb 1.8.0.8 should be able to be released immediately. DO
that, and I've no hesitations to get this into 2.3.
If I thought we didn't need to check for this I wouldn't have (and still do,
because the current one is broken) invest time into this check. But I still
think that a configure script which checks for someting which is not there is
broken because the requirements cannot be fullfilled.

And the target is completely right: 2.3. You committed the configure check, not
me. I always thought of it being committed after we have to check someting for
(1.8.0.8, and that means 1.8.0.8 actually being available).

Easy solution for this: get hsqldb 1.8.0.8 relased, as promised. Then we have a
check which is actually usable. Or get the configure check out of this cws and
do it in another cws (which the might not make 2.3, but the "not sufficient"
check is no regression in 2.3 anyway, it's already in earlier 2.x versions)

For me there exists only two possible solutions.
1. Use a configure script which check for version 1.8.0.8 (which of course can
not be full filled at the moment.)
or
2. Remove the SYSTEM_HSQLDB complete from the configure script and don't allow
building with a locally patched hsqldb version.

The argument with duplicate code doesn't work here as a download version of
hsqldb is currently 1.8.0.7 and doesn't have the patches we need.

These are the only two valid solutions for this. And I thought that to check for
version 1.8.0.8 is much better then totally remove SYSTEM_HSQLDB. When you use a
local hsqldb version it isn't that complicated to patch the manifest file in the
jar as well ;-) 
And I don't have a clue which date version 1.8.0.8 will be released. It depends
on hsqldb.

(fixed configure check committed btw)

oj: I am fine with 1. As long as configures requirements can be fullfilled...
Wich it cannot. fs said that a hsqldb release should be able to be done fast, so
just do it, and we can forget about this issue.

But well, if "just" configure holds up the whole fix... :-( The fix has to be in
2.3, so...
But be prepared to get issues wrt that it's not buildable because it requires a
not-existing hsqldb version...

Yes, I can make the hsqldb maintainer change the manifest, too himself but that
would be a hack and simply lying about the version. 

oj: r10074 of
http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/cws-dba23e.diff?view=log
might be interesting:

"2007-08-14  Tor Lillqvist  <tml@novell.com>

	* patches/src680/cws-dba23e.diff: It's not portable to use an
	#ifdef inside a macro argument."

According to tml it actually breaks the build on Windows, so reopening.

Patch for windows compiler applied.

Please verify. Thanks.

16:55 <@_rene_> tml_: ping?
16:55 <@_rene_> tml_: wrt dba23e again, will this one work with msvc?
16:55 -!- Irssi: Pasting 6 lines to #go-oo. Press Ctrl-K if you wish to do this
or Ctrl-C to
          cancel.
16:55 <@_rene_> +#ifdef SYSTEM_HSQLDB
16:55 <@_rene_> +IIIIIRTL_CONSTASCII_USTRINGPARAM(HSQLDB_JAR
16:55 <@_rene_> +IIIII" vnd.sun.star.expand:$ORIGIN/classes/sdbc_hsqldb.jar")
16:55 <@_rene_> +#else
16:55 <@_rene_>
+IIIIIRTL_CONSTASCII_USTRINGPARAM("vnd.sun.star.expand:$ORIGIN/classes/hsqldb.jar"
16:55 <@_rene_> +IIIII" vnd.sun.star.expand:$ORIGIN/classes/sdbc_hsqldb.jar")
16:55 <@_rene_> +#endif
16:55 <@_rene_> that's what's currently in dba23e.
16:56 <@_rene_> -IIIIaConvertedProperties[nPos++].Value <<=
::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("vnd.sun.star.expand:$ORIGIN/classes/hsqldb.jar
                vnd.sun.star.expand:$ORIGIN/classes/sdbc_hsqldb.jar"));
16:56 <@_rene_> +IIIIaConvertedProperties[nPos++].Value <<= ::rtl::OUString(
16:56 <@_rene_> oops, ^ was missing above the first paste
17:12 <@tml_> if it matches what's in ooo-build trunk, yes
17:12  * tml_ checks
17:13 <@tml_> seems so yes

@ ht990332

does it works now?

please comment

mechtilde, Yes it does work in OOG680_m2 with the patch, thanks.
Will this be included in 2.3 final?

this will be include in 2.3 final you can also test the RC1

-> closed