14 Replies Latest reply on Aug 17, 2009 3:36 PM by pmuir

    Getting the whole cause stack of the deployment exception

    pmuir
    pmuir Jun 29, 2009 9:12 AM

      The current DeployersImpl stores only the root cause of an exception thrown during deployment in the IncompleteDeploymentException - it would be more useful if the entire exception (as orignally thrown, not including any causes added by the MC) was present there.

      It's also worth noting that the whole deployment error reporting system isn't the easiest to use/extract information from. However, I'm not entirely sure how it could be improved. Perhaps the ability to install a custom exception handler which get's notified on a context in error?

      • 29087 Views
      • Tags:
        • 1. Re: Getting the whole cause stack of the deployment exceptio
          alesj
          alesj Jun 29, 2009 4:54 PM (in response to pmuir)

           

          "pete.muir@jboss.org" wrote:
          Perhaps the ability to install a custom exception handler which get's notified on a context in error?

          Yup, this doesn't sound bad.

          I guess we can match an exact exception type or any that's in its sub class hierarchy.
          This should be checked when we're unwinding the exception to its cause,
          as you never know who all is wrapping the real cause.

          We can probably also do a match on the MC contexts that are roots of the problem.

          Wrt to having entire exception in IDE, I think we would need to change too much code,
          in order to still properly display any useful info.
          (we're already not the greatest there, but the issue is more complex than it looks like)


            • Actions
          • 2. Re: Getting the whole cause stack of the deployment exceptio
            pmuir
            pmuir Jun 30, 2009 7:13 AM (in response to pmuir)

             

            "alesj" wrote:

            This should be checked when we're unwinding the exception to its cause,
            as you never know who all is wrapping the real cause.


            Yes, this is probably enough control for those who need to dig deeper into deployment exceptions, especially if I can get the whole stack here.

            "alesj" wrote:
            Wrt to having entire exception in IDE, I think we would need to change too much code, in order to still properly display any useful info.
            (we're already not the greatest there, but the issue is more complex than it looks like)


            For me, IDE isn't a big problem. My use case is that I need to examine deployment exceptions (root cause and sometimes the next level or so up) in an testsuite so I can verify that the correct error happened on deployment.

            But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies...

              • Actions
            • 3. Re: Getting the whole cause stack of the deployment exceptio
              alesj
              alesj Jun 30, 2009 8:06 AM (in response to pmuir)

               

              "pete.muir@jboss.org" wrote:

              But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies...

              How do you know what's accurate? :-)

              I can see this being done in a test, but not in general, e.g. tooling.

              As there can be so many layers in between the real cause and when the exception finally pops out,
              that chance of having one framework wrapping it in useless wrapper is quite big.
              And imho wrong/confusing info is worse than no info at all. :-)

                • Actions
              • 4. Re: Getting the whole cause stack of the deployment exceptio
                adrian.brock Jun 30, 2009 8:20 AM (in response to pmuir)

                 

                "pete.muir@jboss.org" wrote:

                "alesj" wrote:
                Wrt to having entire exception in IDE, I think we would need to change too much code, in order to still properly display any useful info.
                (we're already not the greatest there, but the issue is more complex than it looks like)


                For me, IDE isn't a big problem. My use case is that I need to examine deployment exceptions (root cause and sometimes the next level or so up) in an testsuite so I can verify that the correct error happened on deployment.


                try
{
 deploySomething();
}
catch (IncompleteDeploymentException e)
{
 Throwable t = e.getContextsInError().get(deploymentURL);
 // assert things here
}


                Or if you aren't directly deploying something,
                e.g. the test framework does the deployment.
                You can run the check later: 

                try
{
 deployerClient.checkComplete(deploymentURL);
}
catch (IncompleteDeploymentException e)
{
 // as before.
}


                Or finally more direct access (if you want to peek under the covers into unsupported code): 
                 MainDeployerStructure mds = (MainDeployerStructure) mainDeployer;
 DeploymentContext dc = mds.getDeploymentContext(deploymentURL);
 Throwable t = dc.getProblem();
 // etc.


                  • Actions
                • 5. Re: Getting the whole cause stack of the deployment exceptio
                  adrian.brock Jun 30, 2009 8:27 AM (in response to pmuir)

                   

                  "pete.muir@jboss.org" wrote:

                  But, I can see that this is more generally applicable in the area of tooling (both prod via Jopr, and dev via JBoss Tools) - that if an accurate deployment exception(s) can be reported back to the tool, it can start to suggest possible remedies...


                  Tool interaction should be done via the profile service.
                  But I don't see anything in that api that lets you get the error?
                  http://anonsvn.jboss.org/repos/jbossas/projects/jboss-man/trunk/managed/src/main/java/org/jboss/managed/api/ManagedDeployment.java

                    • Actions
                  • 6. Re: Getting the whole cause stack of the deployment exceptio
                    alesj
                    alesj Jul 13, 2009 9:54 AM (in response to pmuir)

                    Currently I have this contract:

                     void handleException(T exception, ControllerContext context);


                    Should I return boolean or Throwable?
                    In case I return false it would mean that we don't add this as part of missing dependency.
                    Same with returning null.


                      • Actions
                    • 7. Re: Getting the whole cause stack of the deployment exceptio
                      alesj
                      alesj Aug 2, 2009 6:59 AM (in response to pmuir)

                      Pete, can you check if JBDEPLOY-205 is actually useful for this issue (JBAS-7047)?

                      Otherwise, like Adrian said, we need to get this into ProfileService,
                      hence Scott or Emanuel are the one's that should help you with this.

                        • Actions
                      • 8. Re: Getting the whole cause stack of the deployment exceptio
                        pmuir
                        pmuir Aug 6, 2009 6:45 AM (in response to pmuir)

                         

                        "alesj" wrote:
                        Pete, can you check if JBDEPLOY-205 is actually useful for this issue (JBAS-7047)?


                        Yes, looks good, assuming I have a way to install one of these (as below). Also, it would be useful to have the name of the MC bean which threw the exception (as we get in contextsInError) - this allows me to discard all non WB related exceptions.

                        Otherwise, like Adrian said, we need to get this into ProfileService,
                        hence Scott or Emanuel are the one's that should help you with this.


                        I don't use ManagedDeployment at all. Instead I use http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-profileservice-spi/src/main/java/org/jboss/deployers/spi/management/deploy/DeploymentManager.java and it's start/stop/distribute methods. Any deployment exceptions (IncompleteDeploymentException which I then dig into to get the underlying WB exception) are simply thrown out of these methods which we catch.

                        So, what is the best way to attach an exception handler? Can we add something to the PS API for this? Or should it be configured via -beans.xml or something?

                          • Actions
                        • 9. Re: Getting the whole cause stack of the deployment exceptio
                          alesj
                          alesj Aug 6, 2009 6:57 AM (in response to pmuir)

                           

                          "pete.muir@jboss.org" wrote:

                          Also, it would be useful to have the name of the MC bean which threw the exception (as we get in contextsInError) - this allows me to discard all non WB related exceptions.

                          MC bean name == ControllerContext::getName ;-)
                          Where ControllerContext is a parameter here: 
                           void handleException(T exception, ControllerContext context);


                          "pete.muir@jboss.org" wrote:

                          So, what is the best way to attach an exception handler?

                          Simply define a WBNotificationListener in some -jboss-beans.xml
                          and it will be automagically picked up by MC and added to DeployersImpl.

                          "pete.muir@jboss.org" wrote:

                          Can we add something to the PS API for this?

                          No.
                          And that's not what Adrian and me are saying PS should do.
                          OK, it already has this DeploymentManager, but this looks like it doesn't expose enough.
                          It should be the ManagedDeployment that should be able to give you the right exception, no matter how wrapped it is.

                          Or if MD is not the right place, something else should. Scott, Emanuel?


                            • Actions
                          • 10. Re: Getting the whole cause stack of the deployment exceptio
                            pmuir
                            pmuir Aug 6, 2009 7:16 AM (in response to pmuir)

                             

                            "alesj" wrote:
                            "pete.muir@jboss.org" wrote:

                            Also, it would be useful to have the name of the MC bean which threw the exception (as we get in contextsInError) - this allows me to discard all non WB related exceptions.

                            MC bean name == ControllerContext::getName ;-)
                            Where ControllerContext is a parameter here:
                             void handleException(T exception, ControllerContext context);


                            Oops, going blind ;-)

                            "pete.muir@jboss.org" wrote:

                            So, what is the best way to attach an exception handler?

                            Simply define a WBNotificationListener in some -jboss-beans.xml
                            and it will be automagically picked up by MC and added to DeployersImpl.

                            "pete.muir@jboss.org" wrote:

                            Can we add something to the PS API for this?

                            No.
                            And that's not what Adrian and me are saying PS should do.
                            OK, it already has this DeploymentManager, but this looks like it doesn't expose enough.
                            It should be the ManagedDeployment that should be able to give you the right exception, no matter how wrapped it is.

                            Or if MD is not the right place, something else should. Scott, Emanuel?


                            Got it.

                              • Actions
                            • 11. Re: Getting the whole cause stack of the deployment exceptio
                              starksm64
                              starksm64 Aug 14, 2009 3:27 AM (in response to pmuir)

                              Ok, I have a test that shows the lack of the underlying cause so I'm looking into how we can propagate that.

                                • Actions
                              • 12. Re: Getting the whole cause stack of the deployment exceptio
                                emuckenhuber
                                emuckenhuber Aug 14, 2009 9:31 AM (in response to pmuir)

                                 

                                "scott.stark@jboss.org" wrote:
                                Ok, I have a test that shows the lack of the underlying cause so I'm looking into how we can propagate that.


                                Most probably the ManagedDeployment API would fit better for this, as we have an association between the deployment and failure. Although we could also propagate it to the DeploymentProcess.
                                As using ManagedDeployments requires to initialize the ManagementView as well, which could take while.

                                Basically we could catch the IncompleteDeploymentException in the DeployHandler as Adrian mentioned and propagate the stacktrace(s) to the DeploymentID. There is a disconnect though, as one DeploymentID can contain multiple names.

                                  • Actions
                                • 13. Re: Getting the whole cause stack of the deployment exceptio
                                  starksm64
                                  starksm64 Aug 14, 2009 4:46 PM (in response to pmuir)

                                  I did update the exception thrown to include the cause and that is now available on the client as this CNFE example shows. There is an extraneous RuntimeException wrapper that I don't know who is adding yet, but at least the cause is there. This is in the JBAS-7177 issue.

                                  junit.framework.AssertionFailedError: DeploymentStatus.isCompleted: DeploymentStatus(command=START,state=FAILED,message=null,isCompleted=false,isRunning=false,isFailed=true,failure:
java.lang.RuntimeException: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** DEPLOYMENTS IN ERROR: Name -> Error

vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.test:service=NoSuchBean


DEPLOYMENTS IN ERROR:
 Deployment "vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml" is in error due to the following reason(s): java.lang.ClassNotFoundException: org.jboss.test.profileservice.sar.NoSuchBean from BaseClassLoader@ca245c{VFSClassLoaderPolicy@191c1d{name=vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml domain=ClassLoaderDomain@a05c93{name=DefaultDomain parentPolicy=BEFORE parent=java.net.URLClassLoader@52513a} roots=[MemoryContextHandler@8701025[path= context=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u real=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u]] delegates=null exported=[] <IMPORT-ALL>NON_EMPTY}}

 at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:312)
 at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
 at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
 at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testDeployment(DeployUnitTestCase.java:112)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testSarCNFEDeployment(DeployUnitTestCase.java:235)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:164)
 at junit.framework.TestCase.runBare(TestCase.java:130)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:120)
 at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
 at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** DEPLOYMENTS IN ERROR: Name -> Error

vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml -> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.test:service=NoSuchBean


DEPLOYMENTS IN ERROR:
 Deployment "vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml" is in error due to the following reason(s): java.lang.ClassNotFoundException: org.jboss.test.profileservice.sar.NoSuchBean from BaseClassLoader@ca245c{VFSClassLoaderPolicy@191c1d{name=vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml domain=ClassLoaderDomain@a05c93{name=DefaultDomain parentPolicy=BEFORE parent=java.net.URLClassLoader@52513a} roots=[MemoryContextHandler@8701025[path= context=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u real=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u]] delegates=null exported=[] <IMPORT-ALL>NON_EMPTY}}

 at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:310)
 at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:208)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
 at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.lang.ClassNotFoundException: org.jboss.test.profileservice.sar.NoSuchBean from BaseClassLoader@ca245c{VFSClassLoaderPolicy@191c1d{name=vfsfile:/Users/svn/JBossAS/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/testCNFE-service.xml domain=ClassLoaderDomain@a05c93{name=DefaultDomain parentPolicy=BEFORE parent=java.net.URLClassLoader@52513a} roots=[MemoryContextHandler@8701025[path= context=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u real=vfsmemory://5c4o12w-hibs2x-fydde3xq-1-fyddvly8-9u]] delegates=null exported=[] <IMPORT-ALL>NON_EMPTY}}
 at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1213)
 at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
 at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:344)
 at org.jboss.system.ServiceCreator.installPlainMBean(ServiceCreator.java:211)
 at org.jboss.system.ServiceCreator.install(ServiceCreator.java:130)
 at org.jboss.system.microcontainer.InstantiateAction.installAction(InstantiateAction.java:45)
 at org.jboss.system.microcontainer.InstantiateAction.installAction(InstantiateAction.java:37)
 at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
 at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
 at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
 at org.jboss.system.ServiceController.install(ServiceController.java:274)
 at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
 at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
 at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
 at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
 at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
 at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
 at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
 at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
 at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:297)
 at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:208)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
 at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
 at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
 at org.jboss.remoting.Client.invoke(Client.java:1724)
 at org.jboss.remoting.Client.invoke(Client.java:629)
 at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
 at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
 at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
 at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testDeployment(DeployUnitTestCase.java:112)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testSarCNFEDeployment(DeployUnitTestCase.java:235)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at junit.framework.TestCase.runTest(TestCase.java:164)
 at junit.framework.TestCase.runBare(TestCase.java:130)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:120)
 at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
 at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
)
 at junit.framework.Assert.fail(Assert.java:47)
 at junit.framework.Assert.assertTrue(Assert.java:20)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testDeployment(DeployUnitTestCase.java:116)
 at org.jboss.test.profileservice.test.DeployUnitTestCase.testSarCNFEDeployment(DeployUnitTestCase.java:235)
...


                                    • Actions
                                  • 14. Re: Getting the whole cause stack of the deployment exceptio
                                    pmuir
                                    pmuir Aug 17, 2009 3:36 PM (in response to pmuir)

                                    Thanks guys.

                                    One of my open tasks is to make sure that the Web Beans TCK is running ok on Branch_5_x. You just gave me a good reason to move to it :-)

                                      • Actions