Problem with Cartridge User defined function.

Hi,





I totally followed the example of JChem Cartridge User defined function in this link.





http://www.chemaxon.com/jchem/examples/cartridge/user_def_func/getatomcount/index.html








when I executed "select getatomcount(cd_smiles) from jchemtable;", I got the following message from log file of Tomcat.





java.lang.NullPointerException


at chemaxon.jchem.cartridge.servlets.JChemUserDef.doSingle(JChemUserDef.java:206)


at chemaxon.jchem.cartridge.servlets.JChemUserDef.process(JChemUserDef.java:63)


at chemaxon.jchem.cartridge.servlets.JChemServletBase.doPost(JChemServletBase.java:232)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:716)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)


at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200)


at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146)


.......................


at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)


at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)


at java.lang.Thread.run(Thread.java:595)


2007-06-28 14:34:01.501 [null]: JChemUserDef.process: counter=0





JChem version: 3.1.5


JChem Streams version: 3.1.5








Could you please help me out?





Thanks





Bin

There are a few bugs in this feature. I will fix them for the next JChem release.





You can download a modified version of the 3.1.5 jchem.jar containing the fixes from here: http://www.chemaxon.com/shared/pkovacs/userdefop_fix_315/jchem.jar, so you can proceed with your tests until the fix is out.





Thanks


Peter

Hi, Peter,





Thank you very much for your help.





I got the error message,





*******


java.lang.RuntimeException: INCONSISTENT JCHEM VERSIONS:


JChem version in Oracle: 3.1.5, JChem version in servlet: 3.0.15


at chemaxon.jchem.cartridge.servlets.JChemServletBase.checkJChemJarVersion(JChemServletBase.java:312)


at chemaxon.jchem.cartridge.servlets.JChemServletBase.checkJChemVersions(JChemServletBase.java:276)


at chemaxon.jchem.cartridge.servlets.JChemServletBase.doPost(JChemServletBase.java:228)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:716)


at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)


********





I found "JChem version: 3.0.15" is in the VersionInfo.class of your jar.





the version of our developing server is 3.2.7( 3.1.5 is for product server).


I wonder if you could regenerate the modified jchem.jar based on 3.2.7 , since we will use 3.2.7 in the near future.





Thanks.





Bin

pkovacs wrote:

There are a few bugs in this feature. I will fix them for the next JChem release. You can download a modified version of the 3.1.5 jchem.jar containing the fixes from here: http://www.chemaxon.com/shared/pkovacs/userdefop_fix_315/jchem.jar, so you can proceed with your tests until the fix is out. Thanks Peter

Hi Bin,





I've built a jar to be used with JChem 3.2.7 for TESTING: http://www.chemaxon.com/shared/pkovacs/userdefop_fix_32branch/jchem.jar . You have to replace the old jchem.jar in BOTH Oracle AND Tomcat. Please, do not use it in production. It hasn't undergone the standard test procedures -- though it should work reasonably well. It has not been officially versioned either (it carries the version "32branch_3.2.7post_20070630"). I strongly suggest therefore to stop using it after a couple of weeks. (Both of us is likely to forget after a while that this is an unofficial version [let alone if someone else comes in for support] and may find it therefore troublesome to support mistakenly thinking that it is 3.2.7.)





The next JChem version (3.2.8) is scheduled for Wednesday 18 July 2007 anyway and will include the same fix. I suggest to wait for 3.2.8 to use the fix in production.





Since we're about to reanimate this feature from its long hibernation, I would like to suggest a small change in the implementation.





Currently, when the user defined operator is run in index scan mode, the index schema is searched for the jc_idx_udop table to find the name of the Java class implementing the operator. (The index schema is the schema where the index has been created; the jc_idx_udop table is where you have to register the Java implementation class-name for the operator.) Consequently, with the current implementation, you have to register your Java implementation class for each and every index schema which is supposed to use the operator (in index scan mode). (This is not explicitly in the docs, but is implied by the current JChem Cartridge implementation.) I think it would be more practical/logical to specify the operator-to-Java-implementation map in the scope of a JChem Cartridge installation, i.e. put the jc_idx_udop table in the JChem Cartridge owner's schema as opposed to the schema containing the index. The underlying assumption being that all JChem Cartridge users on the site are likely to need the same custom operators (if any) -- and that there is unlikely to be a need for differentating custom operators by index schema. What do you think?





And also a change which doesn't really affect the implementation: I intend to remove the sadistic-looking reg_user_def_ops.sql hack from the documentation (and the file itself from the package) and change the documentation to suggest using ALTER INDEXTYPE ... (as per Oracle SQL Reference) to add the custom operator(s) -- instead of manipulating that file.





Thanks


Peter

JChem 3.2.9 has been released fixing problems with user defined operators.