I want to add --sslAllowInvalidHostnames criteria to the mongo connection in Mule but cannot see how I can add this and only see a tick box for SSL.
How can I add this?
Mongo configuration:
<mongo:config name="Mongo_DB__Configuration" username="${mongodb.username}" password="${mongodb.password}" database="${mongodb.database}" host="${mongodb.host}" doc:name="Mongo DB: Configuration"/>
Thanks
The class org.mule.modules.mongo.Config (in version 4.1.0, can't confirm for others) simply checks for a system property called sslInvalidHostNameAllowed and sets the criteria accordingly.
Try adding -DsslInvalidHostNameAllowed=true to your java command used to launch Mule, or alternatively by adding wrapper.java.additional.<n>=-DsslInvalidHostNameAllowed=true to your wrapper.conf file (in MULE_HOME/conf) for standalone Mule instances.
Related
Product name: Open Liberty
Product version: 20.0.0.7
Product edition: Open
is it possible to implement persistent ejbtimers on filesystem based default derby DB, using embedded.derby.DB
I installed derby in /tmp/derby, configured server.xml with the following, i don't see any file being created under /tmp when I start the OpenLiberty JVM, what am I missing in this approach?
<feature>ejbPersistentTimer-3.2</feature>
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDerbyDatasource" jndiName="jdbc/defaultDatasource" statementCacheSize="10" transactional="false">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
Check this book - http://www.redbooks.ibm.com/abstracts/sg248076.html?Open
In chapter "5.2.4 Developing applications using timers" you should find all stuff needed.
UPDATE based on comment:
If you look to the book and to the log it shows:
[INFO ] CNTR4000I: The ITSOTimerApp.war EJB module in the ITSOTimerApp
application is starting.
[INFO ] CNTR0167I: The server is binding the com.ibm.itso.timers.TimerBean
interface of the TimerBean enterprise bean in the ITSOTimerApp.war module of
the ITSOTimerApp application. The binding location is:
java:global/ITSOTimerApp/TimerBean!com.ibm.itso.timers.TimerBean
[INFO ] DSRA8203I: Database product name : Apache Derby
[INFO ] DSRA8204I: Database product version : 10.8.2.3 - (1212722)
[INFO ] DSRA8205I: JDBC driver name : Apache Derby Embedded JDBC Driver
[INFO ] DSRA8206I: JDBC driver version : 10.8.2.3 - (1212722)
[INFO ] CNTR0219I: The server created 1 persistent automatic timer or timers
and 0 non-persistent automatic timer or timers for the ITSOTimerApp.war module.
TimerBean initialized
It creates db 'as needed' so if you dont have any persistent timers beans, the service will not be started nor db created.
Liberty in general follows lazy model and doesn't start unneeded services.
So create sample application and then your DB will be created. There is no need to create database nor connection to database when no one is requesting for it.
In general, it is not advisable to use Derby Embedded database for persistent EJB timers due to limitations of Derby Embedded that all connections use the same class loader (implying the same JVM as well). This means you cannot leverage the failover capability (missedTaskThreshold setting) or even have multiple servers connected to the database at all. If you decide to use a Derby Embedded database, it means that you are limiting yourself to a single server. You can decide for yourself if that is acceptable based on what your needs are.
In the case of the example configuration you gave, it doesn't work because the EJB persistent timers feature in Liberty has no way of knowing that you dataSource, "DefaultDerbyDatasource" with jndiName "jdbc/defaultDatasource" is the data source that it ought to use. Also, it is incorrect to specify transactional="false" on the data source that you want EJB persistent timers to use because EJB persistent timers are transactional in nature.
I assume that what you are intending to do is configure the Java EE default data source and expecting EJB persistent timers to use it. That approach will work, except that you'll need to configure the Java EE default data source, you need to specify the id as "DefaultDataSource".
Here is an example that switches your configured data source to the Java EE default data source and removes the transactional="false" config,
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDataSource" jndiName="jdbc/defaultDatasource" statementCacheSize="10">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
By default, the EJB persistent timers feature should create database tables once the application runs and the EJB module is used.
However, you may be able to verify the configuration prior to that point by running the ddlgen utility (after correcting the configuration as above)
https://www.ibm.com/docs/en/was-liberty/base?topic=line-running-ddlgen-utility
which gives you the opportunity to see the DDL that it will use and optionally to run it manually (which is useful if you turned off automatic table creation via
<databaseStore id="defaultDatabaseStore" createTables="false"/> )
My application is based on Spring Boot 2.2.2.RELEASE and PostgreSQL. I am relying on Spring's AutoConfiguration as far as persistence is concerned. My application.properties file contains the following:
# Persistence
dbVendor=postgresql
# Basic connection options
spring.dataSource.driver-class-name=org.postgresql.Driver
spring.dataSource.url=jdbc:postgresql://is-0001/<database>
spring.dataSource.username=<username>
spring.dataSource.password=<password>
# Hibernate options
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.properties.hibernate.format_sql=false
spring.jpa.properties.hibernate.hbm2ddl.auto=create
spring.jpa.properties.hibernate.show_sql=false
spring.jpa.properties.hibernate.implicit_naming_strategy=<package>.ImplicitNamingStrategyImpl
spring.jpa.properties.hibernate.physical_naming_strategy=<package>.PhysicalNamingStrategyImpl
# Options to create sql scripts
spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create
spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=/development/projects/<project>/backend/sql/setup/createDb.sql
#spring.jpa.properties.javax.persistence.schema-generation.scripts.drop-target=/development/projects/<project>/backend/sql/setup/dropDb.sql
For some reason the setting for spring.jpa.properties.hibernate.hbm2ddl.auto=create is ignored by Spring - independent of its value - whereas the spring.jpa.properties.javax... properties are applied correctly which is easy to verify by looking at the generated SQL file (createDb.sql and dropDb.sql).
Does anybody have any idea what the reason for this behaviour could be? I would really be thankful as I have been trying to find the root cause for this issue for more than a day now?
Just as a side node: Spring Boot 2.0.5.RELEASE behaves the same.
You can have a look here:
https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto-initialize-a-database-using-hibernate
You need to set the property: spring.jpa.hibernate.ddl-auto=create
I need to add the below values to my existing data source through CLI commands in jboss EAP server
<connection-property name="auto Commit">false</connection-property>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
I have tried to use below command but its says duplicate resource
TRANSACTION_READ_COMMITTED is the attribute value for transaction isolation.
transaction-isolation : This element specifies the java.sql.Connection transaction isolation level to use. The constants defined in the Connection interface are the possible element content values and include:
TRANSACTION_READ_UNCOMMITTED
TRANSACTION_READ_COMMITTED
TRANSACTION_REPEATABLE_READ
TRANSACTION_SERIALIZABLE
TRANSACTION_NONE
You can use the following command to add any of the above strategies:
/profile=full/subsystem=datasources/data-source=ExampleDS:add(transaction-isolation=<Strategy>)
I would like to enable trace for DB2 which I'm accessing via datasource in WebSphere Application Server version 8.
In the server's bootstrap.properties file after the variable com.ibm.ws.logging.trace.specification= add the following code:
for version 6 or later:
*=info:WAS.j2c=all:RRA=all:WAS.database=all:Transaction=all
for version 5:
RRA=all=enabled:WAS.database=all=enabled:J2C=all=enabled
More info can be found on IBM website: https://www-304.ibm.com/support/docview.wss?rs=71&uid=swg21196160#wasconnection
In you datasource you need to specify the traceLevel property as well.
Example:
<dataSource id="db2" jndiName="jdbc/db2" jdbcDriverRef="DB2Driver" >
<properties.db2.jcc databaseName="myDB" traceLevel="-1"/>
</dataSource>
Actually it depends on the WebSphere version and the way DB2 is used. I'll try to summarize your options, for more details look at the links at the bottom.
WebSphere Application Server (Full Profile)
You have the following options:
You can enable general database related tracing via WebSphere tracing infrastructure.
In the WebSphere web admin console go to Troubleshooting > Logging and tracing > serverName > Change log detail levels and either on the Runtime tab (effective immediately) or on Configuration tab (effective after restart) set the trace to *=info:WAS.database=all or more detailed *=info:WAS.j2c=all:RRA=all:WAS.database=all:Transaction=all. This trace string is general, for JDBC connection, not only for DB2.
You can enable DB2 datasource trace related options.
In the WebSphere web admin console go to Resources > JDBC > Data sources > datasourceName > Custom properties. Im the custom properties set trace related properties, the most important ones are:
traceLevel - specifies the level of trace, determined by a bitwise combination of constants:
TRACE_NONE=0,
TRACE_CONNECTION_CALLS=1,
TRACE_STATEMENT_CALLS=2,
TRACE_RESULT_SET_CALLS=4,
TRACE_DRIVER_CONFIGURATION=16,
TRACE_CONNECTS=32,
TRACE_DRDA_FLOWS=64,
TRACE_RESULT_SET_META_DATA=128,
TRACE_PARAMETER_META_DATA=256,
TRACE_DIAGNOSTICS=512,
TRACE_SQLJ=1024,
TRACE_META_CALLS=8192,
TRACE_DATASOURCE_CALLS=16384,
TRACE_LARGE_OBJECT_CALLS=32768,
TRACE_SYSTEM_MONITOR=131072,
TRACE_TRACEPOINTS=262144,
TRACE_ALL=-1.
traceFile - specifies file to store the trace output
WebSphere Liberty Profile
In the folder LIBERTY_HOME/usr/servers/server_name create bootstrap.properties with the following variable for DB2 (for other databases check link at the bottom):
com.ibm.ws.logging.trace.specification=*=audit=enabled:com.ibm.ws.db2.logwriter=all=enabled
Specifying trace via system property
When you use unmanaged connections got from DriverManager, you cannot set driver trace properties via data source. In that case you can create property file with the following contents:
db2.jcc.traceDirectory=/tmp/jcctrace
db2.jcc.traceFile=trace
db2.jcc.traceFileAppend=false
db2.jcc.traceLevel=-1
and specify path to it as JVM system property:
-Ddb2.jcc.propertiesFile=pathToFile/fileName.properties
Useful links:
Tracing with the IBM Data Server driver for JDBC
JDBC trace configuration (Full profile
Enabling JDBC Tracing for the Liberty profile
for version 6 or later:
*=info:WAS.j2c=all:RRA=all:WAS.database=all:Transaction=all
And for version 5:
RRA=all=enabled:WAS.database=all=enabled:J2C=all=enabled
I am using Spring-boot 0.5.0.M6 with Spring-Batch. Configuration has by using #EnableBatchProcessing with datasource etc configured in application.properties.
During first run of the application, everything works fine but after I stop the application and restart application, following error is seen
org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [INSERT into BATCH_JOB_INSTANCE(JOB_INSTANCE_ID, JOB_NAME, JOB_KEY, VERSION) values (?, ?, ?, ?)]; Duplicate entry '1' for key 'PRIMARY'; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1' for key 'PRIMARY'
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:239)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:659)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:908)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:969)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:974)
When digging down, i had observed following lines in logs
2013-12-06 12:12:37 INFO ResourceDatabasePopulator:162 - Executing SQL script from class path resource [org/springframework/batch/core/schema-mysql.sql]
2013-12-06 12:12:37 INFO ResourceDatabasePopulator:217 - Done executing SQL script from class path resource [org/springframework/batch/core/schema-mysql.sql] in 13 ms.
Root problem over here was schema-drop-mysql.sql was not triggered by schema-mysql.sql was triggered, thereby creating two entries in BATCH_JOB_SEQ.
For resolution of the same, I have added
#EnableAutoConfiguration(exclude={BatchAutoConfiguration.class})
However due to this I need to execute schema-mysql.sql explicitly, which as of now is ok, but would be problem when spring-batch version would be updated with updates in schema
Hence have couple of questions:
1. How to autoconfigure batch for even executing schema-drop-mysql.sql before schema-mysql.sql?
2. is there way to configure this BatchDatabaseInitializer to run kind of "update" mode?
Regards
With the current version of Spring Batch autoconfiguration that isn't possible with the upcoming version it is possible to disable the automatic creation of the database tables by specifying the spring.batch.initializer.enabled property and setting it to false.
IMHO you shouldn't use the automatic creation/update features to create schema's either do it yourself or use tools like LiquiBase or FlyWay to do it more controlled.
Also see https://stackoverflow.com/questions/8418814/db-migration-tool-liquibase-or-flyway
You can always execute the schema-drop-mysql.sql yourself, as a work around you could add a #PreDestroy method to your #Configuration class which executes this script. (Maybe you could even add this to an #Configuration class which is enabled only in dev mode/profile).