You already know the context name of the deployment controller
context and how to retrieve it (assuming it has got as
far as creating it :-)
It's an implementation detail of the class you are changing.
The ones you don't know about are those created by
the deployers, i.e. the [Kernel|Service]ControllerContext
You just need those deployers that create them to record
them somewhere for you to check.
Looking at the attachments can even be misleading, because
the attachment may exist (created by the parsing
deployer) but it never got as far as actually
registering them in the controller.
Or maybe the deployer tried to register it, but found it
was a duplicate (already registered).
So you'd actually be looking at the wrong context!
Besides it's over engineered for the purpose.
You just want a set of names that were definitely
registered in the controller for that deployment.
Once you have those, you also need to recurse through the
DependencyInfo looking to find the possible root cause
for failed contexts.
On Wed, 2007-11-14 at 17:37 +0100, Ales Justin wrote:
How does this take care of DeploymentControllerContext?
Since it's not a part of Deployers.
Or just treating this ControllerContext lookup differently?
Via AttachmentCreator this was transparent. :-)
public class ControllerContextAttachmentChecker extends
AbstractAttachmentChecker<ControllerContext>
{
public ControllerContextAttachmentChecker()
{
super(ControllerContext.class);
}
protected ControllerContext getControllerContext(Controller
controller, ControllerContext attachment)
{
return attachment;
}
}
> You don't need to do anything so complicated.
>
> You just need the relevant deployers to record the context names in some
> well defined place, e.g. the Deployment{Unit|Context}
>
> It's probably important enough to use a special method rather than
> an attachment.
>
> e.g.
>
> public class BeanMetaDataDeployer extends
> AbstractSimpleRealDeployer<BeanMetaData>
> {
> /** The kernel controller */
> private final KernelController controller;
>
> /**
> * Create a new BeanDeployer.
> *
> * @param kernel the kernel
> * @throws IllegalArgumentException for a null kernel
> */
> public BeanMetaDataDeployer(Kernel kernel)
> {
> super(BeanMetaData.class);
> if (kernel == null)
> throw new IllegalArgumentException("Null kernel");
> controller = kernel.getController();
> setComponentsOnly(true);
> }
>
> @Override
> public void deploy(DeploymentUnit unit, BeanMetaData deployment)
> throws DeploymentException
> {
> KernelControllerContext context = new
> AbstractKernelControllerContext(null, deployment, null);
> try
> {
> controller.install(context);
> + unit.addControllerContextName(deployment.getName());
> }
> catch (Throwable t)
> {
> throw DeploymentException.rethrowAsDeploymentException("Error
> deploying: " + deployment.getName(), t);
> }
> }
>
> @Override
> public void undeploy(DeploymentUnit unit, BeanMetaData deployment)
> {
> + unit.removeControllerContextName(deployment.getName());
> controller.uninstall(deployment.getName());
> }
> }
>
> In practice, the component deployment unit name should be the context
> name.
> This is at least true for the POJO and Service deployers.
>
> So you could just add it as some kind of easy declaration in the
> constructor:
>
> public BeanMetaDataDeployer(Kernel kernel)
> {
> super(BeanMetaData.class);
> if (kernel == null)
> throw new IllegalArgumentException("Null kernel");
> controller = kernel.getController();
> setComponentsOnly(true);
> // obviously some shorter property name ;-)
> setComponentDeploymentNameIsControllerContextName(true);
> }
>
> and handle it in the abstract classes:
>
> deploy(...); // will throw an error if not registered in the
> controller
> if (unit.isComponent() &&
> isComponentDeploymentNameControllerContextName())
> addComponentContextName(unit.getSimpleName());
>
>
>> View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104658#...
>>
>> Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...
>> _______________________________________________
>> jboss-dev-forums mailing list
>> jboss-dev-forums(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development --
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx