Jerome Dochez wrote:
>
> On Feb 13, 2009, at 10:33 AM, Marina Vatkina wrote:
>
>> Jerome Dochez wrote:
>>
>>> On Feb 13, 2009, at 10:18 AM, Marina Vatkina wrote:
>>>
>>>> Jerome Dochez wrote:
>>>>
>>>>> On Feb 13, 2009, at 7:10 AM, Hong Zhang wrote:
>>>>>
>>>>>> Hi, Jerome
>>>>>> We probably also need some undeployment events.
>>>>>
>>>>>
>>>>> maybe but not for CMP case...
>>>>
>>>>
>>>>
>>>> Especially for the CMP case ;)
>>>>
>>>>>> I know cmp code needs to get the undeployment events for
>>>>>> dropping tables in v2. Actually now to think of it, maybe we
>>>>>> should just add a CMP Deployer to create/delete tables? When
>>>>>> will adding the Deployer more appropriate than using events in
>>>>>> the current infrastructure?
>>>>>>
>>>>> Deployers are the only supported way to add containers to v3,
>>>>> these events should not be used to deploy stuff, because we
>>>>> would not be able to register the Engine in the domain.xml and
>>>>> other important things.
>>>>> For CMP, they need a CMPDeployer and with Origin.unload and
>>>>> Origin.undeploy. they should now when to drop tables or not. Same
>>>>> for creating with load/deploy
>>>>
>>>>
>>>>
>>>> We were creating tables when all the rest of the deployment
>>>> succeeded. If we create tables during CMP jar deploy, but the
>>>> deployment fails at the end for some reason, the tables are left
>>>> behind.
>>>
>>> no they are not, if the deployment fail, your Deployer's clean
>>> method will be called and when you receive a clean() call with a
>>> Origin.Deploy or Origin.Load, you know something went really wrong
>>> during deployment, and you are being rollbacked
>>
>>
>> Not always - if the setting is to create the tables but not drop - in
>> v2 we won't even attempt to create them.
>
> ok my point is that you can get notified that a deployment operation
> failed and you have the opportunity to do whatever need/want to do.
Not quite, but we can talk about that later.
Can clean() behave like afterCompletion() and pass fail or success into it, but
be called anyway?
thanks,
-marina
>
>>
>>
>>>> I think we dropped the tables the 1st thing during the undeploy.
>>>>
>>> why do it matter when you drop the tables ?
>>
>>
>> Because the .sql files and any DDs are still there.
>
> the files are cleaned after the deployer's clean() methods are called
> so it should not be a problem.
>
>>
>>>> Also we were able to report a problem during this process without
>>>> causing the deploy/undeploy to fail.
>>>>
>>> sure your clean() method can issue warnings still not failing
>>> undeployment.
>>
>>
>> Will we need to remember the messages until then? Can Report
>> accumulate the messages (and report them even in case of a success)?
>>
> yes you can use sub reports for that.
>
>> thanks,
>> -marina
>>
>>>> thanks,
>>>> -marina
>>>>
>>>>> jerome
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Hong
>>>>>>
>>>>>>> A number of people have been asking for some new events to be
>>>>>>> sent when deployment is happening
>>>>>>>
>>>>>>> I have added 3 events that will be sent for each deployment
>>>>>>>
>>>>>>> Those events are defined in the
>>>>>>> org.glassfish.internal.deployment.Deployment contract definition
>>>>>>>
>>>>>>> public final EventTypes<ExtendedDeploymentContext>
>>>>>>> DEPLOYMENT_START
>>>>>>> public final EventTypes<ExtendedDeploymentContext>
>>>>>>> DEPLOYMENT_FAILURE
>>>>>>> public final EventTypes<ApplicationInfo> DEPLOYMENT_SUCCESS
>>>>>>>
>>>>>>> to be able to be notified of any application being deployed,
>>>>>>> you can just do
>>>>>>>
>>>>>>> @Inject
>>>>>>> Events events;
>>>>>>>
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>> events.register(new EventListener() {
>>>>>>> public void event(Event e) {
>>>>>>> if (e.is(Deployment.DEPLOYMENT_START)) {
>>>>>>> System.out.println("new deployment detected");
>>>>>>> }
>>>>>>> }
>>>>>>> });
>>>>>>>
>>>>>>> Each even carries the ExtendedDeploymentContext object which
>>>>>>> has all relevant information about what's being deployed
>>>>>>> which can be accessed typed safely like that :
>>>>>>> ExtendedDeploymentContext dc =
>>>>>>> Deployment.DEPLOYMENT_START.getHook(e);
>>>>>>>
>>>>>>> Also some folks have been willing to know what caused a
>>>>>>> deployment operation to happen. For instance there is
>>>>>>> different between first time deployment and loading when
>>>>>>> server restart. In order to disambiguate, each deployment
>>>>>>> operation has an origin attribute which identified what
>>>>>>> caused the deployment operation.
>>>>>>>
>>>>>>> public enum Origin { load, deploy, unload, undeploy }
>>>>>>>
>>>>>>> so say you want to have code that do something when you are in
>>>>>>> deploy (versus just a server restart), you would do with a
>>>>>>> DeploymentContext (dc)
>>>>>>> DeployCommandParameters params =
>>>>>>> dc.getCommandParameters(DeployCommandParameters.class);
>>>>>>> switch(params.origin) {
>>>>>>> case Origin.Deploy :
>>>>>>> System.out.println("This is a first time deployment
>>>>>>> of this operation");
>>>>>>> break;
>>>>>>> case Origin.Load :
>>>>>>> System.out.println("this is a reload after server
>>>>>>> restart or disable/enable");
>>>>>>> break;
>>>>>>> }
>>>>>>> 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
>