[tony.herstell1]

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.InputStream;

import java.util.logging.Logger;

import javax.annotation.Resource;

import javax.ejb.Stateless;

import javax.jcr.AccessDeniedException;

import javax.jcr.Binary;

import javax.jcr.Credentials;

import javax.jcr.ItemExistsException;

import javax.jcr.LoginException;

import javax.jcr.Node;

import javax.jcr.NodeIterator;

import javax.jcr.PathNotFoundException;

import javax.jcr.RepositoryException;

import javax.jcr.Session;

import javax.jcr.SimpleCredentials;

import javax.jcr.UnsupportedRepositoryOperationException;

import javax.jcr.ValueFormatException;

import javax.jcr.lock.LockException;

import javax.jcr.nodetype.ConstraintViolationException;

import javax.jcr.nodetype.NoSuchNodeTypeException;

import javax.jcr.query.Query;

import javax.jcr.query.QueryManager;

import javax.jcr.query.QueryResult;

import javax.jcr.version.VersionException;

// Leverage EJB to get Transactional Support

@Stateless

public class RepositoryServiceImpl implements RepositoryService {

    private Logger logger = Logger.getLogger(RepositoryServiceImpl.class.getName());

    /*-

     * Use JNDI to look up a repository (As shown here)

     * OR

     *  look up the javax.jcr.RepositoryFactory implementations, and use them to ask for a repository given a set of parameters;

     *      the first factory to understand the parameters will return a Repository instance

     * Map<String,String> parameters = ...

     * Repository repository = null;

     *  for (RepositoryFactory factory : ServiceLoader.load(RepositoryFactory.class)) {

     *      repository = factory.getRepository(parameters);

     *      if (repository != null) break;

     *  }

     * 

     * 

     *  Setup in JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7 JBoss7

     * 

     *  Add line to MANIFEST.MF in webapp/META-INF

     *     Dependencies: javax.jcr, org.modeshape.jcr.api export services, org.modeshape export services

     *    

     *  Overlay Jboss with the ModeShape JBoss 7.x Overlay and set JBoss to use the standalone-modeshape.xml config file and edit it:

     *   <cache-container name="modeshape" default-cache="xx-repository">

     *      <local-cache name="xx-repository">

     *          <transaction mode="NON_XA"/>

     *          <file-store relative-to="jboss.server.data.dir" path="modeshape/store/xx-repository" passivation="false" purge="false"/>

     *      </local-cache>

     *      ...

     *      </cache-container>

     *

     *  <subsystem xmlns="urn:jboss:domain:modeshape:1.0">

     *      <repository name="sample"/>

     *      <repository name="xx-repository"/>

     *      ...

     *       

     */

    @Resource(mappedName = "java:/jcr/xx-repository")

    private javax.jcr.Repository repository;

[hchiorean]

Thanks for the code samples Tony. I'll try to replicate this problem in our test environment and get back to you.

[hchiorean]

Update 1: I've taken the Repository, RepositoryImpl and RepositoryServiceTest classes and placed them in our integration tests package, updated the RepostioryServiceTest class to run in Arquillian (by enabling the commented code and adding the MANIFEST.MF to the Deployer) and...everything runs fine.

I've even updated the test to: prepare a repository, create some organizations and drop it.

The next step is to build the war file and try to deploy it in a fresh AS7 container.

[hchiorean]

I've traced the cause of the problem (using the war file inside an overlayed AS7 instance):

• if you take a look inside the WEB-INF/lib folder of the built war, you'll notice (amongst others): lucene-core, lucene-regex, hibernate-search, infinispan jars. These are brought in by Maven, transitively from the modeshape-jcr dependency.
• from an AS7 perspective, each deployed war file has its own (almost independent) class loader
• Hibernate Search's: ClassLoaderHelper#classForName(String name, ClassLoader classLoader) tries first to load a class using the Thread Context Class Loader and if that works, returns the loaded class. This isn't AS7 friendly at all, but this implementation has been discussed and agreed upon by the HS guys here: https://hibernate.onjira.com/browse/HSEARCH-1060

What's happening in this case, is that one Similarity class is loaded from AS7's hibernate module, while the other is loaded from the war's WEB-INF/lib/lucene-core. I think that this is only the surface, because given all the jars that are atm in WEB-INF/lib, there might be other TCCL issues down the line, in one of the other libraries.

So, given that I doubt that HSearch will change this, the only solution is to update your Maven pom.xml and exclude at least the dependencies mentioned above. In reality, you'd have to look if there aren't others which are already provided as part of AS7 as well.

Hope this helps.

Editor: Our documentation now talks about how to properly specify dependencies in your Maven build to avoid this problem.

[tony.herstell1]

Sounds like great progress.

What was the deployed code to add the manifest file?

[tony.herstell1]

Oh crickey.

Well done for finding that.

It sound like a mission to figure out all the dependencies.

[hchiorean]

Tony Herstell wrote:

Sounds like great progress.

What was the deployed code to add the manifest file?

The deployer looked like this (RepositoryServiceTest):

    @Deployment

    public static JavaArchive createDeployment() {

        JavaArchive jar = ShrinkWrap.create(JavaArchive.class).addClass(RepositoryServiceImpl.class)

                                    .addClass(RepositoryService.class)

                                    .addAsResource(new File("src/test/resources/apiary-manager-logo-tall.png"))

                                    .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");

        // Add our custom Manifest, which has the additional Dependencies entry ...

        jar.setManifest(new File("src/main/webapp/META-INF/MANIFEST.MF"));

        System.out.println(jar.toString(true));

        return jar;

    }

I added the png to be able to call createOrganisation

[hchiorean]

Tony Herstell wrote:

Oh crickey.

Well done for finding that.

It sound like a mission to figure out all the dependencies.

Just discussed this with Randall and he has a good point: the easiest way to solve this is to mark the modeshape-jcr dependency as "provided" rather than compile.

Editor: Our documentation now shows how to do this.

[tony.herstell1]

> I've traced the cause of the problem (using the war file inside an overlayed AS7 instance):

Yes this was the correct answer.

The only exceptions I am seeing are the infinispan EOF errors (see another thread and thread raised in Infinispan project).

This appeared to have worked in the pom:

        <!--  Depend on the ModeShape's public API (which depends on the JCR API), -->

        <!--   using provided scope as these are included in JBoss AS 7 subsystem -->

        <dependency>

            <groupId>org.modeshape</groupId>

            <artifactId>modeshape-jcr-api</artifactId>

            <version>3.0.0.Beta1</version>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>javax.jcr</groupId>

            <artifactId>jcr</artifactId>

            <version>2.0</version>

        </dependency>

[rhauch]

This appeared to have worked in the pom:

        <!--  Depend on the ModeShape's public API (which depends on the JCR API), -->

        <!--   using provided scope as these are included in JBoss AS 7 subsystem -->

        <dependency>

            <groupId>org.modeshape</groupId>

            <artifactId>modeshape-jcr-api</artifactId>

            <version>3.0.0.Beta1</version>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>javax.jcr</groupId>

            <artifactId>jcr</artifactId>

            <version>2.0</version>

        </dependency>

You're correct that you need to include the JCR API (since your code is using it directly), but it needs to be "provided" scope or else Maven will include the JCR API JAR in your WAR file, and that could lead to similar classloader issues as those exhibited earlier.

BTW, I'll correct the documentation.