there is no callback but you can add this upgrade code inside the
UpgradeStartup in kernel module, right at the beginning of the start()
method, this is where the domain.xml has finished upgrading but the
apps are not redeployed yet.
jerome
On Aug 21, 2009, at 10:01 AM, Marina Vatkina wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>