Jerome Dochez wrote:
>
> On Aug 19, 2009, at 11:12 AM, Marina Vatkina wrote:
>
>> Marina Vatkina wrote:
>>
>>> Jerome Dochez wrote:
>>>
>>>>
>>>> On Aug 11, 2009, at 1:26 PM, Marina Vatkina wrote:
>>>>
>>>>> Hi Jerome,
>>>>>
>>>>> Will the called code know that it's an undeploy for upgrade (so
>>>>> that we don't drop the tables) and deploy for it (so that we
>>>>> don't create ones)?
>>>>
>>>>
>>>>
>>>> yes, please specify any non default re-deployment options you want
>>>> to have specified for this upgrade redeployment so we make sure
>>>> it's part of the command invocation.
>>>
>>> Everything 'table' related (dropandcreate/drop/create/) should be
>>> explicitly set to false.
>>> For the EJB timer service, that in v3 is loaded on demand only,
>>> we'll need to figure out the point at which to alter the table to be
>>> v3 compatible.
>>
>>
>> Is it possible to have a callback after the domain.xml had been
>> upgraded and I can lookup a resource and get a connection? I need
>> this to happen before redeploy of the user apps.
>>
> no it's not possible right now. Why do you need to do this ?
Because a) the table for the Timer app has changed, and in v2 (and prior) it was
always created, even if no user app would use it, and b) EclipseLink can't
modify a table in java2db mode, only drop and create (but we can't drop as there
might be data).
If there were ejb apps that already used the timer service, on their redeploy
for upgrade, the new timer app will be deployed, and I could try to figure out
how to do modify instead of create at that point.
If there were no users, this logic would become much more complicated as it
would need to happen on the regular 1st deploy of an app that uses ejb timers.
It'd be easier to do an explicit step of looking up the datasource, (hopefully)
identifying the database vendor, and executing a prepared in advance sql to
alter the table.
Regards,
-marina
>
> jerome
>
>> thanks,
>> -marina
>>
>>> thanks,
>>> -marina
>>>
>>>>
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>>> Jerome Dochez wrote:
>>>>>
>>>>>> Hi all
>>>>>> During my last engineering meeting, we talked about upgrade and
>>>>>> the necessity to redeploy applications. After talking to Hong
>>>>>> and experimenting, we have decided to have this redeployment
>>>>>> happen internally during the asadmin start-domain --upgrade call.
>>>>>> This does not change anything for containers as these internal
>>>>>> redeployments will not be any different than a normal
>>>>>> redeployment invoked externally through an asadmin command for
>>>>>> instance.
>>>>>> Let me know if you have any questions.
>>>>>> jerome
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>