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. I think we dropped the tables the 1st
thing during the undeploy.
Also we were able to report a problem during this process without causing the
deploy/undeploy to fail.
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
>