If you are looking for a good interactive Git Cheatsheet, Check out this one provided by NDP Software. It is an amazing reference if you use the git command line on a regular basis.

References

• Git Cheatsheet by NDP Software

Read More...

If you are developing in Java EE6 and are a little over-whelmed by all the annotations and what they do, I have found something that may help out. It is a quick reference card that lists all of the annotations from CDI, EJB3.1, JSF2, JPA2, and JAAS.

Download Java EE6 Reference Sheet

References:

• Original Source

Read More...

I just spent the last few hours working on my DiveLog project and ran into some issues implementing a custom Bean Validator. I was trying to inject a service bean into my validator, but kept getting a NullPointerException on the injected bean. After fiddling with it for half an hour or so, I started doing some research.

As it turns out, Hibernate Bean Validator's are not registered as a CDI managed beans by default, therefore ConstraintValidator implementations are not CDI managed Beans. This of course means that you can not inject any beans into them. Unfortunately there are currently no really great alternatives. You can try to look up the bean you want to inject via the JNDI tree and retrieve it that way, but that has its own little set of problems.

Allegedly Seam 3 Validation will solve this problem by bridging Hibernate Bean Validation to CDI and thus allowing you to inject beans, but after reading the documentation and following the instructions, I was ultimately unable to get it working. I eventually just ended up taking a different route for the validation that didn't involve a custom bean validator, but it is not nearly as clean of a solution.

There is Hope...

Version 1.1 of the Bean Validation specification includes plans to add this support natively, so that you do not need to do any hacks or use any 3rd party libraries. There is currently no release date for version 1.1 of the spec however.

References

• Bean Validation 1.1 Roadmap
• Bean Validation 1.1 Specification - Issue 238

Read More...

Below is a quick reference for several of the most commonly used Subversion commands. Since I have been using both Git and Subversion lately for different projects, I routinely get the commands for the two confused. To help out with that, I created this quick reference.

Commands

checkout / co

Checks out a working copy of the course code into the given directory
svn checkout REPO_URL FOLDER
svn co REPO_URL FOLDER

import

Imports the directory and all files/sub-directories into the subversion server at the specified URL. The URL can be several levels deep.
svn import -m "Import Message" FOLDER REPO_URL

update

Updates the repository to the most recent code.
svn update
Add the -r option to update to a specific revision number.
svn update -r REV

revert

Reverts all the changes made to the current working copy that have not yet been committed. Adding the optional FILE will result in only that file being reverted. The -R flag will tell the command to recurse into all sub-directories as well.
svn revert [-R] [FILE]

diff

Shows the differences between the local copy of FILE and the current working copy.
svn diff FILE

info

Gives you info about the current working copy, including the URL of the repository it points to, and the last changed date/author.
svn info

list

This will list the files in source control for the current workspace directory. If you add the optional REPO_URL then it will list all the files in that repo.
svn -v list [REPO_URL]

commit/ci

Sends all changes from your local working copy to the repo. If you do not provde a log message with your commit, svn will launch your editor for you to provide one.
svn commit -m "MESSAGE GOES HERE"

log

Shows log messages from the repo. If no arguments are supplied, svn log shows the log messages for all files and directories inside (and including) the current working directory of your working copy. You can refine the results by specifying a path, one or more revisions, or any combination of the two.
svn log [PATH]

add

Adds the specified file(s) to version control for the repo associated with the current directory. By default it will recurse into any directories you add and add all of the directories content as well. You can set the level of recurrsion using the --depth option.
svn add [PATH(s)] [OPTIONS]

move/mv

This command moves files or directories in your working copy or in the repository. When moving multiple sources, they will be added as children of DST, which must be a directory.
svn move [PATH(s)] [DEST]

delete/del/remove/rm

Removes the specified file(s) from your local machine as well as version control for the repo associated with the current directory. If you want to keep your local files, you can use the option --keep-local. By default this comment will not delete unmodified or unversioned files, unless the --force option is used.
svn delete [PATH(s)] [OPTIONS]

blame/praise/annotate/ann

Shows author and revision information inline for the specified files or URLs. Each line of text is annotated at the beginning with the author (username) and the revision number for the last change to that line.
svn blame [TARGET]

copy/cp

Copies one or more files in your working copy.
svn copy [SRC...] [DST]

References

• Subversion Book

Read More...

Lately I have been working on developing UI Integration tests for my JEE6 DiveLog project and was having some trouble getting Arquillian Persistence and Arquillian Drone to work together. After spending a few days trying to sort it out, I created a JIRA and with the help of the Arquillian team, I was finally able to get it working.

The Use Case

The immediate use case I was testing was whether or not a user could sign in via the login page. I also needed to test whether or not the correct page elements were displayed and/or hidden after the user logged in. This required that a user already exist in the database.

The Problem

The problem I was having was that the Persistence extension was not executing when the Drone tests ran. This resulted in the user not being created in the database and the test ultimately failing as a result of the user not being found. Behind the scenes, the Persistence extension is not configured to work with tests that are baing run in Client Mode, so when the deployment was set to testable=false the persistence extension never kicked in.

The Solution

The solution is to "trick" the persistence extension into running prior to the client tests running. This is done with the @InSequence(X) annotation on your tests and by marking the deployment as testable=true. Once this is done you will need to create an empty method that does nothing and set it as the first test in the sequence. This test will be run in In Container mode and will cause the persistence extension to execute and setup your database. All of your remaining client tests should be annotated with @RunAsClient and set to come after the database setup method using @InSequence(X). Below is the working code sample:

@RunWith(Arquillian.class)
@DataSource("java:jboss/datasources/ExampleDS")
@UsingDataSet("addUserDataset.yml")
public class DroneTestIT {
    @Deployment(testable = true)
    public static WebArchive createDeployment() {
        // Create Archive
    }
    @Test
    @InSequence(1)
    public void setupDatabase(){
        // Do nothing, so Persistence will setup database
    }
    @Test
    @InSequence(2)
    @RunAsClient
    public void someUiTest(@ArquillianResource URL applicationPath, @Drone GrapheneSelenium browser) {
        // .. Perform Test
    }
}

The down side to this is that each client test has to be annotated with @RunAsClient so Drone will kick off a new Selenium session for each test, rather than using the same session for all the tests like it would if you were not running with mixed container modes. This results in the tests taking slightly longer to run. Hopefully in future versions of Arquillian this behavior can be cleaned up so that the process is a little more streamlined and these two extensions work together better.

Read More...