Solution for “Certificate has expired” in log when starting Glassfish 3.1.2

Since a few weeks my GlassFish installation produces an annoying message whenever it gets started. The message looks like this one posted on stackoverflow:

   ...  
    [exec]  
    [exec] [#|2013-08-15T08:57:42.106+0200|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=39;_ThreadName=Thread-2;|Grizzly  
 Framework 1.9.50 started in: 16ms - bound to [0.0.0.0:1307 6]|#]  
    [exec]  
    [exec] [#|2013-08-15T08:57:42.262+0200|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|GlassFish  
 Server Open Source Edition 3.1.2.2 (5) startup time : Felix (1'1  
 23ms), startup services(609ms), total(1'732ms)|#]  
    [exec]  
    [exec] [#|2013-08-15T08:57:42.309+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.ssl.security.com.sun.enterprise.security.ssl.impl|_ThreadID=40;_ThreadName=Thread-2;|SEC5054:  
 Certificate has expired: [  
    [exec] [  
    [exec]  Version: V3  
    [exec]  Subject: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US  
    [exec]  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5  
    [exec]  
    [exec]  Key: Sun RSA public key, 2048 bits  
    [exec]  modulus: 237418898293472616608124373663877543854434319738611148654904141538840503317458119685231168476255701465927369352097185652960533868421359855348631579831288127741629980536737464707822524076734022381468699944387  
 29551246768368782318393878374421033907597162218758024581735139682087126982809511479059100617027892880227587855877479432885604404402435662802390484099065871430585284534529627347717530352189612077130606642676951640071336717026459037  
 542552927905851171460589361570392199748753414855675665635003335769915908187224347232807336022456537328962095005323382940080676931822787496212635993279098588863972868266229522169377  
    [exec]  public exponent: 65537  
    [exec]  Validity: [From: Fri Aug 14 16:50:00 CEST 1998,  
    [exec]        To: Thu Aug 15 01:59:00 CEST 2013]  
    [exec]  Issuer: CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US  
    [exec]  SerialNumber: [  01b6]  
    [exec]  
    [exec] Certificate Extensions: 4  
    [exec] [1]: ObjectId: 2.5.29.19 Criticality=true  
    [exec] BasicConstraints:[  
    [exec]  CA:true  
    [exec]  PathLen:5  
    [exec] ]  
    [exec]  
    [exec] [2]: ObjectId: 2.5.29.32 Criticality=false  
    [exec] CertificatePolicies [  
    [exec]  [CertificatePolicyId: [1.2.840.113763.1.2.1.3]  
    [exec] [] ]  
    [exec] ]  
    [exec]  
    [exec] [3]: ObjectId: 2.5.29.15 Criticality=true  
    [exec] KeyUsage [  
    [exec]  Key_CertSign  
    [exec]  Crl_Sign  
    [exec] ]  
    [exec]  
    [exec] [4]: ObjectId: 2.5.29.14 Criticality=false  
    [exec] SubjectKeyIdentifier [  
    [exec] KeyIdentifier [  
    [exec] 0000: 76 0A 49 21 38 4C 9F DE  F8 C4 49 C7 71 71 91 9D v.I!8L....I.qq..  
    [exec] ]  
    [exec] ]  
    [exec]  
    [exec] ]  
    [exec]  Algorithm: [SHA1withRSA]  
    [exec]  Signature:  
    [exec] 0000: 41 3A D4 18 5B DA B8 DE  21 1C E1 8E 09 E5 F1 68 A:..[...!......h  
    [exec] 0010: 34 FF DE 96 F4 07 F5 A7  3C F3 AC 4A B1 9B FA 92 4.......<..J....  
    [exec] 0020: FA 9B ED E6 32 21 AA 4A  76 C5 DC 4F 38 E5 DF D5 ....2!.Jv..O8...  
    [exec] 0030: 86 E4 D5 C8 76 7D 98 D7  B1 CD 8F 4D B5 91 23 6C ....v......M..#l  
    [exec] 0040: 8B 8A EB EA 7C EF 14 94  C4 C6 F0 1F 4A 2D 32 71 ............J-2q  
    [exec] 0050: 63 2B 63 91 26 02 09 B6  80 1D ED E2 CC B8 7F DB c+c.&...........  
    [exec] 0060: 87 63 C8 E1 D0 6C 26 B1  35 1D 40 66 10 1B CD 95 .c...l&.5.@f....  
    [exec] 0070: 54 18 33 61 EC 13 4F DA  13 F7 99 AF 3E D0 CF 8E T.3a..O.....>...  
    [exec] 0080: A6 72 A2 B3 C3 05 9A C9  27 7D 92 CC 7E 52 8D B3 .r......'....R..  
    [exec] 0090: AB 70 6D 9E 89 9F 4D EB  1A 75 C2 98 AA D5 02 16 .pm...M..u......  
    [exec] 00A0: D7 0C 8A BF 25 E4 EB 2D  BC 98 E9 58 38 19 7C B9 ....%..-...X8...  
    [exec] 00B0: 37 FE DB E2 99 08 73 06  C7 97 83 6A 7D 10 01 2F 7.....s....j.../  
    [exec] 00C0: 32 B9 17 05 4A 65 E6 2F  CE BE 5E 53 A6 82 E9 9A 2...Je./..^S....  
    [exec] 00D0: 53 0A 84 74 2D 83 CA C8  94 16 76 5F 94 61 28 F0 S..t-.....v_.a(.  
    [exec] 00E0: 85 A7 39 BB D7 8B D9 A8  B2 13 1D 54 09 34 24 7D ..9........T.4$.  
    [exec] 00F0: 20 81 7D 66 7E A2 90 74  5C 10 C6 BD EC AB 1B C2  ..f...t\.......  
    [exec]  
    [exec] ]|#] ...  

There is a simple solution for it. 

Just remove the certificate from the GlassFish keystore. Here is just a simple example used with GlassFish on my Windows developer box. It is slightly different when using a clustered GlassFish.

1. Open a DOS command shell
2. Go to the directory $GLASSFISH_INSTALL/glassfish/domains/domain1/config
3. Type in the following command and execute it

 keytool -delete -alias gtecybertrust5ca -keystore cacerts.jks  

4. In some cases you have to provide a password for the keystore. If you did not change that, it is the default GlassFish keystore password 'changeit'.
5. You can verify whether the alias was deleted by executing the following command in a DOS shell

 keytool -list -keystore cacerts.jks > keytool.output 

6. Opening the file keytool.output in an editor and doing a search for gtecybertrust5ca should yield an empty result set.

Using Eclipse 3.7 and GlassFish 3.1.2 server runtime plugin under Windows to control GlassFish servers

I installed GlassFish 3.1.2 Open Source Edition on my Windows 7 box and wanted to manage the GlassFish instance from Eclipse 3.7 using the GlassFish server runtime plugin.
I installed the plugin via the eclipse marketplace and found out that the version from the marketplace doesn't support GlassFish 3.1.2.
So I googled around and found out about this blog post describing how to install the GlassFish server runtime plugin properly on Eclipse 3.7. There is also a great stackoverflow question describing the problems with multiple "internal GlassFish servers" each time you start Eclipse after you have installed the server runtime plugin for GlassFish 3.1.2.
The later problem only occurs on Windows machines!

Solution for "Sniffers with type [connector] and type [ejb] should not claim the archive at the same time"

In case you are using GlassFish it may happen you run into this error

"java.lang.IllegalArgumentException: Sniffers with type [connector] and type [ejb] should not claim the archive at the same time. Please check the packaging of your archive" 

In my case it happens when I deployed a web archive out of Eclipse directly into a running GlassFish instance on my machine using the GlassFish plugin. 

I tried a Google search for this error and found a blog posting by Adam Bien describing this error and a solution. Well, indeed my packaging was wrong. I accidentally bundled the artifact glassfish-embedded-all into my WAR archive and this was causing the trouble.

The solution is very simple: Either change the scope in your pom.xml to "provided" or - in case you don't need the dependency - remove it from the dependency section of your pom.

In my case it turns out that the dependency was not necessary anymore and I deleted it.

Updating GlassFish 3.1 under RHEL 6 on a 64 Bit machine

Don't be surprised when you have problems updating GlassFish 3.1 on a RedHat Enterprise Linux 6 64 Bit machine. This will not work out of the box (officially Oracle only supports GlassFish on RedHat 4 and 5 not on version 6). But there is a way to get it to work.
You will get this error when executing the pkg command:

 [glassfish@MYMACHINE glassfish3]$ pkg list -u  
 Traceback (most recent call last):  
  File "/opt/glassfish/glassfish3/pkg/bin/client.py", line 61, in ?  
   import pkg.actions as actions  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/__init__.py", line 59, in ?  
   globals(), locals(), [modname])  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/link.py", line 36, in ?  
   import generic  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/generic.py", line 45, in ?  
   import pkg.variant as variant  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/variant.py", line 28, in ?  
   from pkg.misc import EmptyI  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/misc.py", line 49, in ?  
   import zlib  
 ImportError: libz.so.1: cannot open shared object file: No such file or directory  
 ---------------------------------------------------------------  
 There was an error running  
   
 /opt/glassfish/glassfish3/pkg/bin/../python2.4-minimal/bin/python  
   
 You are running on a 64 bit Linux distribution and the 32 bit Linux  
 compatibility libraries do not appear to be installed. In order to use  
 the Update Center tools you must install the 32 bit compatibility libraries.  
   
 On Ubuntu (and possibly other Debian based systems) please install the  
 ia32-libs package. On RedHat 4 (and other RPM based systems), you may  
 need to add multiple 'compat' runtime library packages. Please see the  
 Update Center Release Notes for more information.  
   
   

The solution is to install the following packages using yum

yum install compat-db.i686 zlib.i686 libidn.i686 krb5-libs.i686

The trick is to find out about the correct names of the packages. It's easy on Debian based systems but quiet difficult on RPM based systems.
If you are using CentOS take a closer look at this blog post.

Using the embedded database in Glassfish v2 is that simple

Using the embedded Derby database of Glassfish v2 is pretty simple.

I recently had the requirement to checkout a JEE project to a location where I don't have access to any standard database like DB2, Oracle, MySql, etc ...

Just the embedded database of Glassfish was a viable option. So I checked out the project with Maven and started a build. Before the deployment I had to configure the database to use.

I entered the Glassfish admin web interface and did the following steps:

Resources -> JDBC -> Connection Pools -> New connection pool

 Name = Name of your connection pool  
 Resource Type = javax.sql.DataSource  
 Database Vendor = Derby  

Click "Next"

DataSource Classname = org.apache.derby.jdbc.ClientDataSource (should be prefilled)

Under "Additional Properties"

 connectionAttributes => create=true (this is important)  
 User => APP (this is default)  
 DatabaseName => Name_of_your_database (this is important)  
 Password => APP (this is important)  

Click "Finish" and you are done with the connection pool. Next you will create the datasource.

Resources -> JDBC -> JDBC Resources -> New JDBC Resource

Choose the correct JNDI name which will be used by your JPA and assign the previously created pool to the resource.

Now you are finished.

The dababase will be created when you deploy your application the next time.