Re: [AOLSERVER] Weird expr error

Wolfgang Winkler wrote: It is the nsjava module after all. If I comment it out in the server tcl file everything works fine. I think I'll have to rename this thread and post my question again! nsjava doesn't explicilty mess with locale, so I'm not sure what might be causing the problem. Poss

Re: [AOLSERVER] nsjava and aolserver 3.4.2

Thanks for the feedback! I'll fix the configure problem, and add a check in the module init, so it issues a warning instead of segfaulting when the config options are returned as null. Thanks, Dan Wolfgang Winkler wrote: Solved at last :-) Ns_ConfigGetPath in Ns_ModuleInit didn't get the p

Re: [AOLSERVER] nsjava and aolserver 3.4.2

The configure script doesn't look at JAVA_HOME. Try running configure using the --with-jdk option to specify the location of your jdk installation. Regards, Dan Thanks wiwo Wolfgang Winkler wrote: The $JDK_DIR var in the configure script is set to $JAVA_HOME. (/usr/lib/java). I've checked

Re: [AOLSERVER] nsjava and aolserver 3.4.2

Wolfgang Winkler wrote: Hi! Is anyone using nsjava with aolserver 3.4+? I've compiled the module (after changing a few things in the makefiles). What did you change in the makefiles? Now, when I'm starting up aolserver, it says: Error: startJvm: unable to get libjava.so library handle I fo

[AOLSERVER] ANNOUNCE: OpenFTS release 0.3.2

OpenFTS 0.3.2 is now available for download at http://sourceforge.net/projects/openfts. OpenFTS (Open Source Full Text Search engine) is an advanced PostgreSQL-based search engine that provides online indexing of data and relevance ranking for database searching. Close integration with database al

Re: [AOLSERVER] Other languages (was: Project Update)

Alexander Leykekh wrote: > Use of JNI is of particular interest, as it makes it possible to run Tomcat > and Java Virtual Machine (JVM) within AOLserver process' address space and > have Java servlets interact with other modules, e.g., evaluate Tcl scripts. I don't think it's being maintained any

Re: [AOLSERVER] Other languages (was: Project Update)

Scott Goodwin wrote: > But you are correct in that we need to support other languages. That > could be done with modules, and maybe some means of binding to internal > Tcl data structures at the C level could be found so that, say, a java > module can exchange data *directly* with Tcl internally --