On Aug 21, 2009, at 4:11 PM, Marina Vatkina wrote:
> 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 :(.
>
indeed, I will add a Contract then
> Will this new LegacyConfigurationMigrator be of any help?
>
what is this ? I am not aware of it so far...
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>