Develop Reference

How to set Jetty Request Log to default Timezone using XML

I am not able to make Jetty Request-log log requests with the local time-zone time using the following code,
<Set name="LogTimeZone" type="java.lang.String">
<Get class="java.util.TimeZone" name="default">
<Get name="ID"/>
</Get>
</Set>
it defaults to GMT. The setLogTimeZone() (http://download.eclipse.org/jetty/9.3.9.v20160517/apidocs/org/eclipse/jetty/server/AbstractNCSARequestLog.html#setLogTimeZone-java.lang.String-) accepts a string argument and therefore should ideally work. But, it doesn't! Although, when providing the required String directly it works just fine,
<Set name="LogTimeZone">Europe/London</Set>
the jetty log(std error) seems to be working fine. Is this a known bug?
Jetty Version used : 9.1.1

Take the result of getID() out of the TimeZone.getDefault() into an xml id attribute, then reference it later in the <Set> call using a <Ref> element.
Example of how this works in Jetty XML:
foo.xml
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure id="foo" class="java.lang.Object">
<Get class="java.util.TimeZone" name="default">
<Get id="defaultTimeZone" name="ID"/>
</Get>
<Get id="sysout" class="java.lang.System" name="out">
<Call name="println">
<Arg>
<Ref refid="defaultTimeZone"/>
</Arg>
</Call>
</Get>
</Configure>
Testing it on the command line ...
$ cd /path/to/jetty-dist-9.3.9.v20160517/
$ java -cp lib/jetty-util-9.3.9.v20160517.jar:lib/jetty-xml-9.3.9.v20160517.jar \
org.eclipse.jetty.xml.XmlConfiguration foo.xml
2016-07-13 17:16:25.447:INFO::main: Logging initialized #121ms
America/Phoenix

How do I add JDBC drivers and configure JDBC Resources in Payara Micro?

What are my options to set up JDBC drivers and resources when using Java EE Payara Micro?

This method combines answers from Mike and Adam Bien via tainos. It involves making a new domain.xml, which is a Payara config file. No application modification is needed if it worked with full Payara. The example below is for PostgreSQL JDBC.
Open payara-micro.jar with an archive manager and extract the file /microdomain.xml.
Open microdomain.xml in a text editor.
If your application was already deployed to a full Payara, you can copy-paste the changes below from the full Payara's domain.xml.
Add right above the line containing </resources>, using your dbname, dbuser, dbpassword, hostname:port and poolname:
<jdbc-connection-pool connection-validation-method="auto-commit" driver-classname="org.postgresql.Driver" res-type="java.sql.Driver" name="poolname" is-connection-validation-required="true" connection-creation-retry-attempts="3" validate-atmost-once-period-in-seconds="60">
<property name="URL" value="jdbc:postgresql://localhost:5432/dbname"></property>
<property name="user" value="dbuser"></property>
<property name="password" value="dbpassword"></property>
</jdbc-connection-pool>
<jdbc-resource pool-name="poolname" jndi-name="jdbc/poolname"></jdbc-resource>
Add right above the line containing </server>:
<resource-ref ref="jdbc/poolname"></resource-ref>
Save and close the text editor.
Start Payara micro from command line, using your paths and filenames. Linux syntax:
java -cp "/opt/jdbc/postgresql.jar:/opt/payara/micro.jar" fish.payara.micro.PayaraMicro --deploy webapp.war --domainConfig microdomain.xml

Add the datasource definition to your web.xml and then add the jar file for the JDBC jar into your WEB-INF/lib. Then deploy the war file as usual to Payara Micro.
<data-source>
<name>java:global/ExampleDataSource</name>
<class-name>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</class-name>
<server-name>localhost</server-name>
<port-number>3306</port-number>
<database-name>mysql</database-name>
<user>root</user>
<password>root</password>
<!-- Example of how to use a Payara specific custom connection pool setting -->
<property>
<name>fish.payara.sql-trace-listeners</name>
<value>com.sun.gjc.util.SQLTraceLogger</value>
</property>
</data-source>
There is a complete example of how to do this on the Payara Examples GitHub repository. See Datasource example on Payara GitHub

You can configure JDBC in a normal domain.xml and supply that to Payara. If you're unsure, you can always take an existing domain.xml and use the JDBC configuration from that.
Payara Micro has a few command line options, one of which allows you to specify an alternative domain.xml file:
java -jar payara-micro.jar --deploy myApp.war --domainConfig mydomain.xml
If you're bootstrapping Payara Micro programmatically, you would use:
setAlternateDomainXML(File alternateDomainXML)

As the accepted answer didn't work for me a figured a different and slightly easier way. You still rely on the custom domain.xml, but the startup command can be simplified:
java -jar /opt/payara/payara-micro.jar --deploy webapp.war --domainConfig domain.xml --addJars /opt/mysql-connector-java-5.1.40-bin.jar
This call doesn't require you to know the Main class.

Adam Bien answered this question in his 19th Airhacks video.
My take, When used with custom resources is best used as an embedded server, in the main we configure the JDBC resources and with maven dependencies we include the needed drivers inside the jar or war files.

One of options is glassfish-resources.xml
<!-- db1 -->
<jdbc-connection-pool
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" name="db1"
res-type="javax.sql.DataSource"
steady-pool-size="1"
is-connection-validation-required="true"
connection-validation-method="meta-data"
max-pool-size="10">
<property name="password" value="icoder_pwd"/>
<property name="user" value="icoder_user"/>
<property name="databaseName" value="icoder_db"/>
<property name="serverName" value="localhost"/>
<property name="portNumber" value="3310"/>
<property name="zeroDateTimeBehavior" value="convertToNull"/>
</jdbc-connection-pool>
<jdbc-resource pool-name="db1" jndi-name="jdbc/db1"/>
<!-- db2 -->
<jdbc-connection-pool
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" name="db2"
res-type="javax.sql.DataSource"
steady-pool-size="1"
is-connection-validation-required="true"
connection-validation-method="meta-data"
max-pool-size="10">
<property name="password" value="icoder_pwd"/>
<property name="user" value="icoder_user"/>
<property name="databaseName" value="icoder_db"/>
<property name="serverName" value="localhost"/>
<property name="portNumber" value="3311"/>
<property name="zeroDateTimeBehavior" value="convertToNull"/>
</jdbc-connection-pool>
<jdbc-resource pool-name="db2" jndi-name="jdbc/db2"/>
</resources>
Complete example with entity manager implementation you can find:
https://github.com/igorzg/payara-micro-jpa-multi-tenancy

How to set VM parameters from Spring with value from .properties? [duplicate]

One of our team has implemented loading properties this way (see pseudo code below) and advises this approach is right as the client application using this is free to keep the properties in any file. Contrary to the widely used propertyplaceholderconfigurer.
application-context.xml
<bean class="com.mypackage.Myclass">
<property name="xml" value="classpath:"{com.myapp.myproperty1}"> </property>
</bean>
config.properties
com.myapp.myproperty1=data.xml
edit: I should have added it is data.properties and not data.xml. We want to load a property file (this property file is given in the config.properties as a "property".
com.myapp.myproperty1=data.properties
java class
import org.springframework.core.io.Resource;
public class Myclass {
private Resource xmlField;
// setter & getter methods..
}
Is it right to use spring core.io.Resource?
Another reason is the client application wants to load a environment specific configuration. I suggested use the propertyconfigurer and use maven profiles to generate the environment specific build
Can you please advise which one suits which case? and if it differs in different scenarios, please help me point out them?
thanks

You can put the properties in any file and still use PropertyPlaceholderConfigurer. Here's an example that satisfies both your coworker's concerns and your desire for environment specific stuff:
<bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<!-- default settings -->
<value>classpath:MyCompany.properties</value>
<!-- environment-specific settings -->
<value>classpath:MyCompany.${mycompany.env:dev}.properties</value>
<!-- keep your coworker happy -->
<value>classpath:${mycoworker}</value>
<!-- allows emergency reconfiguration via the local file system -->
<value>file:///${user.home}/MyCompany.properties</value>
</list>
</property>
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
<property name="ignoreResourceNotFound" value="true" />
<!-- should be validated separately, in case users of the library load additional properties -->
<property name="ignoreUnresolvablePlaceholders" value="false"/>
</bean>
If you pass in no -D arguments, then you'll pick up the following properties files, where properties in the later files overwrite previously determined values.
MyCompany.properties off the classpath
MyCompany.dev.properties off the classpath
$HOME/MyCompany.properties if it exists
To swap in a production config for #2, just pass -Dmycompany.env=prod to java. Similarly your coworker can pass -Dmycoworker=/some/path/config.properties if he/she wants.

I'm not sure why a PropertyPlaceholderConfigurator wouldn't have been the correct choice.
I've almost always handled environment-specific configs via a customized PPC that can either (a) get a -D parameter on startup, and/or (b) use the machine name, to decide which property file to load.
For me, this is more convenient than bundling the information in via Maven, since I can more easily test arbitrary configurations from whatever machine I'm on (using a -D property).

+1 for Dave's suggestion. You should be using PropertyPlaceholderConfigurer for loading\reading properties. Here is the example i just pulled out from my previous project if you wonder how to use this. This example is for loading multiple properties files but the concept is same. Good luck.
<bean id="projectProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="locations">
<list>
<value>classpath:config.properties</value>
</list>
</property>
</bean>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" ref="projectProperties" />
</bean>
<bean id="uniqueAssetIdRetriever" class="com.mypackage.Myclass">
<property name="xml" value="${com.myapp.myproperty1}" />
</bean>

loading properties file in spring

One of our team has implemented loading properties this way (see pseudo code below) and advises this approach is right as the client application using this is free to keep the properties in any file. Contrary to the widely used propertyplaceholderconfigurer.
application-context.xml
<bean class="com.mypackage.Myclass">
<property name="xml" value="classpath:"{com.myapp.myproperty1}"> </property>
</bean>
config.properties
com.myapp.myproperty1=data.xml
edit: I should have added it is data.properties and not data.xml. We want to load a property file (this property file is given in the config.properties as a "property".
com.myapp.myproperty1=data.properties
java class
import org.springframework.core.io.Resource;
public class Myclass {
private Resource xmlField;
// setter & getter methods..
}
Is it right to use spring core.io.Resource?
Another reason is the client application wants to load a environment specific configuration. I suggested use the propertyconfigurer and use maven profiles to generate the environment specific build
Can you please advise which one suits which case? and if it differs in different scenarios, please help me point out them?
thanks

You can put the properties in any file and still use PropertyPlaceholderConfigurer. Here's an example that satisfies both your coworker's concerns and your desire for environment specific stuff:
<bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<!-- default settings -->
<value>classpath:MyCompany.properties</value>
<!-- environment-specific settings -->
<value>classpath:MyCompany.${mycompany.env:dev}.properties</value>
<!-- keep your coworker happy -->
<value>classpath:${mycoworker}</value>
<!-- allows emergency reconfiguration via the local file system -->
<value>file:///${user.home}/MyCompany.properties</value>
</list>
</property>
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
<property name="ignoreResourceNotFound" value="true" />
<!-- should be validated separately, in case users of the library load additional properties -->
<property name="ignoreUnresolvablePlaceholders" value="false"/>
</bean>
If you pass in no -D arguments, then you'll pick up the following properties files, where properties in the later files overwrite previously determined values.
MyCompany.properties off the classpath
MyCompany.dev.properties off the classpath
$HOME/MyCompany.properties if it exists
To swap in a production config for #2, just pass -Dmycompany.env=prod to java. Similarly your coworker can pass -Dmycoworker=/some/path/config.properties if he/she wants.

I'm not sure why a PropertyPlaceholderConfigurator wouldn't have been the correct choice.
I've almost always handled environment-specific configs via a customized PPC that can either (a) get a -D parameter on startup, and/or (b) use the machine name, to decide which property file to load.
For me, this is more convenient than bundling the information in via Maven, since I can more easily test arbitrary configurations from whatever machine I'm on (using a -D property).

+1 for Dave's suggestion. You should be using PropertyPlaceholderConfigurer for loading\reading properties. Here is the example i just pulled out from my previous project if you wonder how to use this. This example is for loading multiple properties files but the concept is same. Good luck.
<bean id="projectProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="locations">
<list>
<value>classpath:config.properties</value>
</list>
</property>
</bean>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" ref="projectProperties" />
</bean>
<bean id="uniqueAssetIdRetriever" class="com.mypackage.Myclass">
<property name="xml" value="${com.myapp.myproperty1}" />
</bean>

Memcached Provider for NHibernate not working

I've been at this for days. I have configure my web/app config to use the second level cache with a Memcached server and the provider from NHContrib. I don't get any exceptions yet in testing I see that it does not use the cache for my queries that I have set cacheable = true.
If I switch the provider to the NHibernate.Cache.HashtableCacheProvider and test it works as expected.
here are the relevant config sections I am using
<configuration>
<configSections>
<section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler,NHibernate" />
<section name="memcache" type="NHibernate.Caches.MemCache.MemCacheSectionHandler,NHibernate.Caches.MemCache" />
</configSections>
<memcache>
<memcached host="192.168.215.60" port="11211" />
</memcache>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">
NHibernate.Connection.DriverConnectionProvider
</property>
<property name="dialect">
MT.Core.Persistence.Dialect, MT.Core
</property>
<property name="connection.driver_class">
NHibernate.Driver.SqlClientDriver
</property>
<property name="connection.connection_string">
Server=192.168.1.1;Initial Catalog=Test;User ID=TestUser;Password=fakepassword;
</property>
<property name="show_sql">true</property>
<property name="proxyfactory.factory_class">NHibernate.ByteCode.LinFu.ProxyFactoryFactory,NHibernate.ByteCode.LinFu</property>
<property name="cache.provider_class">NHibernate.Caches.MemCache.MemCacheProvider,NHibernate.Caches.MemCache</property>
<!--<property name="cache.provider_class">NHibernate.Cache.HashtableCacheProvider</property>-->
<property name="cache.use_second_level_cache">true</property>
<property name="cache.use_query_cache">true</property>
</session-factory>
</hibernate-configuration>
</configuration>

The problem ended up being due to a connectivity problem. I used log4net to log any errors to the console and to the application log. It was then I finally saw the errors regarding connecting to the memcached server. Once the code was promoted to a server in the same location the errors were gone. I should have learned to use log4net ages ago.

For memcache the property is 'default_expiration' not 'expiration'. I am not sure about SysCache. But I have used this property for memcache and it works for me.
Initailly I also faced the same error that CountCet mentioned. The attribute 'expiration' is not recognized by the MemCache provider. Later I checked the code and found that it use the property 'default_expiration' and its default value is 300 sec.

I think that the expiration property should set for the memcache provider on the session factory level and not on the provider configuration like others (SysCache)
<property name="expiration">300</property>