Note that that particular issue hasn't been approved officially, per se,
but grew out of an email thread where it got inital approval. I'd like
for it to be as I'm making a change now that could really benefit from
it. If further discussion is needed, perhaps we can talk about it at
the eng. meeting tomorrow? Or I could go ahead and implement that and
use it.
Marina Vatkina wrote:
> Jerome Dochez wrote:
>>
>> 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...
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9219
>
>>
>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>