Deployment unit runtime-name - must it have a packaging type suffix?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Deployment unit runtime-name - must it have a packaging type suffix?

Jaikiran Pai-2
In context of this[1] forum thread, is runtime-name expected/mandated to
include even the packaging type suffix (.war, .ear etc) or can it be any
name? For example, for a deployment foo.war, is it valid to have it
deployed with a runtime-name "bar"? Or should it be bar.war?

What's happening in this case is that there are deployment unit
processors which identify the "type"[2] of the deployment based on the
deploymentUnit.getName() and in the absence of the suffix, end up not
recognizing the type of the deployment unit which then cascades into
issues like the one in that thread, where the WEB-INF/classes isn't
added as a resource root to the module of the deployment unit, since it
wasn't considered a WAR type deployment.


[1] https://developer.jboss.org/thread/276899

[2]
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/deployment/WarDeploymentInitializingProcessor.java#L46

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Brian Stansberry
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 Thu, Jan 4, 2018 at 10:44 PM, Jaikiran Pai <[hidden email]> wrote:
In context of this[1] forum thread, is runtime-name expected/mandated to
include even the packaging type suffix (.war, .ear etc) or can it be any
name? For example, for a deployment foo.war, is it valid to have it
deployed with a runtime-name "bar"? Or should it be bar.war?

What's happening in this case is that there are deployment unit
processors which identify the "type"[2] of the deployment based on the
deploymentUnit.getName() and in the absence of the suffix, end up not
recognizing the type of the deployment unit which then cascades into
issues like the one in that thread, where the WEB-INF/classes isn't
added as a resource root to the module of the deployment unit, since it
wasn't considered a WAR type deployment.


[1] https://developer.jboss.org/thread/276899

[2]
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/deployment/WarDeploymentInitializingProcessor.java#L46

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

David Lloyd-2
On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
<[hidden email]> 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.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Brian Stansberry

On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <[hidden email]> wrote:
On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
<[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Stuart Douglas


On Sat, Jan 6, 2018 at 2:06 AM, Brian Stansberry <[hidden email]> wrote:

On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <[hidden email]> wrote:
On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
<[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

David Lloyd-2
On Sun, Jan 7, 2018 at 7:37 PM, Stuart Douglas
<[hidden email]> wrote:

> On Sat, Jan 6, 2018 at 2:06 AM, Brian Stansberry
> <[hidden email]> wrote:
>> On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <[hidden email]>
>> wrote:
>>>
>>> On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
>>> <[hidden email]> 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.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Brian Stansberry
On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> wrote:
On Sun, Jan 7, 2018 at 7:37 PM, Stuart Douglas
<[hidden email]> wrote:
> On Sat, Jan 6, 2018 at 2:06 AM, Brian Stansberry
> <[hidden email]> wrote:
>> On Fri, Jan 5, 2018 at 8:43 AM, David Lloyd <[hidden email]>
>> wrote:
>>>
>>> On Fri, Jan 5, 2018 at 8:20 AM, Brian Stansberry
>>> <[hidden email]> 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.


I'm confused now. :) 


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

David Lloyd-2
On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
<[hidden email]> wrote:
> On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> 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.


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Brian Stansberry
On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <[hidden email]> wrote:
On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
<[hidden email]> wrote:
> On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> 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.

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

David Lloyd-2
On Mon, Jan 8, 2018 at 10:34 AM, Brian Stansberry
<[hidden email]> wrote:

>
> On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <[hidden email]> wrote:
>>
>> On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
>> <[hidden email]> wrote:
>> > On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Jaikiran Pai-2
In reply to this post by Brian Stansberry

On 08/01/18 10:04 PM, Brian Stansberry wrote:
On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <[hidden email]> wrote:
On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
<[hidden email]> wrote:
> On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> 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.
So it looks like there's no easy way to either mandate the suffix for runtime name, either as a new param or for the value of runtime-name param (backward compatibility issues), nor is there a credible way to get access or infer the suffix of the deployment for managed deployments.


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.
I suspect it was the EJB JNDI name requirements, which rely on the deployment's suffix (.ear specifically) to decide whether or not to use a "app-name" portion in the JNDI name for the EJB [1]. So yes, currently, runtime-name without a suffix affects this semantics too. I guess, given how rarely anyone has reported this so far, not many use runtime-name without a (proper) suffix.

[1] https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbJndiBindingsDeploymentUnitProcessor.java#L111

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Deployment unit runtime-name - must it have a packaging type suffix?

Jaikiran Pai-2
In reply to this post by Brian Stansberry

On 08/01/18 10:04 PM, Brian Stansberry wrote:
On Mon, Jan 8, 2018 at 10:08 AM, David Lloyd <[hidden email]> wrote:
On Mon, Jan 8, 2018 at 9:41 AM, Brian Stansberry
<[hidden email]> wrote:
> On Mon, Jan 8, 2018 at 9:25 AM, David Lloyd <[hidden email]> 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.
So it looks like there's no easy way to either mandate the suffix for runtime name, either as a new param or for the value of runtime-name param (backward compatibility issues), nor is there a credible way to get access or infer the suffix of the deployment for managed deployments.


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.
I suspect it was the EJB JNDI name requirements, which rely on the deployment's suffix (.ear specifically) to decide whether or not to use a "app-name" portion in the JNDI name for the EJB [1]. So yes, currently, runtime-name without a suffix affects this semantics too. I guess, given how rarely anyone has reported this so far, not many use runtime-name without a (proper) suffix.

[1] https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbJndiBindingsDeploymentUnitProcessor.java#L111

-Jaikiran

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev