On Sat, Jan 6, 2018 at 2:06 AM, Brian Stansberry <brian.stansberry@redhat.com> wrote:

On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <david.lloyd@redhat.com> wrote:
On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
<brian.stansberry@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.

Yes, various early DUP's call org.jboss.as.ee.structure.DeploymentTypeMarker#setType to set the deployment type, but it is identified via suffix. 

As most deployment descriptors are optional there is no 100% reliable way of identifying this other than the suffix.

Stuart
 

--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev