8:38 a.m.
Emmanuel Hugonnet has been working on a long requested feature to have
WildFly support "managed exploded deployments." We have a requirements
analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
I just wanted to point that out to the list so anyone interested can
have a look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by
the server/host controller into its internal content repo and then
thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged deployment the
user provides the server with the local FS path to the content and then
the server directly uses that content. All exploded deployments are
unmanaged, as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought on
this are appreciated:
"The explode operation can take an optional path parameter, the value of
which is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to be
exploded.
* This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
* This operation will fail if the content referred to by the path
parameter is already exploded or is not a zip file.
* This operation will fail if any content between the root of the
deployment and the content referred to by the path parameter is an
unexploded archive.
* So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
would fail if thewar.war hadn't previously been exploded."
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:22 a.m.
On 06/10/2016 08:38 AM, Brian Stansberry wrote:
Emmanuel Hugonnet has been working on a long requested feature to
have
WildFly support "managed exploded deployments." We have a requirements
analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
I just wanted to point that out to the list so anyone interested can
have a look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by
the server/host controller into its internal content repo and then
thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged deployment the
user provides the server with the local FS path to the content and then
the server directly uses that content. All exploded deployments are
unmanaged, as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
Hmmm.
Is deployment explosion really an deployer concern, or is it a
deployment provider concern? Consider:
* The deployment provider is the one who will know whether or not
his/her deployment will function correctly with or without exploding.
* The deployment will have been tested in the desired configuration
(exploded or unexploded).
* Making this a deployer/administrator concern means that he/she must
ensure that the extra step(s) taken in development and testing are also
replicated in production.
Wouldn't it make more sense to have some deployment control metadata
(maybe even just a MANIFEST header) that says whether the particular
archive should be exploded?
Also, I don't think it's clear that you always want to explode the outer
archive if an inner archive is to be exploded (I'm not sure that's
necessarily implied by the proposed design, but it certainly would be in
the recursive case). In particular it's definitely useful to explode
WARs inside of EARs that need not be exploded.
Explode!!
(eom)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought on
this are appreciated:
"The explode operation can take an optional path parameter, the value of
which is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to be
exploded.
* This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
* This operation will fail if the content referred to by the path
parameter is already exploded or is not a zip file.
* This operation will fail if any content between the root of the
deployment and the content referred to by the path parameter is an
unexploded archive.
* So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
would fail if thewar.war hadn't previously been exploded."
--
- DML
9:39 a.m.
On 10/06/2016 16:22, David M. Lloyd wrote:
On 06/10/2016 08:38 AM, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
Hmmm.
Is deployment explosion really an deployer concern, or is it a
deployment provider concern? Consider:
* The deployment provider is the one who will know whether or not
his/her deployment will function correctly with or without exploding.
* The deployment will have been tested in the desired configuration
(exploded or unexploded).
* Making this a deployer/administrator concern means that he/she must
ensure that the extra step(s) taken in development and testing are also
replicated in production.
Wouldn't it make more sense to have some deployment control metadata
(maybe even just a MANIFEST header) that says whether the particular
archive should be exploded?
Also, I don't think it's clear that you always want to explode the outer
archive if an inner archive is to be exploded (I'm not sure that's
necessarily implied by the proposed design, but it certainly would be in
the recursive case). In particular it's definitely useful to explode
WARs inside of EARs that need not be exploded.
Explode!!
(eom)
I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a
development environment. so this mecanism is
transparent from the developer point of vuiew.
You have the same functionalities as with the scanner with hopefully a better control over
the deployment management.
Also this means you can develop on a remote server or even on a domain without having to
rebuild the whole archive everytime.
Emmanuel
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
10:06 a.m.
On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
On 10/06/2016 16:22, David M. Lloyd wrote:
> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>> Emmanuel Hugonnet has been working on a long requested feature to have
>> WildFly support "managed exploded deployments." We have a requirements
>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>> I just wanted to point that out to the list so anyone interested can
>> have a look, and comment on this thread or on the document.
>>
>> A managed deployment is one where the user provided content is copied by
>> the server/host controller into its internal content repo and then
>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>> deployments in WildFly are managed. With an unmanaged deployment the
>> user provides the server with the local FS path to the content and then
>> the server directly uses that content. All exploded deployments are
>> unmanaged, as we don't support managed yet.
>>
>> We propose to add 5 new operations to the deployment resource:
>>
>> explode (to convert and archive deployment to exploded)
>
> Hmmm.
>
> Is deployment explosion really an deployer concern, or is it a
> deployment provider concern? Consider:
>
> * The deployment provider is the one who will know whether or not
> his/her deployment will function correctly with or without exploding.
> * The deployment will have been tested in the desired configuration
> (exploded or unexploded).
> * Making this a deployer/administrator concern means that he/she must
> ensure that the extra step(s) taken in development and testing are also
> replicated in production.
>
> Wouldn't it make more sense to have some deployment control metadata
> (maybe even just a MANIFEST header) that says whether the particular
> archive should be exploded?
>
> Also, I don't think it's clear that you always want to explode the outer
> archive if an inner archive is to be exploded (I'm not sure that's
> necessarily implied by the proposed design, but it certainly would be in
> the recursive case). In particular it's definitely useful to explode
> WARs inside of EARs that need not be exploded.
>
> Explode!!
>
> (eom)
I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a
development environment. so this mecanism is
transparent from the developer point of vuiew.
You have the same functionalities as with the scanner with hopefully a better control
over the deployment management.
Also this means you can develop on a remote server or even on a domain without having to
rebuild the whole archive everytime.
So would you use the 'explode' operation in your netbeans plugin, i.e.
start archived and explode? I'm curious if the JBDS guys will.
I suspect it would be used as a convenience; i.e. instead of the tool
initially uploading 100 files, it uploads a zip and explodes it. And
then either way it begins to manipulate the few files that the tool
regards as eligible for update without redeploy (.html, .css, etc.)
Emmanuel
>
>> add-content
>> update-content
>> remove-content
>> read-content
>>
>> There is one "nice-to-have" requirement listed on the doc where
I'm
>> increasingly thinking it needs to be a hard requirement, so thought on
>> this are appreciated:
>>
>>
>> "The explode operation can take an optional path parameter, the value of
>> which is a path within the deployment that should be exploded.
>> * The use case for this is scenarios like an exploded ear that
>> contains an unexploded war, and then the user later wishes the war to be
>> exploded.
>> * This is much closer to a hard requirement if the nice-to-have
>> requirement for recursively exploding is not supported.
>> * This operation will fail if the content referred to by the path
>> parameter is already exploded or is not a zip file.
>> * This operation will fail if any content between the root of the
>> deployment and the content referred to by the path parameter is an
>> unexploded archive.
>> * So,
>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
>> would fail if thewar.war hadn't previously been exploded."
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:18 a.m.
On 10/06/2016 17:06, Brian Stansberry wrote:
On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
>
>
> On 10/06/2016 16:22, David M. Lloyd wrote:
>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>>> Emmanuel Hugonnet has been working on a long requested feature to have
>>> WildFly support "managed exploded deployments." We have a
requirements
>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>>> I just wanted to point that out to the list so anyone interested can
>>> have a look, and comment on this thread or on the document.
>>>
>>> A managed deployment is one where the user provided content is copied by
>>> the server/host controller into its internal content repo and then
>>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>>> deployments in WildFly are managed. With an unmanaged deployment the
>>> user provides the server with the local FS path to the content and then
>>> the server directly uses that content. All exploded deployments are
>>> unmanaged, as we don't support managed yet.
>>>
>>> We propose to add 5 new operations to the deployment resource:
>>>
>>> explode (to convert and archive deployment to exploded)
>>
>> Hmmm.
>>
>> Is deployment explosion really an deployer concern, or is it a
>> deployment provider concern? Consider:
>>
>> * The deployment provider is the one who will know whether or not
>> his/her deployment will function correctly with or without exploding.
>> * The deployment will have been tested in the desired configuration
>> (exploded or unexploded).
>> * Making this a deployer/administrator concern means that he/she must
>> ensure that the extra step(s) taken in development and testing are also
>> replicated in production.
>>
>> Wouldn't it make more sense to have some deployment control metadata
>> (maybe even just a MANIFEST header) that says whether the particular
>> archive should be exploded?
>>
>> Also, I don't think it's clear that you always want to explode the outer
>> archive if an inner archive is to be exploded (I'm not sure that's
>> necessarily implied by the proposed design, but it certainly would be in
>> the recursive case). In particular it's definitely useful to explode
>> WARs inside of EARs that need not be exploded.
>>
>> Explode!!
>>
>> (eom)
>
> I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in
a development environment. so this mecanism is
> transparent from the developer point of vuiew.
> You have the same functionalities as with the scanner with hopefully a better control
over the deployment management.
> Also this means you can develop on a remote server or even on a domain without having
to rebuild the whole archive everytime.
>
So would you use the 'explode' operation in your netbeans plugin, i.e.
start archived and explode? I'm curious if the JBDS guys will.
Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that the
'build' (since the build process it externalized in Netbeans)
will no longer produce an archive but a list of changes.
So I might need to explode the deployment somewhere in time.
I suspect it would be used as a convenience; i.e. instead of the tool
initially uploading 100 files, it uploads a zip and explodes it. And
then either way it begins to manipulate the few files that the tool
regards as eligible for update without redeploy (.html, .css, etc.)
That's also a use case (depending on producing an archive in the first place).
Emmanuel
4:27 p.m.
On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com>
wrote:
On 10/06/2016 17:06, Brian Stansberry wrote:
> On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
>>
>>
>> On 10/06/2016 16:22, David M. Lloyd wrote:
>>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>>>> Emmanuel Hugonnet has been working on a long requested feature to have
>>>> WildFly support "managed exploded deployments." We have a
requirements
>>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497
and
>>>> I just wanted to point that out to the list so anyone interested can
>>>> have a look, and comment on this thread or on the document.
>>>>
>>>> A managed deployment is one where the user provided content is copied
by
>>>> the server/host controller into its internal content repo and then
>>>> thereafter that copy is what is used. I estimate that 99%+ of all
zipped
>>>> deployments in WildFly are managed. With an unmanaged deployment the
>>>> user provides the server with the local FS path to the content and
then
>>>> the server directly uses that content. All exploded deployments are
>>>> unmanaged, as we don't support managed yet.
>>>>
>>>> We propose to add 5 new operations to the deployment resource:
>>>>
>>>> explode (to convert and archive deployment to exploded)
>>>
>>> Hmmm.
>>>
>>> Is deployment explosion really an deployer concern, or is it a
>>> deployment provider concern? Consider:
>>>
>>> * The deployment provider is the one who will know whether or not
>>> his/her deployment will function correctly with or without exploding.
>>> * The deployment will have been tested in the desired configuration
>>> (exploded or unexploded).
>>> * Making this a deployer/administrator concern means that he/she must
>>> ensure that the extra step(s) taken in development and testing are also
>>> replicated in production.
>>>
>>> Wouldn't it make more sense to have some deployment control metadata
>>> (maybe even just a MANIFEST header) that says whether the particular
>>> archive should be exploded?
>>>
>>> Also, I don't think it's clear that you always want to explode the
outer
>>> archive if an inner archive is to be exploded (I'm not sure that's
>>> necessarily implied by the proposed design, but it certainly would be
in
>>> the recursive case). In particular it's definitely useful to explode
>>> WARs inside of EARs that need not be exploded.
>>>
>>> Explode!!
>>>
>>> (eom)
>>
>> I think the main target for explosion scenarios are tools (IDE, build
tools, etc.) in a development environment. so this mecanism is
>> transparent from the developer point of vuiew.
>> You have the same functionalities as with the scanner with hopefully a
better control over the deployment management.
>> Also this means you can develop on a remote server or even on a domain
without having to rebuild the whole archive everytime.
>>
>
> So would you use the 'explode' operation in your netbeans plugin, i.e.
> start archived and explode? I'm curious if the JBDS guys will.
Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that
the 'build' (since the build process it externalized in Netbeans)
will no longer produce an archive but a list of changes.
So I might need to explode the deployment somewhere in time.
I could see this being useful in a scenario where a user launches WildFly
in something like Docker but they want to see changes on static content
without a full redeploy.
If it's all local then it's already possible to do this using an unmanaged
deployment.
>
> I suspect it would be used as a convenience; i.e. instead of the tool
> initially uploading 100 files, it uploads a zip and explodes it. And
> then either way it begins to manipulate the few files that the tool
> regards as eligible for update without redeploy (.html, .css, etc.)
That's also a use case (depending on producing an archive in the first
place).
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
4:41 p.m.
On 6/10/16 4:27 PM, James Perkins wrote:
On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com
<mailto:ehugonne@redhat.com>> wrote:
On 10/06/2016 17:06, Brian Stansberry wrote:
> On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
>>
>>
>> On 10/06/2016 16:22, David M. Lloyd wrote:
>>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>>>> Emmanuel Hugonnet has been working on a long requested feature
to have
>>>> WildFly support "managed exploded deployments." We have a
requirements
>>>> analysis doc for this at
https://developer.jboss.org/docs/DOC-55497 and
>>>> I just wanted to point that out to the list so anyone
interested can
>>>> have a look, and comment on this thread or on the document.
>>>>
>>>> A managed deployment is one where the user provided content is
copied by
>>>> the server/host controller into its internal content repo and then
>>>> thereafter that copy is what is used. I estimate that 99%+ of
all zipped
>>>> deployments in WildFly are managed. With an unmanaged
deployment the
>>>> user provides the server with the local FS path to the content
and then
>>>> the server directly uses that content. All exploded deployments are
>>>> unmanaged, as we don't support managed yet.
>>>>
>>>> We propose to add 5 new operations to the deployment resource:
>>>>
>>>> explode (to convert and archive deployment to exploded)
>>>
>>> Hmmm.
>>>
>>> Is deployment explosion really an deployer concern, or is it a
>>> deployment provider concern? Consider:
>>>
>>> * The deployment provider is the one who will know whether or not
>>> his/her deployment will function correctly with or without
exploding.
>>> * The deployment will have been tested in the desired configuration
>>> (exploded or unexploded).
>>> * Making this a deployer/administrator concern means that he/she
must
>>> ensure that the extra step(s) taken in development and testing
are also
>>> replicated in production.
>>>
>>> Wouldn't it make more sense to have some deployment control
metadata
>>> (maybe even just a MANIFEST header) that says whether the particular
>>> archive should be exploded?
>>>
>>> Also, I don't think it's clear that you always want to explode
the outer
>>> archive if an inner archive is to be exploded (I'm not sure
that's
>>> necessarily implied by the proposed design, but it certainly
would be in
>>> the recursive case). In particular it's definitely useful to
explode
>>> WARs inside of EARs that need not be exploded.
>>>
>>> Explode!!
>>>
>>> (eom)
>>
>> I think the main target for explosion scenarios are tools (IDE,
build tools, etc.) in a development environment. so this mecanism is
>> transparent from the developer point of vuiew.
>> You have the same functionalities as with the scanner with
hopefully a better control over the deployment management.
>> Also this means you can develop on a remote server or even on a
domain without having to rebuild the whole archive everytime.
>>
>
> So would you use the 'explode' operation in your netbeans plugin, i.e.
> start archived and explode? I'm curious if the JBDS guys will.
Well it depends. On NetBeans you have a "Deploy on Save" checkbox so
that the 'build' (since the build process it externalized in Netbeans)
will no longer produce an archive but a list of changes.
So I might need to explode the deployment somewhere in time.
I could see this being useful in a scenario where a user launches
WildFly in something like Docker but they want to see changes on static
content without a full redeploy.
If it's all local then it's already possible to do this using an
unmanaged deployment.
I think David's original point was objecting to the "explode" op which
takes an existing managed archive deployment and turns it into a managed
exploded deployment. He questions whether that's a valid use case to
support. It wasn't about whether managed exploded deployments are a good
idea at all, just whether an internal conversion operation should be
supported.
Managed exploded deployments have a number of benefits over unmanaged:
1) Remote content administration, no local FS access required
2) Automatic content replication in a managed domain.
3) The content is stored in the internal repo, less likely to get messed
up somehow by other user activity on the filesystem.
>
> I suspect it would be used as a convenience; i.e. instead of the tool
> initially uploading 100 files, it uploads a zip and explodes it. And
> then either way it begins to manipulate the few files that the tool
> regards as eligible for update without redeploy (.html, .css, etc.)
That's also a use case (depending on producing an archive in the
first place).
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:46 p.m.
On Fri, Jun 10, 2016 at 2:41 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On 6/10/16 4:27 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com
> <mailto:ehugonne@redhat.com>> wrote:
>
>
>
> On 10/06/2016 17:06, Brian Stansberry wrote:
> > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
> >>
> >>
> >> On 10/06/2016 16:22, David M. Lloyd wrote:
> >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
> >>>> Emmanuel Hugonnet has been working on a long requested feature
> to have
> >>>> WildFly support "managed exploded deployments." We
have a
> requirements
> >>>> analysis doc for this at
> https://developer.jboss.org/docs/DOC-55497 and
> >>>> I just wanted to point that out to the list so anyone
> interested can
> >>>> have a look, and comment on this thread or on the document.
> >>>>
> >>>> A managed deployment is one where the user provided content is
> copied by
> >>>> the server/host controller into its internal content repo and
then
> >>>> thereafter that copy is what is used. I estimate that 99%+ of
> all zipped
> >>>> deployments in WildFly are managed. With an unmanaged
> deployment the
> >>>> user provides the server with the local FS path to the content
> and then
> >>>> the server directly uses that content. All exploded
deployments
are
> >>>> unmanaged, as we don't support managed yet.
> >>>>
> >>>> We propose to add 5 new operations to the deployment resource:
> >>>>
> >>>> explode (to convert and archive deployment to exploded)
> >>>
> >>> Hmmm.
> >>>
> >>> Is deployment explosion really an deployer concern, or is it a
> >>> deployment provider concern? Consider:
> >>>
> >>> * The deployment provider is the one who will know whether or not
> >>> his/her deployment will function correctly with or without
> exploding.
> >>> * The deployment will have been tested in the desired
configuration
> >>> (exploded or unexploded).
> >>> * Making this a deployer/administrator concern means that he/she
> must
> >>> ensure that the extra step(s) taken in development and testing
> are also
> >>> replicated in production.
> >>>
> >>> Wouldn't it make more sense to have some deployment control
metadata
> >>> (maybe even just a MANIFEST header) that says whether the
particular
> >>> archive should be exploded?
> >>>
> >>> Also, I don't think it's clear that you always want to
explode
> the outer
> >>> archive if an inner archive is to be exploded (I'm not sure
that's
> >>> necessarily implied by the proposed design, but it certainly
> would be in
> >>> the recursive case). In particular it's definitely useful to
> explode
> >>> WARs inside of EARs that need not be exploded.
> >>>
> >>> Explode!!
> >>>
> >>> (eom)
> >>
> >> I think the main target for explosion scenarios are tools (IDE,
> build tools, etc.) in a development environment. so this mecanism is
> >> transparent from the developer point of vuiew.
> >> You have the same functionalities as with the scanner with
> hopefully a better control over the deployment management.
> >> Also this means you can develop on a remote server or even on a
> domain without having to rebuild the whole archive everytime.
> >>
> >
> > So would you use the 'explode' operation in your netbeans plugin,
i.e.
> > start archived and explode? I'm curious if the JBDS guys will.
>
> Well it depends. On NetBeans you have a "Deploy on Save" checkbox so
> that the 'build' (since the build process it externalized in
Netbeans)
> will no longer produce an archive but a list of changes.
> So I might need to explode the deployment somewhere in time.
>
>
> I could see this being useful in a scenario where a user launches
> WildFly in something like Docker but they want to see changes on static
> content without a full redeploy.
>
> If it's all local then it's already possible to do this using an
> unmanaged deployment.
I think David's original point was objecting to the "explode" op which
takes an existing managed archive deployment and turns it into a managed
exploded deployment. He questions whether that's a valid use case to
support. It wasn't about whether managed exploded deployments are a good
idea at all, just whether an internal conversion operation should be
supported.
Managed exploded deployments have a number of benefits over unmanaged:
1) Remote content administration, no local FS access required
2) Automatic content replication in a managed domain.
3) The content is stored in the internal repo, less likely to get messed
up somehow by other user activity on the filesystem.
Got it. I think I misread something in there :)
>
>
>
>
> >
> > I suspect it would be used as a convenience; i.e. instead of the
tool
> > initially uploading 100 files, it uploads a zip and explodes it.
And
> > then either way it begins to manipulate the few files that the tool
> > regards as eligible for update without redeploy (.html, .css, etc.)
>
> That's also a use case (depending on producing an archive in the
> first place).
>
> Emmanuel
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
10:16 a.m.
On 6/10/16 9:22 AM, David M. Lloyd wrote:
On 06/10/2016 08:38 AM, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
Hmmm.
Is deployment explosion really an deployer concern, or is it a
deployment provider concern? Consider:
* The deployment provider is the one who will know whether or not
his/her deployment will function correctly with or without exploding.
* The deployment will have been tested in the desired configuration
(exploded or unexploded).
* Making this a deployer/administrator concern means that he/she must
ensure that the extra step(s) taken in development and testing are also
replicated in production.
The admin already has this capability; they can just convert a zip to
unmanaged exploded and redeploy. Granted, this op makes it easier to do
and bypasses limitations that currently exist like the need for said
admin to write to the local FS.
Wouldn't it make more sense to have some deployment control
metadata
(maybe even just a MANIFEST header) that says whether the particular
archive should be exploded?
This one gives me a not so nice feeling, as now we are taking things
typically done by DUPs (analyzing deployment structure, extracting
files, parsing) and doing it in a different area.
Also, I don't think it's clear that you always want to
explode the outer
archive if an inner archive is to be exploded (I'm not sure that's
necessarily implied by the proposed design, but it certainly would be in
the recursive case). In particular it's definitely useful to explode
WARs inside of EARs that need not be exploded.
There's a lot of complexity that comes from allowing the parent to be an
archive and the child exploded. And I don't see a huge benefit. How much
unzipped child content do ears have? Mostly a few deployments
descriptors and a manifest.
I certainly see a benefit though in having the parent and 1 child
exploded while all other children remain as zips.
Explode!!
(eom)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
8:16 a.m.
On 06/10/2016 10:16 AM, Brian Stansberry wrote:
On 6/10/16 9:22 AM, David M. Lloyd wrote:
> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>> Emmanuel Hugonnet has been working on a long requested feature to have
>> WildFly support "managed exploded deployments." We have a requirements
>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>> I just wanted to point that out to the list so anyone interested can
>> have a look, and comment on this thread or on the document.
>>
>> A managed deployment is one where the user provided content is copied by
>> the server/host controller into its internal content repo and then
>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>> deployments in WildFly are managed. With an unmanaged deployment the
>> user provides the server with the local FS path to the content and then
>> the server directly uses that content. All exploded deployments are
>> unmanaged, as we don't support managed yet.
>>
>> We propose to add 5 new operations to the deployment resource:
>>
>> explode (to convert and archive deployment to exploded)
>
> Hmmm.
>
> Is deployment explosion really an deployer concern, or is it a
> deployment provider concern? Consider:
>
> * The deployment provider is the one who will know whether or not
> his/her deployment will function correctly with or without exploding.
> * The deployment will have been tested in the desired configuration
> (exploded or unexploded).
> * Making this a deployer/administrator concern means that he/she must
> ensure that the extra step(s) taken in development and testing are also
> replicated in production.
>
The admin already has this capability; they can just convert a zip to
unmanaged exploded and redeploy. Granted, this op makes it easier to do
and bypasses limitations that currently exist like the need for said
admin to write to the local FS.
Sure, but I think that creates a false equivalency between unmanaged
deployments and exploded deployments. Managed deployments have many
advantages. Exploded deployments on the other hand have key functional
differences at run time (consider the case we used to discuss all the
time: servlets which call ServletContext.getRealPath() and expect to get
a non-null answer). If the answer to a given problem is "use an
unmanaged deployment" then I think we have a deficiency with managed
deployments, which were IMO always meant to be the primary deployment
function for most apps; unmanaged deployments were meant to be a
combination of convenience feature and continuation of capabilities from
previous JBoss AS generations.
That said, I think the IDE case (of dynamic content updates) is
completely legitimate, and honestly one I did not think of. So maybe
the right thing is to support both an operation set as Emmanuel
proposes, *and* a deployment flag that can be set an a per-archive
basis, which would meet all the use cases.
> Wouldn't it make more sense to have some deployment control
metadata
> (maybe even just a MANIFEST header) that says whether the particular
> archive should be exploded?
This one gives me a not so nice feeling, as now we are taking things
typically done by DUPs (analyzing deployment structure, extracting
files, parsing) and doing it in a different area.
Not necessarily - it could be a simple as adding a DUP step which
examines the descriptor and pokes the VFS mount so that at run time, the
deployment is exploded. That would satisfy the run-time requirements
without impacting the implementation of the proposed management
operation(s).
> Also, I don't think it's clear that you always want to
explode the outer
> archive if an inner archive is to be exploded (I'm not sure that's
> necessarily implied by the proposed design, but it certainly would be in
> the recursive case). In particular it's definitely useful to explode
> WARs inside of EARs that need not be exploded.
There's a lot of complexity that comes from allowing the parent to be an
archive and the child exploded. And I don't see a huge benefit. How much
unzipped child content do ears have? Mostly a few deployments
descriptors and a manifest.
I don't think you need to actively prevent a recursive explode
situation, but I think it's just not always necessary and using the DUP
approach it's easier to just explode individual pieces. But using the
management operation approach, the opposite is true, as addressing
interior components is more complex than just recursively exploding the
whole thing.
I certainly see a benefit though in having the parent and 1 child
exploded while all other children remain as zips.
Sure.
--
- DML
10:19 a.m.
Just had an offline discussion with Emmanuel and he cleared up some
things for me. Turns out my recollection of how managed deployments
work was faulty (surprise!)... IOW carry on, nothing to see here :-)
On 06/13/2016 08:16 AM, David M. Lloyd wrote:
On 06/10/2016 10:16 AM, Brian Stansberry wrote:
> On 6/10/16 9:22 AM, David M. Lloyd wrote:
>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>>> Emmanuel Hugonnet has been working on a long requested feature to have
>>> WildFly support "managed exploded deployments." We have a
requirements
>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>>> I just wanted to point that out to the list so anyone interested can
>>> have a look, and comment on this thread or on the document.
>>>
>>> A managed deployment is one where the user provided content is
>>> copied by
>>> the server/host controller into its internal content repo and then
>>> thereafter that copy is what is used. I estimate that 99%+ of all
>>> zipped
>>> deployments in WildFly are managed. With an unmanaged deployment the
>>> user provides the server with the local FS path to the content and then
>>> the server directly uses that content. All exploded deployments are
>>> unmanaged, as we don't support managed yet.
>>>
>>> We propose to add 5 new operations to the deployment resource:
>>>
>>> explode (to convert and archive deployment to exploded)
>>
>> Hmmm.
>>
>> Is deployment explosion really an deployer concern, or is it a
>> deployment provider concern? Consider:
>>
>> * The deployment provider is the one who will know whether or not
>> his/her deployment will function correctly with or without exploding.
>> * The deployment will have been tested in the desired configuration
>> (exploded or unexploded).
>> * Making this a deployer/administrator concern means that he/she must
>> ensure that the extra step(s) taken in development and testing are also
>> replicated in production.
>>
>
> The admin already has this capability; they can just convert a zip to
> unmanaged exploded and redeploy. Granted, this op makes it easier to do
> and bypasses limitations that currently exist like the need for said
> admin to write to the local FS.
Sure, but I think that creates a false equivalency between unmanaged
deployments and exploded deployments. Managed deployments have many
advantages. Exploded deployments on the other hand have key functional
differences at run time (consider the case we used to discuss all the
time: servlets which call ServletContext.getRealPath() and expect to get
a non-null answer). If the answer to a given problem is "use an
unmanaged deployment" then I think we have a deficiency with managed
deployments, which were IMO always meant to be the primary deployment
function for most apps; unmanaged deployments were meant to be a
combination of convenience feature and continuation of capabilities from
previous JBoss AS generations.
That said, I think the IDE case (of dynamic content updates) is
completely legitimate, and honestly one I did not think of. So maybe
the right thing is to support both an operation set as Emmanuel
proposes, *and* a deployment flag that can be set an a per-archive
basis, which would meet all the use cases.
>> Wouldn't it make more sense to have some deployment control metadata
>> (maybe even just a MANIFEST header) that says whether the particular
>> archive should be exploded?
>
> This one gives me a not so nice feeling, as now we are taking things
> typically done by DUPs (analyzing deployment structure, extracting
> files, parsing) and doing it in a different area.
Not necessarily - it could be a simple as adding a DUP step which
examines the descriptor and pokes the VFS mount so that at run time, the
deployment is exploded. That would satisfy the run-time requirements
without impacting the implementation of the proposed management
operation(s).
>> Also, I don't think it's clear that you always want to explode the outer
>> archive if an inner archive is to be exploded (I'm not sure that's
>> necessarily implied by the proposed design, but it certainly would be in
>> the recursive case). In particular it's definitely useful to explode
>> WARs inside of EARs that need not be exploded.
>
> There's a lot of complexity that comes from allowing the parent to be an
> archive and the child exploded. And I don't see a huge benefit. How much
> unzipped child content do ears have? Mostly a few deployments
> descriptors and a manifest.
I don't think you need to actively prevent a recursive explode
situation, but I think it's just not always necessary and using the DUP
approach it's easier to just explode individual pieces. But using the
management operation approach, the opposite is true, as addressing
interior components is more complex than just recursively exploding the
whole thing.
> I certainly see a benefit though in having the parent and 1 child
> exploded while all other children remain as zips.
Sure.
--
- DML
9:24 a.m.
Some details on the current implementation :
* the add-content will overwrite existing content so there is no update-content
updating instead of just adding means having the state on the client as well as on the
server which would require more checks to keep those
in sync for no real value from my point of view.
* the add-content/remove-content work with a list of contents thus for an IDE we don't
have to create a bunch of ops to upload or delete
each change.
* you can start from an 'empty' deployment and add contents to it step by step
Emmanuel
On 10/06/2016 15:38, Brian Stansberry wrote:
Emmanuel Hugonnet has been working on a long requested feature to
have
WildFly support "managed exploded deployments." We have a requirements
analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
I just wanted to point that out to the list so anyone interested can
have a look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by
the server/host controller into its internal content repo and then
thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged deployment the
user provides the server with the local FS path to the content and then
the server directly uses that content. All exploded deployments are
unmanaged, as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought on
this are appreciated:
"The explode operation can take an optional path parameter, the value of
which is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to be
exploded.
* This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
* This operation will fail if the content referred to by the path
parameter is already exploded or is not a zip file.
* This operation will fail if any content between the root of the
deployment and the content referred to by the path parameter is an
unexploded archive.
* So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
would fail if thewar.war hadn't previously been exploded."
10 a.m.
So in terms of the requirements analysis:
On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
Some details on the current implementation :
* the add-content will overwrite existing content so there is no update-content
updating instead of just adding means having the state on the client as well as on the
server which would require more checks to keep those
in sync for no real value from my point of view.
If there is no objection to this, then the requirement should be altered.
* the add-content/remove-content work with a list of contents thus
for an IDE we don't have to create a bunch of ops to upload or delete
each change.
This I think is a nice-to-have requirement. (And yes, I know it already
exists, but if we by some strange chance find horrible problems then it
can be dropped.)
* you can start from an 'empty' deployment and add contents
to it step by step
Yep. This one is in the hard requirements.
Emmanuel
On 10/06/2016 15:38, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:20 p.m.
On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com>
wrote:
Some details on the current implementation :
* the add-content will overwrite existing content so there is no
update-content
updating instead of just adding means having the state on the client as
well as on the server which would require more checks to keep those
in sync for no real value from my point of view.
I think there should be a force attribute, or something along those lines,
that can be changed to indicate an add shouldn't override. It can default
to false, but there are probably scenarios where you would want an add to
fail of the content already exists.
* the add-content/remove-content work with a list of contents thus
for an
IDE we don't have to create a bunch of ops to upload or delete
each change.
* you can start from an 'empty' deployment and add contents to it step by
step
Emmanuel
On 10/06/2016 15:38, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
4:32 p.m.
On 6/10/16 4:20 PM, James Perkins wrote:
On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com
<mailto:ehugonne@redhat.com>> wrote:
Some details on the current implementation :
* the add-content will overwrite existing content so there is no
update-content
updating instead of just adding means having the state on the client
as well as on the server which would require more checks to keep those
in sync for no real value from my point of view.
I think there should be a force attribute, or something along those
lines, that can be changed to indicate an add shouldn't override. It can
default to false, but there are probably scenarios where you would want
an add to fail of the content already exists.
In that case, we should have an op called "update-content". :)
Oh, I think you meant the default should be 'force=true', so by default
add can update but the user can turn that off.
* the add-content/remove-content work with a list of contents thus
for an IDE we don't have to create a bunch of ops to upload or delete
each change.
* you can start from an 'empty' deployment and add contents to it
step by step
Emmanuel
On 10/06/2016 15:38, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a
requirements
> analysis doc for this at
https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is
copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all
zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and
then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where
I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the
value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war
to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:48 p.m.
On Fri, Jun 10, 2016 at 2:32 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On 6/10/16 4:20 PM, James Perkins wrote:
>
>
> On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com
> <mailto:ehugonne@redhat.com>> wrote:
>
> Some details on the current implementation :
> * the add-content will overwrite existing content so there is no
> update-content
> updating instead of just adding means having the state on the client
> as well as on the server which would require more checks to keep
those
> in sync for no real value from my point of view.
>
>
> I think there should be a force attribute, or something along those
> lines, that can be changed to indicate an add shouldn't override. It can
> default to false, but there are probably scenarios where you would want
> an add to fail of the content already exists.
In that case, we should have an op called "update-content". :)
Oh, I think you meant the default should be 'force=true', so by default
add can update but the user can turn that off.
Yes correct. If we want add-content to also act like update-content I think
there should be a way to indicate the operation should fail if content is
being updated instead of added.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
4:48 p.m.
Emmanuel,
Can you work with Alexey and Jeff to add some CLI requirements to this?
I went on PTO and forget about our discussions in Neuchatel about being
able to associate streams wit the add-content op. If we can't make it
easy to do that with low level operations, we'd need a high level command.
The doc already mentions there needs to be some CLI "deploy" command
support for starting an empty exploded deployment. Perhaps that's not
strictly required though; a low level op could suffice. The deployment
doesn't need to be mapped to server groups or enabled until it isn't
empty any more.
On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
Some details on the current implementation :
* the add-content will overwrite existing content so there is no update-content
updating instead of just adding means having the state on the client as well as on the
server which would require more checks to keep those
in sync for no real value from my point of view.
* the add-content/remove-content work with a list of contents thus for an IDE we
don't have to create a bunch of ops to upload or delete
each change.
* you can start from an 'empty' deployment and add contents to it step by step
Emmanuel
On 10/06/2016 15:38, Brian Stansberry wrote:
> Emmanuel Hugonnet has been working on a long requested feature to have
> WildFly support "managed exploded deployments." We have a requirements
> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
> I just wanted to point that out to the list so anyone interested can
> have a look, and comment on this thread or on the document.
>
> A managed deployment is one where the user provided content is copied by
> the server/host controller into its internal content repo and then
> thereafter that copy is what is used. I estimate that 99%+ of all zipped
> deployments in WildFly are managed. With an unmanaged deployment the
> user provides the server with the local FS path to the content and then
> the server directly uses that content. All exploded deployments are
> unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where I'm
> increasingly thinking it needs to be a hard requirement, so thought on
> this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the value of
> which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
> contains an unexploded war, and then the user later wishes the war to be
> exploded.
> * This is much closer to a hard requirement if the nice-to-have
> requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the path
> parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of the
> deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
> would fail if thewar.war hadn't previously been exploded."
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:14 a.m.
Hi,
we have discussed the CLI requirements. The main item is the addition of
a support for streams (in batch and non batch) in low level Operation.
Doing so we will support the update/add-content operation.
A field that it a File stream, will be annotated with attached_stream
and filesystem_path.
In the particular case of the update/add-content operation, the
index_stream attribute should be renamed to a more appropriate name
since we won't use any aliasing in the cli (something like source_file).
This does answer the path/stream duality that CLI user could observe (a
file system path converted internally onto an array index). Introducing
some special aliasing in the metadata would make ergonomics constraint
to slip into lower level API. For a simpler command, with better
options, we should implement a dedicated Command.
Discussing the explode operation, we could have a need for an extra
operation (list-content) that would allow to offer completion when
selecting sub archives to explode.
JF
On 10/06/16 23:48, Brian Stansberry wrote:
Emmanuel,
Can you work with Alexey and Jeff to add some CLI requirements to this?
I went on PTO and forget about our discussions in Neuchatel about being
able to associate streams wit the add-content op. If we can't make it
easy to do that with low level operations, we'd need a high level command.
The doc already mentions there needs to be some CLI "deploy" command
support for starting an empty exploded deployment. Perhaps that's not
strictly required though; a low level op could suffice. The deployment
doesn't need to be mapped to server groups or enabled until it isn't
empty any more.
On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
> Some details on the current implementation :
> * the add-content will overwrite existing content so there is no update-content
> updating instead of just adding means having the state on the client as well as on
the server which would require more checks to keep those
> in sync for no real value from my point of view.
> * the add-content/remove-content work with a list of contents thus for an IDE we
don't have to create a bunch of ops to upload or delete
> each change.
> * you can start from an 'empty' deployment and add contents to it step by
step
>
> Emmanuel
>
>
> On 10/06/2016 15:38, Brian Stansberry wrote:
>> Emmanuel Hugonnet has been working on a long requested feature to have
>> WildFly support "managed exploded deployments." We have a requirements
>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>> I just wanted to point that out to the list so anyone interested can
>> have a look, and comment on this thread or on the document.
>>
>> A managed deployment is one where the user provided content is copied by
>> the server/host controller into its internal content repo and then
>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>> deployments in WildFly are managed. With an unmanaged deployment the
>> user provides the server with the local FS path to the content and then
>> the server directly uses that content. All exploded deployments are
>> unmanaged, as we don't support managed yet.
>>
>> We propose to add 5 new operations to the deployment resource:
>>
>> explode (to convert and archive deployment to exploded)
>> add-content
>> update-content
>> remove-content
>> read-content
>>
>> There is one "nice-to-have" requirement listed on the doc where
I'm
>> increasingly thinking it needs to be a hard requirement, so thought on
>> this are appreciated:
>>
>>
>> "The explode operation can take an optional path parameter, the value of
>> which is a path within the deployment that should be exploded.
>> * The use case for this is scenarios like an exploded ear that
>> contains an unexploded war, and then the user later wishes the war to be
>> exploded.
>> * This is much closer to a hard requirement if the nice-to-have
>> requirement for recursively exploding is not supported.
>> * This operation will fail if the content referred to by the path
>> parameter is already exploded or is not a zip file.
>> * This operation will fail if any content between the root of the
>> deployment and the content referred to by the path parameter is an
>> unexploded archive.
>> * So,
>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
>> would fail if thewar.war hadn't previously been exploded."
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
4:51 p.m.
Please open a separate EAP7 issue linked to the WFCORE one, and let Bilge know so he can
rank it
On 13 Jun 2016, at 17:14, Jean-Francois Denise
<jdenise(a)redhat.com> wrote:
Hi,
we have discussed the CLI requirements. The main item is the addition of
a support for streams (in batch and non batch) in low level Operation.
Doing so we will support the update/add-content operation.
A field that it a File stream, will be annotated with attached_stream
and filesystem_path.
In the particular case of the update/add-content operation, the
index_stream attribute should be renamed to a more appropriate name
since we won't use any aliasing in the cli (something like source_file).
This does answer the path/stream duality that CLI user could observe (a
file system path converted internally onto an array index). Introducing
some special aliasing in the metadata would make ergonomics constraint
to slip into lower level API. For a simpler command, with better
options, we should implement a dedicated Command.
Discussing the explode operation, we could have a need for an extra
operation (list-content) that would allow to offer completion when
selecting sub archives to explode.
JF
On 10/06/16 23:48, Brian Stansberry wrote:
> Emmanuel,
>
> Can you work with Alexey and Jeff to add some CLI requirements to this?
> I went on PTO and forget about our discussions in Neuchatel about being
> able to associate streams wit the add-content op. If we can't make it
> easy to do that with low level operations, we'd need a high level command.
>
> The doc already mentions there needs to be some CLI "deploy" command
> support for starting an empty exploded deployment. Perhaps that's not
> strictly required though; a low level op could suffice. The deployment
> doesn't need to be mapped to server groups or enabled until it isn't
> empty any more.
>
> On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote:
>> Some details on the current implementation :
>> * the add-content will overwrite existing content so there is no update-content
>> updating instead of just adding means having the state on the client as well as
on the server which would require more checks to keep those
>> in sync for no real value from my point of view.
>> * the add-content/remove-content work with a list of contents thus for an IDE we
don't have to create a bunch of ops to upload or delete
>> each change.
>> * you can start from an 'empty' deployment and add contents to it step by
step
>>
>> Emmanuel
>>
>>
>> On 10/06/2016 15:38, Brian Stansberry wrote:
>>> Emmanuel Hugonnet has been working on a long requested feature to have
>>> WildFly support "managed exploded deployments." We have a
requirements
>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>>> I just wanted to point that out to the list so anyone interested can
>>> have a look, and comment on this thread or on the document.
>>>
>>> A managed deployment is one where the user provided content is copied by
>>> the server/host controller into its internal content repo and then
>>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>>> deployments in WildFly are managed. With an unmanaged deployment the
>>> user provides the server with the local FS path to the content and then
>>> the server directly uses that content. All exploded deployments are
>>> unmanaged, as we don't support managed yet.
>>>
>>> We propose to add 5 new operations to the deployment resource:
>>>
>>> explode (to convert and archive deployment to exploded)
>>> add-content
>>> update-content
>>> remove-content
>>> read-content
>>>
>>> There is one "nice-to-have" requirement listed on the doc where
I'm
>>> increasingly thinking it needs to be a hard requirement, so thought on
>>> this are appreciated:
>>>
>>>
>>> "The explode operation can take an optional path parameter, the value
of
>>> which is a path within the deployment that should be exploded.
>>> * The use case for this is scenarios like an exploded ear that
>>> contains an unexploded war, and then the user later wishes the war to be
>>> exploded.
>>> * This is much closer to a hard requirement if the nice-to-have
>>> requirement for recursively exploding is not supported.
>>> * This operation will fail if the content referred to by the path
>>> parameter is already exploded or is not a zip file.
>>> * This operation will fail if any content between the root of the
>>> deployment and the content referred to by the path parameter is an
>>> unexploded archive.
>>> * So,
>>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
>>> would fail if thewar.war hadn't previously been exploded."
>>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:07 p.m.
Quick question here:
Will the various add / update / remove methods have syntax for working on
multiple files at once? Or will one management call be required for each
request? Requiring a separate management call for each changed file might
be pretty slow if the server being acted against is remote.
On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
Emmanuel Hugonnet has been working on a long requested feature to
have
WildFly support "managed exploded deployments." We have a requirements
analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and I
just wanted to point that out to the list so anyone interested can have a
look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by
the server/host controller into its internal content repo and then
thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged deployment the user
provides the server with the local FS path to the content and then the
server directly uses that content. All exploded deployments are unmanaged,
as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought on this
are appreciated:
"The explode operation can take an optional path parameter, the value of
which is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to be
exploded.
* This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
* This operation will fail if the content referred to by the path
parameter is already exploded or is not a zip file.
* This operation will fail if any content between the root of the
deployment and the content referred to by the path parameter is an
unexploded archive.
* So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would
fail if thewar.war hadn't previously been exploded."
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:16 p.m.
Well I only made the add-content (which does the update to) and remove-content support
list of content.
Exploding has only one file support as the order might have an impact. Maybe adding
recusrive is sufficient ?
read-content is also one file only has I didn't have a proper use-case for multiple
targets.
What do you have in mind for read-content or explode ?
Cheers
Emmanuel
On 13/06/2016 19:07, Robert Stryker wrote:
Quick question here:
Will the various add / update / remove methods have syntax for working on multiple files
at once? Or will one management call be required
for each request? Requiring a separate management call for each changed file might be
pretty slow if the server being acted against is remote.
On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Emmanuel Hugonnet has been working on a long requested feature to have WildFly
support "managed exploded deployments." We have a
requirements analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
I just wanted to point that out to the list so
anyone interested can have a look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by the
server/host controller into its internal content repo and
then thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged
deployment the user provides the server with the local FS path to the content and
then the server directly uses that content. All
exploded deployments are unmanaged, as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought
on this are appreciated:
"The explode operation can take an optional path parameter, the value of which
is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that contains an
unexploded war, and then the user later wishes the war to
be exploded.
* This is much closer to a hard requirement if the nice-to-have requirement for
recursively exploding is not supported.
* This operation will fail if the content referred to by the path parameter is
already exploded or is not a zip file.
* This operation will fail if any content between the root of the deployment and
the content referred to by the path parameter is an
unexploded archive.
* So, /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
would fail if thewar.war hadn't previously been
exploded."
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:35 p.m.
I was primarily concerned with update / remove, so I'm glad to hear those
two are targeted to be supported.
At this time, I don't think I have a need for read-content of multiple
items, so I think we're ok there if no one else requires it. In terms of
explode, I'm hard-pressed to design the API, but I'd imagine if order is
critical, that it would take an array or list of paths, and explode them in
the order provided, collecting the errors in some fashion to be returned at
the end. Alternatively, if the server is prepared to discover all
sub-deployments in an efficient manner, perhaps an integer representing
max-depth, with a depth_infinite flag, would work?
Again, these are just ideas, so I defer to your judgement.
On Mon, Jun 13, 2016 at 1:16 PM, Emmanuel Hugonnet <ehugonne(a)redhat.com>
wrote:
Well I only made the add-content (which does the update to) and
remove-content support list of content.
Exploding has only one file support as the order might have an impact.
Maybe adding recusrive is sufficient ?
read-content is also one file only has I didn't have a proper use-case for
multiple targets.
What do you have in mind for read-content or explode ?
Cheers
Emmanuel
On 13/06/2016 19:07, Robert Stryker wrote:
> Quick question here:
>
> Will the various add / update / remove methods have syntax for working
on multiple files at once? Or will one management call be required
> for each request? Requiring a separate management call for each changed
file might be pretty slow if the server being acted against is remote.
>
> On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry <
brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
>
> Emmanuel Hugonnet has been working on a long requested feature to
have WildFly support "managed exploded deployments." We have a
> requirements analysis doc for this at
https://developer.jboss.org/docs/DOC-55497 and I just wanted to point
that out to the list so
> anyone interested can have a look, and comment on this thread or on
the document.
>
> A managed deployment is one where the user provided content is
copied by the server/host controller into its internal content repo and
> then thereafter that copy is what is used. I estimate that 99%+ of
all zipped deployments in WildFly are managed. With an unmanaged
> deployment the user provides the server with the local FS path to
the content and then the server directly uses that content. All
> exploded deployments are unmanaged, as we don't support managed yet.
>
> We propose to add 5 new operations to the deployment resource:
>
> explode (to convert and archive deployment to exploded)
> add-content
> update-content
> remove-content
> read-content
>
> There is one "nice-to-have" requirement listed on the doc where
I'm
increasingly thinking it needs to be a hard requirement, so thought
> on this are appreciated:
>
>
> "The explode operation can take an optional path parameter, the
value of which is a path within the deployment that should be exploded.
> * The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to
> be exploded.
> * This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
> * This operation will fail if the content referred to by the
path parameter is already exploded or is not a zip file.
> * This operation will fail if any content between the root of
the deployment and the content referred to by the path parameter is an
> unexploded archive.
> * So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would
fail if thewar.war hadn't previously been
> exploded."
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3498
days inactive
3501
days old
21 comments
7 participants
participants (7)
-
Brian Stansberry -
David M. Lloyd -
Emmanuel Hugonnet -
James Perkins -
Jean-Francois Denise -
Kabir Khan -
Robert Stryker