Re: [jboss-dev-forums] [Design the new POJO MicroContainer] - Checking DeploymentContext for failures
10:07 a.m.
Since jboss.org is down I'll answer here...
On Wed, 2007-11-14 at 10:48 -0500, alesj wrote:
Regarding http://jira.jboss.com/jira/browse/JBMICROCONT-187.
What's the best way to get failing ControllerContexts that belong to
DeploymentContext param?
This is what I came up currently:
| protected final void checkComplete(
| DeploymentContext context,
| Map<String, Throwable> contextsInError,
| Map<String, Set<MissingDependency>>
contextsMissingDependencies,
| Set<ControllerContext> notInstalled,
| List<ControllerState> states)
| {
| Attachments attachments = context.getDeploymentUnit();
| if (attachments != null && checkers != null)
| {
| for (AttachmentChecker checker : checkers)
| {
| ControllerContext cc = checker.getControllerContext(controller,
attachments);
| if (cc != null)
| {
| if (cc.getState().equals(cc.getRequiredState()) == false &&
notInstalled.contains(cc))
| {
| checkControllerContext(cc, contextsInError,
contextsMissingDependencies, states);
| }
| }
| }
| }
| List<DeploymentContext> children = context.getChildren();
| if (children != null && children.isEmpty() == false)
| {
| for(DeploymentContext child : children)
| checkComplete(child, contextsInError, contextsMissingDependencies,
notInstalled, states);
| }
| }
|
where AttachmentChecker looks like this, e.g. Bean checker:
| public abstract class AbstractAttachmentChecker<T> implements
AttachmentChecker
| {
| private Class<T> type;
|
| protected AbstractAttachmentChecker(Class<T> type)
| {
| if (type == null)
| throw new IllegalArgumentException("Null type.");
| this.type = type;
| }
|
| public ControllerContext getControllerContext(Controller controller, Attachments
attachments)
| {
| T attachment = attachments.getAttachment(type);
| if (attachment != null)
| return getControllerContext(controller, attachment);
|
| return null;
| }
|
| protected abstract ControllerContext getControllerContext(Controller controller, T
attachment);
| }
|
| public class BeanAttachmentChecker extends
AbstractAttachmentChecker<BeanMetaData>
| {
| public BeanAttachmentChecker()
| {
| super(BeanMetaData.class);
| }
|
| protected ControllerContext getControllerContext(Controller controller,
BeanMetaData attachment)
| {
| return controller.getContext(attachment.getName(), null);
| }
| }
|
Another checker implementations would include ServiceAC (mbeans) and ControllerContextAC
(OSGi deployments).
Any others?
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:37 a.m.
New subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Checking DeploymentContext for failures
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
10:50 a.m.
New subject: [jboss-dev-forums] [Design the new POJO MicroContainer] - Checking DeploymentContext for failures
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
6252
days inactive
6252
days old
jboss-development@lists.jboss.org
2 comments
2 participants
participants (2)
-
Adrian -
Ales Justin