I am configuring a database in Spring JPA and I want to know what the possible values are of spring.datasource.initialization-mode. I found this page with common properties but it doesn't give all possible values. I'd expect there to be some documentation on all possible values of all properties you can set.
I am using the property in the props section in my applicationContext.xml as properties for the entityManagerFactory
<util:properties id="props">
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQL82Dialect</prop>
<prop key="hibernate.hbm2ddl.auto">create</prop>
<prop key="hibernate.ddl-auto">create</prop>
<prop key="spring.jpa.show-sql">true</prop>
<prop key="spring.jpa.generate.ddl">true</prop>
<prop key="spring.jpa.hibernate.ddl-auto">create</prop>
<prop key="spring.datasource.initialization-mode">always</prop>
<prop key="spring.jpa.properties.hibernate.jdbc.lob.non_contextual_creation">true</prop>
</util:properties>
When all else fails, you remember "use the source, Luke!". The values are given in the Javadoc of the enum DataSourceInitializationMode. Values are always, embedded and never.
Forgive me for butting in almost a year late. After having faced a similar problem as explained by Christine, I decided to take the clue and begin searching in the source. It would appear that the following is detailed in the link here https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/jdbc/DataSourceInitializationMode.html :
Enum Constant Summary Enum Constants
Enum Constant and Description
ALWAYS Always initialize the datasource.
EMBEDDED Only initialize an embedded datasource.
NEVER Do not initialize the datasource.
Spring Behaviour varies w.r.t to the Spring Version
From 2.7 Version of Spring
Spring Creates Table using schema.sql and data.sql in classpath for Embedded i.e memory database
spring.datasource.url=jdbc:h2:mem:somedbofyours
I have tried the following configuration
Create file based H2
spring.datasource.url=jdbc:h2:file:~/db/eesandb
spring.jpa.generate-ddl=true
spring.jpa.hibernate.ddl-auto=none
Whatever be the above combinations, it didnt create or execute schema.sql in 2.7.4
The Following Property spring.sql.init.mode determines creation of DDL,DML by referring schema.sql and data.sql in classpath
Example spring.sql.init.mode = always (or)
spring.datasource.initialization-mode=always.
Visit Similar Post Why Spring Boot 2.0 application does not run schema.sql?
Simply put, there're 3 options: always, embedded and never.
Note that: the property spring.datasource.initialization-mode is outdated.
You may want to consider spring.sql.init.mode instead for new projects.
source for the old one
/*
* Copyright 2012-2019 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* https://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.springframework.boot.jdbc;
/**
* Supported {#link javax.sql.DataSource} initialization modes.
*
* #author Vedran Pavic
* #author Stephane Nicoll
* #since 2.0.0
* #see AbstractDataSourceInitializer
*/
public enum DataSourceInitializationMode {
/**
* Always initialize the datasource.
*/
ALWAYS,
/**
* Only initialize an embedded datasource.
*/
EMBEDDED,
/**
* Do not initialize the datasource.
*/
NEVER
}
source for the new
/*
* Copyright 2012-2021 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* https://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.springframework.boot.sql.init;
/**
* Supported database initialization modes.
*
* #author Andy Wilkinson
* #since 2.5.1
* #see AbstractScriptDatabaseInitializer
*/
public enum DatabaseInitializationMode {
/**
* Always initialize the database.
*/
ALWAYS,
/**
* Only initialize an embedded database.
*/
EMBEDDED,
/**
* Never initialize the database.
*/
NEVER
}
Related
spring-framework/spring-core/src/main/java/org/springframework/util at main · spring-projects/spring-framework · GitHub
eg: spring-framework/ClassUtils.java at main · spring-projects/spring-framework · GitHub
/**
* Miscellaneous {#code java.lang.Class} utility methods.
* Mainly for internal use within the framework.
*
* #author Juergen Hoeller
* #author Keith Donald
* #author Rob Harrop
* #author Sam Brannen
* #since 1.1
* #see TypeUtils
* #see ReflectionUtils
*/
public abstract class ClassUtils {
// omitted
}
eg: spring-framework/CollectionUtils.java at main · spring-projects/spring-framework · GitHub
/**
* Miscellaneous collection utility methods.
* Mainly for internal use within the framework.
*
* #author Juergen Hoeller
* #author Rob Harrop
* #author Arjen Poutsma
* #since 1.1.3
*/
public abstract class CollectionUtils {
// omitted
}
It is mentioned in Item 4 of "Effective Java": Enforce non-instantiability with a private constructor.
Attempting to enforce noninstantiability by making a class abstract does not work. The class can be subclassed and the subclass instantiated. Furthermore, it misleads the user into thinking the class was designed for inheritance (Item 17).
From Item 4: Enforce noninstantiability with a private constructor | Creating and Destroying Java Objects | InformIT
I have a program that uses annotations and another one that is using fist one as dependency. I was able to do that thanks to persistance.xml. But I added validator class to first one (desktop app) because second one is web app and have some new possibilities like attaching files so I created validator class for it. At this moment I created dao and model layer for it in second program sources but I want to add it to first one instead.
If I don't add tag #Entity to this class then I can;t add it to persistence.xml so my second program can't find that source.
Is it okay to add #Entity when Validator does not and will not use database and there is no table for it?
I know it works because I tested it, but I wonder if this is good attitude.
If not, how can I make it done different way?
Also if validator class is empty, I mean it doesn't have any fields, only one method to validate that return true or false, is it ok to make dao layer and model layer for it?
Atm it is: Validator class, ValidatorDao class and ValidatorDaoInterface interface.
Is that correct approach?
model:
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package xxx.model;
/**
*
* #author
*/
public class Validator {
}
dao:
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package xxx.dao;
import javax.servlet.http.Part;
/**
*
* #author
*/
public class ValidatorDao implements ValidatorDaoInterface {
#Override
public boolean validateFile(Part part, int numberOfFiles) {
/*TODO*/
}
}
interface:
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package xxx.dao;
import javax.servlet.http.Part;
/**
*
* #author
*/
public interface ValidatorDaoInterface {
public boolean validateFile(Part part, int numberOfFiles);
}
yes you can exclude classes that are not annotated with #Entity in your Persitence.xml file.
Just add this line to your persitence-unit
<exclude-unlisted-classes>true</exclude-unlisted-classes>
and you won't have to annotate your validator classes with #Entity because that's wrong.
I've just started using the javadoc tool to create documentation for a package containing a servlet class. It's working as expected for every class except the servlet, where the description doesn't appear.
After trial and error I narrowed down the cause to the #WebServlet annotation I use to declare the servlet for Tomcat. I'd rather not remove this annotation if it can be avoided. Is there an easy workaround that I could use?
This is the relevant section of my code:
import javax.servlet.annotation.WebServlet;
#WebServlet("/MyServlet")
/**
* MyServlet description
*
* #author ViscountRandom
* #since 2014-08-26
*/
public class MyServlet extends HttpServlet {
...
The resulting javadoc page can be seen here (note the description is missing and the #WebServlet annotation appears above the class name).
Thanks in advance for any help you can offer.
EDIT: I have tried repositioning the annotation in my code but that had no effect.
For me, it seems to be working, see
/**
* My javadoc
* <br>25/08/2014
*/
#WebServlet
public class MyServlet {
}
generates
while
#WebServlet
/**
* My javadoc
* <br>25/08/2014
*/
public class MyServlet {
}
generates
I am using Java 7.
If you just want your javadoc to go right above the method declaration in the source code, you can still try
/**
* My javadoc
* <br>25/08/2014
*/
#WebServlet public class MyServlet {
}
which will generate
Reading the Tomcat 7 source code, I just wonder why Tomcat instance Catalina and invokes the related methods by using reflection instead of simply using new to create the object and calling the method directly?
The answer is in the javadoc comment of the Bootstrap class:
/**
* Bootstrap loader for Catalina. This application constructs a class loader
* for use in loading the Catalina internal classes (by accumulating all of the
* JAR files found in the "server" directory under "catalina.home"), and
* starts the regular execution of the container. The purpose of this
* roundabout approach is to keep the Catalina internal classes (and any
* other classes they depend on, such as an XML parser) out of the system
* class path and therefore not visible to application level classes.
*
* #author Craig R. McClanahan
* #author Remy Maucherat
* #version $Id: Bootstrap.java 1142323 2011-07-02 21:57:12Z markt $
*/
public final class Bootstrap { ... }
We've recently upgraded one of our projects. This involves new versions of JARs also.
Sitemesh was one of them. We updated from 2.2.1 to 2.4.2. Things stopped working.
We had a custom filter extend Sitemesh's PageFilter which now does not work because in v2.4 PageFilter extends SiteMeshFilter which does not expose the same methods (the ones we were overriding).
OK, no biggy, we'll just change our code to match, but then I saw this in the source code I downloaded from http://java.net/downloads/sitemesh/
/**
* Core Filter for integrating SiteMesh into a Java web application.
*
* #author Joe Walnes
* #author Scott Farquhar
* #since SiteMesh 3
*/
public class SiteMeshFilter implements Filter {
private FilterConfig filterConfig;
private ContainerTweaks containerTweaks;
private static final String ALREADY_APPLIED_KEY = "com.opensymphony.sitemesh.APPLIED_ONCE";
............
#since SiteMesh 3? This is v2.4.2. What 3?
Is the release corrupt or what? Am I missing something?
I'm using sitemesh 2.4.2 in one project and it works fine.
You can see that that change (which mentions Sitemesh 3) was done back in 2005 when they refactored the architecture to be compatible with sitemesh3. Here's the commit in github.
I remember getting a similar impression when I was browsing the javadocs a few months ago :).
So the answer is: The jar is not corrupt, it's just the result of a crooked merge.