[brian.stansberry]

You're right; I think it's fine. I'd misunderstood what the validate(ControllerContext) call was really doing. I got sucked into a unrelated debugging fest today so haven't proved it yet, but it should be fine.

[emuckenhuber]

You're right; I think it's fine. I'd misunderstood what the validate(ControllerContext) call was really doing. I got sucked into a unrelated debugging fest today so haven't proved it yet, but it should be fine.

No problem, i've updated the xml format to use <hotdeployment-profile/> and stuff like that.
There are actually no changes to the testsuite prototype, as this is the default configuration :)
I like this, because it's also fitting good to my other stuff i'm working on in my sandbox...

So beside the weird implicit dependencies the xml format should not change much, maybe some optional attributes if needed.

One other issue related to your prototype - there is one major cleanup in the spi outstanding.
Basically i want to drop the VFSDeployment from the spi, as it should not be there.
This would also mean - that actually everything related to DeploymentRepositories would
get an implementation detail...
I still need to check how this would affect ManagementView and DeploymentManager,
but i doubt that we need the VFSDeployment there at all.

I guess you don't have a need for an VFSDeployment for your use case? well there will be a similar ProfileDeployment.

[emuckenhuber]

"emuckenhuber" wrote:

I guess you don't have a need for an VFSDeployment for your use case? well there will be a similar ProfileDeployment.

btw. the profile deployment will look something like this:

public interface ProfileDeployment
{
 String getName();
 VirtualFile getRoot();
 Map<String, Object> getAttachments();
 Object getAttachment(String name);
 Object addAttachment(String name, Object attachment);
}

The profile service takes care of transforming that into a VFSDeployment or normal deployment,
loading the persisted attachments and the usual stuff :)

[brian.stansberry]

"emuckenhuber" wrote:
I guess you don't have a need for an VFSDeployment for your use case? well there will be a similar ProfileDeployment.

No, I don't need VFSDeployment. My stuff 1) creates a ProfileMetaData from injected values, 2) asks and injected factory to create a Profile 3) calls ProfileService.register 4) calls ProfileService.activate. I don't care at all about the details of Profile, just need to have one to pass to register(). And 1,2 and 3 will go away once the XML-based approach works, at which point I'll just need to be able to create a ProfileKey to pass to activate(). :)

[brian.stansberry]

You're right; I think it's fine. I'd misunderstood what the validate(ControllerContext) call was really doing. I got sucked into a unrelated debugging fest today so haven't proved it yet, but it should be fine.

Just an update: as expected, this works fine. :-) I included a JMS queue in deploy-hasingleton, which got activated before the JBM server. Worked fine; when JBM got deployed the queue went through create and start.