zorba-coders team mailing list archive

[Chris Hillery <931816@xxxxxxxxxxxxxxxxxx>]

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