Your summary is correct. A URL injection is not proxied in any way, so it needs to be known before injection.

A workaround would be to split up the scenario in multiple Test methods, by makeing the Test Class the full scenario not the Test method and use Test Method Argument injection. e.g. :

public class MyTestCase {

   @Deployment(testable = false, managed = false, name = "my") public static WebArchive create() { ... }

   @ArquillianResource Deployer deployer;

   @Test @InSequence(1)
   public void manualDeploy() {
      deployer.deploy("my");
   }


   @Test @InSequence(2)
   public void shouldXXX(@ArquillianResource URL url) {
      doStuffWith(url)
   }


   @Test @InSequence(3)
   public void manualUnDeploy() {
      deployer.undeploy("my");
   }
}

A manual ArquillianResource API has been dicussed, but not currenlty implemented. That would allow for something like:

public class MyTestCase {

   @Deployment(testable = false, managed = false, name = "my") public static WebArchive create() { ... }

   @ArquillianResource Deployer deployer;

   @ArquillianResource ArquillianResources resources;

   @Test
   public void shouldXXX() {
      deployer.deploy("my");

      URL url = resources.lookup(URL.class)

      deployer.undeploy("my");
   }
}

A deployment can create/expose more Resources then just a single URL even tho URL might be the most common usecase.

JMX connection information, Multiple URLs in a EAR, Multiple URLs in a 'domain server group' deployment etc.

The Deployer could possible chain the ArquillianResources tho, and basically act as a filter to mean this current deployment: e.g.

URL deploymentUrl = deployer.deploy("my").lookup(URL.class)

( or lookup(URL.class, MyServlet.class) or lookup(URL.class, PortalURL.class) )