Category Archives: Java

Post navigation

Installing New Relic in Heroku using a Play 2.4.x (Java) Application

Hi guys, just wanted to write a small post about installing New Relic on a Play Framework App (version 2.4.x) in Heroku. I struggled a bit with some of the instructions I found through the internet (including Heroku’s and New Relic’s).

What I did to make it work:

Install the New Relic Addon through Heroku’s interface

New Relic Installation Screen

This will install the add-on and configure somethings for you (like environment variables). If you do `heroku config` you’l see the following variables:

NEW_RELIC_APP_NAME: APP_NAME

NEW_RELIC_LICENSE_KEY: YOUR_LICENSE_KEY

NEW_RELIC_LOG: stdout

In order for the addon to work you need to enable it’s Java agent, by adding the dependencies to your build.sbt file:

libraryDependencies ++= Seq(

//Your other dependencies

“com.newrelic.agent.java” % “newrelic-agent” % “3.25.0”,

“com.newrelic.agent.java” % “newrelic–api” % “3.25.0”

)

Notice that at the time of writing ( 20/02/2016 – February 20th ) the latest version of the agent is 3.25. You should always check the latest version at maven central and use that.

Now you need the “newrelic.yml” configuration file. You can download when you configure your account in new relic. Once you go to your New Relic account page you’ll see the following screen : Choose “Java”.

After you choose Java, the next screen will show this:

Click the “Download the Java agent” button. This will download a zip file with the java agent and the newrelic.yml file. My suggestion is copy the newrelic.yml file to the Play Framework’s conf directory ( conf/newrelic.yml ).

Now, I’m not sure if target/universal/stage/lib/com.newrelic.agent.java.newrelic-agent-3.25.0.jar will be the same throughout time, but if you get errors like “cannot open zip file” or “cannot read manifest” I suggest you do the following in your terminal:

heroku run bash

Once inside the web dyno, look around and find where the new-relic jar file is and point the environment variable to it.

Hopefully, that’s all you need. I did encounter other issues, but mostly related by not having the newrelic.yml file in the right place (or not having the configuration pointing to the right place).

Hi everyone,
One of the things that I struggled in the beginning (a long time ago in a galaxy far away, cof cof) with SQL queries (or BOQL queries if you’re using the XEO framework) was how to make queries using dates in the where clause, something like this:

select * from table where column_date > SOMETHING

Not knowing how to do date comparisons I usually did stuff like this ( evil code ahead, beware ) :

Notice how you pass a java.sql.Date instance (created using the information from the java.util.Date instance) to the parameter. This has the added benefit that no data conversions are done (meaning extra performance). And if you have an index on a date column that index will be used ( I also learned that when you apply a function to an indexed column, that index won’t be used properly as the function has to be applied to every row in the table – check this )

XALPI

Hi everyone,

I’ve been working on an application, using the XEO Framework, for a while now and there were two situations that I wanted to improve. First it was my inability to write unit tests for my application’s logic (using JUnit, for example) and the other was I had trouble finding which attributes were being used where and overall can’t rely on the compiler to help me out. XEO’s API is very flexible and all but I thought that in order to address these two issues I would have to come up with something on my own.

Notice: This work is not associated with the XEO Framework, although I do work at ITDS (which creates the framework), XALPI does not reflect anything but my own opinion and effort on the subject.

XALPI stands for XEO ALternative API and is a personal attempt to create a more convenient (for me) API and allow the creation of unit tests. It’s an open source project that you can find on Bitbucket, licensed under the BSD license (rev3), meaning you can do just about anything with it.

Provides an interface representing each XEOModel with getters and setters for each attribute (see example bellow)

Set iFile values using java.io.File instances

Get/Set Lov Values using a class instance (good for searching references) instead of the value itself

The description of each attribute/model is placed as javadoc in the generated interfaces / classes

Provides an easy API to create lists of objects and iterate a list

Provides a new Logger abstraction to allow creating application logic to be tested without needing the XEO Logger (which throws a bunch of errors to the error console when the server is not up and running)

Reduces the number of boRuntimeExceptions thrown by the API (only update/destroy throw exceptions)

Each of these situations is (I hope) well explained at the wiki. Although some information may still be missing ( it’s beta after all ) I will, to the best of my abilities, complete it as fast as I can.