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

    JBIDE-3394, hot deployment management api

    Scott Stark Master

      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
          Scott Stark Master

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

          • 2. Re: JBIDE-3394, hot deployment management api
            Max Rydahl Andersen Master

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

            • 3. Re: JBIDE-3394, hot deployment management api
              Rob Stryker Master

              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

              • 4. Re: JBIDE-3394, hot deployment management api
                Scott Stark Master

                 

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


                • 5. Re: JBIDE-3394, hot deployment management api
                  Max Rydahl Andersen Master

                  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 ?

                  • 6. Re: JBIDE-3394, hot deployment management api
                    Emanuel Muckenhuber Master

                     

                    "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 :)

                    • 7. Re: JBIDE-3394, hot deployment management api
                      Max Rydahl Andersen Master

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

                      • 8. Re: JBIDE-3394, hot deployment management api
                        Emanuel Muckenhuber Master

                         

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

                        • 9. Re: JBIDE-3394, hot deployment management api
                          Max Rydahl Andersen Master

                          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 ? ;)

                          • 10. Re: JBIDE-3394, hot deployment management api
                            Emanuel Muckenhuber Master

                             

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


                            • 11. Re: JBIDE-3394, hot deployment management api
                              Rob Stryker Master

                              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?

                              • 12. Re: JBIDE-3394, hot deployment management api
                                Emanuel Muckenhuber Master

                                 

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

                                • 13. Re: JBIDE-3394, hot deployment management api
                                  Pete Muir Master

                                  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
                                    Emanuel Muckenhuber Master

                                     

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



                                    1 2 Previous Next