how to implement EJBTimer (persistant) in Open Liberty - persistence

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"/> )

Related

Spring Boot 2.2.2 and "hibernate.hbm2ddl.auto=(create|create-drop|update|validate)" not working

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

How can I add to the mongodb connection string in Mule

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.

CXF DOSGI ZOOKEEPER

Good morning,
I'm looking for help please.I'm only a beginner.
I am using cxf-dosgi from (DOSGi Apache Karaf Feature distribution)
I want to make transparent use of services between two remote machines. So I have a karaf container on each of these two machines.
I tested this example : to start with two containers karaf hosted on the same machine then I changed the configuration to test with two containers hosted on two different remote machines. And it works great !
So I want to do the same thing to export to export my web services. I am using Spring DM. So I do this on the server side :
<osgi:service id="osgi-service" ref="myservice" interface="org.apache.camel.Endpoint"> <osgi:service-properties> <entry key="name" value="service"/> <entry key="service.exported.interfaces" value="*"/> </osgi:service-properties> </osgi:service>
I did the installations like in the tutorial with cxf dosgi version 1.6 But I get this error:
16:25:53,256 | ERROR | pool-21-thread-3 | w.service.RemoteServiceAdminCore 193 | 184 - cxf-dosgi-ri-dsw-cxf - 1.6.0 | failed to create server for interface org.apache.camel.Endpoint
java.lang.NullPointerException
at java.lang.reflect.Array.newArray(Native Method)[:1.7.0_79]
at java.lang.reflect.Array.newInstance(Array.java:70)[:1.7.0_79]
at org.apache.cxf.aegis.type.TypeUtil.getTypeRelatedClass(TypeUtil.java:259)
at org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:108)
at org.apache.cxf.aegis.type.AbstractTypeCreator.createType(AbstractTypeCreator.java:402)
at org.apache.cxf.aegis.type.basic.BeanTypeInfo.getType(BeanTypeInfo.java:192)
at org.apache.cxf.aegis.type.basic.BeanType.getDependencies(BeanType.java:547)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:394)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)
at org.apache.cxf.aegis.databinding.AegisDatabinding.addDependencies(AegisDatabinding.java:399)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:371)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:283)
at org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:242)
at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:490)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)
at org.apache.cxf.dosgi.dsw.handlers.AbstractPojoConfigurationTypeHandler.createServerFromFactory(AbstractPojoConfigurationTypeHandler.java:191)
at org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:119)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportInterfaces(RemoteServiceAdminCore.java:184)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:140)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:59)
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:57)
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_79]
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:57)[184:cxf-dosgi-ri-dsw-cxf:1.6.0]
at org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:41)[184:cxf-dosgi-ri-dsw-cxf:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.exportServiceUsingRemoteServiceAdmin(TopologyManagerExport.java:185)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport.doExportService(TopologyManagerExport.java:168)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport$3.run(TopologyManagerExport.java:143)[183:cxf-dosgi-ri-topology-manager:1.6.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
Have you an idea of what is wrong?
Ouch .. what are you doing with 1.4-SNAPSHOT. First it is not a release and second it is quite old.
Another thing that looks suspicious is the service.exported.interfaces=myInterface. It should be a fully qualified java interface name. For the start try service.exported.interfaces=* for it.
You should start with my CXF DOSGi tutorial. The code there should work out of the box. You can then add your changes in the config. So it is easier than to start completely new.

deployment to IBM worklight 6.2 server

I installed an IBM WorkLight Server 6.2 20150129 on a WAS 8.5.5.2 ND on a Windows 2008 DataCenter VM with 4GB ram
min heap:512mb, max heap: 1536mb
I am deploying a *-all.wlapp of around 140mb and following error occurrs.
deploying an app of < 20mb is fine.
server1_exception.log
com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS
server1_(very long meaningless text).txt
[2/11/15 7:10:54:960 PST] FFDC Exception:javax.naming.ConfigurationException SourceId:com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS ProbeId:537 Reporter:java.lang.Class#e712aad3
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:184)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:164)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:65)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextPropertyAsLong(ContextPropertyUtil.java:300)
at com.ibm.worklight.admin.actions.BaseCommitable.getLockTimeOutInMillis(BaseCommitable.java:415)
at com.ibm.worklight.admin.actions.CleanUnfinishedTransaction.cleanUnfinishedTransaction(CleanUnfinishedTransaction.java:94)
at com.ibm.worklight.admin.actions.BaseTransaction.internalRun(BaseTransaction.java:284)
at com.ibm.worklight.admin.actions.BaseTransaction$1.run(BaseTransaction.java:210)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:796)
Caused by: javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1228)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
... 15 more
In Microsoft IIS there is an attribute that controls this filesize limit. This attribute is called maxAllowedContentLength and it can be found in the <requestLimits> element of the IIS configuration file. Its default value is 30 000 000 bytes.
You should increase it to a filesize tha will contain the wlapp's filesize.
Uninstalled WAS 8.5.5.2 patch in IBM installation Manager to roll back to WAS 8.5.5.0 and restarted everything, then i can deploy adapters.

How can I enable and collect trace for DB2 through WebSphere?

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