Thursday, February 16, 2012

Puppet Module for JBoss AS 7.1 "Thunder"

We at Bippo Indonesia and Soluvas love JBoss AS. Especially with the shiny new release 7.1.0.Final aka "Thunder".

And we love DevOps with Puppet too!

As the least contribution we could provide, our Puppet Module for JBoss AS on GitHub is available as an open source project.

It's currently a work in progress, but as time goes we hope to make it flexible with Puppet's parameterized class feature and hopefully able to do deploy/redeploy/undeploy operations, change logging features, user management, etc. Especially that JBoss has an excellent CLI tool, we hope the integration with Puppet will be relatively easy.

Thank you JBoss!

Reblogged from https://community.jboss.org/blogs/beyondjavaee/2012/02/16/puppet-module-for-jboss-as-71-thunder

Wednesday, February 15, 2012

UnproxyableResolutionException Workaround when using Scala Closures and javax.inject CDI Beans Together

Some powerful Scala programming language features like closures, pattern matching, and lazy vals don't work well with dependency injection frameworks like javax.inject aka CDI. This is due to stricter class structure requirements to enable proxying.

For example, this "innocent" code will not work:

  @Inject private var fbPhotoImporterFactory: Instance[FacebookPhotoImporter] = _
  @Produces @Named("facebookPhotoImporter") private var fbPhotoImporter: ActorRef = _

  @PostConstruct
  def init() {
    logger.debug("Starting FacebookPhotoImporter actor")
    fbPhotoImporter = Actor.actorOf(fbPhotoImporterFactory.get())
    fbPhotoImporter.start()
  }

It will throw:

Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437 Normal scoped bean class com.satukancinta.web.Persistence is not proxyable because the type is final or it contains a final method public final javax.enterprise.inject.Instance com.satukancinta.web.Persistence.com$satukancinta$web$Persistence$$fbPhotoImporterFactory() - Managed Bean [class com.satukancinta.web.Persistence] with qualifiers [@Any @Default].
    at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:225)
    at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:178)
    at org.jboss.weld.util.Proxies.getUnproxyableTypesExceptionInt(Proxies.java:193)
    at org.jboss.weld.util.Proxies.getUnproxyableTypesException(Proxies.java:167)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:110)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
    at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
    at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
    at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
    ... 5 more

As you can see, my use code isn't exactly "edge cases".

It's actually a pretty common use case: create a Akka actor and pass a factory function to it, as a closure.
The code above doesn't look like it's using a closure, but it actually is when written like this: (same functionality, but still breaks CDI)

    fbPhotoImporter = Actor.actorOf { fbPhotoImporterFactory.get() }

I can see why CDI has a strict requirement, and I can also understand why Scala implements it the way it is (Scala developers definitely already has a lot of problems working around powerful Scala features into a very restrictive JVM bytecode requirements). This is the price we pay for having a somewhat inferior language (Java, please don't get offended) in the first place.

But I as an application developer want to have a quick fix for this issue. Re-coding the class in plain Java is one option, but it turns I don't need to. There is a workaround, by creating a helper method then using it:

  @Inject private var fbPhotoImporterFactory: Instance[FacebookPhotoImporter] = _
  @Produces @Named("facebookPhotoImporter") private var fbPhotoImporter: ActorRef = _
 
  def createFbPhotoImporter() = fbPhotoImporterFactory.get()
 
  @PostConstruct
  def init() {
    logger.debug("Starting FacebookPhotoImporter actor")
    fbPhotoImporter = Actor.actorOf(createFbPhotoImporter)
    fbPhotoImporter.start()
  }

Now Scala is happy and CDI is also happy. Yes it's a bit more verbose but not too bad. And I guess the code is now somewhat more understandable for Java guys. :)

Tip: To learn more about Scala programming, I recommend Programming in Scala: A Comprehensive Step-by-Step Guide, 2nd Edition.

Monday, January 16, 2012

Pentaho Data Integration Transformation and Step Architecture

Pentaho-data-integration-trans

After doing some Pentaho Data Integration (Kettle) work especially with JSON Output Step in PDI-7195 bug, I guess it's a good thing to describe visually how I see the PDI transformations and steps architecture.

Hopefully this is helpful for you and also to remind me when I'm confused because which Kettle step framework classes/interfaces relate to which ones is sometimes easy to forget. :-)

Learn how to process and integrate enterprise databases & data warehouses easily with Pentaho Data Integration 4 Cookbook.

Friday, January 13, 2012

When do work in Enterprise Application Integration field...

...be prepared to get ClassNotFoundException, ClassCastException,

and loads of other classpath and classloading problems often. :-)

(if you don't use OSGi, that is...)

When do work in Enterprise Application Integration field...

...be prepared to get ClassNotFoundException, ClassCastException,

and loads of other classpath and classloading problems often. :-)

(if you don't use OSGi, that is...)

Wednesday, January 11, 2012

Making JSF 2.0 Composite Components Ajax render-capable

Satukancinta-user-follow-jsf-a

If you for example have the following composite component in a JSF 2.0 Facelets XHTML template:

<sc:block title="Followers">

<h:panelGroup rendered="#{not empty userShow.user.followedByUsers}">

<ul>

<ui:repeat var="user" value="#{userShow.user.followedByUsers}">

<li><sc:user_link user="#{user}"/></li>

</ui:repeat>

</ul>

</h:panelGroup>

<h:panelGroup rendered="#{empty usefollowedByUsers}">

#{userShow.user.name} has no followers.

</h:panelGroup>

</sc:block>

and try do ajax render:

<a4j:commandButton value="Follow" action="#{userBean.follow(currentUser, userShow.user)}"

render="followPanel followers"

rendered="#{not currentUser.isFollowing(userShow.user)}"/>

This won't work for some reason. Wrong workaround is using a h:panelGroup and moving the id for ajax render there:

<sc:block title="Followers">

<h:panelGroup id="followers">

<h:panelGroup rendered="#{not empty userShow.user.followedByUsers}">

<ul>

<ui:repeat var="user" value="#{userShow.user.followedByUsers}">

<li><sc:user_link user="#{user}"/></li>

</ui:repeat>

</ul>

</h:panelGroup>

<h:panelGroup rendered="#{empty us.followedByUsers}">

#{userShow.user.name} has no followers.

</h:panelGroup>

</h:panelGroup>

</sc:block>

The correct solution is to put a #{cc.clientId} like below in the composite implementation:

<composite:implementation>

<section id="#{cc.clientId}" class="block">

<div class="block-inner clearfix">

<h2 class="block-title">#{cc.attrs.title}</h2>

<div class="block-content content">

<composite:insertChildren/>

</div>

</div>

</section>

</composite:implementation>

To learn more about Java Web Development using Java EE 6, I highly recommend The Java EE 6 Tutorial: Basic Concepts (4th Edition) (Java Series) by Eric Jendrock, Ian Evans, Devika Gollapudi and Kim Haase.

Thursday, December 22, 2011

Fix Jackson/JAXB JSON Serialization Problem with Spring Data Neo4j @NodeEntity Objects

Spring Data Neo4j @NodeEntity-annotated objects are proxy-enriched by Spring Data Neo4j aspects using AspectJ. There are times we want to expose these objects via JAX-RS REST API or JAX-WS / SOAP web services and then (by default) we will have problems.

The error stacktrace messages (here using JBoss AS 7.0.2) are along the lines of:

HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException: No serializer found for class org.neo4j.graphdb.DynamicRelationshipType and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationConfig.Feature.FAIL_ON_EMPTY_BEANS) ) (through reference chain: com.satukancinta.domain.User["enjoyActivities"]->org.springframework.data.neo4j.fieldaccess.ManagedFieldAccessorSet[0]->com.satukancinta.domain.Activity["persistentState"]->org.neo4j.rest.graphdb.entity.RestNode["relationships"]->org.neo4j.rest.graphdb.entity.RestRelationship["type"])


type Status report

message org.codehaus.jackson.map.JsonMappingException: No serializer found for class org.neo4j.graphdb.DynamicRelationshipType and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationConfig.Feature.FAIL_ON_EMPTY_BEANS) ) (through reference chain: com.satukancinta.domain.User["enjoyActivities"]->org.springframework.data.neo4j.fieldaccess.ManagedFieldAccessorSet[0]->com.satukancinta.domain.Activity["persistentState"]->org.neo4j.rest.graphdb.entity.RestNode["relationships"]->org.neo4j.rest.graphdb.entity.RestRelationship["type"])

description The server encountered an internal error (org.codehaus.jackson.map.JsonMappingException: No serializer found for class org.neo4j.graphdb.DynamicRelationshipType and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationConfig.Feature.FAIL_ON_EMPTY_BEANS) ) (through reference chain: com.satukancinta.domain.User["enjoyActivities"]->org.springframework.data.neo4j.fieldaccess.ManagedFieldAccessorSet[0]->com.satukancinta.domain.Activity["persistentState"]->org.neo4j.rest.graphdb.entity.RestNode["relationships"]->org.neo4j.rest.graphdb.entity.RestRelationship["type"])) that prevented it from fulfilling this request.

To solve this problem, annotate your entity class with @JsonAutoDetect(JsonMethod.NONE) :

import org.codehaus.jackson.annotate.JsonAutoDetect;

import org.codehaus.jackson.annotate.JsonMethod;

import org.codehaus.jackson.annotate.JsonProperty;


@NodeEntity @JsonAutoDetect(JsonMethod.NONE)

public class User implements NodeBacked {

then manually annotate each property you want to serialize with @JsonProperty :

@JsonProperty

public String getName() {

return name;

}

Now the JAX-RS Application works as intended and everybody is happy. :-) There's also a StackOverflow thread that discusses this problem.

To learn more about Java Web Development using Java EE 6, I highly recommend The Java EE 6 Tutorial: Basic Concepts (4th Edition) (Java Series) by Eric Jendrock, Ian Evans, Devika Gollapudi and Kim Haase.

 
Copyright 2009 Spring vs Java EE Web Dev. Powered by Blogger Blogger Templates create by Deluxe Templates. WP by Masterplan