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.

On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <david.lloyd(a)redhat.com&gt; wrote: > On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry > <brian.stansberry(a)redhat.com&gt; 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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Sun, Jan 7, 2018 at 7:37 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: > On Sat, Jan 6, 2018 at 2:06 AM, Brian Stansberry > <brian.stansberry(a)redhat.com&gt; wrote: >> On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <david.lloyd(a)redhat.com&gt; >> wrote: >>> >>> On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry >>> <brian.stansberry(a)redhat.com&gt; 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. I guess I wasn't too clear. I didn't mean to say there was some other way to detect the type. I meant to say that the type determination should be done *before* the overridden runtime name is applied, not after.

On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <david.lloyd(a)redhat.com&gt; wrote: >> I guess I wasn't too clear. I didn't mean to say there was some other >> way to detect the type. I meant to say that the type determination >> should be done *before* the overridden runtime name is applied, not >> after. > > I'm confused now. :) Isn't this entire thread about the ability to use the "runtime-name" attribute to override the actual file name of the JAR? I'm simply stating that the type probably should be based on the name of the content file, not the runtime-name.

On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com>>wrote: On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: > On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com>> wrote: >> I guess I wasn't too clear.  I didn't mean to say there was some other >> way to detect the type.  I meant to say that the type determination >> should be done *before* the overridden runtime name is applied, not >> after. > > I'm confused now. :) Isn't this entire thread about the ability to use the "runtime-name" attribute to override the actual file name of the JAR? I'm simply stating that the type probably should be based on the name of the content file, not the runtime-name. Gotcha. We don't reliably know the name of the content file. For unmanaged content we should, but for managed content when the user adds the deployment they provide a stream or a url (or in theory a ModelType.BYTES ModelNode). It's possible to add an optional param to the add ops to pass in a suffix and then our standard clients could provide that if they are able to figure it out. But if that wasn't provided it would still be down to the suffix of the runtime name.

I also have a vague memory of some of the EE stuff (i.e. not our DUP code) being driven by suffixes. IOW even if our DUPs didn't need to get type info from the suffix, something in EE might. I don't recall the details of this though; something about default values of EE application and module names. Perhaps the DUPs could be adapted to deal with that, or perhaps not.