[wildfly-dev] Deployment unit runtime-name - must it have a packaging type suffix?

Brian Stansberry brian.stansberry at redhat.com
Fri Jan 5 10:06:26 EST 2018


On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <david.lloyd at redhat.com> wrote:

> On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> > In practice the suffix is required. The deployment unit processors need
> to
> > know whether they are interested in the deployment, and in the end that
> gets
> > back to some DUP or other checking the suffix. The alternative would be
> DUPs
> > speculatively digging into the deployment, checking for deployment
> > descriptors or annotations and the like and that would be more expensive,
> > likely buggy (e.g. false positives when some class in the classpath
> includes
> > an annotation not relevant to the deployment) and could mess up some use
> > cases where we want to defer classloading.
>
> Another alternative is for an early processor to identify the type,
> tag it on to the deployment context, and then we modify all other DUPs
> to use that information.  It seems pretty fragile to rely on the name,
> particularly if that mechanism allows the "type" of deployment to
> change in mid-deploy.
>

I agree; if it's not done that way now, it should be. My *impression* is
the general pattern was the way you describe, i.e. for each significant
type some early DUP determines it's a relevant type and attaches some stuff
and then later ones rely on the attachments. But my impression could very
well be wrong in some or many cases. I haven't done much DUP work beyond
code reviews or simple fixes since the AS 7.0 days.

But that early processor still needs a way to identify type and I think
that comes down to the suffix.

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180105/535f40fd/attachment.html 


More information about the wildfly-dev mailing list