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