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

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 >