Using Pretty Print to print JSON structure
I needed to build a “test-api” page for my team so that they could test there API without writing too much code. Nothing special, just a page with a textarea where someone puts in a request string, and another field, where we show the response sent by the server. The server response are in JSON format. For simple responses, everything was fine. But in cases, where the response was huge or had a complex structure, we wanted someway to show the structure in a more readable format. Something that helped developers see the hierarchy.
This is where pretty print (by James Padolsey) helped us.
Its dead simple to use:
[code language=”javascript”]
//include prettyprint .js:
//data contains the JSON response sent by the server.
$(“#detail”).append((prettyPrint($.parseJSON( data ), {
maxArray: 100,
expanded: false,
maxDepth: 100
})));
[/code]
E.g. Output:
Skipping Fields when deserializing JSON using gson
Recently, we’re working on legacy code, where a json strings were to be serialized into java classes. These java classes had a deep hierarchy and some classes had field names same as defined in their parent classes. And these fields were not used at all.
GSON, makes it very simple to handle such scenarios. Use GsonBuilder and add an exclusionStrategy.
E.g.:
[code lang=”java”]
new GsonBuilder().setExclusionStrategies(new ExclusionStrategy() {
@Override
public boolean shouldSkipField(FieldAttributes field) {
if (field.getName().equals(“FIELD_NAME_TO_BE_SKIPED”)) {
return true;
}
return false;
}
@Override
public boolean shouldSkipClass(Class clazz) {
return clazz.equals(CLASS_TO_BE_SKIPPED.class);
}
}).create().fromJson(json, respClass);
[/code]
HyperPublic Java API
Hyperpublic is an open location platform. Developers can use the Hyperpublic API to query local places, deals, and events. Developers can also push your application’s local data into Hyperpublic to get distribution through the entire 3rd party developer ecosystem.
A new Java wrapper around the HyperPublic API has been made available here.
Usage is very simple.
Here’s code to fetch places around a given location:
[sourcecode language=”java”]
HPClient client = HPClient.create(YOUR_CLIENT_ID,YOUR_SECRET);
List
[/sourcecode]
Please try out the API and feel free to send feedback.
Symfony Error: PDO Connection Error: SQLSTATE[HY000] [2002]
PDO Connection Error: SQLSTATE[HY000] [2002] No such file or directory
Warning: PDO::__construct() [pdo.–construct]: [2002] No such file or directory (trying to connect via unix:///var/mysql/mysql.sock) in
This error occurs when the path to mysql.sock in the php.ini file (in the above case /var/mysql/mysql.sock) is incorrect (Thanks to this link). Please note that there may be multiple copies of php.ini on your system. The php.ini file that the webserver uses needs to be changed. To find which php.ini is your webserver using, use phpinfo(). In my case the location was /etc.
Once the correct php.ini is found, look for the property “pdo_mysql.default_socket” and point to the path where mysql.sock resides. To find where your mysql.sock resides, run this command (Thanks to this link):
[sourcecode language=”sql”]
mysqladmin variables
[/sourcecode]
OR
[sourcecode language=”sql”]mysqld –verbose –help | grep ^socket[/sourcecode]
On my system [Mac running MySql 5.1.50] the location was /tmp/mysql.sock.
Hibernate MappingException: persistent class not known
“Caused by: org.hibernate.MappingException: persistent class not known: …“
The root of this exception is, that the entity hibernate is trying to load, is either not configured at all or not configured correctly. Check the following, if you encounter this exception:
- The entity is mapped correctly in the hibernate.cfg.xml.
- If annotations are being used, the entity in question is annotated and annotated correctly as pointed out here.
If you see: “Caused by: org.hibernate.MappingException: Association references unmapped class XYZ…”, make sure, that the class XYZ is configured correctly and check the steps above.
MySQL Communications Link Failure
Recently we were baffled by the “Communications Link Failure” issue on our servers.
Our setup:
Jahia 6 on Tomcat (Apache DBCP, Spring, Hibernate, MySql).
Here’s what we observed:
1. The exception is generally caused by a connection that has become stale. The connections in the pool become stale after the wait_timeout period set in the my.cnf on the mysql server. The pool implementation should somehow validate connections before using them (which is what validationQuery is for). However, setting validationQuery has performance side effects.
2. Setting the autoReconnect (jdbc:mysql://DBHOST/schema?autoReconnect=true) to true on the driver should try to reconnect in case the connection has become stale each time a connection is made. However, this has no effect anymore and can be removed.
After trying a few other options, what helped us was setting the “wait_timeout” value in the my.cnf to a high value. (Some value greater than the max amount of inactivity in the system).
If the wait_timeout is set to a high value so that during the period of inactivity the connections do not become stale, this exception will not be raised.
Of course, the other option is to handle stale connections in your code and recover from such exceptions or use a connection pool implementation that does this for you.
How to get (just the) IP Address on a unix machine
[sourcecode language=”bash”]
ifconfig | grep “Bcast:” | cut -d':’ -f2 | cut -d’B’ -f1
[/sourcecode]
Hey, look at that..
Using Properties Files in Java Applications (And Autoload)
Properties files are one of the most frequently used mechanism for storing configuration information for applications. And so is the code to access these properties from the application. This article is intended to demonstrate (source code can be downloaded here) a simple way of configuring and using Properties files in Java applications.
Please note that, the mechanism is not limited to properties files. The approach supports XML configuration files as well.
The steps are defined below and as we move along, we’ll try and explain the rationale for each of the items:
1. Define System variable for properties file location. Define a system/environment variable that points to the folder, where the properties files will be placed. Finding the properties files through a system/environment variable is straight-forward and helps avoid the classpath issues often found using properties files in webapps. In cases where a system/environment variable cannot be defined, this variable can be passed to the application as an argument. For e.g., java –D APP_PROPS=d:/Properties App
Let’s say the environment variable is called APP_PROPS and it points to D:/Properties. For demonstration, let’s assume there’re two properties files:
a. app.properties
b. security.properties
2. The Properties Store. The properties store (class PropStore), will be used by the application code to fetch properties. For e.g., the following code reads the application title from the app.properties file.
[sourcecode language=”java”]
String title = PropStore.getAppProps(“title”);
[/sourcecode]
Let’s get into the code and see how the PropStore will be structured and how do we add new properties.
Structure. The properties store will have a static “Properties” field, for each “properties” file annotated with a custom annotation (PropertiesHolder, defined later). For e.g.,
[sourcecode language=”java”]
public class PropStore {
@PropertiesHolder(file="app.properties", autoLoad=true)
private static Properties appProps;
@PropertiesHolder(file="security.properties")
private static Properties securityProps;
public static Properties getAppProps() {
return appProps;
}
public static Properties getSecurityProps() {
return securityProps;
}
protected static void setAppProps(Properties appProps) {
PropStore.appProps = appProps;
}
protected static void setSecurityProps(Properties securityProps) {
PropStore.securityProps = securityProps;
}
}
[/sourcecode]
For now, assume, the properties appProps and securityProps are magically loaded. So, the following code sippet can be used in the application code to read securityProps:
[sourcecode language=”java”]
String appUser = PropStore.getSecurityProps().getProperty(“APP_USER”);
[/sourcecode]
To add another properties file, all that needs to be done is add a static field, annotate it with PropertiesHolder with the properties file name as the file attribute, and define a public getter.
3. PropertiesHolder. PropetiesHolder is a custom annotation, that we will use to annotate fields in the PropStore, and set the properties file that field will go against.
[sourcecode language=”java”]
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface PropertiesHolder {
String file();
boolean autoLoad() default false;
}
[/sourcecode]
4. Loading Properties. Properties file need to be loaded at application startup since the application code uses the properties files. We’ll load the properties using PropsLoader class as demonstrated below. PropsLoader can then be used by a startup class (a startup servlet in webapps, or a bootstrap class in a desktop application, for e.g.).
Here’s what the PropsLoader does to load the properties files:
i. Introspect the PropStore to get declared fields.
ii. Loop on the fields and check if the field is annotated with PropertiesHolder.
iii. If it is annotated with PropertiesHolder, create a “Properties” object and load the properties file (set with the file attribute of PropertiesHolder).
iv. Call the appropriate setter, on the PropStore with this “Properties” object.
v. Please note that if there’s a XML configuration file, another reading mechanism can be provided and a Properties object be built from that.
[sourcecode language=”java”]
public class PropsLoader {
private static final String VAR_NAME = “APP_PROPS”;
//TODO: Better Exception Handling
public static void load() throws Exception {
Field[] fields = PropStore.class.getDeclaredFields();
for(Field field:fields) {
if( field.isAnnotationPresent(PropertiesHolder.class) ) {
PropertiesHolder propsHolder = field.getAnnotation(PropertiesHolder.class);
loadPropsAndWatch( field.getName(), propsHolder );
}
}
}
//TODO: Better Exception Handling
private static void loadPropsAndWatch(String fieldName, PropertiesHolder propsHolder) throws Exception {
String propsFile = System.getProperty(VAR_NAME) + File.separator + propsHolder.file();
loadProperties(fieldName, propsFile);
if( propsHolder.autoLoad() ) {
PropsWatcherTask.watch( fieldName, propsFile, propsHolder );
}
}
//TODO: Better Exception Handling
protected static void loadProperties(String fieldName, String propsFile)
throws Exception {
String setterName = “set” + Character.toUpperCase(fieldName.charAt(0)) + fieldName.substring(1);
Method setter = PropStore.class.getDeclaredMethod(setterName, Properties.class);
Properties props = new Properties();
props.load( new FileInputStream(new File(propsFile) ) );
setter.invoke(null, props);
}
}
[/sourcecode]
5. Auto Load. Although, not an absolute essential, sometimes, the properties files need to be auto-loaded in case there’s a change while the application is running.
To auto load properties, the PropsWatcherTask:
a. Schedules itself to run every “x” minutes, and check the last modified time of the properties file to watch.
b. If the new modified timestamp is newer than the timestamp used to build the task, the properties file is reloaded and the local timestamp set accordingly.
[sourcecode language=”java”]
public class PropsWatcherTask extends TimerTask {
private String propsFile;
private long lastMod;
private String fieldName;
private final static Timer timer = new Timer();
private static final long INITIAL_DELAY = 1000 * 60 * 5;
private static final long INTERVAL = 1000 * 60 * 5;
private PropsWatcherTask(long lastMod, String fieldName, String propsFileName) {
this.propsFile = propsFileName;
this.lastMod = lastMod;
this.fieldName = fieldName;
}
@Override
public void run() {
//check last modified time.
long newModTime = new File(propsFile).lastModified();
if( newModTime > lastMod ) {
try {
PropsLoader.loadProperties(fieldName, propsFile);
} catch (Exception e) {
e.printStackTrace();
}
this.lastMod = newModTime;
}
}
protected static void watch(String fieldName, String propsFileName, PropertiesHolder propsHolder) {
File propsFile = new File(propsFileName);
long lastMod = propsFile.lastModified();
timer.scheduleAtFixedRate( new PropsWatcherTask( lastMod, fieldName, propsFileName ) , INITIAL_DELAY, INTERVAL );
}
}
[/sourcecode]
6. Test. The following simple JUnit can be used to test the PropsLoader for both auto load and otherwise.
[sourcecode language=”java”]
public class PropStoreTest {
@Before
public void load() {
try {
PropsLoader.load();
} catch (Exception e) {
e.printStackTrace();
}
}
@Test
public void testProperties() throws Exception{
Assert.assertEquals(“ABC Desktop”, PropStore.getAppProps().getProperty(“APP_TITLE”));
Assert.assertEquals(“ADMIN”, PropStore.getSecurityProps().getProperty(“APP_USER”));
}
@Test
public void testAutoLoad() throws Exception {
write(“APP_TITLE=New ABC Desktop”);
synchronized(this) {
this.wait(45 * 1000);
}
Assert.assertEquals(“New ABC Desktop”, PropStore.getAppProps().getProperty(“APP_TITLE”));
write(“APP_TITLE=ABC Desktop”);
}
private void write(String text) throws Exception {
PrintWriter pw = new PrintWriter( new FileWriter(System.getProperty(“APP_PROPS”) + File.separator + “app.properties”));
pw.print(text);
pw.close();
}
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(PropStoreTest.class);
}
}
[/sourcecode]
Note the PropsLoader.load() being called from the load method of PropStoreTest. The PropsLoader.load() call will generally be made from some startup class (like a startup servlet, etc). To run the test, make sure the APP_PROPS variable is passed as a JVM parameter, or is set in the system properties.
Click here to download the source code. Tester.zip contains the Tester folder, which can be directly imported into Eclipse. If you wish to run this with ant, use Tester/build/build.xml. (Please change the value for APP_PROPS on line 9 in build.xml).
(Please note, that most of the modern web based frameworks do have some sort of Properties/configuration framework built in. Also, there’s commons configuration project from Apache that provides a comprehensive support enabling Java applications to read configuration data from variety of sources. This article is intended for applications that do not have such frameworks/facilities available).
Properties files are one of the most frequently used mechanism for storing configuration information for applications. And so is the code to access these properties from the application. This article is intended to demonstrate a simple (Simple to use from the app and easy to maintain) way of configuring and using Properties files in Java applications.
Please note that, the mechanism is not limited to properties files. The approach supports XML configuration files as well.
The steps are defined below and as we move along, we’ll try and explain the rationale for each of the items:
1.Define System variable for properties file location. Define a system/environment variable that points to the folder, where the properties files will be placed. Finding the properties files through a system/environment variable is straight-forward and helps avoid the classpath issues often found using properties files in webapps. In cases where a system/environment variable cannot be defined, this variable can be passed to the application as an argument. For e.g., java –D APP_PROPS=d:/Properties App
Let’s say the environment variable is called APP_PROPS and it points to D:/Properties. For demonstration, let’s assume there’re two properties files:
a.app.properties
b.security.properties
2.The Properties Store. The properties store (class PropStore), will be used by the application code to fetch properties. For e.g., the following code reads the application title from the app.properties file.
String title = PropStore.getAppProps(“title”);
Let’s get into the code and see how the PropStore will be structured and how do we add new properties.
Structure. The properties store will have a static “Properties” field, for each “properties” file annotated with a custom annotation (PropertiesHolder, defined later). For e.g.,
For now, assume, the properties appProps and securityProps are magically loaded. So, the following code sippet can be used in the application code to read securityProps:
String appUser =
PropStore.getSecurityProps().getProperty(“APP_USER”);
To add another properties file, all that needs to be done is add a static field, annotate it with PropertiesHolder with the properties file name as the file attribute, and define a public getter.
3.PropertiesHolder. PropetiesHolder is a custom annotation, that we will use to annotate fields in the PropStore, and set the properties file that field will go against.
4.Loading Properties. Properties file need to be loaded at application startup since the application code uses the properties files. We’ll load the properties using PropsLoader class as demonstrated below. PropsLoader can then be used by a startup class (a startup servlet in webapps, or a bootstrap class in a desktop application, for e.g.).
Here’s what the PropsLoader does to load the properties files:
i.Introspect the PropStore to get declared fields.
ii.Loop on the fields and check if the field is annotated with PropertiesHolder.
iii.If it is annotated with PropertiesHolder, create a “Properties” object and load the properties file (set with the file attribute of PropertiesHolder).
iv.Call the appropriate setter, on the PropStore with this “Properties” object.
v.Please note that if there’s a XML configuration file, another reading mechanism can be provided and a Properties object be built from that.
Below is the code snapshot that loads the properties.
5.Auto Load. Although, not an absolute essential, sometimes, the properties files need to be auto-loaded in case there’s a change while the application is running.
To auto load properties, the PropsWatcherTask:
a.Schedules itself to run every “x” minutes, and check the last modified time of the properties file to watch.
b.If the new modified timestamp is newer than the timestamp used to build the task, the properties file is reloaded and the local timestamp set accordingly.
6.Testing. The following simple JUnit can be used to test the PropsLoader for both auto load and otherwise.
Note the PropsLoader.load() being called from the load method of PropStoreTest. The PropsLoader.load() call will generally be made from some startup class (like a startup servlet, etc). To run the test, make sure the APP_PROPS variable is passed as a JVM parameter, or is set in the system properties.
The code is attached with this article. Tester.zip contains the Tester folder, which can be directly imported into Eclipse. If you wish to run this with ant, use Tester/build/build.xml. (Please change the value for APP_PROPS on line 9 in build.xml).
