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

Wed Sep 5 11:39:10 EDT 2012

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