Due to how we deploy Hopsworks (hopsworks-ear and hopsworks-ca separately) each class annotated as `@Singleton` will spawn actually 2 different ejbs. One as part of the hopsworks-ear application and one as part of the hopsworks-ca application.
First example: if we have a singleton timer bean, it will be started twice and will do the work twice.
Another example is the `OpenSSLOperations.java` which is supposed to synchronize on openssl operations as openssl doesn't really like concurrent operations. What happens though is that you can try to create a project (and generate the project certificate) and at the same time Hops can request a sign for an App CSR. These operations will be executed concurrently as they rely on 2 different singletons.
Right now hopsworks-common has basically all the business logic. Longer term we should look into reducing the scope of the package. For a shorter term solution, we should move all the security related classes in hopsworks-ca and make rest calls from hopsworks-ear each time we want to sign a certificate (for instance during project creation).
This strategy will help us moving to clustered hopsworks, where we have only a single glassfish instance signing the certificates, and all the other glassfish instances sending rest request to get stuff signed.