JBIDE-3394, hot deployment management api

[starksm64]

The tools integration layer is relying on the jboss.deployment:flavor=URL,type=DeploymentScanner MBean start / stop / addURL service methods. In JBossAS 5 this corresponds to the HDScanner bean start/stop methods, but it no longer is what controls what the hot deployment directories are. That is now part of the profile, and its not property exposed via a management api.

The should be a ManagedObject view that supports this capability, and there could be a corresponding MBean facade that allow JMX based clients to not have to convert to the profile service api.

Its clear we need testcases for the apis that JBIDE is relying on as well.

[starksm64]

JBAS-6323 is a task to validate the apis and create testcases for those that should be supported.

[maxandersen]

So there is no way (not even a hacky one) to modify/query about hot deployment directories in AS 5 ?

[rob.stryker]

Scott:

I can write my own MBean exposing my own interface and deploy it via the tools automatically (since the tools are meant to be for dev-time). All I'd need is for you to point out to me either a test case or a code snippet for each of the following four tasks:

1) add a folder to the scanner list
2) remove a folder from the scanner list
3) suspend the scanner
4) resume the scanner

[starksm64]

Scott:
All I'd need is for you to point out to me either a test case or a code snippet for each of the following four tasks:

I'll create a testcase for this.
https://jira.jboss.org/jira/browse/JBAS-6330

I think something can be hacked together that should work with the current GA, but we need to expose a proper management interface to avoid having to dive into implementation details as is the case now.

More generally, we need to make sure tools is involved in the discussion around the embedded changes as unit testing and dev tools are one of the primary use cases.

[maxandersen]

I would *really* like to avoid us having to deploy *anything* on a server to manage these things.
Deploying something like that is a road to endless support issues.

I would rather not have this feature in the tools if there is no other way - but from the sound of Scott it sounds like we could do something ?

[emuckenhuber]

I would *really* like to avoid us having to deploy *anything* on a server to manage these things.
Deploying something like that is a road to endless support issues.

I would rather not have this feature in the tools if there is no other way - but from the sound of Scott it sounds like we could do something ?

Hmm, how about using something like the ProfileService DeploymentManager:
http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-profileservice-spi/src/main/java/org/jboss/deployers/spi/management/deploy/DeploymentManager.java

With this you can deploy a relative deployment from the file system, or you can tell PS to copy a zipped deployment into the deploy/ dir.
Both ways will include it in the hotDeployment checking.
There is also an API (on the Profile itself) to disable checking for modified deployments.

NOTE: we are going to work on this API in the next weeks, so we can definitely have a look and see how we can simplify things for you.

I can point you to a testcase in the AS testsuite if you want to give this DeploymentManager a try :)

[maxandersen]

sounds interesting - let us know about the link to how to do this remotely....

[emuckenhuber]

sounds interesting - let us know about the link to how to do this remotely....

There is this testcase using the DeploymentManager to deploy/undeploy stuff - which happens in setUp / tearDown:
https://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/main/org/jboss/test/deployers/AbstractDeploymentTest.java

With the copyContent flag you can say if a zipped file should be copied into the deploy folder or should just deploy it from the current location.

[maxandersen]

any example that does not require days spent in reverse engineering AS 5 testsuite to figure out how this remote deployment works and what the minimal dependencies are ? ;)

[emuckenhuber]

any example that does not require days spent in reverse engineering AS 5 testsuite to figure out how this remote deployment works and what the minimal dependencies are ? ;)

The minimal dependencies for compiling is quite easy:

 <dependency>
 <groupId>org.jboss.integration</groupId>
 <artifactId>jboss-profileservice-spi</artifactId>
 <version>5.0.3.GA</version>
 </dependency>

And i guess the minimal dependencies for running are something like this (plus the one above), but not really sure.

 <dependency>
 <groupId>org.jboss.naming</groupId>
 <artifactId>jnp-client</artifactId>
 </dependency>
 <dependency>
 <groupId>org.jboss.aspects</groupId>
 <artifactId>jboss-security-aspects</artifactId>
 </dependency>
 <dependency>
 <groupId>org.jboss.aspects</groupId>
 <artifactId>jboss-remoting-aspects</artifactId>
 </dependency>

And you get the DeploymentManager like this:

 InitialContext ctx = new InitialContext();
 ProfileService ps = (ProfileService) ctx.lookup("ProfileService");
 dm = ps.getDeploymentManager();
 // Load the default profile
 dm.loadProfile(new ProfileKey("default"), false);
 // deploy
 ...

For the jndi properties you can look at: http://www.jboss.org/community/docs/DOC-10949

And one note to the ProfileKey - "default" means the -c default for the moment.

[rob.stryker]

erm...


org.jboss.integration
jboss-profileservice-spi
5.0.3.GA


How is that a compilation dependency? Huh? (Sorry, not familiar with the AS at *all*)

Getting a JNDI reference seems to require, um... compiling against AS5, which tools simply *cannot* do. Tooling cannot compile against versions of the AS. We have our own build system which pretty much forbids compiling against the AS. And if we compiled against one version of the AS, we'd need to recompile for other versions, which means we'd need to make different versions of tooling and / or do a heck of a lot of reflection to get anything to function.

Max: um... any thoughts here?

[emuckenhuber]

erm...

 <dependency>
 <groupId>org.jboss.integration</groupId>
 <artifactId>jboss-profileservice-spi</artifactId>
 <version>5.0.3.GA</version>
 </dependency>

How is that a compilation dependency? Huh? (Sorry, not familiar with the AS at *all*)

Sorry should have mentioned that those are maven dependencies, which are used in the AS build.
I'll see if if i can do a simple demo for you.

[pmuir]

Emanuel, I tried your suggested dependency set

<dependency>
 <groupId>org.jboss.naming</groupId>
 <artifactId>jnp-client</artifactId>
 <scope>runtime</scope>
 </dependency>

 <dependency>
 <groupId>org.jboss.aspects</groupId>
 <artifactId>jboss-security-aspects</artifactId>
 <scope>runtime</scope>
 </dependency>

 <dependency>
 <groupId>org.jboss.aspects</groupId>
 <artifactId>jboss-remoting-aspects</artifactId>
 <scope>runtime</scope>
 </dependency>

 <dependency>
 <groupId>oswego-concurrent</groupId>
 <artifactId>concurrent</artifactId>
 <scope>runtime</scope>
 </dependency>

 <dependency>
 <groupId>org.jboss.integration</groupId>
 <artifactId>jboss-profileservice-spi</artifactId>
 </dependency>

(I had to add in oswego-concurrent due to a CNFE) but I get this exception:

[aop-trace] org.jboss.util.propertyeditor.PropertyEditors Mapping properties for bean: SocketClientInvoker[783cdf2d, socket://localhost:4446]
[aop-trace] org.jboss.util.propertyeditor.PropertyEditors Property editor found for: marshaller, editor: java.beans.PropertyDescriptor@7d215d2b, setter: public void org.jboss.remoting.MicroRemoteClientInvoker.setMarshaller(org.jboss.remoting.marshal.Marshaller)
[aop-trace] org.jboss.util.propertyeditor.PropertyEditors Failed to find property editor for: marshaller
[aop-trace] org.jboss.util.propertyeditor.PropertyEditors Failed to write property
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] setting enableTcpNoDelay to true
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] constructed
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] setting enableTcpNoDelay to true
[aop-debug] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] connecting
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker Creating semaphore with size 50
[aop-trace] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] added new pool ([]) as ServerAddress[127.0.0.1:4446, enableTcpNoDelay timeout 0 ms, maxPoolSize=50]
[aop-debug] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] connected
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446](1) invoking InvocationRequest[1f96a21e, PROFILESERVICE, [advisedMethod=null, unadvisedMethod=null, metadata=[metaData={DISPATCHER={OID=[type=AS_ISvalue=ProfileService]}, REMOTING={SUBSYSTEM=[type=AS_ISvalue=ProfileService], INVOKER_LOCATOR=[type=AS_ISvalue=InvokerLocator [socket://localhost:4446/?dataType=invocation&enableTcpNoDelay=true&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller]]}, security={context=[type=MARSHALLEDvalue=org.jboss.security.plugins.JBossSecurityContext@5a6d6fc5]}}], targetObject=null, arguments=null]]
[aop-trace] org.jboss.remoting.marshal.MarshalFactory Could not find marshaller for data type 'invocation'. Object in collection is null
[aop-trace] org.jboss.remoting.marshal.MarshalFactory Could not look up marshaller by data type ('invocation'). Will try to load dynamically.
[aop-warn] org.jboss.remoting.marshal.MarshalFactory Found marshaller fully qualified class name within locator parameters, but was unable to load class: org.jboss.invocation.unified.marshall.InvocationMarshaller
[aop-trace] org.jboss.remoting.marshal.MarshalFactory Tried to find marshaller from locator by both data type and class name but was unsuccessful. Will try to load it from remote server.
[aop-trace] org.jboss.remoting.marshal.MarshalFactory Could not find marshaller for data type 'invocation'. Object in collection is null
[aop-trace] org.jboss.remoting.InvokerRegistry destroying client invoker InvokerLocator [socket://localhost:4446/?dataType=invocation&enableTcpNoDelay=true&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller], config {}
[aop-debug] org.jboss.remoting.InvokerRegistry removed SocketClientInvoker[783cdf2d, socket://localhost:4446] from registry
[aop-trace] org.jboss.remoting.InvokerRegistry disconnecting SocketClientInvoker[783cdf2d, socket://localhost:4446]
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.transport.socket.MicroSocketClientInvoker clearing pool for ServerAddress[127.0.0.1:4446, enableTcpNoDelay timeout 0 ms, maxPoolSize=50]
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnected
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] is not connected!
[aop-debug] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] disconnecting ...
[aop-trace] org.jboss.remoting.MicroRemoteClientInvoker SocketClientInvoker[783cdf2d, socket://localhost:4446] is not connected!
FAILED CONFIGURATION: @BeforeSuite beforeSuite(org.testng.TestRunner@4dbb3e34)
java.io.IOException
 at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.setup(ProfileServiceContainersImpl.java:53)
 at org.jboss.jsr299.tck.AbstractDeclarativeTest.beforeSuite(AbstractDeclarativeTest.java:165)
Caused by: org.jboss.remoting.marshal.InvalidMarshallingResource: Can not find a valid marshaller for data type: invocation
 at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:90)
 at org.jboss.remoting.Client.invoke(Client.java:1708)
 at org.jboss.remoting.Client.invoke(Client.java:612)
 at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at AOPProxy$0.getDeploymentManager(AOPProxy$0.java)
 at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.initDeploymentManager(ProfileServiceContainersImpl.java:136)
 at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.setup(ProfileServiceContainersImpl.java:49)
 at org.jboss.jsr299.tck.AbstractDeclarativeTest.beforeSuite(AbstractDeclarativeTest.java:165)
 at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
 at AOPProxy$0.getDeploymentManager(AOPProxy$0.java)
 at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.initDeploymentManager(ProfileServiceContainersImpl.java:136)
 at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.setup(ProfileServiceContainersImpl.java:49)
 ... 16 more

A client pom for the profile service would make a lot of sense here.

[emuckenhuber]

A client pom for the profile service would make a lot of sense here.

Hmm agreed, would definitely make sense! Getting a set of required runtime dependencies is on my todo list.
I started with this some time ago, but did not really had time to dig further into this.
I hopefully have some time after the Beta1 release to see what we can do in terms of providing a pom. You can also create a JIRA task if you want, so that i don't forget :)

In the meantime one thing you could do is to add jboss-test as a dependency - this will download a bunch of not needed stuff, but at least it should work.