Kedar Mhaswade wrote:
>
>
> Jerome Dochez wrote:
>>
>> On Feb 8, 2008, at 12:01 PM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Jerome Dochez wrote:
>>>> On Feb 8, 2008, at 9:56 AM, Kedar Mhaswade wrote:
>>>>>
>>>>>
>>>>> Jerome Dochez wrote:
>>>>>> are you changing any Config objects ? up to now, the domain tree
>>>>>> was unchanged when deploying, has this changed ?
>>>>>
>>>>> This is a good time to decide what we should do here. My feeling is
>>>>> that since config access has been improved in V3, we should have
>>>>> an app/module entry created in domain.xml during deployment
>>>>> and removed during undeployment.
>>>>>
>>>>> This also facilitates the target based deployment/undeployment.
>>>>>
>>>>> What do you think?
>>>> yes but not today, we need to have admin/deployment/containers in
>>>> sync to do that successfully....
>>> admin/deployment -- yes. Frankly, the admin adaptor that deals with
>>> (un)deployment (and all management) requests should call deployment
>>> code, which
>>> does not do anything with config (as in domain.xml), gets the status
>>> that
>>> deployment was successful or not and then modify the config
>>> (domain.xml)
>>> accordingly.
>>>
>>> So, I think this is really an admin/config issue and has nothing to do
>>> with containers. Am I missing something?
>> but how would the generic admin adapter know what config objects need
>> to be added/changed/removed ?
>>>
>
> I was referring to something like DeployCommand.java to do this.
> AdminAdaptor
> will end up calling DeployCommand for deployment purpose, right?
yes. but the deployment command does not have all the meta data that
would eventually be stored in the configuration, it's calculated along
the way of deployment,
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>