I don't think #1 is necessary. It may be necessary when we consolidate
the JVM startup (#8) so Zorba can know whether a particular module
import requires the JVM, but that depends on exactly how we do that
I don't understand #5; what does that mean? Is that the "given a URI,
return the ExternalModule object for it" feature? If so, that's not
necessary yet either (and we're not sure it's even desirable or safe).
Also, that would only be implemented at the C++ API level, not in a
module, I don't think.
You received this bug notification because you are a member of Zorba
Coders, which is the registrant for Zorba.
New way of classpath and JVM Singleton handling
Status in Zorba - The XQuery Processor:
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:
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,
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
- the order on calsspath is: ModuleOwnPath, ModuleDependecy, zorba -cp, env
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
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:
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