Details
-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
%
-
-
Description
When the maven:fabric8 plugin is used to deploy a profile to a non-default version in Fuse Fabric, if the profile does not exist in the default version, then the following stack trace is observed in the (client) deployment log:
Failed to invoke mbean io.fabric8:type=ProjectDeployer on jolokia URL: http://nodex.redhat.com:8181/jolokia with user: admin. Error: java.lang.IllegalArgumentException Stack: java.lang.IllegalArgumentException: Profile redhat-example-greet is not valid at io.fabric8.api.Profiles.assertValidProfileId(Profiles.java:446) at io.fabric8.service.FabricServiceImpl.validateProfileRequirements(FabricServiceImpl.java:1174) at io.fabric8.service.FabricServiceImpl.validateRequirements(FabricServiceImpl.java:1168) at io.fabric8.service.FabricServiceImpl.setRequirements(FabricServiceImpl.java:1140) at io.fabric8.deployer.ProjectDeployerImpl.resolveProfileDeployments(ProjectDeployerImpl.java:404) at io.fabric8.deployer.ProjectDeployerImpl.deployProject(ProjectDeployerImpl.java:192) at io.fabric8.deployer.ProjectDeployerImpl.deployProject(ProjectDeployerImpl.java:170) at io.fabric8.deployer.ProjectDeployerImpl.deployProjectJson(ProjectDeployerImpl.java:158) at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.jolokia.handler.ExecHandler.doHandleRequest(ExecHandler.java:98) at org.jolokia.handler.ExecHandler.doHandleRequest(ExecHandler.java:40) at org.jolokia.handler.JsonRequestHandler.handleRequest(JsonRequestHandler.java:89) at org.jolokia.backend.MBeanServerExecutorLocal.handleRequest(MBeanServerExecutorLocal.java:109) at org.jolokia.backend.MBeanServerHandler.dispatchRequest(MBeanServerHandler.java:159) at org.jolokia.backend.LocalRequestDispatcher.dispatchRequest(LocalRequestDispatcher.java:99) at org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:413) at org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:158) at org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:197) at org.jolokia.http.HttpRequestHandler.handlePostRequest(HttpRequestHandler.java:137) at org.jolokia.http.AgentServlet$3.handleRequest(AgentServlet.java:420) at org.jolokia.http.AgentServlet$2.run(AgentServlet.java:297) at org.jolokia.http.AgentServlet$2.run(AgentServlet.java:295) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jolokia.http.AgentServlet.handleSecurely(AgentServlet.java:295) at org.jolokia.http.AgentServlet.handle(AgentServlet.java:277) at org.jolokia.http.AgentServlet.doPost(AgentServlet.java:244) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:748)
This appears to be due to an invocation of require-profile-set (setRequirements) that fails when a profile matching the given name does not exist in the default version and the same trace can be duplicated at the karaf consol with a manual invocation of the command.
This appears to be caused by the fact that the require-profile-list for instance counts is tied to the default version, rather than maintained for each version, while deployment can specify any version for deployment, so if the profile is missing from the default version, invocation fails.
Additional Observation:
During testing of this issue, it was found that deleting a profile from the karaf console removes it from the require-profile-list, while deleting via Hawtio deletes the profile, but leaves the profile name in the list.
Attachments
Issue Links
- is related to
-
ENTESB-6926 [fabric] require-profile-set doesn't handle multi versions of profiles
- Closed