[JBoss JIRA] (JBWS-3690) XMLJavaTypeAdapter not working in Exception Classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3690:
-----------------------------------------------
Mustafa Musaji <mmusaji(a)redhat.com> made a comment on [bug 999893|https://bugzilla.redhat.com/show_bug.cgi?id=999893]
Platform BZ for https://issues.jboss.org/browse/JBWS-3690
Given the interface:
@javax.jws.WebService
public interface WsIntfc {
public void test() throws MyException;
}
And exception class:
public class MyException extends Exception {
private MyClass1 adapted = null;
@XmlJavaTypeAdapter(Cl1ToCl2Adapter.class)
public MyClass1 getAdapted() {
return this.adapted;
}
public void setAdapted(MyClass1 adapted) {
this.adapted = adapted;
}
}
Along with:
public class Cl1ToCl2Adapter extends XmlAdapter<MyClass2, MyClass1> {
@Override
public MyClass1 unmarshal(MyClass2 v) throws Exception {
MyClass1 mc1 = new MyClass1();
mc1.setName(v.getFile());
return mc1;
}
@Override
public MyClass2 marshal(MyClass1 v) throws Exception {
MyClass2 mc2 = new MyClass2();
mc2.setFile(v.getName());
return mc2;
}
}
public class MyClass1 {
private String name = null;
public String getName() {
return this.name;
}
public void setName(String name) {
this.name = name;
}
}
public class MyClass2 {
private String file = null;
public String getFile() {
return this.file;
}
public void setFile(String file) {
this.file = file;
}
}
I get the following schema output:
<xs:complexType name="myClass1">
<xs:sequence>
<xs:element minOccurs="0" name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MyException">
<xs:sequence/>
</xs:complexType>
I should expect myClass2 defined in the schema and referenced by MyException.
> XMLJavaTypeAdapter not working in Exception Classes
> ---------------------------------------------------
>
> Key: JBWS-3690
> URL: https://issues.jboss.org/browse/JBWS-3690
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2
> Reporter: Mustafa Musaji
> Assignee: Mustafa Musaji
> Attachments: cxfTest.jar
>
>
> @XMLJavaTypeAdapter usage in Exception Classes does not work when mapping to a class not in the JAXB Context.
> {code:title=MyEJB.java}
> @Stateless
> @WebService
> public class MyEJB {
> public void launcheMyException() throws MyException {
> return;
> }
> }
> {code}
> {code:title=MyException.java}
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MyException extends Exception {
> @XmlJavaTypeAdapter(Cl1ToCl2Adapter.class)
> MyClass1 obj1;
> @XmlJavaTypeAdapter(NoArgObjAdapter.class)
> NoArgObj obj2;
> public MyClass1 getObj1() {
> return obj1;
> }
>
> public void setObj1(MyClass1 obj1) {
> this.obj1 = obj1;
> }
> public NoArgObj getObj2() {
> return obj2;
> }
> public void setObj2(NoArgObj obj2) {
> this.obj2 = obj2;
> }
> }
> {code}
> {code:title=Cl1ToCl2Adapter.java}
> public class Cl1ToCl2Adapter extends XmlAdapter<MyClass2,MyClass1> {
> @Override
> public MyClass2 marshal(MyClass1 v) throws Exception {
> return new MyClass2();
> }
> @Override
> public MyClass1 unmarshal(MyClass2 v) throws Exception {
> MyClass1 mc1 = new MyClass1(v.getS2());
> return mc1;
> }
> }
> {code}
> This is what the resulting WSDL contains. Obj2 is mapped fine to a String, but MyClass1 is not and should have the MyClass2 mapping here.
> {code:xml}
> <xs:complexType name="MyException">
> <xs:sequence>
> <xs:element name="str" nillable="true" type="xs:string"/>
> <xs:element name="obj2" nillable="true" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> {code}
> If you add the same adapter to a non Exception class it works just fine.
> This is NOT a duplicate of JBWS-3552 as I believe in that use case only known JAXB types were tested (HashMap, Strings etc). This issue is when you are using custom classes that need to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3692) Fix transient failures in JBWS2150TestCaseForked
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3692:
-------------------------------------
Summary: Fix transient failures in JBWS2150TestCaseForked
Key: JBWS-3692
URL: https://issues.jboss.org/browse/JBWS-3692
Project: JBoss Web Services
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: jbossws-cxf, productization
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-4.2.1
We have transient failures in JBWS2150TestCaseForked, possibly because we can end up building multiple clients in the same bus and those clients might be built against different endpoints that are however published at the same address (at different time of course).
Moreover, we should really be reading the initial server config once at the beginning of the Suite and reset values after each test method execution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3691) Refactor default webservice port retrieval mechanism
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3691:
-------------------------------------
Summary: Refactor default webservice port retrieval mechanism
Key: JBWS-3691
URL: https://issues.jboss.org/browse/JBWS-3691
Project: JBoss Web Services
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Alessio Soldano
Fix For: jbossws-cxf-4.3
The AbstractServerConfig has a getConnectorPort method for finding the default port to be used for endpoint addresses; that looks for the proper configured http connector.
The retrieval goes through a MSC service lookup (ServiceName.JBOSS.append("web", "common", "server")) in org.jboss.as.webservices.config.WebServerInfoFactoryImpl / WebServerInfoImpl. This creates a possible race condition at boot, given the web common server service might possibly start after a ws deployment process hit the EndpointAddressDeploymentAspect (actually to be verified). To be honest, the AbstractServerConfig has sensible defaults that would mitigate the problem if happening, but this this should be fixed.
A proposal would be to modify the WebServerInfoFactoryImpl / WebServerInfoImpl to wait for the availability of WS service having dependency on the web common server service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3691) Refactor default webservice port retrieval mechanism
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3691?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3691:
----------------------------------
Description:
The AbstractServerConfig has a getConnectorPort method for finding the default port to be used for endpoint addresses; that looks for the proper configured http connector.
The retrieval goes through a MSC service lookup (ServiceName.JBOSS.append("web", "common", "server")) in org.jboss.as.webservices.config.WebServerInfoFactoryImpl / WebServerInfoImpl. This creates a possible race condition at boot, given the web common server service might possibly start after a ws deployment process hit the EndpointAddressDeploymentAspect (actually to be verified). To be honest, the AbstractServerConfig has sensible defaults that would mitigate the problem if happening, but still this should be fixed.
A proposal would be to modify the WebServerInfoFactoryImpl / WebServerInfoImpl to wait for the availability of WS service having dependency on the web common server service.
was:
The AbstractServerConfig has a getConnectorPort method for finding the default port to be used for endpoint addresses; that looks for the proper configured http connector.
The retrieval goes through a MSC service lookup (ServiceName.JBOSS.append("web", "common", "server")) in org.jboss.as.webservices.config.WebServerInfoFactoryImpl / WebServerInfoImpl. This creates a possible race condition at boot, given the web common server service might possibly start after a ws deployment process hit the EndpointAddressDeploymentAspect (actually to be verified). To be honest, the AbstractServerConfig has sensible defaults that would mitigate the problem if happening, but this this should be fixed.
A proposal would be to modify the WebServerInfoFactoryImpl / WebServerInfoImpl to wait for the availability of WS service having dependency on the web common server service.
> Refactor default webservice port retrieval mechanism
> ----------------------------------------------------
>
> Key: JBWS-3691
> URL: https://issues.jboss.org/browse/JBWS-3691
> Project: JBoss Web Services
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf, jbossws-integration
> Reporter: Alessio Soldano
> Fix For: jbossws-cxf-4.3
>
>
> The AbstractServerConfig has a getConnectorPort method for finding the default port to be used for endpoint addresses; that looks for the proper configured http connector.
> The retrieval goes through a MSC service lookup (ServiceName.JBOSS.append("web", "common", "server")) in org.jboss.as.webservices.config.WebServerInfoFactoryImpl / WebServerInfoImpl. This creates a possible race condition at boot, given the web common server service might possibly start after a ws deployment process hit the EndpointAddressDeploymentAspect (actually to be verified). To be honest, the AbstractServerConfig has sensible defaults that would mitigate the problem if happening, but still this should be fixed.
> A proposal would be to modify the WebServerInfoFactoryImpl / WebServerInfoImpl to wait for the availability of WS service having dependency on the web common server service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3690) XMLJavaTypeAdapter not working in Exception Classes
by Mustafa Musaji (JIRA)
[ https://issues.jboss.org/browse/JBWS-3690?page=com.atlassian.jira.plugin.... ]
Mustafa Musaji updated JBWS-3690:
---------------------------------
Attachment: cxfTest.jar
> XMLJavaTypeAdapter not working in Exception Classes
> ---------------------------------------------------
>
> Key: JBWS-3690
> URL: https://issues.jboss.org/browse/JBWS-3690
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2
> Reporter: Mustafa Musaji
> Attachments: cxfTest.jar
>
>
> @XMLJavaTypeAdapter usage in Exception Classes does not work when mapping to a class not in the JAXB Context.
> {code:title=MyEJB.java}
> @Stateless
> @WebService
> public class MyEJB {
> public void launcheMyException() throws MyException {
> return;
> }
> }
> {code}
> {code:title=MyException.java}
> @XmlAccessorType(XmlAccessType.FIELD)
> public class MyException extends Exception {
> @XmlJavaTypeAdapter(Cl1ToCl2Adapter.class)
> MyClass1 obj1;
> @XmlJavaTypeAdapter(NoArgObjAdapter.class)
> NoArgObj obj2;
> public MyClass1 getObj1() {
> return obj1;
> }
>
> public void setObj1(MyClass1 obj1) {
> this.obj1 = obj1;
> }
> public NoArgObj getObj2() {
> return obj2;
> }
> public void setObj2(NoArgObj obj2) {
> this.obj2 = obj2;
> }
> }
> {code}
> {code:title=Cl1ToCl2Adapter.java}
> public class Cl1ToCl2Adapter extends XmlAdapter<MyClass2,MyClass1> {
> @Override
> public MyClass2 marshal(MyClass1 v) throws Exception {
> return new MyClass2();
> }
> @Override
> public MyClass1 unmarshal(MyClass2 v) throws Exception {
> MyClass1 mc1 = new MyClass1(v.getS2());
> return mc1;
> }
> }
> {code}
> This is what the resulting WSDL contains. Obj2 is mapped fine to a String, but MyClass1 is not and should have the MyClass2 mapping here.
> {code:xml}
> <xs:complexType name="MyException">
> <xs:sequence>
> <xs:element name="str" nillable="true" type="xs:string"/>
> <xs:element name="obj2" nillable="true" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> {code}
> If you add the same adapter to a non Exception class it works just fine.
> This is NOT a duplicate of JBWS-3552 as I believe in that use case only known JAXB types were tested (HashMap, Strings etc). This issue is when you are using custom classes that need to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3690) XMLJavaTypeAdapter not working in Exception Classes
by Mustafa Musaji (JIRA)
Mustafa Musaji created JBWS-3690:
------------------------------------
Summary: XMLJavaTypeAdapter not working in Exception Classes
Key: JBWS-3690
URL: https://issues.jboss.org/browse/JBWS-3690
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.2
Reporter: Mustafa Musaji
Attachments: cxfTest.jar
@XMLJavaTypeAdapter usage in Exception Classes does not work when mapping to a class not in the JAXB Context.
{code:title=MyEJB.java}
@Stateless
@WebService
public class MyEJB {
public void launcheMyException() throws MyException {
return;
}
}
{code}
{code:title=MyException.java}
@XmlAccessorType(XmlAccessType.FIELD)
public class MyException extends Exception {
@XmlJavaTypeAdapter(Cl1ToCl2Adapter.class)
MyClass1 obj1;
@XmlJavaTypeAdapter(NoArgObjAdapter.class)
NoArgObj obj2;
public MyClass1 getObj1() {
return obj1;
}
public void setObj1(MyClass1 obj1) {
this.obj1 = obj1;
}
public NoArgObj getObj2() {
return obj2;
}
public void setObj2(NoArgObj obj2) {
this.obj2 = obj2;
}
}
{code}
{code:title=Cl1ToCl2Adapter.java}
public class Cl1ToCl2Adapter extends XmlAdapter<MyClass2,MyClass1> {
@Override
public MyClass2 marshal(MyClass1 v) throws Exception {
return new MyClass2();
}
@Override
public MyClass1 unmarshal(MyClass2 v) throws Exception {
MyClass1 mc1 = new MyClass1(v.getS2());
return mc1;
}
}
{code}
This is what the resulting WSDL contains. Obj2 is mapped fine to a String, but MyClass1 is not and should have the MyClass2 mapping here.
{code:xml}
<xs:complexType name="MyException">
<xs:sequence>
<xs:element name="str" nillable="true" type="xs:string"/>
<xs:element name="obj2" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
{code}
If you add the same adapter to a non Exception class it works just fine.
This is NOT a duplicate of JBWS-3552 as I believe in that use case only known JAXB types were tested (HashMap, Strings etc). This issue is when you are using custom classes that need to be mapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3689) Ensure consistent state of server config is always used
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3689:
-------------------------------------
Summary: Ensure consistent state of server config is always used
Key: JBWS-3689
URL: https://issues.jboss.org/browse/JBWS-3689
Project: JBoss Web Services
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-integration
Reporter: Alessio Soldano
Fix For: jbossws-cxf-4.3
The ServerConfig can be modified, through management API, JMX, etc. We should ensure that each time we use data from the server config, a consistent state is actually used. This is tightly related to the work / efforts under WFLY-1759, as we might for instance keep a reference to a copy of the config with pending updates to its values still to be applied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (JBWS-3688) Upgrade to Apache CXF 2.7.7
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3688?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3688:
---------------------------------------
Author: asoldano
Date: 2013-08-20 11:09:50 -0400 (Tue, 20 Aug 2013)
New Revision: 17879
Modified:
stack/cxf/trunk/modules/addons/transports/udp/pom.xml
Log:
Adding test scope asm dependency, require by latest snapshot of cxf 2.7.7
Modified: stack/cxf/trunk/modules/addons/transports/udp/pom.xml
===================================================================
--- stack/cxf/trunk/modules/addons/transports/udp/pom.xml 2013-08-19 17:29:32 UTC (rev 17878)
+++ stack/cxf/trunk/modules/addons/transports/udp/pom.xml 2013-08-20 15:09:50 UTC (rev 17879)
@@ -26,6 +26,11 @@
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
+ <dependency>
+ <groupId>asm</groupId>
+ <artifactId>asm</artifactId>
+ <scope>test</scope>
+ </dependency>
</dependencies>
</project>
> Upgrade to Apache CXF 2.7.7
> ---------------------------
>
> Key: JBWS-3688
> URL: https://issues.jboss.org/browse/JBWS-3688
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Reporter: Alessio Soldano
> Fix For: jbossws-cxf-4.2.1
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months