Group items tagged

JSF 2.0, CDI, Scala 2.8 using Eclipse, Maven and Tomcat Tools used: * JDK 1.6 * Maven 2.2.1 * Eclipse 3.5 * Eclipse Scala plugin (I am using nightly build - http://www.scala-lang.org/scala-eclipse-plugin-nightly) * m2eclipse plugin Download the source from here

"I've had an opportunity recently to work on a product that needed an RIA web interface, and I chose my recent favorite tool for this, Vaadin. The services for this project needed to be highly scalable, and lent themselves well to functional techniques, so I selected Scala as my language of choice. I build my projects with Maven, for reasons I won't go into right now, and I do much of my JVM-language work in Intellij's excellent IDEA IDE. Given these tools, I found a way to facilitate very rapid development of web UI's, and I thought I'd pass it along. Another technique I use, which I'll expound on later, is creating "dummy" implementations of all of my backing services for my application. The "real" implementations are written as OSGi services, in separate modules from my UI. The UI is packaged as a war, but is also OSGi aware, with a bundle activator. This activator only gets called if the war is deployed into an OSGi container, and not otherwise. This allows the app to select which implementation of the services it uses - the "dummy" ones when it's deployed outside of OSGi, and the "real" ones when they're available. This means I can use the handy Maven jetty plugin to quickly spin up my application and test it on my local workstation, without needing all of the dependencies (like a data store and such) of my real services. That's good, in that I can get my "cycle time" down to a few seconds, where "cycle time" is the time between making a change and actually being able to test it in my browser. We can do better, though. I'm using Scala as my language of choice for building the UI as well, as it works just fine with Vaadin (and with everything else in the JVM ecosystem, for that matter, which is why I didn't choose a non-JVM language - but that's yet another rant). I compile my Scala with the Maven scala plugin - here's where the next handy bit comes into play. Turns out the Scala plugin has a goal cal

This article explains how to develop RESTful web services in Java with the JAX-RS reference implementation Jersey. In this article Eclipse 3.5, Java 1.6, Tomcat 6.0 and JAX-RS 1.1. (Jersey 1.1.5) is used.

So I started with a maven web application in Eclipse to do my test drive of jersey. I added the repositories, and the jersey-server dependency (https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0.2/jersey/dependencies.html) I started out with a filter, instead of the servlet. I always prefer filters. I also added the following initialization parameters:

Creating, Deploying, and Running Jersey Applications

JAX-RS 1.1 offers a @ApplicationPath annotation applicable to javax.ws.rs.core.Application which let you specify the webcontext and remove the need for any web.xml

"Hibernate OGM is an attempt to store data in a NoSQL data grid using he Hibernate Core engine rather than rewriting a JPA engine from scratch. The benefits are fairly obvious: reimplementing the complex JPA specification is a lot of work a new implementation would mature at a rather slow rate and risk of bugs would be high Hibernate is familiar to many people Earlier designs for this feature in Infinispan can be found on http://community.jboss.org/wiki/DesignofJPA-likeAPIandNewFineGrainedreplication"

"JBoss World Keynote 2011"

Caching is the most important performance optimization technique. There are many things that can be cached in persistence, objects, data, database connections, database statements, query results, meta-data, relationships, to name a few. Caching in object persistence normally refers to the caching of objects or their data. Caching also influences object identity, that is that if you read an object, then read the same object again you should get the identical object back (same reference). JPA 1.0 does not define a shared object cache, JPA providers can support a shared object cache or not, however most do. Caching in JPA is required with-in a transaction or within an extended persistence context to preserve object identity, but JPA does not require that caching be supported across transactions or persistence contexts. JPA 2.0 defines the concept of a shared cache. The @Cacheable annotation or cacheable XML attribute can be used to enable or disable caching on a class.

JDBC realm has a lot of attention in recent months. This blog summarizes the evolution of the JDBC realm implementation in GlassFish and explains how the latest implementation works. I would like to thank Jean-Baptiste, and Richter for their contributions and comments. The participation from the open source community definitely helps everyone. I encourage all of you to give feedback, participate, and help evolve this feature further. GlassFish always had the capability for anyone to plug-in a realm. Implementing a custom realm in the Sun Java System Application Server EE 8.0 is described in the article Authentication Using Custom Realms in Sun Java System Application Server. In S1AS 7.x, there is a JDBC Realm bundled in sample. Jean-Baptiste formally filed an enhancement and provided a clear text version of JDBCRealm for GlassFish. Richter wrote another implementation because the GlassFish JDBCRealm at that time not compatible with Tomcat.

"This chapter introduces the Expression Language (also referred to as the EL), which provides an important mechanism for enabling the presentation layer (web pages) to communicate with the application logic (backing beans). The EL is used by both JavaServer Faces technology and JavaServer Pages (JSP) technology. The EL represents a union of the expression languages offered by JavaServer Faces technology and JSP technology."