On Mon, Jan 8, 2018 at 10:34 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <david.lloyd(a)redhat.com> wrote:
>
> On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
> <brian.stansberry(a)redhat.com> wrote:
> > On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <david.lloyd(a)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.
OK, I was assuming the "name" attribute would always correspond to the
"real" file name but I guess that's not always going to be the case.
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.
This is beyond my recollection.
--
- DML