Stable deployment API for tools

[jason.greene]

The tools team is concerned that the profile service is too much of a moving target, and that they need a stable API & protocol that is BC across minor releases.

Since their usage is limited to basic deployment (they actually preferred using JMX), should we consider a simple wrapper service API for this use-case? It would then be much easier to guarantee backwards compatibility.

[starksm64]

Yes, I was thinking of this today as a simple facade that would avoid introducing a dependency on the deployment manager stuff that is in progress. Define the mbean interface they need and we'll validate it and get some tests in the as testsuite for it.

[maxandersen]

Things that we do today on AS 4.x:

We "deploy" by copying files. We rely on both zipped and exploded deployments and even copies -ds.xml files for easy configuration.

Add an url for deployment location so we can avoid "polluting" the default/deploy directory

suspend/restart hotdeploy scanning to avoid unnecessary restarts while we are copying files
(even if we got an option for doing 100% remote deploy instead of file copy I still think file copy should be supported since it is the *simple* and works 99,9% of the time)


Things that would be really nice to do:

Do a remote deploy for remote systems and be able to somehow control where it gets "copied" or at least get info on where a deployment is located.

Get stacktrace/exceptions/logging per deployment so we can do a better error tracing than just tell them to look in the console. (this could be as simple as have a log file or folder per deployment instead of all munged together). Actual exceptions occurring doing runtime would help a lot too.

[starksm64]

Ok, I'll propose and mbean interface for this shortly.

[adrian.brock]

Ok, I'll propose and mbean interface for this shortly.

But why not just use jsr88? That should work in all versions of JBoss whether it is
implemented on top of the legacy DeploymentManagerService or the ProfileService.

The legacy implementation already has all the features Max is asking for,
except the remote/isolated logging stuff. You do get deployment exceptions.

Even if you don't like the jsr88 api you could use the DeploymentManagerService directly.
http://www.jboss.org/community/docs/DOC-9553
It should then just be a case of re-implementing it at some point on top of the
profile service so that those deployments become manageable in the console
(i.e. the profile service knows about them).

[emuckenhuber]

Ok, I'll propose and mbean interface for this shortly.

Hmm but JSR88 or DeploymentManager seem to provide those nice-to-have already ? (well maybe not fully implemented but still :)
Beside that we still need to integrate JSR88 properly into the ProfileService.

I mean we can also just expose HDScanner in JMX, as the legacy MainDeployer(MBean) should be still there,
as the testsuite is also using that.

[starksm64]

Ok, so an mbean variation of the DeploymentManager is the starting point. We just need some variation of the existing DeployUnitTestCase to validate the tools api usage is stable.

[maxandersen]

with respect to JSR-88 then that was attempted once a loong time ago and the conclusion back then was that it only seemed to implement just enough for the TCK to pass but when trying to actually use it that just failed.

And when we then were told it was not supported and not really something we thought would be living on it was dropped.

If that has changed then cool.

[jason.greene]

Also FYI, JSR88 will be removed from EE7, although we have quite a ways to go for that :)

[jason.greene]

This work is a blocker for 5.1 CR1

https://jira.jboss.org/jira/browse/JBAS-6330

[alesj]

Where in jbossas should I put this interface(s)?

[maxandersen]

While we are at it any chance this could be isolated into a jar that could be placed in a 5.0.x AS and have the api work there too ? (just a wish ;)

[alesj]

Sure, I can try to port the changes back to 5_0.
And just implement proper facade on top for existing 5.0 profile service integration.