Using Jackrabbit JCR 2.2.5 with SLF4J 1.6.1 and Logback Classic

Recently I was hit by a bug where it is impossible to use Jackrabbit 2.2.5 with SLF4J 1.6.1 due to a conflicting dependency error.
For some reason, SLF4J 1.5.11 is still loaded.

It turned that this is because Jackrabbit 2.2.5 depends on Apache Tika 0.8 which in turn depends on edu.ucar:netcdf:4.2 which bundles SLF4J 1.5. This error has since been fixed for Tika 0.9, so this should not be a problem for future Jackrabbit 2.3 versions.

To fix it, you need to exclude edu.ucar:netcdf:4.2 and replace the dependency with edu.ucar:netcdf:4.2-min as follows:

<dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-parsers</artifactId>
    <version>0.8</version>
    <exclusions>
        <exclusion>
            <!-- NOTE: Version 4.2 has bundled slf4j -->
            <groupId>edu.ucar</groupId>
            <artifactId>netcdf</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <!-- Patched version 4.2-min does not bundle slf4j -->
    <groupId>edu.ucar</groupId>
    <artifactId>netcdf</artifactId>
    <version>4.2-min</version>
</dependency>

Here's a complete Maven dependencies in pom.xml for Jackrabbit 2.2.5 and using SLF4J 1.6.1 with Logback classic logging implementation:

<!-- The JCR API -->
<dependency>
    <groupId>javax.jcr</groupId>
    <artifactId>jcr</artifactId>
    <version>2.0</version>
</dependency>

<!-- Jackrabbit content repository -->
<dependency>
    <groupId>org.apache.jackrabbit</groupId>
    <artifactId>jackrabbit-core</artifactId>
    <version>2.2.5</version>
</dependency>

<dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-parsers</artifactId>
    <version>0.8</version>
    <exclusions>
        <exclusion>
            <!-- NOTE: Version 4.2 has bundled slf4j -->
            <groupId>edu.ucar</groupId>
            <artifactId>netcdf</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <!-- Patched version 4.2-min does not bundle slf4j -->
    <groupId>edu.ucar</groupId>
    <artifactId>netcdf</artifactId>
    <version>4.2-min</version>
</dependency>

<!-- Use Logback for logging -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.6.1</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>1.6.1</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>0.9.28</version>
    <scope>runtime</scope>
</dependency>

Transitive Dependency Management in Groovy Grape / @Grab via @GrabExclude

Sébastien Launay provided a better solution for Fixing Slow @Grab Dependencies Issue with Groovy/Grape Scripts.

I didn't know that Groovy's Grape / @Grab supports transitive dependency management features (that Apache Ivy underneath is actually very good at). (where are the @Grab/@GrabExclude docs???) So this is very new to me.

Below is his post copied verbatim:

. . .

Actually I think a more sexier way would be to provide explicitly the version of groovy or even exclude the dependency it as it is provided by the application classloader.

So the following examples work and do not need to create a file:

@Grab(group="org.codehaus.groovy.modules.http-builder",
  module="http-builder", version="0.5.1")
@Grab(group="org.codehaus.groovy", module="groovy", version="1.7.10")

or

@Grab(group="org.codehaus.groovy.modules.http-builder",
  module="http-builder", version="0.5.1")
@GrabExclude("org.codehaus.groovy:groovy")

All of these are workarounds, the problem IMHO still lies in the usage of a version range dependency.

I am not sure what happens when the application classloader has let's say Groovy 1.7.0 and the Grape classloader (asuming there is a nested classloader) provides Groovy 1.8.0, I would say that Grape comes from Groovy 1.7.0 but the target script is compiled and executed with Groovy 1.8.0, am I right?

Fixing Slow @Grab Dependencies Issue with Groovy/Grape Scripts

Groovy scripts are not only quick to write and powerful but also very flexible because it can download Maven dependencies/artifacts automatically using the @Grab "annotation".

However there is currently an issue being discussed:  @Grab is Unusably Slow in Groovy-User mailing list.

Fortunately there is a solution (actually, workaround) before the powers that be (either Grapes and/or the http-builder guys) implements a proper solution.

The following is a verbatim copy of Sébastien Launay's post:

.

I also got the same issue which is a pain because scripting Rest Web Service in Groovy is very powerful especially when it is easy to share with Grape / @Grab.

The dynamic (version range) dependency is actually defined by http-builder himself. IMHO using version range is often a bad practice, at least on production release, because for the same sources the build result can be different when launched again which renders difficult bug analysis and maintenance.

The other thing is that Apache Ivy configuration tries all remote repositories to check for a new version even if it was resolved before but this is appropriate as it is a dynamic dependency. This can be tuned in Ivy with the cache TTL feature.

Indeed, I had the following logs:

== resolving dependencies
org.codehaus.groovy.modules.

http-builder#http-builder;0.5.1->org.codehaus.groovy#groovy;[1.5,1.7.99]
...
downloadGrapes: Checking cache for: dependency:
org.codehaus.groovy#groovy;[1.5,1.7.99] ...
default-cache: cached resolved revision expired for

org.codehaus.groovy#groovy;[1.5,1.7.99]

The default TTL in Ivy 2.1.0 is 10 seconds, by changing it I got
faster startup, this can be done by creating the file ~/.groovy/grapeConfig.xml from the one found in svn and
editing the file to have:

<ivysettings>
  <property name="ivy.cache.ttl.default" value="15m"/>
...

JBoss Seam version 3.0.0 Final for Java EE 6 Released

The Seam development team is pleased to announce the final release of Seam 3.0. Seam is a modular collection of portable extensions and tooling for Java EE6.

This latest version represents a significant milestone in Seam's history, as it is the first release to be based on the standardized component model defined by the CDI (JSR-299 Java Contexts and Dependency Injection) specification.

Seam's goal is to enable developers to create rich, standards-based internet applications by solving many of the challenges encountered when developing software in today's connected world. It achieves this by providing an integrated set of feature-centric modules, each targetted at a single area of concern. This modular design also allows users the choice of using individual Seam modules based on the requirements of their project, without forcing them to adopt the overhead of a monolithic framework stack.

The following table contains a list of the modules included in the Seam 3.0 release, along with a brief description of their features.

Solder	Provides a collection of useful features for portable extension developers, and generally useful annotations and more for CDI-based applications.
Catch	Provides a simple infrastructure based on the CDI event bus to allow developers to establish a unified and robust exception handling process.
Config	Provides the capability to configure beans via alternate bean metadata sources, such as an XML-based configuration file.
Faces	Further unifies JSF and CDI by providing additional features not defined by the specification, and provides JSF integration with other Seam modules.
International	Provides a set of language and locale-based features to allow complete internationalization of your internet application.
Persistence	Enables transactions and persistence features for managed beans, and provides a simplified transaction API.
Remoting	Allows web-based applications to interact with the server-side component model via AJAX.
REST	Provides JAX-RS integration for your Seam-based application.
Security	Authentication and authorization services for your Java EE6 application.
Servlet	Unifies the Servlet and CDI programming models via an event bridge, and provides producers for implicit Servlet objects.
Validation	Provides enhanced validation features based on Hibernate Validator.
Wicket	Integrates the CDI programming model and other portable Seam enhancements with Apache Wicket.

Maven Users

The Seam BOM (Bill Of Materials) is a Maven POM artifact that is provided as a convenience for your Seam application. It declares the versions for all Seam modules and third party libraries that are used in the Seam stack. To use Seam in your Maven-based project, it is first recommended that you define the Seam version you wish to use by declaring the following property value:

<properties> <seam.version>3.0.0.Final</seam.version> </properties>

Next, add the following section to your project's POM file to import the Seam BOM:

<dependencyManagement> <dependencies> <dependency> <groupId>org.jboss.seam</groupId> <artifactId>seam-bom</artifactId> <version>${seam.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

After this, it is a simple matter of declaring which Seam modules you wish to use in your project. For example, if you wish to use the Seam Catch module in your project, simply add the following dependency:

<dependency> <groupId>org.jboss.seam.catch</groupId> <artifactId>seam-catch</artifactId> </dependency>

Please note that the Seam artifacts are published to the JBoss Community Maven Repository. See this page for more details on configuring Maven to use this repository.

Glassfish Users

If you use Glassfish 3.1 (or earlier) you must update the version of Weld contained inside your Glassfish installation. Please refer to the instructions at http://www.seamframework.org/Seam3/Compatibility for further information.

Downloads

Seam is available for download as a bundled distribution that includes all the modules, or alternatively as individual downloads for each module.

Bundled distribution: http://sourceforge.net/projects/jboss/files/Seam/3/3.0.0.Final/

Individual module downloads: http://www.seamframework.org/Seam3/Downloads

Documentation

Reference Documentation

API Documentation

Documentation for individual modules can also be found on the Seam documentation page.

User Forums

The Seam 3 user forums can be found at http://www.seamframework.org/Community/Seam3Users.

IRC

The Seam community is very active on IRC. Join us on the #seam or #seam-dev channels on Freenode to chat with the Seam developers. Find out more on the Seam Chat page.

Tooling

The Seam distribution comes bundled with Seam Forge, which replaces the seam-gen tool that was part of earlier versions of Seam. Forge is a rapid application development tool for Java EE6, which provides many productivity-enhancing features.

JBoss Tools 3.2 also supports Seam 3 development with its excellent CDI tooling. Some of the new features of Seam 3 are not yet covered, but are on the roadmap for JBoss Tools 3.3. You can find an informative walkthrough of the CDI tooling features here.

GWT

GWT support for CDI is provided by Errai. Please refer to the Errai reference documentation for details on integrating your GWT-based application with a CDI-based backend.

Acknowledgements

The Seam development team consists of a small team of full-time developers, plus a rapidly growing number of community contributors! Many of the modules in Seam 3 are led by community members who love and believe in Open Source software. Their ambition, innovation and ideas have made this important milestone possible! The entire Seam community should recognize and appreciate them for their dedication to the project, which is very much a collective community effort. While there are too many names to mention individually in this post, the full list of Seam contributors can be found here.

The above article is copied verbatim from Seam 3.0.0 Final announcement.

Autocompletion of JSF/CDI Managed Beans in JBoss Tools

Current JBoss Tools 3.2 (Eclipse IDE plugin for developing Java EE web applications) is not yet able to show JSF 2.0 managed beans annotated with @ManagedBean.

For example, the code below will load just fine with JSF 2.0, but JBoss Tools will "ignore" it:

import javax.faces.bean.ManagedBean;

import javax.faces.bean.SessionScoped;

@ManagedBean(name="refillManager")

@SessionScoped

public class RefillManager {

When you type the following in the Facelets XHTML template editor, you will not get a code assist hint for refillManager bean :

<h:dataTable value="#{refillManager.refills}">

However there is an alternative, which is actually a better one anyway. (hint: why use JSF-only Managed Beans when you have CDI beans that you can use everywhere?)

Use CDI's @Named annotation :

import java.io.Serializable;

import javax.enterprise.context.SessionScoped;

import javax.inject.Named;

@SuppressWarnings("serial")

@Named("refillCdi")

@SessionScoped

public class RefillCdi implements Serializable {

Now this CDI bean will be detected by JBoss Tools and will show up in autocompletion popup.

To activate CDI (Java Context and Dependency Injection) in a Java EE 6 web application, create an empty file named WEB-INF/beans.xml and you're done. :-) JBoss Tools also has excellent support for CDI.

JBoss AS default Administrator username & password

As of JBoss Application Server 6.0.0.Final, the default administrator password is :

Username: admin

Password: admin

You can access JBoss AS admin console from:

http://127.0.0.1:8080/admin-console

Define the Datasources (persistence databases) with JNDI Names in: Servers > JBoss AS 6 (default) > Resources > Datasources > Local Tx Datasources.

How to Set Context Path of Java EE/Web Application in JBoss App Server

If your web application is packaged as a WAR file then you can create jboss-web.xml under WEB-INF folder of WAR file and specify the context-root in jboss-web.xml like this :

<jboss-web>   <context-root>MyWebAppContext</context-root> </jboss-web>

If your application is packaged as an EAR file then you can specify context-root in META-INF/application.xml of EAR like this

<module>     <web>       <web-uri>MyWAR.war</web-uri>       <context-root>MyWebAppContext</context-root>     </web>   </module>

Source: http://stackoverflow.com/questions/2046604/context-path-in-jboss