We Keep Coding

Payara 4.1 autodeploy WAR deploy error NullPointerException NCLS-CORE-00069 AS-WEB-CORE-00108

after some code changes I observe a very odd exception from the payara server. The problem with it, I cannot pinpoint down what it is complaining about. Basically I don't know even what is wrong.
Any ideas what could be wrong are much appreciated.
Exceptions in the log during startup:
{"Timestamp":"2018-07-14T11:31:34.430+0000","Level":"WARNING","Version":"Payara 4.1","LoggerName":"javax.enterprise.system.core","ThreadID":"58","ThreadName":"AutoDeployer","TimeMillis":"1531567894430","LevelValue":"900","MessageID":"NCLS-CORE-00069","LogMessage":{"Exception":"Exception while dispatching an event","StackTrace":"org.glassfish.api.invocation.InvocationException
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:219)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:310)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:333)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:505)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:227)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:536)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
at org.glassfish
.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
"}}
Followed by -- twice:
{"Timestamp":"2018-07-14T11:31:34.998+0000","Level":"SEVERE","Version":"Payara 4.1","LoggerName":"javax.enterprise.web.core","ThreadID":"58","ThreadName":"AutoDeployer","TimeMillis":"1531567894998","LevelValue":"1000","MessageID":"AS-WEB-CORE-00108","LogMessage":{"Exception":"ContainerBase.addChild: start: ","StackTrace":"org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5523)
at com.sun.enterprise.web.WebModule.start(WebModule.java:594)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:956)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:939)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:684)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2105)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1750)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:294)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:357)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:509)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:227)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:536)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.e
xecute(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2884)
at org.apache.catalina.core.StandardContext.addApplicationListener(StandardContext.java:2080)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureApplicationListener(TomcatDeploymentConfig.java:236)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureWebModule(TomcatDeploymentConfig.java:95)
at com.sun.enterprise.web.WebModuleContextConfig.start(WebModuleContextConfig.java:239)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:336)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:163)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5520)
... 34 more
Caused by: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:3005)
at org.apache.catalina.core.StandardContext.loadListener(StandardContext.java:5043)
at com.sun.enterprise.web.WebModule.loadListener(WebModule.java:1732)
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2882)
... 41 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:353)
at com.sun.enterprise.web.WebContainer.createListenerInstance(WebContainer.java:808)
at com.sun.enterprise.web.WebModule.createListenerInstance(WebModule.java:2102)
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:3003)
... 44 more
Caused by: java.lang.NullPointerException
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:358)
at org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.java:283)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:476)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:429)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:337)
... 47 more
"}}
This warning comes later a couple of times
{"Timestamp":"2018-07-14T11:31:35.079+0000","Level":"WARNING","Version":"Payara 4.1","LoggerName":"javax.enterprise.web","ThreadID":"58","ThreadName":"AutoDeployer","TimeMillis":"1531567895079","LevelValue":"900","LogMessage":{"Exception":"java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener","StackTrace":"java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:960)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:939)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:684)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2105)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1750)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:294)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:357)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:509)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:227)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:536)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:544)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:540)
at j
ava.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:570)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:562)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:561)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1469)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:111)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1851)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
"}}
These exceptions are now repeated multiple times followed by the container has not yet started exception and in the end the good old "Autodeploy failed"
Locally it deploys fine, only on the server (OpenShift Linux Pod) it fails.
This are the only warnings I get on a local successful deploy (app runs):
WARNUNG: Could not load service class fish.payara.appserver.roles.api.extension.RolesCDIExtension
WARNUNG: Could not load service class fish.payara.appserver.roles.api.extension.RolesCDIExtension
WARNUNG: Could not load service class fish.payara.appserver.roles.api.extension.RolesCDIExtension
Information: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(#Observes ProcessAnnotatedType) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
Information: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(#Observes ProcessAnnotatedType) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
Information: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(#Observes ProcessAnnotatedType) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
WARNUNG: The following warnings have been detected: WARNING: Parameter interceptedBean of type javax.enterprise.inject.spi.Bean from private javax.enterprise.inject.spi.Bean org.glassfish.soteria.cdi.LoginToContinueInterceptor.interceptedBean is not resolvable to a concrete type.
WARNUNG: The following warnings have been detected: WARNING: Parameter interceptedBean of type javax.enterprise.inject.spi.Bean from private javax.enterprise.inject.spi.Bean org.glassfish.soteria.cdi.RememberMeInterceptor.interceptedBean is not resolvable to a concrete type.
WARNUNG: Class class [Ljava.lang.String; has null package
INFORMATION: Initializing Soteria 1.1-b01 for context ''
INFORMATION: Mojarra 2.2.14 (-SNAPSHOT 20170628-1326 unable to get svn info) für Kontext '' wird initialisiert.
WARN: WELD-000718: No EEModuleDescriptor defined for bean archive with ID: XXXXXXXXX_war.war. #Initialized and #Destroyed events for ApplicationScoped may be fired twice.
What have I tried:
Reverted any version updates of any libs
removed any Startup EJBs -- which in the end showed the above error
Verified the configuration
Thanks in advance
Paul

The exception is most probably a deployment error caused by your application or configuration. Payara Server has a bug that it doesn't log the original exception but throws only a subsequent exception, so you can't see what's wrong in your application from the log messages.
The issue with logging the original message is described in https://github.com/payara/Payara/issues/2332. It's fixed in Payara 5.182 and users also reported that the new weld version in 5.182 removed their deployment error.
You may try upgrading to Payara 5.182. If that's not possible, you may find out what's causing the deployment problem by debugging your the server, putting an exception breakpoint on DeploymentException and check the message of the exception.

I could pin it down to the Payara version (docker image). It seems like that where is a bigger difference between:
sh-4.2$ ./asadmin version
Version = Payara Server 4.1.2.181 #badassfish (build 220)
Command version executed successfully.
Which works fine and:
sh-4.2$ ./asadmin version
Version = Payara Server 4.1.2.182.1 #badassfish (build 308)
Command version executed successfully.
Which causes the error above. I haven't looked into the details till now -- and just reverted the version of the Payara to 4.1.2.181 again.
Disclaimer: As it is a docker image it is possible, that the payara was modified and it has nothing todo with the payara itself. I haven't verified that, as mentioned above.

JUnit testing - Hw can I set up my DB connect to avoid tests failing due to maximum DB connection reached

I am doing some DAO testing in Java, and I have defined a class that sets the connection to the testing DB like this
import io.dropwizard.testing.ResourceHelpers;
import io.dropwizard.testing.junit.DropwizardAppRule;
import my.project.package.ProjectTestAppConfiguration;
import my.project.package.ProjectTestApplication;
import my.project.package.domain.ProjectClass1;
import org.hibernate.Session;
import org.hibernate.SessionException;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.junit.ClassRule;
import java.util.Map;
import java.util.logging.Level;
public class DAOTestConfig {
protected SessionFactory sessionFactory;
#ClassRule
public static final DropwizardAppRule<ProjectTestAppConfiguration> RULE =
new DropwizardAppRule<ProjectTestAppConfiguration>
(ProjectTestApplication.class, ResourceHelpers.resourceFilePath("applicationTest.yml"));
public DAOTestConfig() {
Map<String, String> properties = RULE.getConfiguration().getDataSourceFactory().getProperties();
Configuration configuration = new Configuration();
for (Map.Entry<String, String> property : properties.entrySet()) {
configuration.setProperty(property.getKey(), property.getValue());
}
/* Add annotated classes here */
configuration.addAnnotatedClass(ProjectClass1.class);
/* ... */
sessionFactory = configuration.buildSessionFactory();
}
public Session getSession() {
Session session;
try{
session = sessionFactory.getCurrentSession();
} catch (SessionException e) {
session = sessionFactory.openSession();
}
return session;
}
}
My applicationTest.yml file contains standard db connection, like
# Database settings.
database:
# the name of your JDBC driver
driverClass: org.postgresql.Driver
# the username for DB
user: ${FH_DB_USER}
# the password
password: ${FH_DB_PASSWORD}
# the JDBC URL
url: jdbc:postgresql://${FH_DB_HOST}:${FH_DB_PORT}/${FH_DB_NAME}
# any properties specific to your JDBC driver:
properties:
charSet: UTF-8
hibernate.dialect: org.hibernate.dialect.PostgreSQLDialect
hibernate.connection.driver_class: org.postgresql.Driver
hibernate.temp.use_jdbc_metadata_defaults: false
hibernate.connection.url: jdbc:postgresql://${FH_DB_HOST}:${FH_DB_PORT}/${FH_DB_NAME}
hibernate.connection.username: ${FH_DB_USER}
hibernate.connection.password: ${FH_DB_PASSWORD}
hibernate.current_session_context_class: thread
hibernate.show_sql: true
I currently have more than twenty test case classes that have an average of 5 test cases in each, that connects to the DB. As you can see, I am using dropwizard and hibernate in my procts; my DAO classes use hibernate C-R-U-D (crate, read, updte, delete) methods, and the connections are made to a postgres DB. And each class extends this DAOTestConfig class.
I was running the test on my local michine but I want to use a remote DB instance, and now some of my tests are failing with the error Error calling Driver#connect
Here is an example of the stack trace of one of the tests that failed:
org.hibernate.exception.GenericJDBCException: Error calling Driver#connect
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111)
at org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.convertSqlException(BasicConnectionCreator.java:118)
at org.hibernate.engine.jdbc.connections.internal.DriverConnectionCreator.makeConnection(DriverConnectionCreator.java:41)
at org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.createConnection(BasicConnectionCreator.java:58)
at org.hibernate.engine.jdbc.connections.internal.PooledConnections.addConnections(PooledConnections.java:106)
at org.hibernate.engine.jdbc.connections.internal.PooledConnections.<init>(PooledConnections.java:40)
at org.hibernate.engine.jdbc.connections.internal.PooledConnections.<init>(PooledConnections.java:19)
at org.hibernate.engine.jdbc.connections.internal.PooledConnections$Builder.build(PooledConnections.java:138)
at org.hibernate.engine.jdbc.connections.internal.DriverManagerConnectionProviderImpl.buildPool(DriverManagerConnectionProviderImpl.java:110)
at org.hibernate.engine.jdbc.connections.internal.DriverManagerConnectionProviderImpl.configure(DriverManagerConnectionProviderImpl.java:74)
at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:94)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:217)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:189)
at org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.buildBootstrapJdbcConnectionAccess(JdbcEnvironmentInitiator.java:158)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.getBootstrapJdbcConnectionAccess(JdbcServicesImpl.java:71)
at org.jadira.usertype.spi.shared.AbstractUserTypeHibernateIntegrator.use42Api(AbstractUserTypeHibernateIntegrator.java:83)
at org.jadira.usertype.spi.shared.AbstractUserTypeHibernateIntegrator.integrate(AbstractUserTypeHibernateIntegrator.java:206)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:276)
at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:465)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:708)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:724)
at my.project.package.persistence.DAOTestConfig.<init>(DAOTestConfig.java:106)
at my.project.package.persistence.ProjectClass1DAOTest.<init>(ProjectClass1DAOTest.java:19)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: org.postgresql.util.PSQLException: FATAL: remaining connection slots are reserved for non-replication superuser connections
at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:691)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:207)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:65)
at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:149)
at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:35)
at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22)
at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:47)
at org.postgresql.jdbc42.AbstractJdbc42Connection.<init>(AbstractJdbc42Connection.java:21)
at org.postgresql.jdbc42.Jdbc42Connection.<init>(Jdbc42Connection.java:28)
at org.postgresql.Driver.makeConnection(Driver.java:415)
at org.postgresql.Driver.connect(Driver.java:282)
at org.hibernate.engine.jdbc.connections.internal.DriverConnectionCreator.makeConnection(DriverConnectionCreator.java:38)
... 50 more
On my local machine I added a work around on this to make all my tests pass, by changing the maximum connection number from 100 to 300, but now that I want to find a permanent solution in case that number become small in the future. And there are other project that will be using that same remote DB instance.
I have googled for the solution to this but I can't find it. Either there is none or I am asking the wrong question. Can anyone help me on this?
Thank you.

Hw can I set up my DB connect to avoid tests failing due to maximum DB connection reached
When UnitTesting you do not connect to a database.
You mock the classes that do the actual database connection and configure them to return well defined values suitable for your test case. In order to do that you may use a mocking framework like Mockito or alike.
Also UnitTest verify behavior of your own code. Your Test verifies the behavior of the code that connects to the database and this looks like some Framework you use. This would only be needed if you don't trust that framework, but if it is not trustworthy, why do you use it then?

ClassFormatError: Duplicate method name&signature from EnhancerBySpringCGLIB

I"m really stumped here. I've upgraded our Spring libraries from 4.0.6 to 4.3.2. One of our tests fail when running with 4.3.2. This is the code in question:
#Bean(name = SCHEDULER_FACTORY)
public SchedulerFactoryBean getSchedulerFactory()
{
SchedulerFactoryBean schedulerFactory = new SchedulerFactoryBean();
schedulerFactory.setConfigLocation(schedulerConfig);
schedulerFactory.setResourceLoader(null);
schedulerFactory.setDataSource(dataSource);
schedulerFactory.setJobFactory(getSchedulerJobFactory());
schedulerFactory.setAutoStartup(false);
return schedulerFactory;
}
#Bean(name = SCHEDULER)
public Scheduler getScheduler()
{
return getSchedulerFactory().getScheduler();
}
I'm getting the error java.lang.ClassFormatError: Duplicate method name&signature in class file org/springframework/scheduling/quartz/SchedulerFactoryBean$$EnhancerBySpringCGLIB$$bee87fe8$$EnhancerBySpringCGLIB$$6bb26669.
Running the test using spring 4.0.6 framework works perfectly fine, but with 4.3.2, it's failing. When using 4.0.6, I was using cglib no dependencies library. With 4.3.2, the tests fail regardless of whether or not I use cglib.
Spring embeds cglib and objensis into 4.3.* core library. "Furthermore, Spring Framework 4.3 embeds the updated ASM 5.1, CGLIB 3.2.4, and Objenesis 2.4 in spring-core.jar." SpringDocs
We were using Java 8 and cglib-no-dep 2.2 with Spring framework 4.0.6. We tried running this code with and without the standalone library and see the same results.
Stack trace:
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.quartz.Scheduler]: Factory method 'getScheduler' threw exception; nested exception is org.springframework.cglib.core.CodeGenerationException:java.lang.reflect.InvocationTargetException >null
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:189)
at org.springframework.beans.factory.support.ConstructorResolver$3.run(ConstructorResolver.java:582)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:579)
... 112 more
Caused by: org.springframework.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException >null
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:345)
at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:492)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 188.486 sec
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
at org.springframework.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:480)
at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:337)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.enhanceFactoryBean(ConfigurationClassEnhancer.java:452)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:338)
at com.example.SpringConfiguration$$EnhancerBySpringCGLIB$$54d3cb35.getSchedulerFactory(<generated>)
at com.example.SpringConfiguration.getScheduler(SpringConfiguration.java:242)
at com.example.SpringConfiguration$$EnhancerBySpringCGLIB$$54d3cb35.CGLIB$getScheduler$24(<generated>)
at com.example.SpringConfiguration$$EnhancerBySpringCGLIB$$54d3cb35$$FastClassBySpringCGLIB$$a2a6e004.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:356)
at com.example.SpringConfiguration$$EnhancerBySpringCGLIB$$54d3cb35.getScheduler(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
... 115 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:413)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:336)
... 140 more
Caused by: java.lang.ClassFormatError: Duplicate method name&signature in class file org/springframework/scheduling/quartz/SchedulerFactoryBean$$EnhancerBySpringCGLIB$$bee87fe8$$EnhancerBySpringCGLIB$$6bb26669
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
... 145 more

This is definetly a bug in cglib. It seems like it does not currectly determines a method in the type hierarchy to be equal to another method. Are you using Java 8 in combination with default methods in interfaces?
Cglib is not really tested for modern Java versions and experiences only little maintenance. Newer features sometimes cause trouble when using the library.

Spring boot does not start when secondary datasource database connection unavailable

Caused by: java.lang.NullPointerException
at org.springframework.boot.actuate.endpoint.DataSourcePublicMetrics.initialize(DataSourcePublicMetrics.java:64) ~[spring-boot-actuator-1.3.2.RELEASE.jar:1.3.2.RELEASE]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_79]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_79]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_79]
at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_79]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:354) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
I disabled the metrics too but no luck
endpoints.enabled=false
endpoints.autoconfig.enabled=false
endpoints.metrics.enabled=false
The DataSourcePublicMetrics bean always gets created, even when the metrics are disabled. This causes a NullPointerException when the database connection is unavailable, causing spring boot not to start.

I am using Hikari datasource and it fails to construct data source object when database is unavailable. Hence NPE from DataSourcePublicMetrics bean. I am able to circumvent the issue creating a Hikari data source that is lazy initialized with database config even when database is unavailable for later use when database becomes available. Not sure why HikariDataSource does not have a constructor for lazy init. It does have a default constructor but database config can't be set using any setter method. This is useful for applications where database is not always necessary to start them up.
public class LazyConnectionDataSource extends HikariDataSource {
public LazyConnectionDataSource(HikariConfig config) {
config.validate();
config.copyState(this);
}
}

Error while indexing in Hibernate Search (before transaction completion)

I am tired of banging my head around this problem So if anyone could suggest me where I am wrong I'll be grateful.
The problem is I am using Spring-Batch and Hibernate Full-Text Search in my Spring MVC project.So from the batch job Tasklet I am calling following code:
A a=aDao.merge(a);
b.setA(a);
bDao.save(b);
While doing the save update on these entites I am getting an exception and the stacktrace is as follows:
org.springframework.orm.hibernate3.HibernateSystemException: Error while indexing in Hibernate Search (before transaction completion); nested exception is org.hibernate.HibernateException: Error while indexing in Hibernate Search (before transaction completion)
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:690)
at org.springframework.orm.hibernate3.HibernateTransactionManager.convertHibernateAccessException(HibernateTransactionManager.java:793)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:664)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:147)
at org.springframework.batch.core.step.tasklet.TaskletStep$2.doInChunkContext(TaskletStep.java:264)
at org.springframework.batch.core.scope.context.StepContextRepeatCallback.doInIteration(StepContextRepeatCallback.java:76)
at org.springframework.batch.repeat.support.RepeatTemplate.getNextResult(RepeatTemplate.java:367)
at org.springframework.batch.repeat.support.RepeatTemplate.executeInternal(RepeatTemplate.java:214)
at org.springframework.batch.repeat.support.RepeatTemplate.iterate(RepeatTemplate.java:143)
at org.springframework.batch.core.step.tasklet.TaskletStep.doExecute(TaskletStep.java:250)
at org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:195)
at org.springframework.batch.core.job.SimpleStepHandler.handleStep(SimpleStepHandler.java:135)
at org.springframework.batch.core.job.flow.JobFlowExecutor.executeStep(JobFlowExecutor.java:61)
at org.springframework.batch.core.job.flow.support.state.StepState.handle(StepState.java:60)
at org.springframework.batch.core.job.flow.support.SimpleFlow.resume(SimpleFlow.java:144)
at org.springframework.batch.core.job.flow.support.SimpleFlow.start(SimpleFlow.java:124)
at org.springframework.batch.core.job.flow.FlowJob.doExecute(FlowJob.java:135)
at org.springframework.batch.core.job.AbstractJob.execute(AbstractJob.java:281)
at org.springframework.batch.core.launch.support.SimpleJobLauncher$1.run(SimpleJobLauncher.java:120)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.hibernate.HibernateException: Error while indexing in Hibernate Search (before transaction completion)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:175)
at org.hibernate.engine.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:543)
at org.hibernate.engine.ActionQueue.beforeTransactionCompletion(ActionQueue.java:216)
at org.hibernate.impl.SessionImpl.beforeTransactionCompletion(SessionImpl.java:571)
at org.hibernate.jdbc.JDBCContext.beforeTransactionCompletion(JDBCContext.java:250)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:138)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:656)
... 21 more
Caused by: org.hibernate.LazyInitializationException: could not initialize proxy - no Session
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:167)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:215)
at org.hibernate.search.util.HibernateHelper.unproxy(HibernateHelper.java:62)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.buildDocumentFields(DocumentBuilderIndexedEntity.java:394)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.buildDocumentFields(DocumentBuilderIndexedEntity.java:481)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.buildDocumentFields(DocumentBuilderIndexedEntity.java:481)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.getDocument(DocumentBuilderIndexedEntity.java:379)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.createAddWork(DocumentBuilderIndexedEntity.java:317)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue(DocumentBuilderIndexedEntity.java:295)
at org.hibernate.search.engine.WorkPlan$PerEntityWork.enqueueLuceneWork(WorkPlan.java:445)
at org.hibernate.search.engine.WorkPlan$PerClassWork.enqueueLuceneWork(WorkPlan.java:246)
at org.hibernate.search.engine.WorkPlan.getPlannedLuceneWork(WorkPlan.java:150)
at org.hibernate.search.backend.WorkQueue.prepareWorkPlan(WorkQueue.java:134)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:124)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.beforeCompletion(PostTransactionWorkQueueSynchronization.java:89)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:172)
... 27 more
I am not getting whats gone wrong.I am using org.springframework.orm.hibernate3.HibernateTransactionManager and my Spring version is 3.2 Hibernate core version is 3.6 final.
Note :This exception occurs often but When I create a new tables or use fresh db it works like charm and all modification/insertion are getting reflected properly in database.Can somebody explain me this behavior or Have i done something fishy.
Tell me if you need more details.
Thank you.
Code Update:
<batch:job-repository id="jobRepository"
data-source="myJNDI"
transaction-manager="transactionManager"
isolation-level-for-create="READ_COMMITTED"
max-varchar-length="2500"
lob-handler="defaultLobHandler"
/>
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="safeSessionFactory" />
</bean>
Like this I am configuring transaction manager in applicationContext.xml for Spring-Batch.And I have tried doing this with manually opening and closing session with manual commit of transaction but the exception remains same.And yes I have annotated my method as #Transactional.

I found the root cause of problem is Spring's Declarative Transaction Management.
Spring Batch in Action Reference:
Disable Spring’s declarative transactions for your batch application—Don’t use the tx:annotation-driven element or any XML
configuration related to declara- tive transaction management.
Be careful using propagation levels if declarative transactions are on—If you call trans- actional classes from a Spring Batch job,
Spring’s transaction propagation can interfere with the Spring Batch
transaction because of the propagation level. The REQUIRES_NEW
propagation level could typically cause problems because the
application code runs in its own transaction, independent of the
Spring Batch transaction.
The following are guidelines to avoid conflict between Spring Batch–managed and
Spring-managed transactions: