Re: [jboss-as7-dev] problems with deployment overlays and linking

So, do you have any objections to merging Stuart's patch? On 9/5/12 10:39 AM, Alexey Loubyansky wrote: > Ok, I finally made it work in the domain mode. Here > https://github.com/aloubyansky/jboss-as/commits/deployment-overlay > > I am not so happy with domain mode, though. I mean the command itself, > its syntax. So, I'll need to think a bit more about the usability. > In the domain mode it requires --server-group and targets only one > server group at a time. Unless, it is a remove, it can remove from > everywhere in one go. > > Standalone mode is straightforward. > > I updated the help for the command too. It's long and confusing :) It'll > need some more work. > > If somebody wants to try it and give feedback, you are very welcome. > I'll explain everything :) > > Thanks, > Alexey > > On 08/31/2012 06:28 PM, Brian Stansberry wrote: >> Do you see value in cherry-picking his patch and adjusting the command >> first? The issues you find implementing the command are what led to >> these changes, so it'd be nice to know your commands work before merging >> his stuff. >> >> On 8/31/12 5:03 AM, Alexey Loubyansky wrote: >>> Great. Once it's merged I'll adjust the deployment-overlay command and >>> submit a pull request. >>> >>> Thanks, >>> Alexey >>> >>> On 08/31/2012 05:29 AM, Stuart Douglas wrote: >>>> >>>> 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 >>>> >> >>