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 :)
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.
> 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.
> 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.
> 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>
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
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>