dev@glassfish.java.net

Re: slides Re: V3 Upgrade Service TOI Thur Jul 23 11:00 PT

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Thu, 06 Aug 2009 13:21:27 -0700

we will do "redeployment". it is still unclear if this will have to be
done externally by the upgrade tool or if it will be done internally
when the server is called with --upgrade.

We should have a decision this week.

jerome

On Aug 6, 2009, at 10:14 AM, Mitesh Meswani wrote:

> That is a possible solution. However, we will need to adjust code
> gen logic for cmp which executes at deploy time. I think other
> container will need adjustment too. We will also need to test it
> thoroughly to make sure that nothing is broken because of lazy code
> gen. Do we want to make such drastic change so late in project? Lets
> wait for Jerome to get back. Here is last note from him
> /
> I need to talk with Rebecca about this, clearly not redeploying upon
> upgrade is a tough proposition for deployment back end and
> containers so we may revisit that decision. stay tuned.
> /
>
> Thanks,
> Mitesh
> kedar wrote:
>> One of the facets of generated code we discussed was that we generate
>> the code when needed rather than doing that at deployment time. I
>> think
>> we are removing the generated folder (that holds generated artifacts)
>> during upgrade -- if that's true, shouldn't code gen happen at the
>> runtime
>> in which case, it will create code that is aligned with runtime's
>> version.
>>
>> -Kedar
>>
>>> Mitesh Meswani wrote:
>>>> Hi Rebecca, Jerome,
>>>>
>>>> Any update on this subject?
>>>>
>>>> Thanks,
>>>> Mitesh
>>>>
>>>> Jerome Dochez wrote:
>>>>> I need to talk with Rebecca about this, clearly not redeploying
>>>>> upon upgrade is a tough proposition for deployment back end and
>>>>> containers so we may revisit that decision. stay tuned.
>>>>>
>>>>> jerome
>>>>>
>>>>> On Jul 26, 2009, at 11:07 PM, Mitesh Meswani wrote:
>>>>>
>>>>>> Jerome Dochez wrote:
>>>>>>>
>>>>>>> On Jul 23, 2009, at 12:41 PM, Mitesh Meswani wrote:
>>>>>>>
>>>>>>>> Jerome, Rebecca,
>>>>>>>>
>>>>>>>> During the TOI, it was stated that upgrade tool will not
>>>>>>>> redeploy applications after upgrade. CMP code gen (which
>>>>>>>> happens at deployment time) has changed to adept with V3
>>>>>>>> changes. How do we handle this scenario for upgrade ?
>>>>>>> do we have a way to know that which applications have old CMP
>>>>>>> code (without loading the DOL) ?
>>>>>> We can definitely dig up something or introduce code which
>>>>>> identifies that app as being deployed on V3.
>>>>>>
>>>>>> What are you hinting at?
>>>>>>
>>>>>> Thanks,
>>>>>> Mitesh
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mitesh
>>>>>>>>
>>>>>>>>
>>>>>>>> Rebecca Searls wrote:
>>>>>>>>> slides attached
>>>>>>>>>
>>>>>>>>> On 07/22/09 16:26, Rebecca Searls wrote:
>>>>>>>>>> On 07/21/09 13:47, Rebecca Searls wrote:
>>>>>>>>>>>
>>>>>>>>>>> For those who missed the first presentation. Here is the
>>>>>>>>>>> second one.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please join me Thur Jul 23 from 11:00-12:00am PT to learn
>>>>>>>>>>> about the API
>>>>>>>>>>> each module *must* implement to support domain
>>>>>>>>>>> upgrades in V3.
>>>>>>>>>>>
>>>>>>>>>>> V3's design model requires a new way of performing
>>>>>>>>>>> domain upgrades.
>>>>>>>>>>> Modules are required to implement a new service to
>>>>>>>>>>> support domain
>>>>>>>>>>> upgrade functionality. This TOI will present the API
>>>>>>>>>>> that must
>>>>>>>>>>> be implemented, discuss how to test your
>>>>>>>>>>> implementations, and
>>>>>>>>>>> answer your questions.
>>>>>>>>>>>
>>>>>>>>>>> Slides will be available day of the TOI.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Date: Thur Jul 23
>>>>>>>>>>> Time: 11:00-12:00am PT
>>>>>>>>>>> Toll-free ( US) 866-545-5227
>>>>>>>>>>> International number 215-446-3648
>>>>>>>>>>> Passcode: 5933769
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>