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

Fri Aug 31 08:17:27 EDT 2012

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 at redhat.com
> <mailto:brian.stansberry at 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 at redhat.com <mailto:emuckenh at 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 at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at 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 at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>