1 2 Previous Next 16 Replies Latest reply on Apr 2, 2009 8:12 AM by dimitris

JBIDE-3394, hot deployment management api

starksm64 Dec 16, 2008 6:24 PM

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.

1. Re: JBIDE-3394, hot deployment management api

starksm64 Dec 16, 2008 6:31 PM (in response to starksm64)

JBAS-6323 is a task to validate the apis and create testcases for those that should be supported.
Actions
2. Re: JBIDE-3394, hot deployment management api

maxandersen Dec 17, 2008 7:45 AM (in response to starksm64)

So there is no way (not even a hacky one) to modify/query about hot deployment directories in AS 5 ?
Actions
3. Re: JBIDE-3394, hot deployment management api

rob.stryker Dec 17, 2008 11:17 AM (in response to starksm64)

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
Actions
4. Re: JBIDE-3394, hot deployment management api

starksm64 Dec 17, 2008 12:09 PM (in response to starksm64)

"rob.stryker@jboss.com" wrote:
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.
Actions
5. Re: JBIDE-3394, hot deployment management api

maxandersen Dec 18, 2008 9:18 AM (in response to starksm64)

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 ?
Actions
6. Re: JBIDE-3394, hot deployment management api

emuckenhuber Dec 21, 2008 7:19 AM (in response to starksm64)

"max.andersen@jboss.com" wrote:
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 :)
Actions
7. Re: JBIDE-3394, hot deployment management api

maxandersen Dec 21, 2008 9:27 AM (in response to starksm64)

sounds interesting - let us know about the link to how to do this remotely....
Actions
8. Re: JBIDE-3394, hot deployment management api

emuckenhuber Jan 5, 2009 8:50 AM (in response to starksm64)

"max.andersen@jboss.com" wrote:
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.
Actions
9. Re: JBIDE-3394, hot deployment management api

maxandersen Jan 5, 2009 9:06 AM (in response to starksm64)

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 ? ;)
Actions
10. Re: JBIDE-3394, hot deployment management api

emuckenhuber Jan 5, 2009 12:45 PM (in response to starksm64)
"max.andersen@jboss.com" wrote:
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.
Actions
11. Re: JBIDE-3394, hot deployment management api

rob.stryker Jan 16, 2009 2:10 AM (in response to starksm64)

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?
Actions
12. Re: JBIDE-3394, hot deployment management api

emuckenhuber Jan 16, 2009 4:16 AM (in response to starksm64)
"rob.stryker@jboss.com" wrote:
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.
Actions

13. Re: JBIDE-3394, hot deployment management api

pmuir Mar 6, 2009 10:20 AM (in response to starksm64)

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.

14. Re: JBIDE-3394, hot deployment management api

emuckenhuber Mar 6, 2009 1:02 PM (in response to starksm64)

"pete.muir@jboss.org" wrote:

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.
Actions

1 2 Previous Next

Go to original post