&quot;thomas.diesler(a)jboss.com&quot; wrote : If I remember correctly, we started of with the requirement that bundles can be deployed in any order. | | I now made this configurable | | | | <!-- | | If set to 'true' bundles can be deployed in any order. Deployed bundle will get started when their dependencies can be resolved. | | If set to 'false' bundles must be deployed in the order that is required to start them. | | --> | | <entry><key>org.jboss.osgi.deferred.start</key><value>true</value></entry> | | | | If you set this to 'false' the dependency item is used and deployed bundles are expected to get resolved so that the start/stop deployer can start the bundle. | | In case the bundle cannot get resolved you will get an exception (with the deployers in jboss-5.0.1) | If you don't want the exception then you need to control the "required state" of the deployment such that it doesn't move to "Installed" and instead remains the unresolved state (Described?). There already is a method to change the "required state" of an existing deployment DeployerClient.change(deploymentName, DeploymentState); but there's nothing currently that lets you set it at initial deployment, e.g. something like DeployerClient.deploy(Deployment, DeploymentState); // DOES NOT EXIST anonymous wrote : | I definitely agree with you, if MainDeployerImpl.checkComplete | would not throw an exception we could always use the DI based approach. | | | | 15:15:08,642 WARN [MainDeployer] Failed to deploy: file:/.../jbosgi38-bundleB.jar | | org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): | | | | DEPLOYMENTS MISSING DEPENDENCIES: | | Deployment "vfszip:/.../jbosgi38-bundleB.jar/" is missing the following dependencies: | | Dependency "<UNKNOWN jbosgi38-bundleB>" (should be in state "ClassLoader", but is actually in state "** UNRESOLVED Bundle: jbosgi38-bundleB [10] **") | | | | DEPLOYMENTS IN ERROR: | | Deployment "<UNKNOWN jbosgi38-bundleB>" is in error due to the following reason(s): ** UNRESOLVED Bundle: jbosgi38-bundleB [10] ** | | | | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993) | | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939) | | at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:869) | | at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:858) | | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:833) | | | | Perhaps, we can continue the discussion on the topic of what to do with that exception. Should it be thrown or should there be a warning instead? | | In case an exception is no longer thrown it would change the behaviour of | | | | MainDeployer.deploy(URL) | | | | on the client side. | | In case the behaviour stays unchanged (i.e. MainDeployerImpl.checkComplete throw an exception) the client is forced to deploy the bundles in the correct order, which contradicts our initial requirement. | | No. MainDeployerMBean.deploy(url) is a convenience methods on the OLD api that just does: Deployment deployment = new VFSDeployment(url); DeployerClient.addDeployment(deployment); DeployerClient.process(); DeployerClient.checkComplete(deployment); If you need more control, use the more detailed protocol on the NEW api. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215328#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...