[JBoss JIRA] (DROOLS-4806) The fields of a DataObject used in a pattern aren't presented in the menu list
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4806?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4806:
-------------------------------------
[~mdessi] please try your scenario once more, double check the java class is saved before interaction with guided decision table editor. Thank you.
> The fields of a DataObject used in a pattern aren't presented in the menu list
> ------------------------------------------------------------------------------
>
> Key: DROOLS-4806
> URL: https://issues.jboss.org/browse/DROOLS-4806
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.30.0.Final
> Reporter: Massimiliano Dessi
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
> Attachments: 1.png, 2.png, 3.png, 4.png
>
>
> Isn't possible to create a column "Set the value of a field", the menulist doesn't show the field of the data object chosen as a pattern.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-4047:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> SLSB with WebService Annotation generates duplicate endpoint when JMS transport used
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4047
> URL: https://issues.jboss.org/browse/WFLY-4047
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Wojciech Oczkowski
> Assignee: Jim Ma
> Priority: Major
> Attachments: TestWSJMS.zip
>
>
> When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport).
> 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72]
> Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371)
> at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)
> at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129)
> at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67)
> at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 5 more
> Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a <jms:destination name="{http://test.ctdp.pl/}NewSessionBeanPort.jms-destination"> and set the jndiConnectionFactoryName ?
> at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115)
> at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119)
> at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49)
> at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95)
> at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362)
> ... 13 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-7643) JAX-WS Webservice endpoint naming conflict between different virtual hosts
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-7643?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-7643:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> JAX-WS Webservice endpoint naming conflict between different virtual hosts
> --------------------------------------------------------------------------
>
> Key: WFLY-7643
> URL: https://issues.jboss.org/browse/WFLY-7643
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
> Reporter: István Tóth
> Assignee: Jim Ma
> Priority: Major
> Attachments: Hello.java, jboss-web.xml, vhost-config-fragment.xml
>
>
> When deploying identically named POJO JAX-WS webservice endpoints into different virtualhosts with the same context, the ServiceName generated for the second deployment conflicts with the first one, and the deployment fails with org.jboss.msc.service.DuplicateServiceException.
> This can be worked around by defining the endpoint as a servlet, and giving globally distinct <servlet-name> s to them.
> I think the cause for the bug is that the ServiceName for the Endpoint is in a server instance namespace, but the the name is generated from only the endpoint name, and the context, which is not unique among deployments on different virtual hosts.
> Adding the virtual host to the generated name would make the service name unique, and should also allow routing to it based on virtualhost info by web server.
> In the test case the names could be for example *jboss.ws.endpoint.vhost="hosta".context=."helloservice.endpoint.Hello"* and *jboss.ws.endpoint.vhost="hostb".context=."helloservice.endpoint.Hello"* .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-5967) Have web services add javax.xml.rpic.api dependency to deployments instead of EjbDependencyDeploymentUnitProcessor
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-5967?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-5967:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> Have web services add javax.xml.rpic.api dependency to deployments instead of EjbDependencyDeploymentUnitProcessor
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5967
> URL: https://issues.jboss.org/browse/WFLY-5967
> Project: WildFly
> Issue Type: Task
> Components: EJB, Web Services
> Affects Versions: 10.0.0.CR5
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Major
>
> Prior to WFLY-5922, the packages in the javax.xml.rpic.api module were being made available to deployments because EjbDependencyDeploymentUnitProcessor added the javax.ejb.api module, and javax.ejb.api *exported* javax.xml.rpc.api.
> WFLY-5922 removed that export, which broke the TCK signature tests. So I'm about to put up a workaround PR that has EjbDependencyDeploymentUnitProcessor directly add a dep on javax.xml.rpc.api.
> That's a workaround for 10.0.0.Final, but Jason noted he thought it would make more sense for this dep to come from the ws subsystem. So this JIRA is to track looking into that.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-8160:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> Webservice response File Descriptor leak
> ----------------------------------------
>
> Key: WFLY-8160
> URL: https://issues.jboss.org/browse/WFLY-8160
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final
> Environment: JDK: jdk1.8.0_121, jdk1.8.0_66
> WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final
> OS: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Hardware: 64 bit 4 core
> Reporter: Mahesh Reddy
> Assignee: Jim Ma
> Priority: Major
> Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt, file-leak-detector_output.txt
>
>
> We are getting File descriptor leak when wildfly responds to webservice call.
> I think this happens if the webresvice response is huge complex structure,
> I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,.
> I notice for each webservice call, 2 file descriptors are open and never closed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-3987:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> Regression regarding WS Client when using header authentication
> ---------------------------------------------------------------
>
> Key: WFLY-3987
> URL: https://issues.jboss.org/browse/WFLY-3987
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A
> Reporter: Marcus Carlson
> Assignee: Jim Ma
> Priority: Major
> Attachments: HPD_IncidentInterface_Create_WS.wsdl, Tomcat.txt
>
>
> I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projec... for an example of how the WSDL file looks like.
> I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this:
> {noformat}
> port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo);
> {noformat}
> Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request:
> {noformat}
> ID: 1
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><AuthenticationInfo xmlns="urn:HPD_IncidentInterface_WS"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></AuthenticationInfo></soap:Header><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS"><Qualification>'Status' = "Closed"</Qualification><startRecord>0</startRecord><maxLimit>1000</maxLimit></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!):
> {noformat}
> ID: 2
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AuthenticationInfo"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> I've also tried 9.0.0.Alpha1 with same result. What could be wrong?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-6057) JAXB bindings of XmlJavaTypeAdapter are ignored
by Alessio Soldano (Jira)
[ https://issues.jboss.org/browse/WFLY-6057?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-6057:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> JAXB bindings of XmlJavaTypeAdapter are ignored
> -----------------------------------------------
>
> Key: WFLY-6057
> URL: https://issues.jboss.org/browse/WFLY-6057
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.0.0.CR5
> Reporter: George Turner
> Assignee: Jim Ma
> Priority: Major
>
> I filed this problem in WF8, and I still cannot get it to work in WF10
> Every xsd:date field prints as a xs:dateTime, and ignores by custom bindings.
> Here is my setup:
> binding.xjb
> <?xml version="1.0" encoding="UTF-8"?>
> <bindings xmlns="http://java.sun.com/xml/ns/jaxb"
> xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> extensionBindingPrefixes="xjc" version="2.1">
> <globalBindings
> choiceContentProperty="true" generateIsSetMethod="true" typesafeEnumMaxMembers="2000">
> <xjc:javaType name="java.util.Date" xmlType="xs:date"
> adapter="com.lmco.spacefence.infrastructure.webservices.util.XmlDateAdapter"/>
> <xjc:serializable/>
> </globalBindings>
> </bindings>
> package-info.java
> @XmlJavaTypeAdapters({
> @XmlJavaTypeAdapter(value = XmlDateAdapter.class, type = java.util.Date.class),
> @XmlJavaTypeAdapter(value = XmlDatetimeAdapter.class, type = java.util.Calendar.class)
> })
> package com.lmco.spacefence.infrastructure.webservices.util;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapters;
> XmlDateAdapter.java
> package com.lmco.spacefence.infrastructure.webservices.util;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.xml.bind.annotation.adapters.XmlAdapter;
> /**
> * Class is used to marshal/unmarshal String/Date in XML.
> */
> public class XmlDateAdapter extends XmlAdapter<String, Date> {
> /**
> * Parses a Date value from the String.
> *
> * @param value to unmarshal
> * @return the parsed Date
> */
> @Override
> public Date unmarshal(String value) throws Exception {
> if (value == null) {
> return null;
> }
> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
> return sdf.parse(value);
> }
> /**
> * Prints the Date value as a String.
> *
> * @param value to marshal
> * @return the String of the Date
> */
> @Override
> public String marshal(Date value) throws Exception {
> if (value == null) {
> return null;
> }
> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
> return sdf.format(value);
> }
> }
> Field in generated source class from cxf-codegen-plugin using binding.xjb
> @XmlJavaTypeAdapter(XmlDateAdapter.class)
> protected Date createDate;
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months