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

Thu Sep 6 10:53:56 EDT 2012

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 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
>>>>
>>
>>

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat