Alexander Smirnov’s personal Weblog

May 18, 2011

Neo4j Java EE connector

Filed under: Uncategorized — alexsmirnov @ 12:28 pm

Recently, I needed to add ‘graph relations’ to the data objects in the some JEE application. That application uses JPA and MySQL to store data objects, and first attempt was done by adding “many-to-many” relationships that points back to entity itself, but such schema doesnt work well in SQL. Therefore, we decided to keep graph-like relationships in the Neo4j database.

The next question was: how to add Neo4j to our application and how to coordinate transactions between JPA and Neo4j ? Because we run inside Glassfish 3.1 container, we put graph database outside of application and created Java EE connector neo4j-connector that deployed to server as resource adaptor and manages Neo4j database. Application get instance of GraphDatabaseService from JNDI and doesn’t have to care about database startup/shutdown, configuration, and transactions.

Connector features:

  • Standard JCA 1.6 connector, that can be installed on any Java EE 6 compatible server. For the oldest servers, It’s pretty easy to convert connector to JCA 1.5 API.
  • ResourceAdapter starts Neoj4 database at first request and shutdown it with server.
  • Supports both LocalTransaction and XA transaction. XA support may be not quite correct – instead of using proper XAResource from adapter, it provides access to platform TransactionManager for Neo4j server. Diving into Neo4j internals, I’ve found that it creates couple of XAResource objects and enlists them in the Transaction, while ResourceAdaptor lets to create only one XAResource. Finally, I creater Provider for JEE Server TransactionManager, similar to the Spring Data project.


  1. Check out source code from the Github neo4j-connector project and build it with Maven. Project uses some artifacts from the Jboss Maven repository, so you have to configure it before build.
  2. Deploy connector to your application server. For Glassfish 3, there is shell script that deploys resource adapter and configures connector. All what you need is having asadmin application in the path or GLASSFISH_HOME environment variable. The connector supports two configuration options: dir for the Neo4j database location and boolean “xa” property that switches adapter from Local to XA transactions.
  3. Add neo4j-connector-api library to comple your application. JCA classes loaded in the parent Classloader on the server, you don’t need neo4j classes at runtime. For maven, just add dependency to ejb or war project:

There you go – Neo4j GraphDatabaseService now available as JNDI resource!

 Neo4JConnectionFactory neo4jConnectionFactory;

 GraphDatabaseService createDatabaseService() throws ResourceException{
 return neo4jConnectionFactory.getConnection();

In the EJB services, you don’t have to start/stop transactions by hand, it will be done by container if you set apporpriate @TransactionAttribute for EJB/business method.
In the XA mode, you can use JPA/SQL and Neo4j together, and container will take care for data consistency ( of course, database connection also have to use XADataSource ).

Future plans

  1. Add database configuration parameters to adapter.
  2. Support Neo4j High Availability cluster in the adaptor. I plan to start and configure all necessary services directly in the adapter, using Application Server cluster service where possible. Therefore, JEE application can be scaled without any changes in the code, as it supposed for JEE.
  3. Provide JPA style Object to Graph mapping, most likely as the CDI extension.

April 8, 2011

RichFaces CDK: How To Create JSF Renderer

Filed under: Uncategorized — alexsmirnov @ 1:44 pm

JSF Renderer

JSF Renderer responsible for two functions, rendering component as HTML markup and processing request attributes. While processing attributes in the code usually is simple, generating markup in the Java code may be cumbersome for big components. Just by human mind nature, it would be hard to imagine how calls to ResponseWrited converted to HTML, and then imagine the second transformation, from html and CSS to visual representation.
Also, each element and attribute require five times more characters when generated string itself, that makes renderer code much bigger when original design.
JSF 2.0 offers “composite components” for code reuse, but native component developer still have to write dosens of startElement/writeAttribute/writeText/endElement calls.
RichFaces CDK closes a gap between component html design and Java code. It lets developer to create xhtml template, similar to the composite component and converts that template to Java code. That templates reuses JSF 2 composite component syntax where possible, what lets developers to prototype component as composite and convert it into native for production, with better performance and extended functionality/

Renderer Template

Base structure

Same as JSF composite component, Renderer template is well-formed XML file. The main difference that CDK template should have document element <root> from the cdk namespace “;. To allow XML validation for non-standard html attributes, the default namespace should be “;, associated with CDK xml schema. The full list of template schemes described in the table below:

Namespace URI Schema location Description; HTML 4.0.1 with CDK extensions.; CDK template document; CDK version of JSTL tags; CDK version of JSF 2 composite component tags; Extensions for html attributes to process component pass-throuth attributes

Same as for JSF composite component, CDK contains two main sections: interface with meta information necessary to generate Renderer and implementation with HTML markup.

<composite:interface> Element

Interface section supports <composite:attribute> elements from the JSF composite component, with children <composite:clientBehavior>. The syntax is same as for composite component, while meaning is different: These elements define renderer-specific component attributes. If rendered-specific component generated by CDK, these attributes will be added to the component, and generated code will use getter and setter methods for them instead of attributes Map.
In addition, there are CDK-specific elements used by CDK only:

  • <cdk:class>, the content of that element should be full-qualified Java class name for generated renderer. By default, CDK infer name for generated class by naming conventions.
  • <cdk:superclass>, the content of that element should be full-qualified Java class name for generated Renderer superclass. That class should extend javax.faces.render.Renderer, and can be used to put decode logic and helper methods. By default, renderer extends javax.faces.render.Renderer class.
  • <cdk:component-family>, the content of that element should contain JSF component family ID, used to associate renderer with component. By default, that walue calculated by naming conventions or taken from UIComponent class annotation that contains renderer attribute referrenced to this template.
  • <cdk:renderer-type>, the content of that element contains JSF Renderer type assigned to the generated renderer. Same as for component family, its value can be inferred or taken from UIComponent.
  • <cdk:renderkit-id> defines JSF render kit for which generated rendered belongs to. By default, it’s JSF HTML_BASIC render kit.
  • <cdk:renders-children>, its content contains logical value ( true or false ) that should be returned from getRendersChildren method. By default, CDK doesn’t override that method from superclass.
  • <cdk:import> defines additional Java import directives for generated class. Attributes:
    • package – fully qualified Java package name
    • names – short names for imported classes, comma-separated list
    • static – tells CDK to generate “import static” directive
  • <cdk:import-attributes> allows CDK to import attributes definition from faces-config fragment, same as used by the @JsfComponent#attributes . The ‘src’ attributes should contain URL for that fragment.
  • <cdk:resource-dependency> defines JSF resource used by the component. Resource defined by that element added to @ResourceDependencies annotation for generated type. Attributes:
    • name – defines resource name.
    • library – optional, defines resource library name
    • target – optional, forces resource to be rendered in html head, body, or form element.


While <interface> section defines meta-information, most of the Renderer code generated from the content of <implementation> element. Html content of that element converted to calls of startElement/writeAttribute/endElement ResponseWriter methods.

Encoding children components

JSF Renderer has three methods that participate in encoding process: encodeBegin, encodeChildern and encodeEnd. For components that do not contain children elements ( input field, for example ), it’s better to perform encoding in the single method, usually encodeEnd. If component children encoded in the natural order, developer can left default encodeChildren functionality and render component prolog in the encodeBegin() and finish it in the encodeEnd. For components that can change rendering sequence of its children, rendering of content usually performed in the encodeChildren mathod, with rendersChildren method returns true ( see <cdk:renders-children> element above ).
To define methods used for encoding, developer can put <cdk:body> element. Everything before that element going to the encodeBegin method, and rest of the <composite:implementation> content after <cdk:body> going to the encodeEnd. If this element is empty, no encodeChildren method generated unless ‘enforce’ attribute set to true, so encoding of children components performing by default in superclass. Otherwise, content of <cdk:body> generated inside encodeChildren method.


CDK evaluates Expression Language statements into Java code. It supports Expression Language 2.2 syntax, and recognises their argument types where possible. Because expressions generates as the Java code, the type checking is more strict when it allowed in the dynamic interpreter. For example it impossible to access to unknown method or field if argument recognized as Object.
EL-expressions allowed in text, html attributes, and flow control directives. CDK does not recognise EL-expressions as HTML element names yet.
To call method that returns void, use <cdk:call> element, with call expression provided in element body or by the ‘expression’ attribute.

Flow control

CDK supports JSTL-like directives to control rendering:

  • <c:if> element used to generate Java if() statements. Content of the ‘test’ attribute used to generate condition expression, usually from EL-expression.
  • <c:choose> with <c:when> and <c:otherwise> children elements used to chain Java if() …else if() … else statements. ‘test’ attribute of each <c:when> element used to generate conditions, and content of the <c:otherwise> going to the final else {} block.
  • <c:forEach> used for iterations over collections. Its ‘items’ attribute should be evaluated to Java Collection or array ( Iterator/Enumeration not supported yet ), and variable defined by ‘var’ attribute can be used in EL-expressions inside iteration.

In addition, there is <cdk:switch> with <cdk:case> and <cdk:default> elements using to construct Java ‘switch’ directives. The ‘key’ attribute used to define switch() condition, and ‘values’ attribute from <cdk:case> used to generate case … : statement condition. Of course, these expression should be evaluated to types which valid for Java switch/case statement.


CDK can assign computation results to variables, which can be used in EL-expressions. Predefined variable names are:

  • component – the UIComponent used to call Renderer#encode…() method.
  • facesContext – the current FacesContext instance.
  • clientId – client id of component used to call Rendered method.
  • responseWriter – instance of JSF ResponceWriter used to write Renderer output.

Developer can define his own variables using <cdk:object> element. The variable name defined by the ‘name’ attribute, and value evaluated from the ‘value’ attribute or element body.
The scope of object is the current Java block, hence objects defined in the different parts sepatated by the <cdk:body> statement are not visible in another parts because they are going in different methods. Also, variables defined inside flow control elements are not visible outside of element.


In the typical component, most HTML attributes generated from the component attributes. There are two cases for each attribute:

  1. Attribute value generated as the String.
  2. Pass throw attribute, which content comes from the component attribute, with optional behavior-generated event handlers.

For the first case, developer can provide attribute value as literal or EL-expression. CDK recognises HTML 4 schema ( no HTML5 schema implemented yet ) and properly render URL and boolean values.
In the second case, use attributes from the CDK extensions namespace. Each html attribute has its ‘extension’ version. For these attributes, cdk threat attribute value as the name of the component attribute from which attribute value comes. If component attribute was not set, no html attribute will be rendered. For attributes with associated ClientBehavior events component renders scripts from all behaviors for that event.
To reduce the number of code in component template, there are three attributes for bulk operations:

  • cdk:passThroughWithExclusions, that renders all attributes allowed for html element except ones defined in attribute value ( space separated list ). CDK expect that component attribute name the same as for html. That’s useful to render single-element components or for the root element.
  • cdk:passThrough renders all attributes defined in its value ( space-separated list ). If component and html attributes have the same name, it typed as is. Otherwise, developer can provide component attribute name separated by colon, for example: <cdk:passThrough=” style class:styleClass”, what means render component ‘style’ attribute as html style, and component#styleClass as HTML class.


March 25, 2011

Maven deployer plugin for Glassfish 3.1 and Jboss

Filed under: Glassfish, Uncategorized — alexsmirnov @ 4:46 pm

Plugin features

Encouraged by the Jason Lee articles about Glassfish REST API, I added support for that API to the plugin that I use to deploy my projects, and published the code to GitHub. That’s forked from the original Maven Jboss Plugin far ago, and modified to meet my needs:

  • Find module, most suitable for deployment, in the multi-module projects. For the ‘pom’ packaging, plugin checks all dependent modules and deploys artifact with this precedence: EAR, WAR, EJB, SAR. That lets to build and deploy project to the target server in the single command: mvn package deploy.
  • Jboss downloads archives for deployment from network by http protocol. Therefore, when you deploy application to remote server, it’s necessary to put the public address of developer machine in JMX call. Plugin tries to resolve public IP for remote deployment, or can get it from configuration.
  • Added workaround for Jboss 5 bug that crashes in attempt to deploy file from url with http: protocol.
  • https: protocol added, to deploy on secured console.
  • And, at the last, it also supports Glassfish REST api with same features.


         <!-- configuration options -->

Define target server

By default, plugin deploys artifact using http://localhost:4848/ URL for management application.

To define another server, use these configuration options:

  • <targetHost> – hostname or IP address of target server.
  • <targetPort> – http port where management application listening, if it different from default 4848.
  • <secure> – if you use https protocol ( enabled by asadmin enable-secure-console command ).


By default, plugin connected to the target server as user ‘admin’ with empty password what’s Glassfish default. There are several options to define user name and password:

  1. Using <server> element in Maven settings.xml. You can create that element with the same ID as target host name, or tell plugin which id to use by <serverId> option.
  2. Define them in configuration by <username> and <password> element – not recommended for remote deployment because they visible for anyone who have acces tou your project code.
  3. use command line options -Dusername=… and -Dpassword=…

Define deployment file

For the projects with packaging ‘jar’ ‘war’ ‘ear’ ‘sar’ plugin deploys the main project artifact with the same application name as artifactId. For packaging ‘pom’, it tries to find most suitable artifact in project modules:

  1. If some module has ‘ear’ packaging, use it.
  2. Otherwise, try to find ‘war’ module.
  3. if no ‘ear’ or ‘war’ modules found, try to find ‘ejb’ or ‘sar’ modules.
  4. Otherwise, use the last module with packaging ‘jar’

The plugin has ‘aggregator’ flag in its configuration that enforces Maven to build dependent modules first. Therefore, whole project can be built and deployed by the single command:

mvn package deployer:deploy-glassfish

either from the command line, IDE or on the continuous integration server. I really use it to deploy my project to Glassfish running on Amazon EC2 cloud instance. Nirvana…

If default behavior not suitable, it can be overrided by configuration or command line options:

  • <deploymentFile>, -DdeploymentFile – path to archive to be deployed.
  • <name> -Dname – application name.
  • <contextRoot>, -DcontextRoot – web application context path.

April 12, 2010

RichFaces 3.3.3.Final is out

Filed under: Uncategorized — alexsmirnov @ 3:20 pm

RichFaces 3.3.3.Final is out

RichFaces 3.3.3.Final release was published on Tuesday April 13. I hope it will be the last release for the 3.x version branch, so we can make effort for 4.0 and JSF 2.0 features. Although that release has JSF 2.0 support; it has been designed for backward compatibility only, so developers can run their existing applications on JEE6 containers which shipped with JSF 2.0 out of the box.

The portlet bridge project is also on the way for the final release that should be ready for QA in the end of April. I already changed its dependencies for RichFaces 3.3.3.Final so it will work with the latest stable releases of all involved projects. Besides the JSF 2.0 support, The Jboss Portlet Bridge should be released with its own name “Mobius“. Surely, it’s twisted enough to have that name…

Google Apps Web Services Hub

Filed under: Semantic web, Uncategorized — Tags: , , — alexsmirnov @ 12:04 am

Last Wednesday, I was on the Google Apps Marketplace meetup. There were awesome presentations from Google’s Scott McMullan who gave a clear view about Marketplace business model and its opportunities for developers, and four excellent examples from companies that already offer their applications there. While I was listening about these applications and services offered by Google, I got an idea that there something is missed. Although each product has tight integration with Google Apps, they have no clue about others, so it’s hardly possible to associate sales contract from myERP with manymoon project, or use JIRA Studio for custom software development contract. MyERP has no payroll feature, but such applications are already presented in the Google Marketplace, yet they cannot be easy integrated with myERP accounting. Without such interaction capability, customers get only set of the independent applications, but not a solid corporate system.

Of course, applications may expose their own web services that can be used by others. For example, JIRA studio can use OpenSocial API ( not sure about RPC that is available for its standalone product), and someone can use it in another project. But, it’s hardly possible for any application to know about all possible partners and create connectors for all of them. Also, each application has to provide its own management tool there user can configure what are included into his corporate domain and how to use them. It would be also a nightmare for an administrator who have to use couple of different management tools just to append new application to domain or change user permissions.

The solution is well known in the software development: that is service dispatcher architecture. Any application should connect to the single controller that knows about all services in the domain and transfer request to appropriate endpoints. That can be REST-style service that only perform lookup tor the desired type of services and return response with service description and endpoint address so application can call discovered services directly.

There should be common contract for all services, so different applications can call any endpoint and understand its response. On the other hand, such contract should be extensible to easy introduce new type of service. I see that as some kinf of the Semantic Web ontology ( Semantic Web Services Registry ), there any developer can introduce a new type of service as extension of the existing one and register it on the service dispatcher. Other application can use it as the base type, while another will be able to get extended information. For example, accounting system can export its data in XBRL format, that extends XML+Stylesheet content, and latest may inherit simple file service. In this case, the same service can be used by an application that simple attach its response to the mail message because any file can be used there. Another consumer can display the same report on web page as result of XSLT transformation. Finally, any financial service that recognizes XBRL format may leverage all available information. In the opposite direction, the same ontology should also provide information about content types that can be accepted by the client, so service endpoint will decide proper format according to the request “Accept” header.

It’s not necessary for such REST web service hub to be provided by Google Apps. It can be independent application compatible with Google Apps contract, that uses OpenId and Oauth to authenticate, with its own management system. Any application in the customer domain can register its services and their descriptions, so another client would get it by request for particular type of services. That hub should also maintain user permissions, so domain administrator can use the single management console to configure services and grant or disable particular users to use some services. For applications that does not follow common format, or do not included into the domain there would be converters that seamless translate calls to target. For example, Salesforse clients can use their account from Google applications. Of course, there should be compatibility kit to test services provided by the third party applications, and libraries for most popular computer languages that makes service development easy.

The hardest part of such project will not be a technical implementation, but carefully designed format of services, and encouraging providers to use these standards. Really, the success mostly depends from how many third party developers will support proposed services. But if they do, all parts participated to the Google Apps Marketplace will be winners: Consumers would get more integrated solution that can improve business performance; developers can use already existing services to increase capabilities of their products, and they can faster put applications to market because it is not necessary to implement already existing features. Finally, it will increase Google Apps market and make it more profitable for Google.

Create a free website or blog at