For the upgrade process, i have no idea how this would apply. We
already have interfaces in place to do schema upgrades in that case.
Marina brought it up and I just wanted to clarify that this idea hadn't
officially been approved yet.
Jerome Dochez wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>