One problem I thought of: The Library Path I mentioned above is actually a feature of the static context. When Zorba needs to launch the JVM, the only static context it would be reasonable to look at would be the root static context. However, this is not the static context which gets populated by zorbacmd's --lib-path argument; zorbacmd creates a child static context for executing the query, and populates that static context's library path.
So, a user could not use --lib-path (or --module-path) to point to an alternate module library installation directory and then invoke a query using a Java-based module. I'm not sure yet what the right answer here is. Perhaps zorbacmd could just directly modify the root static context rather than the child. Also, we will need to document for C++ API users that only the root static context's library path will be used for the JVM classpath. -- You received this bug notification because you are a member of Zorba Coders, which is the registrant for Zorba. https://bugs.launchpad.net/bugs/931816 Title: New way of classpath and JVM Singleton handling Status in Zorba - The XQuery Processor: New Bug description: This bug is to track work related to makeing Zorba modules implemented in Java be robust and working all together. It was decided that a few things need to happen: Critical: 1. (chris) add cmake macros to let build know a module is using java 2. (chris) cmake macros that define it's own jar implementation 3. (chris) cmake macros that define external dependencies (like xmlbeans.jar, xsl-fo.jar) 4. (cezar) add zorba classpath option, and CLASSPATH environment 5. (chris) add core module that can resolve a known (by URI) external module 6. (chris) add external java-helper module that provides concatenation of classpathes - the order on calsspath is: ModuleOwnPath, ModuleDependecy, zorba -cp, env CLASSPATH 7. (chris) make sure binary packages set up classpathes correctly 8. (cezar) add code to external java-helper module to create a singleton JVM 9. (cezar) refactor xmlbeans and xsl-fo modules to make use of external java-helper module Nice to have, not critical: 10. Have a generic way to implement modules directly in Java, Python etc, using swig extension. To manage notifications about this bug go to: https://bugs.launchpad.net/zorba/+bug/931816/+subscriptions -- Mailing list: https://launchpad.net/~zorba-coders Post to : email@example.com Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp