-
1. Re: Current behavior of DeploymentUnit.getAttachment
starksm64 Nov 12, 2006 5:05 PM (in response to starksm64)For now I just added a helper class that provides the desired child to parent search logic:
package org.jboss.deployers.plugins.deployers.helpers; import org.jboss.deployers.spi.deployer.DeploymentUnit; import org.jboss.deployers.spi.structure.DeploymentContext; /** * Search a DeploymentUnit structure from child to parent for a matching * attachment. * * @author Scott.Stark@jboss.org * @version $Revision:$ */ public class AttachmentLocator { static public Object search(DeploymentUnit unit, String name) { ... } static public <T> T search(DeploymentUnit unit, String name, Class<T> expectedType) { ... } static public <T> T search(DeploymentUnit unit, Class<T> type) { ... } }
-
2. Re: Current behavior of DeploymentUnit.getAttachment
adrian.brock Nov 13, 2006 7:55 AM (in response to starksm64)The problem is one of leakage when the order of processing attachments
is not defined.
e.g. More explicitly, imagine an ear that contains an ear
where the inner ear doesn't have an application.xml
it would see the application.xml of the containing ear.
This is why I described the current behaviour as a hack.
It only works because the component deployers are at the end
and they only process the specific component attachments/metadata
So there is no deployer that will look at a component and reprocess the parent's
metadata. -
3. Re: Current behavior of DeploymentUnit.getAttachment
starksm64 Nov 13, 2006 3:14 PM (in response to starksm64)Right, but we need to have a distinction between resource visibility and hierarchical metadata. Until we get aligned on metadata being a more properly defined aspect of the vdf we kind of have a free for all in terms of who is doing what in the processing of deployments.