[wildfly-dev] Managed exploded deployments

James Perkins jperkins at redhat.com
Fri Jun 10 17:48:12 EDT 2016


On Fri, Jun 10, 2016 at 2:32 PM, Brian Stansberry <
brian.stansberry at 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 at redhat.com
> > <mailto:ehugonne at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e55d4758/attachment.html 


More information about the wildfly-dev mailing list