Bringing the trunk profile service changes to 5_x

[starksm64]

I took a look at merging the current trunk profile service changes into the Branch_5_x using just the 6.0.0.Alpha3 org.jboss.integration:jboss-profileservice-spi, but I see it has dependencies on updated deployer classes like org.jboss.deployers.client.plugins.deployment.AbstractDeployment. Are we going to be able to update the deployers and related jars?

This is just the system subproject so far.

[emuckenhuber]

I took a look at merging the current trunk profile service changes into the Branch_5_x using just the 6.0.0.Alpha3 org.jboss.integration:jboss-profileservice-spi, but I see it has dependencies on updated deployer classes like org.jboss.deployers.client.plugins.deployment.AbstractDeployment. Are we going to be able to update the deployers and related jars?

Hmm actually the idea was to make the spi independent of the deployers project.
Therefore we might want to drop the AttachmentStore from the spi, because it's actually creating a real Deployment.

Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
Which is then the last thing referencing a VFSDeployment.

The implementation uses the AbstractDeployment only because there is no DeploymentFactory.getInstance(),
but shouldn't the AbstractDeployment already be in 5_x?

[starksm64]

"emuckenhuber" wrote:

Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
Which is then the last thing referencing a VFSDeployment.

The notion was that the template might need to create the attachments that define the deployment after it has a VFSDeployment because it may not have put out enough information in the VirtualFile returned by the first phase when applyTemplate was called. A template may not want to have a complete xml or file based view of the properties what it writes out.

"emuckenhuber" wrote:

The implementation uses the AbstractDeployment only because there is no DeploymentFactory.getInstance(),
but shouldn't the AbstractDeployment already be in 5_x?

Yes, I found it. I thought it was in jboss-deployers-client-spi.jar, but turns out its in
jboss-deployers-client.jar so its just that the system subproject dependencies did not include this.

[brian.stansberry]

Just an FYI, using the profile-service-spi currently in trunk plus subclassing a couple classes in system, I'm able to pretty simply get the required services in place to do what I want for an AS 5.1 clustered deployment repository. See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150107.

[emuckenhuber]

Just an FYI, using the profile-service-spi currently in trunk plus subclassing a couple classes in system, I'm able to pretty simply get the required services in place to do what I want for an AS 5.1 clustered deployment repository.

Okay good, the current plan is that i'll start to port the changes from trunk to the 5.1 branch by the end of this week or starting next week.
So we can also take a look then if there is still something missing for you.

[emuckenhuber]

"emuckenhuber" wrote:

Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
Which is then the last thing referencing a VFSDeployment.

The notion was that the template might need to create the attachments that define the deployment after it has a VFSDeployment because it may not have put out enough information in the VirtualFile returned by the first phase when applyTemplate was called. A template may not want to have a complete xml or file based view of the properties what it writes out.

Hmm looking at applyTemplate() in ManagementView again, i noticed that applyTemplate() is actually creating a real file in a profile and therefore bypassing the minimal synchronization we have for ModifiedDeployments.

I think it would make more sense to use the DeploymentManager for this.
So it could write the template into a temp file and then use deploymentManager to distribute and deploy it?

[starksm64]

"emuckenhuber" wrote:

Hmm looking at applyTemplate() in ManagementView again, i noticed that applyTemplate() is actually creating a real file in a profile and therefore bypassing the minimal synchronization we have for ModifiedDeployments.

I think it would make more sense to use the DeploymentManager for this.
So it could write the template into a temp file and then use deploymentManager to distribute and deploy it?

Yes, makes sense. The templating was written before we created the DeploymentManager.

[emuckenhuber]

Hmm we could do it somehow like this:

public interface DeploymentTemplate
{
 // Get the deployment info
 DeploymentTemplateInfo getInfo();

 // Get the deployment name
 String getDeploymentName(String baseName);

 // Apply template
 VirtualFile applyTemplate(DeploymentTemplateInfo info);
}

Where managementView is more or less doing this:

 // Create a temp deployment
 VirtualFile vf = template.applyTemplate(deploymentInfo);
 // Get the deployment name
 String deploymentName = template.getDeploymentName(baseName);
 // Distribute deployment
 deploymentMgr.distribute(deploymentName, vf.toURL(), true);
 // Start deployment
 deploymentMgr.start(deploymentName);
 // Delete temp deployment
 vf.delete();

Although now i really don't know where to put this updateTemplateDeployment(VFSDeployment ctx, DeploymentTemplateInfo values);
IMO a deployment template does not need to know where it gets copied to. Furthermore it won't have access to the DeploymentContext until it's deployed anyway.
Also adding something to the deployments attachment would not make much sense, as it will get lost during the next startup.
I think additional updates to this template should use updateComponent() and be stored as a attachment.

There is also this in the SPI:

 * TODO: this needs to be fleshed out in terms of the various pieces, raw deployment
 * files, ManagedObjects, etc.

not sure what you mean by that - so is there still something missing?