H2 console error: No suitable driver found for 08001/0

Question

Hello Im having problem with viewing my schema in H2 console Database:

Im using spring boot:

spring.datasource.initialize=true
spring.datasource.url=jdbc:h2:~/test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MV_STORE=FALSE;MVCC=FALSE
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=
spring.h2.console.enabled=true

this is my login page:

so what i see inside is standard console view , without my tables and yet my app is working fine.

Gaptoothed

Hi @filemonczyk, were you able to solve this? – Nurserymaid

tbh I dont remember the solution – Gaptoothed

I recommend to use direct connection to your H2 db right from your IDE... – Vardon

Answer 1

Usually "Test connection" is working (green line after login form), but connecting does not. This can be caused by handling of headers, which can be caused by filters or security config. For example, I was hit by this twice:

1. I have same symptoms and problem was caused by usage of logging. Removing dependency helped to get rid of No suitable driver found for 08001/0 message while logging into h2-console:

   <dependency>
       <groupId>org.zalando</groupId>
       <artifactId>logbook-spring-boot-starter</artifactId>
   </dependency>
   

I am not sure, if it is bug of given project, or by wrong usage/config.

2. Configuring OAuth2 does hit me also. I need to exclude h2-console uri from web and also http security. See some info here. See snippets:

   @Configuration
   @EnableWebSecurity
   @EnableGlobalMethodSecurity(
           securedEnabled = true,
           jsr250Enabled = true,
           prePostEnabled = true
   )
   @RequiredArgsConstructor
   public class SecurityConfig extends WebSecurityConfigurerAdapter {
       @Override
       public void configure(WebSecurity web) {
           web.ignoring().antMatchers("/h2-console/**");
       }
       @Override
       protected void configure(HttpSecurity http) throws Exception {
           http
                   // only part of config is shown here...
                   .authorizeRequests()
                   .antMatchers("/",
                           "/error",
                           "/favicon.ico",
                           "/**/*.png",
                           "/**/*.gif",
                           "/**/*.svg",
                           "/**/*.jpg",
                           "/**/*.html",
                           "/**/*.css",
                           "/**/*.js",
                           "/h2-console/**")
                   .permitAll()
                   .antMatchers("/auth/**", "/oauth2/**").permitAll()
                   .anyRequest().authenticated()
                   .and()
                   .oauth2Login();
       }
   }
   

Duumvirate

Dear Lubo, thank you very much! After using your solution, i can also start h2-database and the error is gone. Important ist, really NOT use the dependency as you said, and do add the block: "@Override public void configure(WebSecurity web) { web.ignoring().antMatchers("/h2-console/**"); }" – Cut

I have zalando logbook in pom.xml and also org.zalando.logbook: TRACE in application-local.yml. I cannot log into h2 db in the browser, saying "No suitable driver found for 08001/0". After I commented out the line in application-local.yml, I was able to log into h2 db. – Olpe

Answer 2

In my case, the problem was that I implemented a custom Filter (see here, here and here) and the custom HttpServletRequestWrapper needs to take care of the H2 console login request which comes with the form data (including Driver Class input) and parse it as parameters:

public class MyHttpServletRequestWrapper extends HttpServletRequestWrapper {

private String body;

public MyHttpServletRequestWrapper(HttpServletRequest request) {
    super(request);
    this.body = IOUtils.toString(request.getReader());
    //...
}

@Override
public Enumeration<String> getParameterNames() {
    if (!parsedParams)
        parseParams();

    List<String> result = Collections.list(super.getParameterNames());
    result.addAll(parameters.keySet());

    return Collections.enumeration(result);
}

private void parseParams() {
    if (!body.isEmpty()) {
        String[] rps = body.split("&");

        for (String rp : rps) {
            String[] kv = rp.split("=");
            try {
                parameters.put(kv[0], kv.length > 1 ? new String[]{URLDecoder.decode(kv[1], "UTF-8")} : new String[]{""});
            } catch (UnsupportedEncodingException e) {
                e.printStackTrace();
            }
        }

        parameters.setLocked(true);
        parsedParams = true;
    }
}

@Override
public Map<String, String[]> getParameterMap() {
    if (!parsedParams)
        parseParams();

    Map<String, String[]> s = super.getParameterMap();
    return Stream.concat(parameters.entrySet().stream(), s.entrySet().stream()).collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));
}

@Override
public String getParameter(String name) {
    return parameters.get(name) != null ? parameters.get(name)[0] : super.getParameter(name);
}

@Override
public String[] getParameterValues(String name) {
    String[] s = super.getParameterValues(name);
    return ArrayUtils.addAll(s, parameters.get(name));
}
}

Nurserymaid

Had a similar issue and I think I found a little simpler (read fewer new lines of code) workaround. In the constructor call one of the request methods that deals with parameters, e.g. getParameterNames or getParameter("anything"). For some reason, this wasn't working in the filter though. Haven't figured out why yet. – Gooseherd

same, adding a simple logger statement logger.info(request.getParameterNames()); did the trick, it would be interesting to understand the rationale – Bluejacket

confirmed: getParameterNames() internally calls org.apache.catalina.connector.Request.parseParameters(). This does a lot of encoding and parsing stuff. And somehow that initialises something that .... solves the problem :-) – Rodge

@Bluejacket Thanks a lot for that solution. I did not use logger. But just calling request.getParameterNames() solved my problem. – Presidentship

@Rodge Were you able to find out anything more around that. I am lost how it fixes just by calling request.getParameterNames(). – Presidentship

Answer 3

When I encountered this problem I was following a spring boot tutorial. In this tutorial, my spring boot guru used the following code in the application.properties:

spring.h2.console.enabled=true
spring.datasource.platform=h2
spring.datasource.url=jdbc:h2:mem:someName

The last line is not necessary because these are the default configurations done by spring boot:

spring.datasource.url=jdbc:h2:mem:testdb  
spring.datasource.driverClassName=org.h2.Driver  
spring.datasource.username=sa  
spring.datasource.password=  
spring.h2.console.enabled=false

When I removed it, all worked as intended.

Bairn

Answer 4

Just adding the problem and solution I had here, because I did not find any explicit mentions.

I had this problem when updating from Spring Boot 2.1 to 2.2. (When testing I found the problem occurred even when switching from latest 2.1.13.RELEASE to 2.2.0.RELEASE.)

Analysis: Our application uses both Jersey/JAX-RS and Spring Web. To make this work:

• On Spring Boot 2.1 our application configured Jersey to use a servlet filter using (spring.jersey.type=filter) and the JerseyConfig used ServletProperties.FILTER_FORWARD_ON_404 to forward requests it couldn't handle to Spring Boot. This seems to break the h2-console in Spring Boot 2.x

• For Spring Boot 2.2, I removed the "spring.jersey.type=filter" configuration, so that Jersey uses a servlet instead. To make it play nice with Spring Web, I restricted Jersey using @ApplicationPath("/api") (all our JAX-RS requests start with that prefix anyway)

Patronymic

Answer 5

From my end the issue was related to how logbook handles form request.

The LogbookFilter will, by default, treat requests with a application/x-www-form-urlencoded body not different from any other request, i.e you will see the request body in the logs. The downside of this approach is that you won't be able to use any of the HttpServletRequest.getParameter*(..) methods. See issue #94 for some more details.

The logbook team recomends setting up the system property

As of Logbook 1.5.0, you can now specify one of three strategies that define how Logbook deals with this situation by using the logbook.servlet.form-request system property:

i.e

java -jar -Dlogbook.servlet.form-request=parameter server/target/server-1.0-SNAPSHOT.jar

Emrich

Answer 6

Use entire String for connection in H2 Console i.e. , You will see only your tables

jdbc:h2:~/test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;MV_STORE=FALSE;MVCC=FALSE

Selfness