Hans Cappelle wrote:
I really think this is a Derby issue.
Had some conversation with a developer of sun who told me they indeed
can only sign jars for 1 year, so every year they have to release the
same software. He told me to use the latest release.
Which I did. I used JavaMail: 1.3.3 and even 1.4 EA.
1.4 was released december 2005 so this should still be valid.
Also these jars verify successfully with the jarsigner provided by Java:
jarsigner -verify jar-file
No one else having these kind of problems?
2006/4/26, Stanley Bradbury <[EMAIL PROTECTED]>:
Hans Cappelle wrote:
>We got this exception on mail.jar and activation.jar stored in our
>derby database. Both latest releases and other versions of Derby (like
>latest nightly build) did not help. Setting system clock before 26
>01:59:59 or replacing jars with unsigned jars is only solution we
>could find.
>
>2006-04-26 10:43:19 ... org.apache.derby.client.am.SqlException: The
>exception 'java.lang.ExceptionInInitializerError' was thrown while
>evaluating an expression. SQLSTATE: XJ001: Java exception: ':
>java.lang.ExceptionInInitializerError'. SQLSTATE: XJ001: Java
>exception: 'Security
>exception thrown accessing class javax.mail.MessagingException in jar
>"TEST"."MAIL" : NotAfter: Wed Apr 26 01:59:59 CEST 2006:
>java.lang.SecurityException'.
>
>Thanks for any help.
>
>
>
Hi -
This is a JavaMail issue. The certificate associated with the signed
jars has expired. You need to update the certificate or obtain a
version of the files with an updated certificate.
--
Hans Cappelle
I assume you replaced the old jarfile with the new one using a command
like this:
CALL sqlj.replace_jar('c:\myjarfiles\mail.jar', 'TEST.MAIL')
You can directly check the success of this command by comparing the file
referenced above against the one stored in
DERBY_SYSTEM_HOME\<myDBname>\jar\TEST\mail.jar.G<xxx>
where <xxx> is the generation id listed in the SYS.SYSFILES table for
this jarfile.
If the 'replace_jar' succeeds and the files do not match then you have
found a bug with jar replacement.
Also, as Craig suggests, check that the database classpath contains the
jarfile:
e.g. CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY (
’derby.database.classpath’, ’TEST.MAIL’)
and that mail.jar is not anywhere ELSE in your CLASSPATH that might
override the the database jar.
HTH
