We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. 1) Allow the user to specify alternate deployment descriptors as part of the deployment process At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. e.g. to add the descriptor you would do something like: /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) or for domain mode /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)

Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. 2) is the approach that I prefer, as I think it gives the most flexibility. What does everyone think? Stuart _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Hmm, so we really have to support the deployment-scanner use case? I mean beside some API/address differences - the (not implemented) deployment content thing is basically doing the same. Just wondering if i missed something obvious? On 03/27/2012 03:55 PM, Brian Stansberry wrote: > On 3/27/12 12:34 AM, Stuart Douglas wrote: >> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >> >> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >> >> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >> >> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >> >> e.g. to add the descriptor you would do something like: >> >> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >> >> or for domain mode >> >> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >> > > For domain mode, this should be basically a parallel to the existing > deployment=* handling: > > a) The override is a top level resource, adding an item to the > "pallette" that is usable in any server-group: > > /dd-override=my-deployment-descriptor:add(deployment="test.ear", > file="test.jar/META-INF/ejb-jar.xml", content=…) > > b) The server-group part is just a mapping that says "use this from the > pallette: > > /server-group=foo/dd-override=my-deployment-descriptor:add > > Actually, this last bit is probably unnecessary, since the HC can figure > out what dd-overrides are required from the deployment="test.ear" > attribute on the dd-override=my-deployment-descriptor resource. > >> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >> >> 2) is the approach that I prefer, as I think it gives the most flexibility. >> >> What does everyone think? >> >> Stuart >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

The part i am trying to figure out is that we basically would have 2 things doing the same. Another issue people are complaining about is that we don't support symlinks in .war deployments. One of the easiest ways to solve this would be to just mount a local file system path. Where i am not sure if moving this to the dd-overrides makes more sense. Hopefully i do remember correctly that we support VFS in our web integration :) I think the dd-override sounds like less work in the beginning, but if you include invalidation of overrides i am not sure if that is also true for all the tooling. The deployment-scanner seems to be an edge case in general, so perhaps we it can just adapt (be smarter) once we have some other workflows. On 03/27/2012 08:04 PM, Brian Stansberry wrote: > It's not immediately critical. But a little voice inside my ear tells me > we'll be *strongly* pressured to support it at some point. People love > the deployment scanner. And I think once people get used to being able > to have override descriptors they will love that as well. > > Override descriptors are very nice for keeping a base deployment but > adapting it for different environments. I'd thought of it as more of a > production thing (a workaround to a corporate policy that says a jar > can't be cracked open and change) but David convinced me it's more of a > developer or staging thing (override the production settings with > dev-workstation-specific settings). And once you are talking developers, > you are also talking deployment scanner. > > A big question I'd like to see talked through on this thread is how best > to do tooling around this (including CLI and web console.) What's > easiest for the user, in common workflows? > > In option 1, the dd-override is a separate resource from the deployment. > That means it can be independently controlled. Good and bad there. Good, > it can be added once and then left alone while the war, whatever is > tweaked and redeployed many times. Bad, it's a separate thing. > > Conversely, with 2, the content items are part of a list attribute of > the deployment resource. The good and bad points are the opposite of 1. > > On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >> Hmm, so we really have to support the deployment-scanner use case? I >> mean beside some API/address differences - the (not implemented) >> deployment content thing is basically doing the same. Just wondering if >> i missed something obvious? >> >> >> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>> >>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>> >>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>> >>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>> >>>> e.g. to add the descriptor you would do something like: >>>> >>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>> >>>> or for domain mode >>>> >>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>> >>> For domain mode, this should be basically a parallel to the existing >>> deployment=* handling: >>> >>> a) The override is a top level resource, adding an item to the >>> "pallette" that is usable in any server-group: >>> >>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>> >>> b) The server-group part is just a mapping that says "use this from the >>> pallette: >>> >>> /server-group=foo/dd-override=my-deployment-descriptor:add >>> >>> Actually, this last bit is probably unnecessary, since the HC can figure >>> out what dd-overrides are required from the deployment="test.ear" >>> attribute on the dd-override=my-deployment-descriptor resource. >>> >>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>> >>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>> >>>> What does everyone think? >>>> >>>> Stuart >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 28/03/2012, at 5:48 AM, Emanuel Muckenhuber wrote: > The part i am trying to figure out is that we basically would have 2 > things doing the same. Another issue people are complaining about is > that we don't support symlinks in .war deployments. One of the easiest > ways to solve this would be to just mount a local file system path. > Where i am not sure if moving this to the dd-overrides makes more sense. > Hopefully i do remember correctly that we support VFS in our web > integration :) > > I think the dd-override sounds like less work in the beginning, but if > you include invalidation of overrides i am not sure if that is also true > for all the tooling. The deployment-scanner seems to be an edge case in > general, so perhaps we it can just adapt (be smarter) once we have some > other workflows. > I don't know if invalidation of the overrides is really that much of a problem. If you have to specify the overrides at deployment time then you need to make sure your environment is setup so that you will always provide that override file whenever you deploy, which means that for developers they would need tooling support, and for production they would need to have their deployment scripts setup to make sure that the override is always deployed with the deployment. Both of these use cases will still work with dd-override (i.e. you can just have tools or scripts to modify it every time before deployment).

If on the other hand these descriptors only change infrequent, then dd-override has a major advantage, in that it can just be setup once and then left alone. Stuart > On 03/27/2012 08:04 PM, Brian Stansberry wrote: >> It's not immediately critical. But a little voice inside my ear tells me >> we'll be *strongly* pressured to support it at some point. People love >> the deployment scanner. And I think once people get used to being able >> to have override descriptors they will love that as well. >> >> Override descriptors are very nice for keeping a base deployment but >> adapting it for different environments. I'd thought of it as more of a >> production thing (a workaround to a corporate policy that says a jar >> can't be cracked open and change) but David convinced me it's more of a >> developer or staging thing (override the production settings with >> dev-workstation-specific settings). And once you are talking developers, >> you are also talking deployment scanner. >> >> A big question I'd like to see talked through on this thread is how best >> to do tooling around this (including CLI and web console.) What's >> easiest for the user, in common workflows? >> >> In option 1, the dd-override is a separate resource from the deployment. >> That means it can be independently controlled. Good and bad there. Good, >> it can be added once and then left alone while the war, whatever is >> tweaked and redeployed many times. Bad, it's a separate thing. >> >> Conversely, with 2, the content items are part of a list attribute of >> the deployment resource. The good and bad points are the opposite of 1. >> >> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >>> >>> Hmm, so we really have to support the deployment-scanner use case? I >>> mean beside some API/address differences - the (not implemented) >>> deployment content thing is basically doing the same. Just wondering if >>> i missed something obvious? >>> >>> >>> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>>> >>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>>> >>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>>> >>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>>> >>>>> e.g. to add the descriptor you would do something like: >>>>> >>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>> >>>>> or for domain mode >>>>> >>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>> >>>> >>>> For domain mode, this should be basically a parallel to the existing >>>> deployment=* handling: >>>> >>>> a) The override is a top level resource, adding an item to the >>>> "pallette" that is usable in any server-group: >>>> >>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>>> >>>> b) The server-group part is just a mapping that says "use this from the >>>> pallette: >>>> >>>> /server-group=foo/dd-override=my-deployment-descriptor:add >>>> >>>> Actually, this last bit is probably unnecessary, since the HC can figure >>>> out what dd-overrides are required from the deployment="test.ear" >>>> attribute on the dd-override=my-deployment-descriptor resource. >>>> >>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>>> >>>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>>> >>>>> What does everyone think? >>>>> >>>>> Stuart >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Max, any thoughts on this subject? I think a tooling perspective is critical here.

On 3/29/12 6:50 AM, Emanuel Muckenhuber wrote: > On 03/29/2012 05:12 AM, Stuart Douglas wrote: >> >> On 28/03/2012, at 5:48 AM, Emanuel Muckenhuber wrote: >>> The part i am trying to figure out is that we basically would have 2 >>> things doing the same. Another issue people are complaining about is >>> that we don't support symlinks in .war deployments. One of the easiest >>> ways to solve this would be to just mount a local file system path. >>> Where i am not sure if moving this to the dd-overrides makes more sense. >>> Hopefully i do remember correctly that we support VFS in our web >>> integration :) >>> >>> I think the dd-override sounds like less work in the beginning, but if >>> you include invalidation of overrides i am not sure if that is also true >>> for all the tooling. The deployment-scanner seems to be an edge case in >>> general, so perhaps we it can just adapt (be smarter) once we have some >>> other workflows. >>> >> >> I don't know if invalidation of the overrides is really that much of a problem. If you have to specify the overrides at deployment time then you need to make sure your environment is setup so that you will always provide that override file whenever you deploy, which means that for developers they would need tooling support, and for production they would need to have their deployment scripts setup to make sure that the override is always deployed with the deployment. Both of these use cases will still work with dd-override (i.e. you can just have tools or scripts to modify it every time before deployment). >> > > Hmm, redeploying works through the :replace operation, which should > allow you to replace a single content-item, but preserve exiting ones. > So you would also have to provide it only once. > > But yeah, once you call :remove it would also invalidate all the > overrides. However the lifecycle seems more straightforward and there is > the option that you just disable the deployment as well. > > I do see that this does not work that well for the deployment-scanner, > but then there is no deployment-scanner in the domain. So for me that is > more an issue of the scanner and should perhaps better be solved there. > > Emanuel > >> If on the other hand these descriptors only change infrequent, then dd-override has a major advantage, in that it can just be setup once and then left alone. >> >> Stuart >> >> >>> On 03/27/2012 08:04 PM, Brian Stansberry wrote: >>>> It's not immediately critical. But a little voice inside my ear tells me >>>> we'll be *strongly* pressured to support it at some point. People love >>>> the deployment scanner. And I think once people get used to being able >>>> to have override descriptors they will love that as well. >>>> >>>> Override descriptors are very nice for keeping a base deployment but >>>> adapting it for different environments. I'd thought of it as more of a >>>> production thing (a workaround to a corporate policy that says a jar >>>> can't be cracked open and change) but David convinced me it's more of a >>>> developer or staging thing (override the production settings with >>>> dev-workstation-specific settings). And once you are talking developers, >>>> you are also talking deployment scanner. >>>> >>>> A big question I'd like to see talked through on this thread is how best >>>> to do tooling around this (including CLI and web console.) What's >>>> easiest for the user, in common workflows? >>>> >>>> In option 1, the dd-override is a separate resource from the deployment. >>>> That means it can be independently controlled. Good and bad there. Good, >>>> it can be added once and then left alone while the war, whatever is >>>> tweaked and redeployed many times. Bad, it's a separate thing. >>>> >>>> Conversely, with 2, the content items are part of a list attribute of >>>> the deployment resource. The good and bad points are the opposite of 1. >>>> >>>> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >>>>> >>>>> Hmm, so we really have to support the deployment-scanner use case? I >>>>> mean beside some API/address differences - the (not implemented) >>>>> deployment content thing is basically doing the same. Just wondering if >>>>> i missed something obvious? >>>>> >>>>> >>>>> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>>>>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>>>>> >>>>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>>>>> >>>>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>>>>> >>>>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>>>>> >>>>>>> e.g. to add the descriptor you would do something like: >>>>>>> >>>>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>> >>>>>>> or for domain mode >>>>>>> >>>>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>> >>>>>> >>>>>> For domain mode, this should be basically a parallel to the existing >>>>>> deployment=* handling: >>>>>> >>>>>> a) The override is a top level resource, adding an item to the >>>>>> "pallette" that is usable in any server-group: >>>>>> >>>>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>>>>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>> >>>>>> b) The server-group part is just a mapping that says "use this from the >>>>>> pallette: >>>>>> >>>>>> /server-group=foo/dd-override=my-deployment-descriptor:add >>>>>> >>>>>> Actually, this last bit is probably unnecessary, since the HC can figure >>>>>> out what dd-overrides are required from the deployment="test.ear" >>>>>> attribute on the dd-override=my-deployment-descriptor resource. >>>>>> >>>>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>>>>> >>>>>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>>>>> >>>>>>> What does everyone think? >>>>>>> >>>>>>> Stuart >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

Customer requested feature is ability to externalize a file from a deployment archive and have it be an addition to the files in the archive or to override an existing file. Use cases: 1) Production: can't crack the deployment archive for policy reasons, but need to change some config. So they add an override deployment descriptor. This AIUI is the customer requested use case. 2) QE: override the production config to make some settings match the QE environment. 3) Dev: same as QE, but to match the dev environment.

The original idea we had for this can be seen in the structure of a deployment=foo.war resource in the management API. It has a "content" attribute of type LIST. The LIST was to allow multiple pieces of content, the first being the archive, the rest being overrides. That's "approach 2)" in Stuart's original email in this thread. The new proposed approach (Stuart's "1)") is to have an entire new resource type, peer to deployment=foo.war, called dd-override=x. That resource would include attribute deployment=foo.war used to associate the override with a particular deployment.

What I'm looking for is some perspective on how JBoss Tools would deal with this kind of feature. On 4/4/12 8:24 AM, Max Rydahl Andersen wrote: > Hi brian, > >> Max, any thoughts on this subject? I think a tooling perspective is critical here. > > I'm trying to decipher the real question but seems i'm missing some context ;) > > Care to give a summary/hint ? > > /max > >> >> On 3/29/12 6:50 AM, Emanuel Muckenhuber wrote: >>> On 03/29/2012 05:12 AM, Stuart Douglas wrote: >>>> >>>> On 28/03/2012, at 5:48 AM, Emanuel Muckenhuber wrote: >>>>> The part i am trying to figure out is that we basically would have 2 >>>>> things doing the same. Another issue people are complaining about is >>>>> that we don't support symlinks in .war deployments. One of the easiest >>>>> ways to solve this would be to just mount a local file system path. >>>>> Where i am not sure if moving this to the dd-overrides makes more sense. >>>>> Hopefully i do remember correctly that we support VFS in our web >>>>> integration :) >>>>> >>>>> I think the dd-override sounds like less work in the beginning, but if >>>>> you include invalidation of overrides i am not sure if that is also true >>>>> for all the tooling. The deployment-scanner seems to be an edge case in >>>>> general, so perhaps we it can just adapt (be smarter) once we have some >>>>> other workflows. >>>>> >>>> >>>> I don't know if invalidation of the overrides is really that much of a problem. If you have to specify the overrides at deployment time then you need to make sure your environment is setup so that you will always provide that override file whenever you deploy, which means that for developers they would need tooling support, and for production they would need to have their deployment scripts setup to make sure that the override is always deployed with the deployment. Both of these use cases will still work with dd-override (i.e. you can just have tools or scripts to modify it every time before deployment). >>>> >>> >>> Hmm, redeploying works through the :replace operation, which should >>> allow you to replace a single content-item, but preserve exiting ones. >>> So you would also have to provide it only once. >>> >>> But yeah, once you call :remove it would also invalidate all the >>> overrides. However the lifecycle seems more straightforward and there is >>> the option that you just disable the deployment as well. >>> >>> I do see that this does not work that well for the deployment-scanner, >>> but then there is no deployment-scanner in the domain. So for me that is >>> more an issue of the scanner and should perhaps better be solved there. >>> >>> Emanuel >>> >>>> If on the other hand these descriptors only change infrequent, then dd-override has a major advantage, in that it can just be setup once and then left alone. >>>> >>>> Stuart >>>> >>>> >>>>> On 03/27/2012 08:04 PM, Brian Stansberry wrote: >>>>>> It's not immediately critical. But a little voice inside my ear tells me >>>>>> we'll be *strongly* pressured to support it at some point. People love >>>>>> the deployment scanner. And I think once people get used to being able >>>>>> to have override descriptors they will love that as well. >>>>>> >>>>>> Override descriptors are very nice for keeping a base deployment but >>>>>> adapting it for different environments. I'd thought of it as more of a >>>>>> production thing (a workaround to a corporate policy that says a jar >>>>>> can't be cracked open and change) but David convinced me it's more of a >>>>>> developer or staging thing (override the production settings with >>>>>> dev-workstation-specific settings). And once you are talking developers, >>>>>> you are also talking deployment scanner. >>>>>> >>>>>> A big question I'd like to see talked through on this thread is how best >>>>>> to do tooling around this (including CLI and web console.) What's >>>>>> easiest for the user, in common workflows? >>>>>> >>>>>> In option 1, the dd-override is a separate resource from the deployment. >>>>>> That means it can be independently controlled. Good and bad there. Good, >>>>>> it can be added once and then left alone while the war, whatever is >>>>>> tweaked and redeployed many times. Bad, it's a separate thing. >>>>>> >>>>>> Conversely, with 2, the content items are part of a list attribute of >>>>>> the deployment resource. The good and bad points are the opposite of 1. >>>>>> >>>>>> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >>>>>>> >>>>>>> Hmm, so we really have to support the deployment-scanner use case? I >>>>>>> mean beside some API/address differences - the (not implemented) >>>>>>> deployment content thing is basically doing the same. Just wondering if >>>>>>> i missed something obvious? >>>>>>> >>>>>>> >>>>>>> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>>>>>>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>>>>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>>>>>>> >>>>>>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>>>>>>> >>>>>>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>>>>>>> >>>>>>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>>>>>>> >>>>>>>>> e.g. to add the descriptor you would do something like: >>>>>>>>> >>>>>>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>> >>>>>>>>> or for domain mode >>>>>>>>> >>>>>>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>> >>>>>>>> >>>>>>>> For domain mode, this should be basically a parallel to the existing >>>>>>>> deployment=* handling: >>>>>>>> >>>>>>>> a) The override is a top level resource, adding an item to the >>>>>>>> "pallette" that is usable in any server-group: >>>>>>>> >>>>>>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>>>>>>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>> >>>>>>>> b) The server-group part is just a mapping that says "use this from the >>>>>>>> pallette: >>>>>>>> >>>>>>>> /server-group=foo/dd-override=my-deployment-descriptor:add >>>>>>>> >>>>>>>> Actually, this last bit is probably unnecessary, since the HC can figure >>>>>>>> out what dd-overrides are required from the deployment="test.ear" >>>>>>>> attribute on the dd-override=my-deployment-descriptor resource. >>>>>>>> >>>>>>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>>>>>>> >>>>>>>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>>>>>>> >>>>>>>>> What does everyone think? >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-as7-dev mailing list >>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

>> Customer requested feature is ability to externalize a file from a deployment archive and have it be an addition to the files in the archive or to override an existing file. Use cases: >> >> 1) Production: can't crack the deployment archive for policy reasons, but need to change some config. So they add an override deployment descriptor. This AIUI is the customer requested use case. >> >> 2) QE: override the production config to make some settings match the QE environment. >> >> 3) Dev: same as QE, but to match the dev environment. > > Could this feature also be used to do incremental deployments via remote management API ? > > This is one of the reasons we avoid using the remote deployment features of AS7 since it does not allow incremental updates. > i.e. could we deploy a .war or .ear (exploded or zipped) and then from that point on use this "override" functionallity to replace them or will these still require full module restart to work ? > > ( I know this i proably out of scope but just wondering if it would be a nice sideffect-feature ;) > That's out of scope for what's being done now, but it does raise an interesting point. When the original work on https://issues.jboss.org/browse/AS7-431 was done, where we said the "content" attribute for a deployment was a LIST, the idea was to use the members of that list to build up a "virtual" deployment. Those pieces of content could be anything, not just a deployment descriptor. That approach doesn't magically mean incremental deployment would work, but it's a move in that direction. What's being proposed now is restricting this to deployment descriptors. Basically, the overrides would be processed during deployment and then discarded. So that's not in the direction of incremental deployment.

>> The new proposed approach (Stuart's "1)") is to have an entire new resource type, peer to deployment=foo.war, called dd-override=x. That resource would include attribute deployment=foo.war used to associate the override with a particular deployment. > > And all this override would be via management API's, not doable with any deployment-scanner operations? > > i.e. can I do something like: > > cd overridestuff > cp * to /data/contents/xyz.war/ > > now xyz.war has an "incomplete" override of xyz.war > which will be "overlayed" on to deployment named xyz.war (independent on wether it comes from deployment scanner or management api) > > or is it all just via management api's that would need to be executed on every restart/change to the data/contents folder ? > Just via management APIs. But not "executed on every restart/change to the data/contents folder". This is where the two approaches differ. With 1), the management API call to /dd-override=my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) is done once and then that override is stored in data/contents and in standalone.xml and the override will be applied every time test.ear is deployed. There is no need to do it again.

With 2), the override configuration is part of the deployment=test.ear config, so if that deployment is removed, so is the config.

On 04/04/2012 05:01 PM, Max Rydahl Andersen wrote: > And all this override would be via management API's, not doable with any deployment-scanner operations? > > i.e. can I do something like: > > cd overridestuff > cp * to > /data/contents/xyz.war/ > > > now xyz.war has an "incomplete" override of xyz.war > which will be "overlayed" on to deployment named xyz.war (independent on wether it comes from deployment scanner or management api) > > or is it all just via management api's that would need to be executed on every restart/change to the data/contents folder ? > > /max > How about? standalone/deployments/xyz.war.part01/ standalone/deployments/xyz.war.part02/ standalone/deployments/xyz.war.part03/ touch standalone/deployments/xyz.war.dodeploy

Are you sure that this truly reflects what most users want? Are you not just adding a lot of complexity to cater for the whim of a small group of users? From what I can gather from this thread, the motivation for these overrides are rather thin. It is based on some users having a "policy" to not break-open deployment artefacts. How overriding is better or safer that "breaking open" escapes me at the moment. Very much part of the EJB specification is the definition of roles and responsibilities. As you know, it describes a definite role for composing (and by implication "breaking-open" to recompose) artefacts. If your configuration is too dynamic for this approach then it is a matter of application design to pick this up from elsewhere (DB or properties file). -----Original Message----- From: jboss-as7-dev-bounces(a)lists.jboss.org [mailto:jboss-as7-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl Andersen Sent: 05 April 2012 10:22 AM To: Carlo de Wolf Cc: jboss-as7-dev(a)lists.jboss.org Subject: Re: [jboss-as7-dev] Overriding Deployment Descriptors On Apr 5, 2012, at 10:17 AM, Carlo de Wolf wrote: > On 04/04/2012 05:01 PM, Max Rydahl Andersen wrote: >> And all this override would be via management API's, not doable with any deployment-scanner operations? >> >> i.e. can I do something like: >> >> cd overridestuff >> cp * to >> /data/contents/xyz.war/ >> >> >> now xyz.war has an "incomplete" override of xyz.war which will be >> "overlayed" on to deployment named xyz.war (independent on wether it >> comes from deployment scanner or management api) >> >> or is it all just via management api's that would need to be executed on every restart/change to the data/contents folder ? >> >> /max >> > > How about? > > standalone/deployments/xyz.war.part01/ > standalone/deployments/xyz.war.part02/ > standalone/deployments/xyz.war.part03/ > > touch standalone/deployments/xyz.war.dodeploy I like that but I thought these were ment to be put in a separate location than /deployments ? (if not then +1) /max _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Overriding descriptors is essentially a JSR 88 functionality.

So cracking open artifacts is not required. Fixing content is orthogonal to JSR 88. Hence a combined solution that can make sense. Carlo On 04/05/2012 11:51 AM, Max Rydahl Andersen wrote: > I actually agree with you here on the fact that deployment descriptors is really the last thing I would like to override. > I see much more relevance in fixing graphics or html content this way - but i'll let Brian outline what the specifics > of the user/customer requests have been. > > /max > >> Are you sure that this truly reflects what most users want? Are you not just >> adding a lot of complexity to cater for the whim of a small group of users? >> From what I can gather from this thread, the motivation for these overrides >> are rather thin. It is based on some users having a "policy" to not >> break-open deployment artefacts. How overriding is better or safer that >> "breaking open" escapes me at the moment. >> >> Very much part of the EJB specification is the definition of roles and >> responsibilities. As you know, it describes a definite role for composing >> (and by implication "breaking-open" to recompose) artefacts. If your >> configuration is too dynamic for this approach then it is a matter of >> application design to pick this up from elsewhere (DB or properties file). >> >> >> >> -----Original Message----- >> From: jboss-as7-dev-bounces(a)lists.jboss.org >> [mailto:jboss-as7-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl >> Andersen >> Sent: 05 April 2012 10:22 AM >> To: Carlo de Wolf >> Cc: jboss-as7-dev(a)lists.jboss.org >> Subject: Re: [jboss-as7-dev] Overriding Deployment Descriptors >> >> >> On Apr 5, 2012, at 10:17 AM, Carlo de Wolf wrote: >> >>> On 04/04/2012 05:01 PM, Max Rydahl Andersen wrote: >>>> And all this override would be via management API's, not doable with any >> deployment-scanner operations? >>>> i.e. can I do something like: >>>> >>>> cd overridestuff >>>> cp * to >>>> /data/contents/xyz.war/ >>>> >>>> >>>> now xyz.war has an "incomplete" override of xyz.war which will be >>>> "overlayed" on to deployment named xyz.war (independent on wether it >>>> comes from deployment scanner or management api) >>>> >>>> or is it all just via management api's that would need to be executed on >> every restart/change to the data/contents folder ? >>>> /max >>>> >>> How about? >>> >>> standalone/deployments/xyz.war.part01/ >>> standalone/deployments/xyz.war.part02/ >>> standalone/deployments/xyz.war.part03/ >>> >>> touch standalone/deployments/xyz.war.dodeploy >> I like that but I thought these were ment to be put in a separate location >> than /deployments ? (if not then +1) >> >> /max >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>

> On Apr 5, 2012, at 12:12 PM, Carlo de Wolf wrote: > >> Overriding descriptors is essentially a JSR 88 functionality. > I'm curious, what are the usecases in JSR 88 for this ? You tell the DeploymentManager to distribute the given module with an alternate deployment plan.

Carlo > > /max > >> So cracking open artifacts is not required. >> >> Fixing content is orthogonal to JSR 88. >> >> Hence a combined solution that can make sense. >> >> Carlo >> >> On 04/05/2012 11:51 AM, Max Rydahl Andersen wrote: >>> I actually agree with you here on the fact that deployment descriptors is really the last thing I would like to override. >>> I see much more relevance in fixing graphics or html content this way - but i'll let Brian outline what the specifics >>> of the user/customer requests have been. >>> >>> /max >>> >>>> Are you sure that this truly reflects what most users want? Are you not just >>>> adding a lot of complexity to cater for the whim of a small group of users? >>>> From what I can gather from this thread, the motivation for these overrides >>>> are rather thin. It is based on some users having a "policy" to not >>>> break-open deployment artefacts. How overriding is better or safer that >>>> "breaking open" escapes me at the moment. >>>> >>>> Very much part of the EJB specification is the definition of roles and >>>> responsibilities. As you know, it describes a definite role for composing >>>> (and by implication "breaking-open" to recompose) artefacts. If your >>>> configuration is too dynamic for this approach then it is a matter of >>>> application design to pick this up from elsewhere (DB or properties file). >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: jboss-as7-dev-bounces(a)lists.jboss.org >>>> [mailto:jboss-as7-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl >>>> Andersen >>>> Sent: 05 April 2012 10:22 AM >>>> To: Carlo de Wolf >>>> Cc: jboss-as7-dev(a)lists.jboss.org >>>> Subject: Re: [jboss-as7-dev] Overriding Deployment Descriptors >>>> >>>> >>>> On Apr 5, 2012, at 10:17 AM, Carlo de Wolf wrote: >>>> >>>>> On 04/04/2012 05:01 PM, Max Rydahl Andersen wrote: >>>>>> And all this override would be via management API's, not doable with any >>>> deployment-scanner operations? >>>>>> i.e. can I do something like: >>>>>> >>>>>> cd overridestuff >>>>>> cp * to >>>>>> /data/contents/xyz.war/ >>>>>> >>>>>> >>>>>> now xyz.war has an "incomplete" override of xyz.war which will be >>>>>> "overlayed" on to deployment named xyz.war (independent on wether it >>>>>> comes from deployment scanner or management api) >>>>>> >>>>>> or is it all just via management api's that would need to be executed on >>>> every restart/change to the data/contents folder ? >>>>>> /max >>>>>> >>>>> How about? >>>>> >>>>> standalone/deployments/xyz.war.part01/ >>>>> standalone/deployments/xyz.war.part02/ >>>>> standalone/deployments/xyz.war.part03/ >>>>> >>>>> touch standalone/deployments/xyz.war.dodeploy >>>> I like that but I thought these were ment to be put in a separate location >>>> than /deployments ? (if not then +1) >>>> >>>> /max >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>

Are you sure that this truly reflects what most users want? Are you not just adding a lot of complexity to cater for the whim of a small group of users? > From what I can gather from this thread, the motivation for these overrides are rather thin. It is based on some users having a "policy" to not break-open deployment artefacts. How overriding is better or safer that "breaking open" escapes me at the moment. Very much part of the EJB specification is the definition of roles and responsibilities. As you know, it describes a definite role for composing (and by implication "breaking-open" to recompose) artefacts. If your configuration is too dynamic for this approach then it is a matter of application design to pick this up from elsewhere (DB or properties file).

Customer requested feature is ability to externalize a file from a deployment archive and have it be an addition to the files in the archive or to override an existing file. Use cases: 1) Production: can't crack the deployment archive for policy reasons, but need to change some config. So they add an override deployment descriptor. This AIUI is the customer requested use case. 2) QE: override the production config to make some settings match the QE environment. 3) Dev: same as QE, but to match the dev environment. The original idea we had for this can be seen in the structure of a deployment=foo.war resource in the management API. It has a "content" attribute of type LIST. The LIST was to allow multiple pieces of content, the first being the archive, the rest being overrides. That's "approach 2)" in Stuart's original email in this thread. The new proposed approach (Stuart's "1)") is to have an entire new resource type, peer to deployment=foo.war, called dd-override=x. That resource would include attribute deployment=foo.war used to associate the override with a particular deployment. Both cases, the override descriptor would need to be uploaded to the server and stored in the data/contents dir, just like a deployment. I Either way, the user would need to use some sort of tooling to do the upload and associate the override descriptor with a deployment. Stuart's approach 1) is more deployment-scanner friendly. The user does whatever to get the override uploaded and registered. The scanner uploads the archive and tells the server to deploy it like it does now, and doesn't need to know anything about overrides. With approach 2) the scanner really can't handle it; it has no way to know two separate files it finds in the deployments/ dir are associated with each other. What I'm looking for is some perspective on how JBoss Tools would deal with this kind of feature. On 4/4/12 8:24 AM, Max Rydahl Andersen wrote: > Hi brian, > >> Max, any thoughts on this subject? I think a tooling perspective is critical here. > I'm trying to decipher the real question but seems i'm missing some context ;) > > Care to give a summary/hint ? > > /max > >> On 3/29/12 6:50 AM, Emanuel Muckenhuber wrote: >>> On 03/29/2012 05:12 AM, Stuart Douglas wrote: >>>> On 28/03/2012, at 5:48 AM, Emanuel Muckenhuber wrote: >>>>> The part i am trying to figure out is that we basically would have 2 >>>>> things doing the same. Another issue people are complaining about is >>>>> that we don't support symlinks in .war deployments. One of the easiest >>>>> ways to solve this would be to just mount a local file system path. >>>>> Where i am not sure if moving this to the dd-overrides makes more sense. >>>>> Hopefully i do remember correctly that we support VFS in our web >>>>> integration :) >>>>> >>>>> I think the dd-override sounds like less work in the beginning, but if >>>>> you include invalidation of overrides i am not sure if that is also true >>>>> for all the tooling. The deployment-scanner seems to be an edge case in >>>>> general, so perhaps we it can just adapt (be smarter) once we have some >>>>> other workflows. >>>>> >>>> I don't know if invalidation of the overrides is really that much of a problem. If you have to specify the overrides at deployment time then you need to make sure your environment is setup so that you will always provide that override file whenever you deploy, which means that for developers they would need tooling support, and for production they would need to have their deployment scripts setup to make sure that the override is always deployed with the deployment. Both of these use cases will still work with dd-override (i.e. you can just have tools or scripts to modify it every time before deployment). >>>> >>> Hmm, redeploying works through the :replace operation, which should >>> allow you to replace a single content-item, but preserve exiting ones. >>> So you would also have to provide it only once. >>> >>> But yeah, once you call :remove it would also invalidate all the >>> overrides. However the lifecycle seems more straightforward and there is >>> the option that you just disable the deployment as well. >>> >>> I do see that this does not work that well for the deployment-scanner, >>> but then there is no deployment-scanner in the domain. So for me that is >>> more an issue of the scanner and should perhaps better be solved there. >>> >>> Emanuel >>> >>>> If on the other hand these descriptors only change infrequent, then dd-override has a major advantage, in that it can just be setup once and then left alone. >>>> >>>> Stuart >>>> >>>> >>>>> On 03/27/2012 08:04 PM, Brian Stansberry wrote: >>>>>> It's not immediately critical. But a little voice inside my ear tells me >>>>>> we'll be *strongly* pressured to support it at some point. People love >>>>>> the deployment scanner. And I think once people get used to being able >>>>>> to have override descriptors they will love that as well. >>>>>> >>>>>> Override descriptors are very nice for keeping a base deployment but >>>>>> adapting it for different environments. I'd thought of it as more of a >>>>>> production thing (a workaround to a corporate policy that says a jar >>>>>> can't be cracked open and change) but David convinced me it's more of a >>>>>> developer or staging thing (override the production settings with >>>>>> dev-workstation-specific settings). And once you are talking developers, >>>>>> you are also talking deployment scanner. >>>>>> >>>>>> A big question I'd like to see talked through on this thread is how best >>>>>> to do tooling around this (including CLI and web console.) What's >>>>>> easiest for the user, in common workflows? >>>>>> >>>>>> In option 1, the dd-override is a separate resource from the deployment. >>>>>> That means it can be independently controlled. Good and bad there. Good, >>>>>> it can be added once and then left alone while the war, whatever is >>>>>> tweaked and redeployed many times. Bad, it's a separate thing. >>>>>> >>>>>> Conversely, with 2, the content items are part of a list attribute of >>>>>> the deployment resource. The good and bad points are the opposite of 1. >>>>>> >>>>>> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >>>>>>> Hmm, so we really have to support the deployment-scanner use case? I >>>>>>> mean beside some API/address differences - the (not implemented) >>>>>>> deployment content thing is basically doing the same. Just wondering if >>>>>>> i missed something obvious? >>>>>>> >>>>>>> >>>>>>> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>>>>>>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>>>>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>>>>>>> >>>>>>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>>>>>>> >>>>>>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>>>>>>> >>>>>>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>>>>>>> >>>>>>>>> e.g. to add the descriptor you would do something like: >>>>>>>>> >>>>>>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>> >>>>>>>>> or for domain mode >>>>>>>>> >>>>>>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>> >>>>>>>> For domain mode, this should be basically a parallel to the existing >>>>>>>> deployment=* handling: >>>>>>>> >>>>>>>> a) The override is a top level resource, adding an item to the >>>>>>>> "pallette" that is usable in any server-group: >>>>>>>> >>>>>>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>>>>>>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>> >>>>>>>> b) The server-group part is just a mapping that says "use this from the >>>>>>>> pallette: >>>>>>>> >>>>>>>> /server-group=foo/dd-override=my-deployment-descriptor:add >>>>>>>> >>>>>>>> Actually, this last bit is probably unnecessary, since the HC can figure >>>>>>>> out what dd-overrides are required from the deployment="test.ear" >>>>>>>> attribute on the dd-override=my-deployment-descriptor resource. >>>>>>>> >>>>>>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>>>>>>> >>>>>>>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>>>>>>> >>>>>>>>> What does everyone think? >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-as7-dev mailing list >>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat

I can definitely see how this would be useful though. > Now a tool can let the user choose subhandlers by finding all the > instances of custom-handler and file-handler. It then presents a pick > list of the handlers it found. The tool doesn't need any special > knowledge about handlers. It just knows how the list is defined and > acts accordingly. All the UI logic can be generated from the resource > description. > > And when you go to delete a handler, the management model will know that > an async handler has subhandler references pointing to it. So, it thows > an exception. > That's not the case, as the referent does not know what all refers to it. For example, there's no way socket-binding=* can know from its own static metadata what all the other resources are that might refer to a socket-binding. Some custom subsystem yet to be written by an end user may refer to it. The server itself needs to track that at runtime.

> On 4/4/2012 10:41 AM, Brian Stansberry wrote: >> Customer requested feature is ability to externalize a file from a >> deployment archive and have it be an addition to the files in the >> archive or to override an existing file. Use cases: >> >> 1) Production: can't crack the deployment archive for policy reasons, >> but need to change some config. So they add an override deployment >> descriptor. This AIUI is the customer requested use case. >> >> 2) QE: override the production config to make some settings match the QE >> environment. >> >> 3) Dev: same as QE, but to match the dev environment. >> >> The original idea we had for this can be seen in the structure of a >> deployment=foo.war resource in the management API. It has a "content" >> attribute of type LIST. The LIST was to allow multiple pieces of >> content, the first being the archive, the rest being overrides. That's >> "approach 2)" in Stuart's original email in this thread. >> >> The new proposed approach (Stuart's "1)") is to have an entire new >> resource type, peer to deployment=foo.war, called dd-override=x. That >> resource would include attribute deployment=foo.war used to associate >> the override with a particular deployment. >> >> Both cases, the override descriptor would need to be uploaded to the >> server and stored in the data/contents dir, just like a deployment. I >> >> Either way, the user would need to use some sort of tooling to do the >> upload and associate the override descriptor with a deployment. >> >> Stuart's approach 1) is more deployment-scanner friendly. The user does >> whatever to get the override uploaded and registered. The scanner >> uploads the archive and tells the server to deploy it like it does now, >> and doesn't need to know anything about overrides. With approach 2) the >> scanner really can't handle it; it has no way to know two separate files >> it finds in the deployments/ dir are associated with each other. >> >> What I'm looking for is some perspective on how JBoss Tools would deal >> with this kind of feature. >> >> On 4/4/12 8:24 AM, Max Rydahl Andersen wrote: >>> Hi brian, >>> >>>> Max, any thoughts on this subject? I think a tooling perspective is critical here. >>> I'm trying to decipher the real question but seems i'm missing some context ;) >>> >>> Care to give a summary/hint ? >>> >>> /max >>> >>>> On 3/29/12 6:50 AM, Emanuel Muckenhuber wrote: >>>>> On 03/29/2012 05:12 AM, Stuart Douglas wrote: >>>>>> On 28/03/2012, at 5:48 AM, Emanuel Muckenhuber wrote: >>>>>>> The part i am trying to figure out is that we basically would have 2 >>>>>>> things doing the same. Another issue people are complaining about is >>>>>>> that we don't support symlinks in .war deployments. One of the easiest >>>>>>> ways to solve this would be to just mount a local file system path. >>>>>>> Where i am not sure if moving this to the dd-overrides makes more sense. >>>>>>> Hopefully i do remember correctly that we support VFS in our web >>>>>>> integration :) >>>>>>> >>>>>>> I think the dd-override sounds like less work in the beginning, but if >>>>>>> you include invalidation of overrides i am not sure if that is also true >>>>>>> for all the tooling. The deployment-scanner seems to be an edge case in >>>>>>> general, so perhaps we it can just adapt (be smarter) once we have some >>>>>>> other workflows. >>>>>>> >>>>>> I don't know if invalidation of the overrides is really that much of a problem. If you have to specify the overrides at deployment time then you need to make sure your environment is setup so that you will always provide that override file whenever you deploy, which means that for developers they would need tooling support, and for production they would need to have their deployment scripts setup to make sure that the override is always deployed with the deployment. Both of these use cases will still work with dd-override (i.e. you can just have tools or scripts to modify it every time before deployment). >>>>>> >>>>> Hmm, redeploying works through the :replace operation, which should >>>>> allow you to replace a single content-item, but preserve exiting ones. >>>>> So you would also have to provide it only once. >>>>> >>>>> But yeah, once you call :remove it would also invalidate all the >>>>> overrides. However the lifecycle seems more straightforward and there is >>>>> the option that you just disable the deployment as well. >>>>> >>>>> I do see that this does not work that well for the deployment-scanner, >>>>> but then there is no deployment-scanner in the domain. So for me that is >>>>> more an issue of the scanner and should perhaps better be solved there. >>>>> >>>>> Emanuel >>>>> >>>>>> If on the other hand these descriptors only change infrequent, then dd-override has a major advantage, in that it can just be setup once and then left alone. >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>>> On 03/27/2012 08:04 PM, Brian Stansberry wrote: >>>>>>>> It's not immediately critical. But a little voice inside my ear tells me >>>>>>>> we'll be *strongly* pressured to support it at some point. People love >>>>>>>> the deployment scanner. And I think once people get used to being able >>>>>>>> to have override descriptors they will love that as well. >>>>>>>> >>>>>>>> Override descriptors are very nice for keeping a base deployment but >>>>>>>> adapting it for different environments. I'd thought of it as more of a >>>>>>>> production thing (a workaround to a corporate policy that says a jar >>>>>>>> can't be cracked open and change) but David convinced me it's more of a >>>>>>>> developer or staging thing (override the production settings with >>>>>>>> dev-workstation-specific settings). And once you are talking developers, >>>>>>>> you are also talking deployment scanner. >>>>>>>> >>>>>>>> A big question I'd like to see talked through on this thread is how best >>>>>>>> to do tooling around this (including CLI and web console.) What's >>>>>>>> easiest for the user, in common workflows? >>>>>>>> >>>>>>>> In option 1, the dd-override is a separate resource from the deployment. >>>>>>>> That means it can be independently controlled. Good and bad there. Good, >>>>>>>> it can be added once and then left alone while the war, whatever is >>>>>>>> tweaked and redeployed many times. Bad, it's a separate thing. >>>>>>>> >>>>>>>> Conversely, with 2, the content items are part of a list attribute of >>>>>>>> the deployment resource. The good and bad points are the opposite of 1. >>>>>>>> >>>>>>>> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote: >>>>>>>>> Hmm, so we really have to support the deployment-scanner use case? I >>>>>>>>> mean beside some API/address differences - the (not implemented) >>>>>>>>> deployment content thing is basically doing the same. Just wondering if >>>>>>>>> i missed something obvious? >>>>>>>>> >>>>>>>>> >>>>>>>>> On 03/27/2012 03:55 PM, Brian Stansberry wrote: >>>>>>>>>> On 3/27/12 12:34 AM, Stuart Douglas wrote: >>>>>>>>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought. >>>>>>>>>>> >>>>>>>>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process >>>>>>>>>>> >>>>>>>>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it. >>>>>>>>>>> >>>>>>>>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment. >>>>>>>>>>> >>>>>>>>>>> e.g. to add the descriptor you would do something like: >>>>>>>>>>> >>>>>>>>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>>>> >>>>>>>>>>> or for domain mode >>>>>>>>>>> >>>>>>>>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>>>> >>>>>>>>>> For domain mode, this should be basically a parallel to the existing >>>>>>>>>> deployment=* handling: >>>>>>>>>> >>>>>>>>>> a) The override is a top level resource, adding an item to the >>>>>>>>>> "pallette" that is usable in any server-group: >>>>>>>>>> >>>>>>>>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear", >>>>>>>>>> file="test.jar/META-INF/ejb-jar.xml", content=…) >>>>>>>>>> >>>>>>>>>> b) The server-group part is just a mapping that says "use this from the >>>>>>>>>> pallette: >>>>>>>>>> >>>>>>>>>> /server-group=foo/dd-override=my-deployment-descriptor:add >>>>>>>>>> >>>>>>>>>> Actually, this last bit is probably unnecessary, since the HC can figure >>>>>>>>>> out what dd-overrides are required from the deployment="test.ear" >>>>>>>>>> attribute on the dd-override=my-deployment-descriptor resource. >>>>>>>>>> >>>>>>>>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml. >>>>>>>>>>> >>>>>>>>>>> 2) is the approach that I prefer, as I think it gives the most flexibility. >>>>>>>>>>> >>>>>>>>>>> What does everyone think? >>>>>>>>>>> >>>>>>>>>>> Stuart >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-as7-dev mailing list >>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-as7-dev mailing list >>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>> _______________________________________________ >>>>>>> jboss-as7-dev mailing list >>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> -- >>>> Brian Stansberry >>>> Principal Software Engineer >>>> JBoss by Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

This is something of a different usage of references from elsewhere in the model though, which I see now is one reason why I was a bit uncomfortable about it. Elsewhere, if resource A needs resource B, it has a ref to B. Here we have B referring to A.

On Apr 4, 2012, at 6:06 PM, ssilvert(a)redhat.com wrote: > The tools can handle whatever you want to do, please don't say that - Just because you can, doesn't make it right :) /max