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.
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.
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.
Those are half-backed ideas, not sure if any combination of those would
work for you or would be really more interesting to the ones actually
implementing the clients?
Emanuel
[1]
<deployment-overlay name="deployment.scanner.overlay" >
<overlay path="myApp.war" link="myApp-override" />
<overlay path="other.ear" link="other-override" />
</deployment-overlay>
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 :)