IIRC, your proposal was to leverage this interface to support legacy
set/get dotted names. I don't quite remember what else is needed in
normal domain.xml upgrade on server startup. can you clarify ?
On Aug 24, 2009, at 11:19 AM, Justin Lee wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>