Permissions errors with JChem 3.1.0?

Hi again. Sorry to ask so many questions.





I'm having problems with JChem version 3.1.0. I have successfully installed (upgraded) JChem 3.1.0, but now the functionality that was working in 3.0.8 is no longer working. As a side, I uninstalled JChem, the j2sdk, and Tomcat 4.1 and reinstalled them when migrating to JChem 3.1.0. I have successfully created a structure table within the JChem schema and inserted into that table, but when I try to use other functions (jcf_molweight, jcf_formula, etc) I get errors.





The statement:

Quote:

DECLARE v2 cd_id_array := cd_id_array(NULL); BEGIN v2 := jc_insert('[SeH]c1ccccc1', 'JCHEM.RMS_STRUCTURE', 'JCHEM.JCHEMPROPERTIES', 'true', 'false'); END;

works fine and the structure can be found in the RMS_STRUCTURE table.





But this is what happens when I try to go a step farther:

Quote:

SQL> declare 2 v_out NUMBER; 3 begin 4 v_out := jcf_molweight('[SeH]c1ccccc1'); 5 end; 6 / declare * ERROR at line 1: ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException: The following exception has been thrown by the servlet: Exception: java.io.IOException: file format not recognized ORA-06512: at "JCHEM.JCHEM_CORE_PKG", line 0 ORA-06512: at "JCHEM.JCF_MOLWEIGHT", line 7 ORA-06512: at line 4

The Tomcat 4.1 logs say this:

Quote:

chemaxon.formats.MolFormatException: java.io.IOException: file format not recognized at chemaxon.util.MolHandler.toMolFormatException(MolHandler.java:698) at chemaxon.util.MolHandler.importMol(MolHandler.java:686) at chemaxon.util.MolHandler.setMolecule(MolHandler.java:159) at chemaxon.util.MolHandler.<init>(MolHandler.java:94) at chemaxon.jchem.cartridge.servlets.JChemMisc.getMolProp(JChemMisc.java:319) at chemaxon.jchem.cartridge.servlets.JChemMisc.process(JChemMisc.java:89) 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.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) 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:534)

I have a feeling I'm just missing a permission but I've been over the documentation, install, and everything else I can think of and can't seem to figure out what I'm forgetting.





I've tried:

Quote:

call dbms_java.grant_permission, 'JCHEM','SYS:java.net.SocketPermission','localhost','resolve'); call dbms_java.grant_permission('JCHEM','SYS:java.net.SocketPermission','localhost:8080','resolve'); call dbms_java.grant_permission('JCHEM','SYS:java.net.SocketPermission','127.0.0.1:8080','resolve'); grant execute on JCHEM."chemaxon/marvin/modules/CxsmilesImport" to JCHEM

Please help....?

Sorry.





I also meant to mention that I realize the structure table holds the structure weight, formula, etc. I am providing the above example to keep things simple. I need to generate the binary "PNG" for each structure.





For example:

Quote:

declare v_out BLOB; begin v_out := jcf_molconvertb('[SeH]c1ccccc1', 'png'); end; /

I figured the calculation of molecular weight would be the simplest place to start.

This is a bug in JChem Cartridge. It will be fixed in 3.1.1. Thank you for reporting it.

Hi,





It looks like that I can see the similar exception when I use JChem base. This error appears on the new JChem test version (Version TEST_2005_08_29).





I just want to remind you that this error may not completely associated with Cartridge, and the test version still have the bug. I hope you already know that.





Best regards,





Ben Li





The exception I got on my tomcat


------------------------------------------


java.io.IOException: file format not recognized


at chemaxon.formats.MolInputStream.init(MolInputStream.java:402)


at chemaxon.formats.MolInputStream.<init>(MolInputStream.java:105)


at chemaxon.formats.MolInputStream.<init>(MolInputStream.java:76)


at chemaxon.formats.MolInputStream.<init>(MolInputStream.java:88)


at chemaxon.util.MolHandler.importMol(MolHandler.java:677)


at chemaxon.util.MolHandler.setMolecule(MolHandler.java:159)


at chemaxon.util.MolHandler.<init>(MolHandler.java:94)


at com.nrgn.core.CompoundRepository.searchCompounds(CompoundRepository.java:334)


at com.nrgn.compreg.servlet.StructureSearchToolCommand.doWork(StructureSearchToolCommand.java:317)


at com.nrgn.BaseCommand.execute(BaseCommand.java:19)


at com.nrgn.compreg.servlet.CompoundRegServlet.service(CompoundRegServlet.java:51)


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


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


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


at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)


at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)


at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)


at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)


at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)


at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)


at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)


at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)


at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)


at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)


at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

benli and pkovacs,





Thanks for all the help.





I haven't installed the beta 3.1.1 yet. I'm not in that large of a rush and I know how hard it is to get beta's out before testing so I figured I'd give you guys some time. Is this a bug in 3.1? How can I double check my version? I've checked the jchemstreams version web page and the test batch file and both say I'm on 3.1.

Quote:

JCHEM_CORE_PKG.GETENVIRONMENT() -------------------------------------------------------------------------------- Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production PL/SQL Release 9.2.0.5.0 - Production CORE 9.2.0.6.0 Production TNS for 32-bit Windows: Version 9.2.0.5.0 - Production NLSRTL Version 9.2.0.5.0 - Production NLSRTL Version 9.2.0.5.0 - Production JChem version in the database: 3.1 JChem version in the Tomcat server: 3.1 java.vm.version: 1.4.2_09-b05 java.vm.vendor: Sun Microsystems Inc. Apache Tomcat/4.1.31 JCHEM_CORE_PKG.GETENVIRONMENT() -------------------------------------------------------------------------------- Major JDBC version in Tomcat: 1 Minor JDBC version in Tomcat: 0

Not a big deal. Just letting you know. I'll wait for 3.1.1.





Thanks again,


Jim

Jim,





The bug is in JChem 3.1 (Cartridge). You have this version installed. It can be seen in the output of the test script:

Quote:

JChem version in the database: 3.1 JChem version in the Tomcat server: 3.1

The test version of yesterday does not contain the fix for this problem yet.





(The problem benli is referring to might be another, unrelated bug.)





Peter

Sorry. It's first thing in the morning here. Apparently I need a cup of coffee.

Hi Ben,





I think your problem in Tomcat is not related to the mentioned cartridge bug.





This exception occurs when MolHandler cannot interpret a molecule string.





If you can reproduce the problem, I suggest you to extract the String that you pass to MolHandler.


For example you can write it to the standard error stream, and examine it in Tomcat's log.


If it looks a legal molecule string, please send it us for analysis.





Best regards,





Szilard

Hi Szilard,





It seems to do the samething to any compound even as simple as benzene. A structure I have is :


Marvin 08300516122D





5 5 0 0 0 0 999 V2000


-0.7813 1.3087 0.0000 N 0 0 0 0 0 0 0 0 0 0 0 0


-1.4957 1.7212 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0


-1.4957 2.5462 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0


-0.0668 2.5462 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0


-0.0668 1.7212 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0


1 2 1 0 0 0 0


1 5 1 0 0 0 0


2 3 2 0 0 0 0


3 4 1 0 0 0 0


4 5 2 0 0 0 0


M END


$$$$


The codes I execute are:


MolHandler mh=null;


Molecule mole=null;


try{


mh=new MolHandler(mol);


mole=mh.getMolecule();


}catch(IOException ie){


mh=new MolHandler("\n"+mol);


mole=mh.getMolecule();


}


where mol= the mol file in String.





Maybe the mol file misses a newline. My application gets the mol file from MarvinSketch.





Ben Li

Hi Szilard,





Just want to make sure that you know, I am using the test version JChem_TEST_2005_08_29, instead of version 3.1.





Ben Li

Hi,








There should be an empty line before "Marvin 08300516122D".


Does adding the newline makes the exception disappear ?





I do not think that this missing new line is a ChemAxon error.


(the mentioned JChem version produces correct output)





Probably you trim the string at some point, or you pass it on the wrong way from a browser window.


You should use a hidden form variable to post it to the server.


(it should not be sent as an encoded part of the URL)





Example:

Code:

<form method="post" name="queryForm"> <input type="hidden" name="molfile">

You should set the value with javascript, and submit the form. Example :

Code:

form = document.queryForm; form.action = "nextpage.jsp"; form.molfile.value = document.msketch.getMol('mol'); form.submit();

I hope this helps,





Szilard





PS:


Please note that the normal forum text is not very suitable for structure files and code parts (any number of spaces will appear as one due to html conventions)


You can use "Code" styling while writing your message for code parts.


We prefer multi-line structures as file attachments, if possible.

Hi Szilard,





We did put the sd file in a hidden variable as you mentioned. My application gets sd file string from MarvinSketch, and use javascript to set molfile value with sd file string. The software has not changed since last version. The exception information prints out when the test version was installed. So my analysis is that there is System.out.println(exception.toString()) in the class of MolHandler which was helpful for your debugging, but this statement was not commented out in the released test version. Hope you can comment it out in the formal release of 3.1.1.





This code was used in my application


try{


mh=new MolHandler(mol); //error message printed out here


mole=mh.getMolecule();


}catch(IOException ie){


mh=new MolHandler("\n"+mol); //no error


mole=mh.getMolecule();


}





Another issue is that it seems the sd file lacks a newline when I get from MarveinSketch. The javascript codes are


document.queryForm.sdfile.value = document.msketch.getMol('sdf');


This is almost identical to yours. But this sd file string seems not well-formed, and MolHandler throws IOException as we observed. This problem was there long before the new versions. That's why I have this try/catch in my codes.





Best regards,





Ben Li

Hi Ben,





It is a common (and usually useful) practice to print the stack trace before rethrowing an exception.


We use it in multiple parts of our code.


I do not see a reason to comment it out.





Your "cover up" code is not a healthy solution.


You should find out where the new line was lost.





You can check in javascript that the applet generates the correct output:

Code:

document.queryForm.sdfile.value = document.msketch.getMol('sdf'); alert("**"+document.queryForm.sdfile.value); // the debug line

The "**" helps to see, that if source produced by the applet begins with a newline, in this case it must be lost somewhere else.





Sincerely,





Szilard

Szilard,





Can you post a update tomorrow around lunch with the status of 3.1.1 (or the beta of 3.1.1)?





If a beta type build is ready, I might be able to help QA some of it?





Thanks,


Jim

Hi Jim,





3.1.1 is expected in 1-2 weeks depending on the progress of some tasks.


The latest test version was issued on the 28th of August, and is available here:





http://www.chemaxon.com/download.php?d=/data/download/jchem/test





We will let you know if a new test version or the new release is available.





Best regards,





Szilard