You don't want that code to depend on persistence or connector code that would
identify the vendor and perform sql operations, don't you? I.e. I need to
implement an interface and be indeed called back :(.
Will this new LegacyConfigurationMigrator be of any help?
thanks,
-marina
Jerome Dochez wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>