Group items tagged

" Given that web service invocations are always remote across the internet, developing rigorous and responsive web service client applications has always been a challenge for architects and developers working with SOA. JAX-WS 2.0 comes with one effective solution to this problem: asynchronous web service invocation, with which a web service client may interact with a web service in a non-blocking, asynchronous approach. In this article, we will provide an exposition of this technology with examples built upon the reference implementation. Our examples utilize JDK 5.0, JAX-WS 2.0 reference implementation (RI), and Tomcat 5.5. JAX-WS 2.0 requires JAXP 1.3. To replace the JAXP 1.2 released with JDK 5.0 with this newer version, one approach is to download the JAXP 1.3 RI, and copy the endorsed directory under /lib of its installation home to %JAVA_HOME%/jre/lib. We need to copy the jaxp-api.jar of JAXP 1.3 RI to %JAVA_HOME%/jre/lib/endorsed as well. To make Tomcat 5.5 work with JAX-WS 2.0, readers need to copy all the .jar files under the /lib directory of the JAX-WS 2.0 RI installation to the %CATALINA_HOME%/shared/lib directory. As of this writing (in addition to Tomcat 5.5), Sun Java System Application Server 9.0, GlassFish, and Celtix also support JAX-WS 2.0. xFire is in the process of completing its implementation of this specification. Since asynchronous web service invocation in JAX-WS 2.0 is built upon the concurrent programming support in JDK 5.0 introduced with the java.util.concurrent package, we will start from there."

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

In this article I'll describe the setup I use to do develop Lift applications. While more heavy-weight than if an interpreted language is used, I find this setup provides fairly decent turnaround times. So, it took a little longer than expected to write this article which continues where the previous stopped. But all good things come to he who waits The software used in the previous article all had major updates in the meantime: Scala 2.8 (2.8.1 is just around the corner) Eclipse 3.6 Scale IDE for Eclipse (though a nightly build is currently needed for Eclipse 3.6) Gradle 0.9 RC1 Lift 2.1 RC2

"Scalaz is a library written in the Scala Programming Language. The intention of Scalaz is to include general functions that are not currently available in the core Scala API. The scalaz-core module depends only on the core Scala API and the core Java 2 Standard Edition API. Scalaz is released under a BSD open source licence making it compatible with the licence of the Scala project. Scalaz 6.0.1 was released in June 2011, targeting Scala 2.8.1 and 2.9.0.1. "

"Blueprint provides a dependency injection framework for OSGi and was standardized by the OSGi Alliance in OSGi Compendium R4.2. It is designed to deal with the dynamic nature of OSGi, where services can become available and unavailable at any time. The specification is also designed to work with plain old Java objects (POJOs) enabling simple components to be written and unit tested in a JSE environment without needing to be aware of how they are assembled. The Blueprint XML files that define and describe the assembly of various components are key to the Blueprint programming model. The specification describes how the components get instantiated and wired together to form a running module. The following documentation covers the 80:20 usage of Blueprint. For further details, please refer to the OSGi Compendium R4.2 specification."

Last weekend while pondering the question "Is Scala ready for the enterprise?" I decided to write a simple Java EE 6 app entirely in Scala, without using any Java. I had three main reasons for doing this: one was just to see how easy/difficult it would be to write everything in Scala (it was easy).  Another was to document the process for others journeying down the same road (the entire project is on github).  Finally, I wanted to identify advantages of using Scala instead of Java that are specific to Java EE apps (I found several). Background The specific app I created was an adaptation of the Books example from Chapter 10 of Beginning Java™ EE 6 Platform with GlassFish™ 3. It's a simple web app that displays a list of books in a database and lets you add new books. Although it's a pretty trivial app, it does touch on several important Java EE 6 technologies: JPA 2.0, EJB 3.1 and JSF 2.0.

I am working on a web site that will help students practice their Scala programming skills. As I labored along, writing my JSF app code, I thought "this is silly-why not practice Scala at the same time?" But I like JSF and wasn't ready to jump to Lift or Vaadin. With Eclipse, this isn't all that hard. Install the Java plugin. Make a dynamic web project in the usual way, using the Java EE perspective. Then, switch to the Scala perspective, right-click on the project, and, if all planets are aligned correctly, you will get a menu item "Add Scala nature". (If they are not, see here for a manual approach.) Add your managed beans as Scala classes. Finally, switch back to the Java EE perspective, select the project properties, and add the Scala library JAR as a Java EE module dependency. But I like NetBeans and wasn't ready to switch to Eclipse. (Unfortunately, JSF 2 support in Eclipse is pretty minimal, the Glassfish integration is a bit flaky, and the Scala plugin has very little usable code completion.) NetBeans doesn't let me add a "Scala nature" to a web project. If I add Scala files to the project, I can edit them with the Scala editor, but they just get copied to the WAR file, without any compilation. I had one look at the Ant scripts for a Scala and a web project and decided that I wasn't going to figure out how to merge them. This blog shows how you can use Maven to make a mixed Scala/Java project in NetBeans. So I gathered up JSF and Scala pom.xml files from here and here, cut out the considerable crud from the JSF POM file that was probably meant for supporting Tomcat, and merged the results to the best of my ability-see below. You use the usual Maven directory structure, but with a src/main/scala directory instead of src/main/java:

Papyrus is aiming at providing an integrated and user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst them UML 2 and SysML and the glue required for integrating these editors (GMF-based or not) with other MBD and MDSD tools. Papyrus also offers a very advanced support of UML profiles that enables users to define editors for DSLs based on the UML 2 standard. The main feature of Papyrus regarding this latter point is a set of very powerful customization mechanisms which can be leveraged to create user-defined Papyrus perspectives and give it the same look and feel as a "pure" DSL editor.

"Business Intelligence and Reporting Tools BIRT is an open source Eclipse-based reporting system that integrates with your Java/J2EE application to produce compelling reports. Get started with the newest major release, BIRT 2.6.1. Get started with the latest in the BIRT 2.5 series. Need help with BIRT? BIRT provides core reporting features such as report layout, data access and scripting. Please try BIRT and tell us what you think by filling bugs reports & enhancement requests through Bugzilla as explained on the community page. "

"JAX-WS Reference Implementation Project. This project provides the core of Metro project, inside GlassFish community This project develops and evolves the code base for the reference implementation of the Java API for XML Web Services (JAX-WS) specification. The current code base supports JAX-WS 2.0 and JAXWS 2.1 but the project will track future versions of the JAX-WS specifications."

Struts 2 tutorial for beginners with examples in eclipse. Struts2 tutorial point. Struts 2 tutorial with examples. Learn Struts tutorial step by step way.

ModeShape (formerly "JBoss DNA") is a JCR 2.0 (JSR-283) implementation that provides access to content stored in many different kinds of systems. A ModeShape repository isn't yet another silo of isolated information, but rather it's a JCR view of the information you already have in your environment: files systems, databases, other repositories, services, applications, etc. To your applications, ModeShape looks and behaves like a regular JCR repository. Using the standard JCR API, applications can search, navigate, version, and listen for changes in the content. But under the covers, ModeShape gets its content by federating multiple back-end systems (like databases, services, other repositories, etc.), allowing those systems to continue "owning" the information while ensuring the unified repository stays up-to-date and in sync. ModeShape repositories can be used in a variety of applications. One of the most obvious ones is in provisioning and management, where it's critical to understand and keep track of the metadata for models, database, services, components, applications, clusters, machines, and other systems used in an enterprise. Governance takes that a step farther, by also tracking the policies and expectations against which performance can be verified. In these cases, a repository is an excellent mechanism for managing this complex and highly-varied information. But a ModeShape repository doesn't have to be large and complex: it could just manage configuration information for an application, or it could just provide a JCR interface on top of a couple of non-JCR systems.

There is no migration system in vanilla grails (although possibly in Grails 2.0 …. ?) but there do exist several plugins that provide  some migration functionality. As of this post I am aware of three: dbMigrate, Liquibase, and Autobase. Of these, I prefer Liquibase and cannot recommend it enough. While it uses XML to describe its changesets it is a mature open-source Java project that works flawlessly (and has some excellent documentation). I did not have much luck using DbMigrate and Autobase when including in an existing project… which is a shame as Autobase (which is built on Liquibase) uses a nice DSL syntax to build the migrations.

"A lot of people have asked me to document the reasons I want to migrate Hibernate from Maven to Gradle as its build tool so I enumerate those reasons here. If you are completely new to Gradle, I suggest having a look at their overview page. Up front I want to point out that this is not intended as a "Maven bash session" nor as a means to directly compare Maven and Gradle. It is just a means to describe the issues and frustrations I have seen in my 2.5+ years of using Maven for Hibernate builds; in many cases the cause is simply an assumption or concept in Maven itself which did not line up cleanly with how I wanted to do build stuff in Hibernate. Some of the list aggregated by Paul comes directly from Hibernate use-cases; I'd suggest reading through those as well. It is also a means to describe why I decided on Gradle as opposed to other related build tools out there now (Buildr, SBT, etc). Note that there is a comparison wiki between Gradle and Maven, but that it is quite old and out of date in many respects especially in regards to Gradle. The issues I had with Maven (note that these are largely chronological, not in order of "importance") are as follows:"

The default EMF UML2 repository implementation was changed from UML2 1.x to UML2 2.x, in order to support the most current versions of the MagicDraw and Rational tools. Due to conflicting dependencies in the uml libraries, both implementations could not be supported at the same time.

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I'd implied, so I thought I'd spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse. Prerequisites This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven't already - I had issues when I had multiple Lift projects imported with Xmx set to 386. Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I'm not sure how well it works with m2eclipse - I'm going to play with that more later. I also assume you know how to install plugins into Eclipse - I will create a more in-depth screencast for doing all of this if there is enough interest.

There was a recent outburst in blogs on the topic of Groovy and how it compares to Java. Although I respect the youthfull entusiasim of Groovy and Co. working on this little exercise I'm just perplexed by the "WHY?" in this whole discussion. Let me just say again: W H Y ?!?! 1. Practically no one cares about Groovy (let alone Groovy++ strap-on) beyond Grails community. So this language just as "widely accepted" as Ruby (at least for enterprise software development) 2. If you know Java it's equally "challenging" to pick up either Groovy or Scala. Don't let anyone insult your intelligence by claiming that Scala syntax is somehow more complex than Groovy. In both languages you will need to adapt to functional thinking - and that's where you will have to spend a couple of weekends… 3. If you know Groovy - you already know 90% of Scala (different syntax and few extra features can be picked up in the evening) 4. Scala is designed by people who have proper academic background, experience and talent in the area of language design - Groovy has never been that way (and anyone who dares to look inside of Groovy runtime or history of changes in it will attest to that). NOTE: it did come out rather strong - but that's how I feel about it and after some thinking I'll leave as is. Nothing personal to anyone reading it… 5. Scala as a post-functional language is years ahead of Groovy (static typing with best-in-business type inference, highly tuned mix of imperative and functional styles, powerful and done-right generics, etc.) 6. Groovy will ALWAYS be slower than Scala or Java (latest benchmarks put even Groovy++ about 50 times slower than Java) just by its nature unless someone changes the language and rebuilds the runtime from the ground up. 7. Once we get decent integration with Eclipse, NetBeans and IDEA for Scala, the Groovy will lose its only serious advantage

"Besides a rich user interaction many applications need to display a big amount of data sets as diagrams or reports as part of their applications. In order to bridge the gap the BIRT project was created as part of the eclipse ecosystem. BIRT is an open source Eclipse-based reporting system that integrates with your Java/J2EE application to produce compelling reports. That BIRT integrates well with classic RCP applications is a well known fact. But the need for rich internet applications is still growing. And here the RAP comes into play. As a platform for developing Web 2.0 applications with the same patterns as for RCP it paves the way for single sourcing applications running on both platforms. In this talk we will show how to integrate diagrams and reports known from BIRT into RAP applications. Topics covered include how to setup the environment to let BIRT and RAP play well together. In addition we will give advices how to use the reports inside RAP applications and which problems may arise. As a final outcome of we will know everything to bring reporting capabilities into RAP applications. "

The Apache Open For Business Project is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP, Open Source CRM, Open Source E-B