I've been prototyping a CLI command that manages deployment overlays and got worried :) I think, the current representation (actually, the data structure, in other words) of the overlays and their linking in the management model will lead to a lot of issues related to consistency of the data and complicate management of deployments in general. Basically, it's a many-to-many relationship between overlays and deployments. Currently, overlays and deployments are defined separately and linked using the "third table", each row of which consists of a link name, overlay name and deployment name (or deployment name regex). (BTW, I understand this design is not random, there were reasons to organize it this way but I'd like to raise my concerns). Which is a common practice in a relational database design but our management model is not as sophisticated, yet :) We don't have: - foreign key constraints (again, yet, I know Brian is going to look into that); - no cascade-delete; - no queries (e.g. by node attributes). CREATING A LINK AND LOOKING FOR IT To create a link between an overlay and a deployment, I have to come up with a name for it, which has to be unique, like a primary key. Well, I chose the format overlay_name-deployment_name. Then, in CLI, I rely on this format to search for the link(s), since searching by resource attributes turns out to be much more complicated, although possible. Actually, even searching using this naming format by deployment name or an overlay name is not that smooth. So, the CLI now expects a specific naming format. Taking into account that the CLI is not the only management tool and that any application or user can manage things "manually", it'd be good for all the users and tools to agree on the naming format, which is not practical. REMOVING A DEPLOYMENT Until now it was about removing only the deployment. Now, not to run into inconsistencies in the model, the "third table" has to be searched for references and cleaned up if found. Removing an overlay leads to the same consequences, of course, which is unavoidable anyway. But I think we could re-organize the model to minimize the risks or running into inconsistencies and simplify management. ALTERNATIVE STRUCTURES I discussed these issues with Emanuel, who agreed and had in mind another idea to represent this in the model, which I actually find more logical and elaborate. I'll let him follow up and describe it in details. Thanks, Alexey _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Another issue related to this command and management of the overlay and links is that this command can't be a part of a batch because actions like create a new overlay with content and adding content to an existing overlay can't translate into a single composite operation, which a batch translates to. The problem is referencing results of one step in a composite operation from arguments of another step in the same composite operation. Alexey On 08/15/2012 04:11 PM, Alexey Loubyansky wrote: > I've been prototyping a CLI command that manages deployment overlays and > got worried :) > > I think, the current representation (actually, the data structure, in > other words) of the overlays and their linking in the management model > will lead to a lot of issues related to consistency of the data and > complicate management of deployments in general. > > Basically, it's a many-to-many relationship between overlays and > deployments. Currently, overlays and deployments are defined separately > and linked using the "third table", each row of which consists of a link > name, overlay name and deployment name (or deployment name regex). (BTW, > I understand this design is not random, there were reasons to organize > it this way but I'd like to raise my concerns). > > Which is a common practice in a relational database design but our > management model is not as sophisticated, yet :) We don't have: > - foreign key constraints (again, yet, I know Brian is going to look > into that); > - no cascade-delete; > - no queries (e.g. by node attributes). > > > CREATING A LINK AND LOOKING FOR IT > > To create a link between an overlay and a deployment, I have to come up > with a name for it, which has to be unique, like a primary key. Well, I > chose the format overlay_name-deployment_name. Then, in CLI, I rely on > this format to search for the link(s), since searching by resource > attributes turns out to be much more complicated, although possible. > Actually, even searching using this naming format by deployment name or > an overlay name is not that smooth. So, the CLI now expects a specific > naming format. Taking into account that the CLI is not the only > management tool and that any application or user can manage things > "manually", it'd be good for all the users and tools to agree on the > naming format, which is not practical. > > REMOVING A DEPLOYMENT > > Until now it was about removing only the deployment. Now, not to run > into inconsistencies in the model, the "third table" has to be searched > for references and cleaned up if found. > > Removing an overlay leads to the same consequences, of course, which is > unavoidable anyway. But I think we could re-organize the model to > minimize the risks or running into inconsistencies and simplify management. > > ALTERNATIVE STRUCTURES > > I discussed these issues with Emanuel, who agreed and had in mind > another idea to represent this in the model, which I actually find more > logical and elaborate. I'll let him follow up and describe it in details. > > Thanks, > Alexey > _______________________________________________ > 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

Deployments are different because /deployment=xxx:add(...) accepts content. Deployment overlays are created in two steps: - :upload-deployment-stream - read results of the above and use the checksums as arguments to the overlay/content:add(...) Yes, a workaround would be to add operations to overlays that would combine these actions. Or invest in transactions :)

On 08/15/2012 05:53 PM, Brian Stansberry wrote: > I don't quite understand this one. How is this different from > deployments? Is this just an issue of not having all the API options > available for adding overlays that we have for deployments? If so we can > solve that easily enough. > > On 8/15/12 9:57 AM, Alexey Loubyansky wrote: >> Another issue related to this command and management of the overlay and >> links is that this command can't be a part of a batch because actions >> like create a new overlay with content and adding content to an existing >> overlay can't translate into a single composite operation, which a batch >> translates to. >> >> The problem is referencing results of one step in a composite operation >> from arguments of another step in the same composite operation. >> >> Alexey >> >> On 08/15/2012 04:11 PM, Alexey Loubyansky wrote: >>> I've been prototyping a CLI command that manages deployment overlays and >>> got worried :) >>> >>> I think, the current representation (actually, the data structure, in >>> other words) of the overlays and their linking in the management model >>> will lead to a lot of issues related to consistency of the data and >>> complicate management of deployments in general. >>> >>> Basically, it's a many-to-many relationship between overlays and >>> deployments. Currently, overlays and deployments are defined separately >>> and linked using the "third table", each row of which consists of a link >>> name, overlay name and deployment name (or deployment name regex). (BTW, >>> I understand this design is not random, there were reasons to organize >>> it this way but I'd like to raise my concerns). >>> >>> Which is a common practice in a relational database design but our >>> management model is not as sophisticated, yet :) We don't have: >>> - foreign key constraints (again, yet, I know Brian is going to look >>> into that); >>> - no cascade-delete; >>> - no queries (e.g. by node attributes). >>> >>> >>> CREATING A LINK AND LOOKING FOR IT >>> >>> To create a link between an overlay and a deployment, I have to come up >>> with a name for it, which has to be unique, like a primary key. Well, I >>> chose the format overlay_name-deployment_name. Then, in CLI, I rely on >>> this format to search for the link(s), since searching by resource >>> attributes turns out to be much more complicated, although possible. >>> Actually, even searching using this naming format by deployment name or >>> an overlay name is not that smooth. So, the CLI now expects a specific >>> naming format. Taking into account that the CLI is not the only >>> management tool and that any application or user can manage things >>> "manually", it'd be good for all the users and tools to agree on the >>> naming format, which is not practical. >>> >>> REMOVING A DEPLOYMENT >>> >>> Until now it was about removing only the deployment. Now, not to run >>> into inconsistencies in the model, the "third table" has to be searched >>> for references and cleaned up if found. >>> >>> Removing an overlay leads to the same consequences, of course, which is >>> unavoidable anyway. But I think we could re-organize the model to >>> minimize the risks or running into inconsistencies and simplify management. >>> >>> ALTERNATIVE STRUCTURES >>> >>> I discussed these issues with Emanuel, who agreed and had in mind >>> another idea to represent this in the model, which I actually find more >>> logical and elaborate. I'll let him follow up and describe it in details. >>> >>> Thanks, >>> Alexey >>> _______________________________________________ >>> 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

We were mainly discussing the possibility of removing the deployment-overlay-links and "link" overlays directly from the deployment section of the model: <deployment name="myapp.war" ... <overrides> <override path="WEB-INF/lib" link="override2" /> <content path="WEB-INF/web.xml" content="83e4e22f3422267b" /> <file path="downloads" relative-to="download.file.path" /> </overrides> </deployment> So you would be able to configure overlays as part of the deployment as well as link to shared deployment-overlays. This obviously does not give you all the possibilities the deployment-overlay-links would, however it avoids a many-to-many relationship. From a tooling standpoint it should make it easier. I know we talked about something similar the last time we discussed overlays, but perhaps it's worth re-evaluating this with an actual mgmt client trying to impelement overlays.

On 08/15/2012 05:51 PM, Brian Stansberry wrote: > I want to hear Emanuel's ideas. > > But for sure we need to get rid of the requirement to give names to > links. Not just the need for some of rule for how the names are > constructed; we should get rid of the need for names altogether. > > On 8/15/12 9:11 AM, Alexey Loubyansky wrote: >> I've been prototyping a CLI command that manages deployment overlays and >> got worried :) >> >> I think, the current representation (actually, the data structure, in >> other words) of the overlays and their linking in the management model >> will lead to a lot of issues related to consistency of the data and >> complicate management of deployments in general. >> >> Basically, it's a many-to-many relationship between overlays and >> deployments. Currently, overlays and deployments are defined separately >> and linked using the "third table", each row of which consists of a link >> name, overlay name and deployment name (or deployment name regex). (BTW, >> I understand this design is not random, there were reasons to organize >> it this way but I'd like to raise my concerns). >> >> Which is a common practice in a relational database design but our >> management model is not as sophisticated, yet :) We don't have: >> - foreign key constraints (again, yet, I know Brian is going to look >> into that); >> - no cascade-delete; >> - no queries (e.g. by node attributes). >> >> >> CREATING A LINK AND LOOKING FOR IT >> >> To create a link between an overlay and a deployment, I have to come up >> with a name for it, which has to be unique, like a primary key. Well, I >> chose the format overlay_name-deployment_name. Then, in CLI, I rely on >> this format to search for the link(s), since searching by resource >> attributes turns out to be much more complicated, although possible. >> Actually, even searching using this naming format by deployment name or >> an overlay name is not that smooth. So, the CLI now expects a specific >> naming format. Taking into account that the CLI is not the only >> management tool and that any application or user can manage things >> "manually", it'd be good for all the users and tools to agree on the >> naming format, which is not practical. >> >> REMOVING A DEPLOYMENT >> >> Until now it was about removing only the deployment. Now, not to run >> into inconsistencies in the model, the "third table" has to be searched >> for references and cleaned up if found. >> >> Removing an overlay leads to the same consequences, of course, which is >> unavoidable anyway. But I think we could re-organize the model to >> minimize the risks or running into inconsistencies and simplify management. >> >> ALTERNATIVE STRUCTURES >> >> I discussed these issues with Emanuel, who agreed and had in mind >> another idea to represent this in the model, which I actually find more >> logical and elaborate. I'll let him follow up and describe it in details. >> >> Thanks, >> Alexey >> _______________________________________________ >> 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 big problem with this is that it does not work with the deployment scanner.

It also has to be specified on every re-deploy.

I think the simplest solution here is to just move the links under the deployment-overlays element and loose the flexibility to link at different levels. e.g: /deployment-overlay=myOverlay/deployment=test.war /deployment-overlay=myOverlay/deployment=*.jar

So what are we going to do here? Personally I much prefer the idea of having this stored in the model and linking it to a deployment, so the overlay lifecycle is not tied to that of the deployment. Another idea I had is that we could do something like define the overlays at domain level, but then define the links at server group or server level using the same name. basically something like: /deployment-overlay=myOverlay/content=WEB-INF/web.xml /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml /server-group=server-group1/deployment-overlay=myOverlay/deployment=test.war /server-group=server-group1/deployment-overlay=myOverlay/deployment=*.war For standalone they would just be combined, similar to what I had below: /deployment-overlay=myOverlay/content=WEB-INF/web.xml /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml /deployment-overlay=myOverlay/deployment=test.war /deployment-overlay=myOverlay/deployment=*.war Stuart On 17/08/2012, at 11:03 PM, Emanuel Muckenhuber <emuckenh(a)redhat.com&gt; wrote: > > On 08/17/2012 02:52 AM, Stuart Douglas wrote: >> The big problem with this is that it does not work with the deployment scanner. >> > > Yeah, the deployment-scanner is always a story for itself. However i think we could actually make it persist information and be aware of overlays. > > Having overlays as part of the deployment means the lifecycle is managed together, so the deployment-scanner could define it's own invalidation policy. May it be based on whether the content got removed or we have a specific marker for that. > > We could also think of providing a file-based overlay solution, managed by the deployment scanner only. In the end people use the deployment-scanner for a reason, so perhaps not having to worry about the model or "content" folder could be interesting. This would not even need to access persistent information though. Anyway just some ideas on the side. > >> It also has to be specified on every re-deploy. > > When you do a "remove" and "add" then yes. We do have specific operations to replace the content and redeploy the deployment without removing the information from the model. > >> I think the simplest solution here >> is to just move the links under the deployment-overlays element and loose the >> flexibility to link at different levels. e.g: >> >> /deployment-overlay=myOverlay/deployment=test.war >> /deployment-overlay=myOverlay/deployment=*.jar >> > > Yes, i was not really going for the simplest solution for now - this would most likely would be it :) _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

My main concern is regarding the domain mode, since the additional linking does not seem to be necessary to me and just additional steps mgmt clients have to take care of. Whereas the deployment-scanner is a single client for standalone, which is under our control. So i wanted to see if we there is a way we can make this work which also satisfies your use cases. I have two things in mind which i'll try to explain quickly: 1) you still link the overlays as part of the <deployment />, however the deploment-scanner is aware of that and won't remove deployments with overlays until you use a specific invalidation marker.

2) use overlay directories - this is more the file based approach, Where we just pick the "deployment.name + suffix" for the overlay. So there would be an automatic overlay/linking done by the deployment-scanner.

2.1) the overlay directory could be just a link to a virtual file (a shared <deployment-overlay />) [1] - so in this case the overlays are managed by the model and are not linked to the deployment lifecycle.

Those are half-backed ideas, not sure if any combination of those would work for you or would be really more interesting to the ones actually implementing the clients? Emanuel [1] <deployment-overlay name="deployment.scanner.overlay" > <overlay path="myApp.war" link="myApp-override" /> <overlay path="other.ear" link="other-override" /> </deployment-overlay> On 08/22/2012 01:03 AM, Stuart Douglas wrote: > > So what are we going to do here? Personally I much prefer the idea of having this stored in the model and linking it to a deployment, so the overlay lifecycle is not tied to that of the deployment. > > Another idea I had is that we could do something like define the overlays at domain level, but then define the links at server group or server level using the same name. basically something like: > > /deployment-overlay=myOverlay/content=WEB-INF/web.xml > /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml > > /server-group=server-group1/deployment-overlay=myOverlay/deployment=test.war > /server-group=server-group1/deployment-overlay=myOverlay/deployment=*.war > > For standalone they would just be combined, similar to what I had below: > > > /deployment-overlay=myOverlay/content=WEB-INF/web.xml > /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml > /deployment-overlay=myOverlay/deployment=test.war > /deployment-overlay=myOverlay/deployment=*.war > > > > Stuart > > On 17/08/2012, at 11:03 PM, Emanuel Muckenhuber <emuckenh(a)redhat.com&gt; wrote: > >> >> On 08/17/2012 02:52 AM, Stuart Douglas wrote: >>> The big problem with this is that it does not work with the deployment scanner. >>> >> >> Yeah, the deployment-scanner is always a story for itself. However i think we could actually make it persist information and be aware of overlays. >> >> Having overlays as part of the deployment means the lifecycle is managed together, so the deployment-scanner could define it's own invalidation policy. May it be based on whether the content got removed or we have a specific marker for that. >> >> We could also think of providing a file-based overlay solution, managed by the deployment scanner only. In the end people use the deployment-scanner for a reason, so perhaps not having to worry about the model or "content" folder could be interesting. This would not even need to access persistent information though. Anyway just some ideas on the side. >> >>> It also has to be specified on every re-deploy. >> >> When you do a "remove" and "add" then yes. We do have specific operations to replace the content and redeploy the deployment without removing the information from the model. >> >>> I think the simplest solution here >>> is to just move the links under the deployment-overlays element and loose the >>> flexibility to link at different levels. e.g: >>> >>> /deployment-overlay=myOverlay/deployment=test.war >>> /deployment-overlay=myOverlay/deployment=*.jar >>> >> >> Yes, i was not really going for the simplest solution for now - this would most likely would be it :) > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 08/23/2012 01:11 AM, Brian Stansberry wrote: > Sorry for the slow responses on this thread. > > I think we should go with Stuart's approach, particularly if Alexey is > comfortable that the CLI can support high level commands associated with it. > Yeah, i am fine then as well - nevertheless some comments inline :)

> > On 8/22/12 8:22 AM, Emanuel Muckenhuber wrote: >> >> My main concern is regarding the domain mode, since the additional >> linking does not seem to be necessary to me and just additional steps >> mgmt clients have to take care of. >> >> Whereas the deployment-scanner is a single client for standalone, which >> is under our control. So i wanted to see if we there is a way we can >> make this work which also satisfies your use cases. >> >> I have two things in mind which i'll try to explain quickly: >> >> 1) you still link the overlays as part of the <deployment />, however >> the deploment-scanner is aware of that and won't remove deployments with >> overlays until you use a specific invalidation marker. >> > > This requires that the overlays be controlled by the scanner as well. > Why? Because we don't persist the model resource for scanner-controlled > deployments. So if a user linked a non-scanner-controlled overlay to a > scanner controlled deployment (which seems quite rational if the overlay > involves some environmental settings that never change), the link > information will be lost on server reboot. > I know, but that's an ancient limitation. I guess we could just start to persist stuff.

>> 2) use overlay directories - this is more the file based approach, Where >> we just pick the "deployment.name + suffix" for the overlay. So there >> would be an automatic overlay/linking done by the deployment-scanner. >> > > Same issue as 1). > Not really. It can automatically recreate the overlays therefore it does not require persistent information.

>> 2.1) the overlay directory could be just a link to a virtual file (a >> shared <deployment-overlay />) [1] - so in this case the overlays are >> managed by the model and are not linked to the deployment lifecycle. >> > > I confess I don't understand this. In particular, how does it > fundamentally differ from what Stuart proposes in terms of how to > organize the data? > Well that is the point. It's basically the same, just that it removes the requirement for the additional linking in the domain.

>> On 08/22/2012 01:03 AM, Stuart Douglas wrote: >>> >>> So what are we going to do here? Personally I much prefer the idea of having this stored in the model and linking it to a deployment, so the overlay lifecycle is not tied to that of the deployment. >>> >>> Another idea I had is that we could do something like define the overlays at domain level, but then define the links at server group or server level using the same name. basically something like: >>> >>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml >>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml >>> >>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=test.war >>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=*.war >>> >>> For standalone they would just be combined, similar to what I had below: >>> >>> >>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml >>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml >>> /deployment-overlay=myOverlay/deployment=test.war >>> /deployment-overlay=myOverlay/deployment=*.war >>> >>> >>> >>> Stuart >>> >>> On 17/08/2012, at 11:03 PM, Emanuel Muckenhuber <emuckenh(a)redhat.com&gt; wrote: >>> >>>> >>>> On 08/17/2012 02:52 AM, Stuart Douglas wrote: >>>>> The big problem with this is that it does not work with the deployment scanner. >>>>> >>>> >>>> Yeah, the deployment-scanner is always a story for itself. However i think we could actually make it persist information and be aware of overlays. >>>> >>>> Having overlays as part of the deployment means the lifecycle is managed together, so the deployment-scanner could define it's own invalidation policy. May it be based on whether the content got removed or we have a specific marker for that. >>>> >>>> We could also think of providing a file-based overlay solution, managed by the deployment scanner only. In the end people use the deployment-scanner for a reason, so perhaps not having to worry about the model or "content" folder could be interesting. This would not even need to access persistent information though. Anyway just some ideas on the side. >>>> >>>>> It also has to be specified on every re-deploy. >>>> >>>> When you do a "remove" and "add" then yes. We do have specific operations to replace the content and redeploy the deployment without removing the information from the model. >>>> >>>>> I think the simplest solution here >>>>> is to just move the links under the deployment-overlays element and loose the >>>>> flexibility to link at different levels. e.g: >>>>> >>>>> /deployment-overlay=myOverlay/deployment=test.war >>>>> /deployment-overlay=myOverlay/deployment=*.jar >>>>> >>>> >>>> Yes, i was not really going for the simplest solution for now - this would most likely would be it :) >>> >> _______________________________________________ >> 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

I have done up an initial implementation of this here https://github.com/jbossas/jboss-as/pull/2989 . Stuart On 24/08/2012, at 2:08 AM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: > On 8/23/12 3:39 AM, Emanuel Muckenhuber wrote: >> On 08/23/2012 01:11 AM, Brian Stansberry wrote: >>> Sorry for the slow responses on this thread. >>> >>> I think we should go with Stuart's approach, particularly if Alexey is >>> comfortable that the CLI can support high level commands associated >>> with it. >>> >> >> Yeah, i am fine then as well - nevertheless some comments inline :) >> > > Me too. ;) > >>> >>> On 8/22/12 8:22 AM, Emanuel Muckenhuber wrote: >>>> >>>> My main concern is regarding the domain mode, since the additional >>>> linking does not seem to be necessary to me and just additional steps >>>> mgmt clients have to take care of. >>>> >>>> Whereas the deployment-scanner is a single client for standalone, which >>>> is under our control. So i wanted to see if we there is a way we can >>>> make this work which also satisfies your use cases. >>>> >>>> I have two things in mind which i'll try to explain quickly: >>>> >>>> 1) you still link the overlays as part of the <deployment />, however >>>> the deploment-scanner is aware of that and won't remove deployments >>>> with >>>> overlays until you use a specific invalidation marker. >>>> >>> >>> This requires that the overlays be controlled by the scanner as well. >>> Why? Because we don't persist the model resource for scanner-controlled >>> deployments. So if a user linked a non-scanner-controlled overlay to a >>> scanner controlled deployment (which seems quite rational if the overlay >>> involves some environmental settings that never change), the link >>> information will be lost on server reboot. >>> >> >> I know, but that's an ancient limitation. I guess we could just start to >> persist stuff. >> > > We'd have to persist some association between a deployment and a scanner > (e.g. scanner="default" on the deployment element) and then use that to > indicate that the server should not auto-deploy on boot but should defer > to the scanner to tell it what to do. And then alter the scanner to add > logic for it to reconcile the state it sees in the scan directory vs > what the model shows. > > Doable, but a fair bit of work. > > I considered this before going with the "don't persist" approach. I > don't recall though if there was some fundamental problem with it that > I'm not remembering, or if it was solely that "don't persist" was doable > within the time constraints. > >>>> 2) use overlay directories - this is more the file based approach, >>>> Where >>>> we just pick the "deployment.name + suffix" for the overlay. So there >>>> would be an automatic overlay/linking done by the deployment-scanner. >>>> >>> >>> Same issue as 1). >>> >> >> Not really. It can automatically recreate the overlays therefore it does >> not require persistent information. >> > > It can only recreate the association for overlays that it scans, not > ones that were added via CLI/console. > >>>> 2.1) the overlay directory could be just a link to a virtual file (a >>>> shared <deployment-overlay />) [1] - so in this case the overlays are >>>> managed by the model and are not linked to the deployment lifecycle. >>>> >>> >>> I confess I don't understand this. In particular, how does it >>> fundamentally differ from what Stuart proposes in terms of how to >>> organize the data? >>> >> >> Well that is the point. It's basically the same, just that it removes >> the requirement for the additional linking in the domain. >> > > Ok, then I still don't understand it. If it solves a problem I'd like to > understand. Can you explain further? > >>>> On 08/22/2012 01:03 AM, Stuart Douglas wrote: >>>>> >>>>> So what are we going to do here? Personally I much prefer the idea >>>>> of having this stored in the model and linking it to a deployment, >>>>> so the overlay lifecycle is not tied to that of the deployment. >>>>> >>>>> Another idea I had is that we could do something like define the >>>>> overlays at domain level, but then define the links at server >>>>> group or server level using the same name. basically something like: >>>>> >>>>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml >>>>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml >>>>> >>>>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=test.war >>>>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=*.war >>>>> >>>>> For standalone they would just be combined, similar to what I had >>>>> below: >>>>> >>>>> >>>>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml >>>>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml >>>>> /deployment-overlay=myOverlay/deployment=test.war >>>>> /deployment-overlay=myOverlay/deployment=*.war >>>>> >>>>> >>>>> >>>>> Stuart >>>>> >>>>> On 17/08/2012, at 11:03 PM, Emanuel Muckenhuber >>>>> <emuckenh(a)redhat.com <mailto:emuckenh@redhat.com>> wrote: >>>>> >>>>>> >>>>>> On 08/17/2012 02:52 AM, Stuart Douglas wrote: >>>>>>> The big problem with this is that it does not work with the >>>>>>> deployment scanner. >>>>>>> >>>>>> >>>>>> Yeah, the deployment-scanner is always a story for itself. >>>>>> However i think we could actually make it persist information and >>>>>> be aware of overlays. >>>>>> >>>>>> Having overlays as part of the deployment means the lifecycle is >>>>>> managed together, so the deployment-scanner could define it's own >>>>>> invalidation policy. May it be based on whether the content got >>>>>> removed or we have a specific marker for that. >>>>>> >>>>>> We could also think of providing a file-based overlay solution, >>>>>> managed by the deployment scanner only. In the end people use the >>>>>> deployment-scanner for a reason, so perhaps not having to worry >>>>>> about the model or "content" folder could be interesting. This >>>>>> would not even need to access persistent information though. >>>>>> Anyway just some ideas on the side. >>>>>> >>>>>>> It also has to be specified on every re-deploy. >>>>>> >>>>>> When you do a "remove" and "add" then yes. We do have specific >>>>>> operations to replace the content and redeploy the deployment >>>>>> without removing the information from the model. >>>>>> >>>>>>> I think the simplest solution here >>>>>>> is to just move the links under the deployment-overlays element >>>>>>> and loose the >>>>>>> flexibility to link at different levels. e.g: >>>>>>> >>>>>>> /deployment-overlay=myOverlay/deployment=test.war >>>>>>> /deployment-overlay=myOverlay/deployment=*.jar >>>>>>> >>>>>> >>>>>> Yes, i was not really going for the simplest solution for now - >>>>>> this would most likely would be it :) >>>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> >>> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@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 <mailto:jboss-as7-dev@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