Bug 616035 - WS namespace not dynamically set at build time
Summary: WS namespace not dynamically set at build time
Status: CLOSED NOTABUG
Alias: None
Product: RHQ Project
Classification: Other
Component: Web Services   
(Show other bugs)
Version: 3.0.0
Hardware: All
OS: Linux
medium
medium vote
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Jay Shaughnessy
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-19 14:01 UTC by Simeon Pinder
Modified: 2014-05-09 16:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-09 16:04:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Simeon Pinder 2010-07-19 14:01:53 UTC
Description of problem:
WS namespace needs to be manually changed before release.

Version-Release number of selected component (if applicable):
All

How reproducible:
N/A

Steps to Reproduce:
1. View org.rhq.enterprise.server.system.ServerVersion.namespace
  
Actual results:
Static

Expected results:
Include build/release/project version.

Additional info:

Comment 1 Simeon Pinder 2010-07-20 13:24:47 UTC
Checked in manual change to release-3.0.0 for namespace. >= 70 successful jon-tag-release build.

commit hash: 273b5adbddf03b97fbe3601c150f46d8eb2b3f7c

Checking full fix into master.

Comment 2 Corey Welton 2010-09-28 12:29:01 UTC
simeon - what would it take fo rthe whole dynamic fix?

Comment 3 Simeon Pinder 2010-09-28 14:52:14 UTC
This change was checked in already. Just once change in src and a few lines update in a maven pom.
 Commit hash: 09d836bba1d73eef4d48cc6dcf83931b042572fd

Comment 4 Mike Foley 2011-06-17 18:36:31 UTC
version and build number appear in help/about.

Comment 5 Simeon Pinder 2011-06-20 14:15:25 UTC
Version and build numbers in help/about are not connected to the WS interface version(which this bug is about).  The way to test this is to start up the Webservices interface and verify that the version details in the namespace (of the exposed WSDL) is correctly bound to the maven pom version.  

Should look something like "http://www.rhq-project.org/4.1.0-SNAPSHOT/Webservices.xsd", where the 4.*-SNAPSHOT piece changes with rhq/jon target release numbers. 

*Instructions for starting up the WS interface: http://www.rhq-project.org/display/JOPR2/RHQ+Web+Services+Installation

Moving this back to ON_QA.

Comment 6 Mike Foley 2011-06-21 15:14:37 UTC
Followed the instructions for starting the WS interface.  But the WSDL would not display.  Therefore, I cannot verify this BZ at this time.  Discussed with Simeon, who asked for a new BZ.  This new BZ is 715008  https://bugzilla.redhat.com/show_bug.cgi?id=715008


#
2011-06-21 10:43:44,566 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/root/rhq/rhq-server-4.1.0-SNAPSHOT/jbossas/server/default/deploy/rhq.ear/rhq-enterprise-server-ejb3.jar/
#
java.lang.IllegalArgumentException: Duplicate operation with name=createPackageBackedResource, found in binding '{http://www.rhq-project.org/4.1.0-SNAPSHOT/Webservices.xsd}WebservicesRemoteBinding'.
#
        at com.ibm.wsdl.BindingImpl.getBindingOperation(Unknown Source)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.getBindingOperation(WSDL11Reader.java:1061)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.getOperationStyle(WSDL11Reader.java:1070)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processPortTypeOperations(WSDL11Reader.java:752)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processPortType(WSDL11Reader.java:739)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processBinding(WSDL11Reader.java:1156)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processPort(WSDL11Reader.java:1681)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processPorts(WSDL11Reader.java:1666)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processServices(WSDL11Reader.java:1636)
#
        at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(WSDL11Reader.java:182)
#
        at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:126)
#
        at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
#
        at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:174)
#
        at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:50)
#
        at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderEJB3.buildMetaData(JAXWSMetaDataBuilderEJB3.java:76)
#
        at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.start(UnifiedMetaDataDeploymentAspect.java:69)
#
        at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:129)
#
        at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:95)
#
        at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:88)
#
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
#
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
#
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
#
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
#
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
#
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
#
        at $Proxy34.start(Unknown Source)
#
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
#
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
#
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
#
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
#
        at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
#
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
#
        at java.lang.reflect.Method.invoke(Method.java:616)
#
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
#
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
#
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
#
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
#
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
#
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
#
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
#
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
#
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)

Comment 7 Jay Shaughnessy 2014-05-09 16:04:05 UTC
WebServices are no longer supported.


Note You need to log in before you can comment on or make changes to this bug.