Upgrade from 3.2.6 to 5.0.1 is not successful

Hi.


I followed the upgrade instructions in the 5.0.1 release, my prior version was 3.2.6





After starting the server and trying


SQL> call jchem_core_pkg.use_password('chemical');


call jchem_core_pkg.use_password('chemical')


*


ERROR at line 1:


ORA-29532: Java call terminated by uncaught Java exception:


java.lang.ExceptionInInitializerError








.


There is no info in the log.


My oracle is 10R1 64bit.





What am I missing ?


Regards,


Mikael

It is kind of urgent since the database is not working now.

Please, could you post the corresponding Java stack trace from the Oracle session logs?





Thanks


Peter

more info.


After starting the server, i can verify it listens.


vader:/opt/apache-tomcat-5.5.15/bin # netstat -an | grep 1099


tcp 0 0 :::1099 :::* LISTEN





It also responds with telnet on that port


mimi@blackhole:~> telnet vader 1099


Trying 10.27.1.54...


Connected to vader.


Escape character is '^]'.


��sr4chemaxon.jchem.cartridge.rmi.impl.DirectoryImpl_Stubxrjava.rmi.server.RemoteStub���ɋ�exrjava.rmi.server.RemoteObject�a��


a3xpw2


UnicastRef localhostp?7A�
�����xConnection closed by foreign host.


mimi@blackhole:~>





Trying to start the 3.2.6 tomcat server gives another answer in sqlplus


SQL> call jchem_core_pkg.use_password('chemical');


call jchem_core_pkg.use_password('chemical')


*


ERROR at line 1:


ORA-29532: Java call terminated by uncaught Java exception:


java.lang.NoClassDefFoundError








Why does it try to use the old server ?


Regards,


Mikael

bvtmaiy wrote:

more info. After starting the server, i can verify it listens. vader:/opt/apache-tomcat-5.5.15/bin # netstat -an | grep 1099 tcp 0 0 :::1099 :::* LISTEN It also responds with telnet on that port mimi@blackhole:~> telnet vader 1099 Trying 10.27.1.54... Connected to vader. Escape character is '^]'. ��sr4chemaxon.jchem.cartridge.rmi.impl.DirectoryImpl_Stubxrjava.rmi.server.RemoteStub���ɋ�exrjava.rmi.server.RemoteObject�a�� a3xpw2 UnicastRef localhostp?7A� �����xConnection closed by foreign host. mimi@blackhole:~> Trying to start the 3.2.6 tomcat server gives another answer in sqlplus SQL> call jchem_core_pkg.use_password('chemical'); call jchem_core_pkg.use_password('chemical') * ERROR at line 1: ORA-29532: Java call terminated by uncaught Java exception: java.lang.NoClassDefFoundError Why does it try to use the old server ? Regards, Mikael

Please, could post the content of the <jchem-owner>.jc_idx_property table?





Please, could you also post the corresponding Java stack trace from the Oracle session logs?





Thanks


Peter

Hi.


Here is the content from the table.


PROP_NAME PROP_VALUE PROP_VALUE_EXT


jchem.service.endPoint.url.1 http://localhost:8080/jchemstreams/


rmi.server.1 localhost:1099








The trace comes soon.


/Mikael

And here is the trace.


/u01/oracle/product/admin/star/udump/star_ora_31898.trc


Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 - 64bit Production


With the Partitioning option


ORACLE_HOME = /u01/oracle/product/10R1_64bit


System name: Linux


Node name: vader


Release: 2.6.5-7.283-smp


Version: #1 SMP Wed Nov 29 16:55:53 UTC 2006


Machine: x86_64


Instance name: star


Redo thread mounted by this instance: 1


Oracle process number: 17


Unix process pid: 31898, image: oracle@vader (TNS V1-V3)





*** 2008-03-13 11:50:26.925


*** ACTION NAME:() 2008-03-13 11:50:26.925


*** MODULE NAME:(SQL*Plus) 2008-03-13 11:50:26.925


*** SERVICE NAME:(SYS$USERS) 2008-03-13 11:50:26.925


*** SESSION ID:(307.1430) 2008-03-13 11:50:26.925


java.lang.ExceptionInInitializerError


at java.util.logging.Logger.getLogger(Logger.java)


at java.util.logging.Logger.<clinit>(Logger.java)


at sun.rmi.runtime.Log$LoggerLogFactory.createLog(Log.java)


at sun.rmi.runtime.Log.getLog(Log.java)


at sun.rmi.server.UnicastRef.<clinit>(UnicastRef.java)


at java.lang.Class.forName0(Class.java)


at java.lang.Class.forName(Class.java)


at java.rmi.server.RemoteObject.readObject(RemoteObject.java)


at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java)


at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java)


at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java)


at java.lang.reflect.Method.invoke(Method.java)


at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java)


at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java)


at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java)


at java.io.ObjectInputStream.readObject0(ObjectInputStream.java)


at java.io.ObjectInputStream.readObject(ObjectInputStream.java)


at chemaxon.jchem.cartridge.rmi.client.RmiDirectory.locate(RmiDirectory.java:69)


at chemaxon.jchem.cartridge.rmi.client.RmiDirectory.locate(RmiDirectory.java:50)


at chemaxon.jchem.cartridge.rmi.client.RmiDirectory.getServer(RmiDirectory.java:86)


at chemaxon.jchem.cartridge.JFunctions.getRmiTunnel(JFunctions.java:333)


at chemaxon.jchem.cartridge.JFunctions.setCheckPassword(JFunctions.java:286)


at chemaxon.jchem.cartridge.JFunctions.setPassword(JFunctions.java:265)


Caused by: java.security.AccessControlException: the Permission (java.lang.RuntimePermission shutdownHooks) has not been granted to JCHEM. The PL/SQL to grant this is dbms_java.grant_permission( 'JCHEM', 'SYS:java.lang.RuntimePermission', 'shutdownHooks', '' )


at java.security.AccessControlContext.checkPermission(AccessControlContext.java)


at java.security.AccessController.checkPermission(AccessController.java:419)


at java.lang.SecurityManager.checkPermission(SecurityManager.java)


at oracle.aurora.rdbms.SecurityManagerImpl.checkPermission(SecurityManagerImpl.java)


at java.lang.Runtime.addShutdownHook(Runtime.java)


at java.util.logging.LogManager.<init>(LogManager.java)


at java.util.logging.LogManager.<clinit>(LogManager.java)


... 23 more








Should I try to grant the shutdownHooks ?


Regards,


Mikael

Quote:

Should I try to grant the shutdownHooks ?

Yes, please.





Thanks


Peter

Hi.


After granting the following


call dbms_java.grant_permission( 'JCHEM', 'SYS:java.lang.RuntimePermission','shutdownHooks', '' )


call dbms_java.grant_permission( 'JCHEM', 'SYS:java.util.logging.LoggingPermission', 'control', '' )








I got the following result.


SQL> call jchem_core_pkg.use_password('chemical');


call jchem_core_pkg.use_password('chemical')


*


ERROR at line 1:


ORA-29532: Java call terminated by uncaught Java exception:


java.lang.Exception: Problem connecting to JChemServer: rmi://localhost:1099:


the Permission (java.net.SocketPermission 127.0.0.1:8048 connect,resolve) has


not been granted to JCHEM. The PL/SQL to grant this is


dbms_java.grant_permission( 'JCHEM', 'SYS:java.net.SocketPermission',


'127.0.0.1:8048', 'connect,resolve' )





Why does it want to connect on port 8048 ?


Regards,


Mikael

Hi,





Have you granted the SocketPermissions as described in the install docs: without port specification?





Thanks


Peter

After making sure I had done that, and adding the 2 other grants to the users it now seems to work.











Regards,


Mikael

Running jcman to regenerate the tables results in error





Error at molecule with cd_id: 30538


java.sql.SQLException: ERROR: field "CD_SORTABLE_FORMULA" is not present in table "CHEMSPEC.JCMOL_MOLTABLE".


at chemaxon.jchem.db.UpdateHandler.getField(UpdateHandler.java:1898)


at chemaxon.jchem.db.UpdateHandler.setFieldCdSortableFormula(UpdateHandler.java:1826)


at chemaxon.jchem.db.UpdateHandler.setFields(UpdateHandler.java:1657)


at chemaxon.jchem.db.UpdateHandler.execute(UpdateHandler.java:2275)


at chemaxon.jchem.db.UpdateHandler.execute(UpdateHandler.java:2233)


at chemaxon.jchem.db.Regenerator$RegenThread.run(Regenerator.java:78)





Is it supposed to do that ?, do I need to run any script to create that column on every structure database ?

I see you have opened a different topic for this last issue:





http://www.chemaxon.com/forum/ftopic3639.html





(Please only ask a question once to avoid confusion).





Best regards,





Szilard