Steps to reproduce:
      1) inject a Deployer via @ArquillianResource
      2) declare a deployment as managed=false, use the deployer to deploy artifacts to a managed container
      3) run a test method that operates on the deployment
      4) check that classes inside the test method have the same classloader as the test class itself (see the code below where I call cache.getClass().getClassLoader())
      5) this does not happen when the deployment is managed=true and deployer API is NOT used. In this case, the classes have a different class loader

      In the test below, I tried to load different versions of Infinispan in two deployments and test backward compatibility. However, due to this class loading issue the Infinispan classes are of the latest version regardless of libraries bundled in the WAR. This is probably due to the fact that the Maven test module has the latest Infinispan libraries defined in <dependencies> while the older version is downloaded separately via Maven dependency plugin.

      package com.jboss.datagrid.test.backwardcompatibility;
      
      
      @RunWith(Arquillian.class)
      public class SingleFileStoreBackwardCompatibilityIT {
      
          private DefaultCacheManager dfc;
          private String cacheName = "testCache";
      
          private static final String OLD_ISPN = "dep1_with_old_ispn";
          private static final String NEW_ISPN = "dep2_with_new_ispn";
      
          private static Map<String, String> storedMap;
      
          @ArquillianResource
          Deployer deployer;
      
          @Deployment(name = OLD_ISPN, testable = true, managed = true, order=1)
          @TargetsContainer("container1")
          public static WebArchive createDeploymentOld() {
              WebArchive jar = DeploymentBuilder.createTestArchiveWithPreviousJDG("test1.war", "previous");
              System.out.println("ClassLoader: " + SingleFileStoreBackwardCompatibilityIT.class.getClassLoader());
              return jar;
          }
      
          @Deployment(name = NEW_ISPN, testable = true, managed = true, order=2)
          @TargetsContainer("container2")
          public static WebArchive createDeploymentNew() {
              WebArchive jar = DeploymentBuilder.createTestArchive("test2.war", "current");
              return jar;
          }
      
          private DefaultCacheManager configureCacheManager(boolean clearCacheStore) throws Exception {
              GlobalConfiguration glob = new GlobalConfigurationBuilder().nonClusteredDefault()
                      .globalJmxStatistics().allowDuplicateDomains(true).
                              build();
              ConfigurationBuilder c = new ConfigurationBuilder();
              c.clustering().cacheMode(CacheMode.LOCAL);
      
              File tmpStore = new File("/tmp/cache/" + cacheName + ".dat");
              if (clearCacheStore && tmpStore.exists()) {
                  tmpStore.delete();
              }
              c.persistence().passivation(false).addSingleFileStore().purgeOnStartup(false).location("/tmp/cache/");
              Configuration cnf = c.build();
              DefaultCacheManager manager = new DefaultCacheManager(glob);
      
              manager.defineConfiguration(cacheName, cnf);
              return manager;
          }
      
          @Test
          @OperateOnDeployment(OLD_ISPN)
          @InSequence(1)
          public void testStoreWithOldJDG() throws Exception {
              deployer.deploy(OLD_ISPN);
              dfc = configureCacheManager(true);
              dfc.start();
              Cache<Object, Object> cache = dfc.getCache(cacheName);
              System.out.println("Version: " + cache.getVersion());
              System.out.println("ClassLoader: " + cache.getClass().getClassLoader());
              storedMap = new HashMap<String, String>();
              storedMap.put("k", "v");
              cache.put("mapKey", storedMap);
              dfc.stop();
              deployer.undeploy(OLD_ISPN);
          }
      
          @Test
          @OperateOnDeployment(NEW_ISPN)
          @InSequence(2)
          public void testReadWithNewJDG() throws Exception {
              deployer.deploy(NEW_ISPN);
              dfc = configureCacheManager(false);
              dfc.start();
              Cache<Object, Object> cache = dfc.getCache(cacheName);
              System.out.println("ClassLoader: " + cache.getClass().getClassLoader());
              System.out.println("Version: " + cache.getVersion());
              assertEquals(storedMap, cache.get("mapKey"));
              dfc.stop();
              deployer.undeploy(NEW_ISPN);
          }
      
      }
      
      

            [ARQ-1937] Class loading issue with injected deployer

            Thanks, filed ARQ-2012

            Ladislav Thon added a comment - Thanks, filed ARQ-2012

            lthon@redhat.com Yes, please do.

            Aslak Knutsen added a comment - lthon@redhat.com Yes, please do.

            Do you want me to file a new JIRA for this?

            Ladislav Thon added a comment - Do you want me to file a new JIRA for this?

            Good catch!

            Aslak Knutsen added a comment - Good catch!

            Hi,
            yeah, I have to admit that the warning wasn't good idea - I will fix it.

            Matous Jobanek added a comment - Hi, yeah, I have to admit that the warning wasn't good idea - I will fix it.

            After looking at Arquillian code and my project where I'm getting the warnings, I need to clarify my previous comment – I'm only getting warnings when there is no @Deployment at all. This might be a corner case, but I actually have quite a lot of tests like that

            Ladislav Thon added a comment - After looking at Arquillian code and my project where I'm getting the warnings, I need to clarify my previous comment – I'm only getting warnings when there is no @Deployment at all. This might be a corner case, but I actually have quite a lot of tests like that

            I'd like to understand more about this.

            In my tests, I'm often intentionally setting my @Deployment to testable = false, or I have no @Deployment at all, with the intention that the test will run as client. I never use @RunAsClient, simply because it's superfluous. Yet I started to get warnings now.

            Am I absolutely positively supposed to use @RunAsClient when I want the test to run as client?

            Ladislav Thon added a comment - I'd like to understand more about this. In my tests, I'm often intentionally setting my @Deployment to testable = false , or I have no @Deployment at all, with the intention that the test will run as client. I never use @RunAsClient , simply because it's superfluous. Yet I started to get warnings now. Am I absolutely positively supposed to use @RunAsClient when I want the test to run as client?

            Aslak Knutsen added a comment - Pushed upstream https://github.com/arquillian/arquillian-core/commit/96ad96f345e06c11e04eef94d0a3b4f5f23f684c

            Hi,
            in general, when there is no running deployment the current implementation launches a test method on the client side - no matter if the annotation @RunAsClient is not declared or the parameter testable is set to true [1]. So the question might be if this can be allowed at all - something similar to Aslak's suggestion, but more general. I do not see this approach as a good solution - too cruel , I believe that some log warning, or changed javadoc could be sufficient - like this one: [2]. WDYT?

            [1] https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/RunModeUtils.java#L50
            [2] https://github.com/MatousJobanek/arquillian-core/commit/42a2528cb65f540c5b6114deec338a1796f58901

            Matous Jobanek added a comment - Hi, in general, when there is no running deployment the current implementation launches a test method on the client side - no matter if the annotation @RunAsClient is not declared or the parameter testable is set to true [1]. So the question might be if this can be allowed at all - something similar to Aslak's suggestion, but more general. I do not see this approach as a good solution - too cruel , I believe that some log warning, or changed javadoc could be sufficient - like this one: [2]. WDYT? [1] https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/RunModeUtils.java#L50 [2] https://github.com/MatousJobanek/arquillian-core/commit/42a2528cb65f540c5b6114deec338a1796f58901

            Your suggestion sounds good. And yes, the confusing part was that I can operate on deployment when it's not deployed.

            Martin Gencur added a comment - Your suggestion sounds good. And yes, the confusing part was that I can operate on deployment when it's not deployed.

              aslak@redhat.com Aslak Knutsen
              mgencur Martin Gencur
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: