Spring boot Embedded MongoDb data prefilled - mongodb

I want to know if there are any tools like Flyway which can assist in database initialization / migration for mongodb. Some of the thoughts I had is
I have used flapdoodle as embedded mongo with springboot. This works fine but, I need to manually put data into it.
For Junit tests with mongo db, I use nosqlunit. This works perfectly fine with Fongo(Fake mongo). It has support to read data from a json file and prefill the database with data during startup. But this works only with junit, since this is a JUnit extension.
What I am looking for is a mix of both of the above, an embedded mongo which works not only with JUnit and can prefill data from a given json(similar to V1__init.sql in Flyway)
Is there any such tool ?

You can also use Mongobee for this. If runs your changeset when the application loads.
Maven dependency
<dependency>
<groupId>com.github.mongobee</groupId>
<artifactId>mongobee</artifactId>
</dependency>
you will need to create the bean for Mongobee in your context xml file
<bean id="mongobee" class="com.github.mongobee.Mongobee">
<constructor-arg ref="mongo"/>
<property name="dbName" value="${mongo.databaseName}"/>
<property name="enabled" value="true"/>
<property name="changeLogsScanPackage" value="basepackagewherechangesetispresent"/>
Now add changeset class
#ChangeLog(order = "1")
public class DatabaseChangeLog {
#ChangeSet(order = "101", id = "somelogicalnameforthischangeset", author = "nameofpersonwhodidthischange")
public void setupSeedData(MongoTemplate mongoTemplate) {
// run your datasetup, prefill,migration here.
}
And just like flyway, it also maintains the schema version table, so that same change set does not ran again in same environment.

Finally, I developed this simple version of data prefill for Mongo. Here is the code.
https://github.com/pvpkiran/mongoprefill
Given seed data, this Autoconfiguration fills up mongo.

You can import JSON data during your tests with flapdoodle
See the answer to a similar question here: Import JSON file in Mongo db using Spring Data Embedded Mongo

Related

MongoTemplate - get the connection URI

We are injecting the mongotemplate using the spring config
<mongo:mongo-client id="mongoClient" connection-string="${mongodb.connect-string}">
<mongo:client-settings read-preference="PRIMARY_PREFERRED" retry-writes="true" />
</mongo:mongo-client>
<mongo:db-factory id="mongoDbFactory" dbname="${mongodb.database}" mongo-client-ref="mongoClient" />
<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
<constructor-arg name="mongoDbFactory" ref="mongoDbFactory"/>
</bean>
#Inject
private MongoTemplate mongoTemplate;
Now we are creating a separate integration checkpoint to ensure the mongo db is available and show a green or red traffic light. Is it possible to get the connection URI from the instantiated mongotemplate or I should use ${mongodb.connect-string} to build the integration point?
In the older version of mongotemplate (springDataMongoDb : 1.8.2) we were able to use the following method to get the address
ServerAddress address = mongoTemplate.getDb().getMongo().getAddress();
but with spring 3.4.6 it is not possible to get the address using the above.
I would suggest using ${mongodb.connect-string} as you suggested since this is much more straight forward and doesn't require you to have to wire in the mongo template just to return a constant value when that is the exact propose of spring configs via the #Value annotation.
But a better solution to the green/red for mongo connectivity is using spring actuator which already has this functionality built in.
https://reflectoring.io/spring-boot-health-check/

Servicemix spring context with JPA

I m having a problem with ServiceMix and JPA.
I m new on servicemix and on the project I work for.
A bundle already exist to set the database configuration and contains a persistence.xml file with some properties in persistence-unit.
this persistent unit is for a postgresql database and work fine.
Recently someone add a new bundle. This bundle is a migration of an existing application that contains work to clean all table in relation with the treatment to have empty db -> readfile-> insert into db some data-> extract data into file for another application.
Now in OSGI bundle, we decide to create an H2 database with spring-context each time the process is launch. We work in memory and we don t have to clean all table with this solution.
So we have done a blueprint.xml that launch a bean, and the bean create a appContext = new OsgiBundleXmlApplicationContext(...)
And when treatment is done we do appContext.close() and all spring context is destroy. (this treatment is run only once a day so no problem with time loading)
To do so we have an applicationContext.xml that contain
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation" value="classpath:META-INF/persistence.xml" />
...
<bean id="dataSource" class="org.springframework.jdbc.datasource.SingleConnectionDataSource">
....
....
All work fine, Spring Context is loaded with H2 in memory databse, and at the end of the treatment, h2 database not exist anymore.
Now the problem is when a query is launch on postgresql database, i have problem with insertion because entitymanager try to save entity with 0 id!
O id is meaning null because we don't allow-zero-id in persistence.xml for postgressql database, but in persistence.xml for H2 databse we set allow-zero-id to true and if the H2 treatment is launch only one time, the other entitymanager(postrgesql) don't work anymore and try to insert always 0 id in database instead of call sequence because of the allow-zero-id.
I don't now why the property for persistent unit defined in H2 databse ovveride property of persistence-unit of postgresql.
If someone can help? does new OsgiBundleXmlApplicationContext(..) try to find an osgi service for entitymaneger and get an existing one instead of create à new one?

Apache Ignite: Failed to unmarshal discovery data

I'm trying to use the Ignite Jdbc connection; with my goal to be able to call the cache from any client over Jdbc.
I've got a number of scenario's working; so have data loaded correctly; and can run sql queries 'directly' against the cache.
When I try to call from a separate client with
ResultSet rs = conn.createStatement().executeQuery("select * from my_table");
I hit an error:
class org.apache.ignite.IgniteCheckedException: Failed to find class with given class loader for unmarshalling (make sure same versions of all classes are available on all nodes or enable peer-class-loading) [clsLdr=URLClassLoader with NativeCopyLoader with RawResources(
Is there a way to prevent the Ignite jdbc connection from trying to do any unmarshalling?
I would like my client to be as agnostic as possible to the Ignite classes. For example; I would like to swap out calling mariaDb to Ignite - with as little code change as possible on the client side.
If I'm thinking about things the wrong way; then answer along the lines of No, that will never work because ... are more than welcome too.
Thanks
Brent
If you don't want copy libs to client's lib folder, you can turn on Peer Class Loading:
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
...
<!-- Explicitly enable peer class loading. -->
<property name="peerClassLoadingEnabled" value="true"/>
...
</bean>
Also, you can work with BinaryObject, instead of your classes. Here is some example of using sql with BinaryObjects. More information on the binary format is provided here.

Alfresco Share: Retrieve config data from Java

I'd like to access share-config-custom.xml data from a Java bean in the Share webapp.
What is the equivalent to the following javascript syntax (which access the config root object) but in a Java context:
config.scoped['RepositoryLibrary']['root-node']
Is the share-config-custom translated to a bean itself? Or is there an API to read it from Java?
First, there is no "reasonable" way to use this API "looking" at one XML config file. In gen eral, the ConfigService creates a configuration merging from various sources. But looking directly at the XML should not be needed anyways.
That being said, the Javascript object config actually is a org.springframework.extensions.webscripts.ScriptConfigModel.
To get something equivalent in Java get yourself a reference to the ConfigService. To obtain the reference, let spring inject it in your custom bean:
<property name="configService" ref="web.config" />
Calling configService.getGlobalConfig() should get you the equivalent of config.scoped.
I know this is already answered, but Andreas' answer only got me halfway there. The configuration class is actually the XMLConfigService now.
Here's a code snippet that worked with Enterprise 4.1.* Alfresco:
Java class
import org.springframework.extensions.config.xml.XMLConfigService;
public class PDFValidate extends BaseJavaDelegate implements ExecutionListener
{
protected XMLConfigService configService;
public void setConfigService( XMLConfigService scriptConfigModel )
{
this.configService = scriptConfigModel;
}
Bean registration:
<bean id="AbstractWorkflowDelegate" parent="baseJavaDelegate" abstract="true" depends-on="activitiBeanRegistry" />
<bean id="PDFValidate" parent="AbstractWorkflowDelegate" class="com.epnet.alfresco.metadata.listener.PDFValidate">
<property name="repository" ref="repositoryHelper" />
<property name="configService" ref="web.config" />
</bean>
And from there, you can use the configService in your java code to get the config values.
The XMLConfigService is located in the spring-surf-core-configservice-1.2.0-SNAPSHOT.jar for my version of Alfresco.

Correct way to make datasources/resources a deploy-time setting

I have a web-app that requires two settings:
A JDBC datasource
A string token
I desperately want to be able to deploy one .war to various different containers (jetty,tomcat,gf3 minimum) and configure these settings at application level within the container.
My code does this:
InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")
Let's assume I've used the glassfish management interface to create two jdbc resources: jdbc/test-datasource and jdbc/live-datasource which connect to different copies of the same schema, on different servers, different credentials etc. Say I want to deploy this to glassfish with and point it at the test datasource, I might have this in my sun-web.xml:
...
<resource-ref>
<res-ref-name>jdbc/datasource</res-ref-name>
<jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...
but
sun-web.xml goes inside my war, right?
surely there must be a way to do this through the management interface
Am I even trying to do the right thing? Do other containers make this any easier? I'd be particularly interested in how jetty 7 handles this since I use it for development.
EDIT Tomcat has a reasonable way to do this:
Create $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml with:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
<!-- String resource -->
<Environment name="token" value="value of token" type="java.lang.String" override="false" />
<!-- Linking to a global resource -->
<ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />
<!-- Derby -->
<Resource name="jdbc/datasource2"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
url="jdbc:derby:test;create=true"
/>
<!-- H2 -->
<Resource name="jdbc/datasource3"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.h2.jdbcx.JdbcDataSource"
url="jdbc:h2:~/test"
username="sa"
password=""
/>
</Context>
Note that override="false" means the opposite. It means that this setting can't be overriden by web.xml.
I like this approach because the file is part of the container configuration not the war, but it's not part of the global configuration; it's webapp specific.
I guess I expect a bit more from glassfish since it is supposed to have a full web admin interface, but I would be happy enough with something equivalent to the above.
For GF v3, you may want to try leveraging the --deploymentplan option of the deploy subcommand of asadmin. It is discussed on the man page for the deploy subcommand.
We had just this issue when migrating from Tomcat to Glassfish 3. Here is what works for us.
In the Glassfish admin console, configure datasources (JDBC connection pools and resources) for DEV/TEST/PROD/etc.
Record your deployment time parameters (in our case database connect info) in properties file. For example:
# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod
Each web app can load the same database properties file.
Lookup the JDBC resource as follows.
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* #param resourceName the resource name of the connection pool (eg jdbc/dbdev)
* #return Connection a pooled connection from the data source
* associated with resourceName
* #throws NamingException will be thrown if resource name is not found
*/
public Connection getDatabaseConnection(String resourceName)
throws NamingException, SQLException {
Context initContext = new InitialContext();
DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
return pooledDataSource.getConnection();
}
Note that this is not the usual two step process involving a look up using the naming context "java:comp/env." I have no idea if this works in application containers other than GF3, but in GF3 there is no need to add resource descriptors to web.xml when using the above approach.
I'm not sure to really understand the question/problem.
As an Application Component Provider, you declare the resource(s) required by your application in a standard way (container agnostic) in the web.xml.
At deployment time, the Application Deployer and Administrator is supposed to follow the instructions provided by the Application Component Provider to resolve external dependencies (amongst other things) for example by creating a datasource at the application server level and mapping its real JNDI name to the resource name used by the application through the use of an application server specific deployment descriptor (e.g. the sun-web.xml for GlassFish). Obviously, this is a container specific step and thus not covered by the Java EE specification.
Now, if you want to change the database an application is using, you'll have to either:
change the mapping in the application server deployment descriptor - or -
modify the configuration of the existing datasource to make it points on another database.
Having an admin interface doesn't really change anything. If I missed something, don't hesitate to let me know. And just in case, maybe have a look at this previous answer.