db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: SecurityException on mail.jar and activation.jar
Date Tue, 02 May 2006 23:07:26 GMT
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 <Stan.Bradbury@gmail.com>:
>
>> 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


Mime
View raw message