ODB tries to create log files inside its own jar on Win7

I sent a demo of an app I've been developing on Linux to some Windows 7 users, and they were unable to run it.  The stack traces they sent me indicated that ODB was trying to create its log files inside objectdb.jar, which was inside the executable jar packaged by Eclipse.  Here's the end of the stack trace:

[code]Caused by: com.objectdb.o.UserException: Failed to create a new file 'rsrc:objec
tdb.jar\log\odb20120417.log'
        at com.objectdb.o.MSG.d(MSG.java:74)
        at com.objectdb.o.LFL.L(LFL.java:841)
        at com.objectdb.o.LFL.I(LFL.java:781)
        at com.objectdb.o.LFL.I(LFL.java:750)
        at com.objectdb.o.LGM.<init>(LGM.java:120)
        at com.objectdb.o.CFG.u(CFG.java:275)
        at com.objectdb.o.CFG.<clinit>(CFG.java:58)
        ... 50 more
Caused by: java.io.FileNotFoundException: rsrc:objectdb.jar\log\odb20120417.log
(The filename, directory name, or volume label syntax is incorrect)
        at java.io.RandomAccessFile.open(Native Method)
        at java.io.RandomAccessFile.<init>(Unknown Source)
        at com.objectdb.o.LFL.L(LFL.java:828)
        ... 55 more[/code]

I don't know if this is a problem with ODB itself, or with the way Eclipse packaged it.  Either way, it does not affect Linux users; I can copy my executable jar to another Linux machine and it works fine.  (I didn't check where it creates its log files, but evidently it doesn't try to create them inside the jar.)

I was using Bundle-Version 2.3.6.b14.  I just upgraded to 2.3.7.b15, but in my haste to get feedback from Win7 users, that wasn't the only change I made.  I also added the workaround described by paolutus in this seemingly related thread: https://www.objectdb.com/forum/507  I'll follow up as soon as I hear the results.  If this was a known issue, I'll remove the workaround and see how it goes.

ObjectDB works well on Win7 including in Eclipse plugins so it seems to be related to packaging.

Configuration and logging paths are by default relative to ObjectDB Home ($objectdb) which is set automatically based on the location of the ObjectDB jar file. If the ObjectDB jar file is packaged in another jar or loaded by a special protocol (rsrc:) - the result could be a failure to handle these paths.

Setting ObjectDB Home ($objectdb) explicitly could solve the problem.

If you can upload a sample Eclipse application that demonstrates this it could help in improving ObjectDB so it will be able to solve this situation automatically.

Okay... I downloaded the latest version of Eclipse for Java Developers (http://eclipse.org/downloads/packages/eclipse-ide-java-developers/indigosr2) and installed it in a separate location from the version I was using, with its own clean workspace.  I created a new project, added objectdb.jar to the build path as an external jar, and wrote this one-class program:

package test;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public class Test {

public static void main(String[] args) {
  try {
   EntityManagerFactory emf = Persistence.createEntityManagerFactory("objectdb:test.odb");
   EntityManager em = emf.createEntityManager();
   em.close();
   emf.close();
  }
  catch(Exception e) {
   e.printStackTrace();
   System.exit(1);
  }
  System.out.println("Everything turned out better than expected.");
}

}

I then exported it as a runnable jar with the option "Package required libraries into generated JAR" and sent it to a Win7 user.  When he ran it, this is what he got:

C:\Users\Scott\Desktop>java -jar odb-test.jar
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:58)
Caused by: java.lang.ExceptionInInitializerError
        at com.objectdb.o.RCL.<clinit>(RCL.java:33)
        at com.objectdb.o.UNM$z.<init>(UNM.java:165)
        at com.objectdb.o.UNM.x(UNM.java:105)
        at com.objectdb.o.UNM.w(UNM.java:75)
        at com.objectdb.jpa.Provider.createEntityManagerFactory(Provider.java:56
)
        at com.objectdb.jpa.Provider.createEntityManagerFactory(Provider.java:32
)
        at javax.persistence.Persistence.createEntityManagerFactory(Persistence.
java:78)
        at javax.persistence.Persistence.createEntityManagerFactory(Persistence.
java:54)
        at test.Test.main(Test.java:11)
        ... 5 more
Caused by: com.objectdb.o.UserException: Failed to create a new file 'rsrc:objec
tdb.jar\log\odb20120418.log'
        at com.objectdb.o.MSG.d(MSG.java:74)
        at com.objectdb.o.LFL.L(LFL.java:841)
        at com.objectdb.o.LFL.I(LFL.java:781)
        at com.objectdb.o.LFL.I(LFL.java:750)
        at com.objectdb.o.LGM.<init>(LGM.java:120)
        at com.objectdb.o.CFG.u(CFG.java:275)
        at com.objectdb.o.CFG.<clinit>(CFG.java:58)
        ... 14 more
Caused by: java.io.FileNotFoundException: rsrc:objectdb.jar\log\odb20120418.log
(The filename, directory name, or volume label syntax is incorrect)
        at java.io.RandomAccessFile.open(Native Method)
        at java.io.RandomAccessFile.<init>(Unknown Source)
        at com.objectdb.o.LFL.L(LFL.java:828)
        ... 19 more

I also received confirmation that explicitly setting the "objectdb.home" system property to the current directory fixes this problem on Win7.  That seems to already be the default on Linux.

Thank you for the test case. This Eclipse packaging method doesn't enable ObjectDB to find the path to its jar, which is required for setting ObjectDB Home automatically.

As a workaround, starting build 2.3.7_17 the user directory will be used as ObjectDB Home in this case (unless it is set explicitly).