[METRO-33] WebMethods from different classes with same name don't work Created: 08/Apr/16  Updated: 08/Apr/16

Status: Open
Project: metro
Component/s: None
Affects Version/s: not determined, 2.3
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: PeterSdsw Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

org.glassfish.metro:webservices-rt:2.3.1
Tomcat 7



 Description   

Following Java-first approach to develop soap-services for Tomcat 7, using org.glassfish.metro:webservices-rt:2.3.1 as soap-provider via Maven.

If webservices have the same function name but in different classes with different parameters and return-types, only one of them will work when deployed to the webserver, the other will report a argument type mismatch.

Parameters and return-types are classes with @XmlRootElement defined and different namespaces.

If one of the functions is renamed, both of them will work.






[METRO-32] Improper OSGi manifest Created: 23/Mar/15  Updated: 11/Nov/15

Status: Open
Project: metro
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Herr-Herner Assignee: Martin Grebac
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I am using the OSGi version of Metro in version 2.3.1, but I cannot create an OSGi runtime environment so that all package dependencies get fulfilled. I have a minimum standalone runtime (without OSGi) using:
jetty:9.2.10.v20150310, stax:1.7.7, gmbal:4.0.0.b001, management-api:3.2.1.b002, pfl-tf:4.0.0.b004, pfl-basic:4.0.0.b004, ha-api:3.1.9, javax.servlet-api:3.1.0.

Everything is working fine, but in OSGi I have tried to fulfill all package dependencies, but there is no way of getting Metro working. Some packages are not available on the OSGi package layer by third party bundles and some come directly from the underlying JRE. I think that the manifest file must be fixed to get a working version of Metro in OSGi and make all packages optional that are not required by Metro.

That's a hard blocker for me and hopefully there is an OSGi expert available that can help me getting Metro running under OSGi.



 Comments   
Comment by Herr-Herner [ 25/Mar/15 ]

I got it working, but you must correct the manifest generation.

Here is the solution. Can you please add it?

webservices-osgi:pom.xml
<Import-Package>
...
com.sun.xml.xsom.*;resolution:=optional,
...
</Import-Package>
<DynamicImport-Package>
*
</DynamicImport-Package>

The packages com.sun.xml.xsom.* are exported by jaxb-osgi, but without any versions. The fix in the import statements allows OSGi to bind the optional package dependency to jaxb-osgi bundle. The dynamic package import of * is necessary, because we must load classes listed in the @WebService annotation at runtime, e.g. @WebService(endpointInterface = "webservice.TestWebService"). Otherwise, we get a ClassNotFoundException because the interfaces are not known in advance, so that the packages dependencies cannot be declared in form of import statements.

Comment by Martin Grebac [ 30/Mar/15 ]

Looking at JAXB builds, jaxb osgi manifest, I'm seeing:
com.sun.xml.xsom;uses:="org.relaxng.datatype,org.xml.sax,com.sun
.xml.xsom.impl.scd,javax.xml.namespace,com.sun.xml.xsom.util,com.sun.
xml.xsom.parser,com.sun.xml.xsom.visitor";version=20140925
in the export. So, the version is in there. Am I missing something?
DynamicImport causes trouble to consuming products, such as GF:
http://wiki.osgi.org/wiki/DynamicImport-Package
Though I'm not aware of any other solution.

Comment by Herr-Herner [ 01/Apr/15 ]

I am refering to webservices-osgi 2.3.1. The manifest contains under Import-Package com.sun.xml.xsom.parser;version="[20130531.0,20130532)", but the jaxb-osgi 2.2.11 has the export statement com.sun.xml.xsom.parser;version=20140925. The versions do not match resulting that webservices-osgi does not get resolved. Any ideas?

Without the DynamicImport-Package statement, a web service containing e.g. @WebService(endpointInterface = "webservice.TestWebService") fails with a ClassNotFoundException because the package "webservice" is not visible to the classloader of webservices-osgi that you are using for loading the class. If you use another classloader, this will be possible. One way is to get the classloader of the class containing the annotation (that is acually the WebService implementation) and get the class from him. This classloader sees the class in OSGi because it is the classloader of the corresponding bundle.

If you are willing to make some code adaptions, I would try to test it directly in my OSGi environment. My aim is to get a full working version of Metro in the OSGi world.

Comment by Herr-Herner [ 01/Apr/15 ]

Just a question: What are the next steps in Metro development? The project seems not be really active, although Sun, Oracle and you made a good implementation job and I think it is worthwhile to revive Metro. In comparison to Apache CXF, Metro is much more light-weighted, but the project requires "some" maintainance work. It builds only under an old Maven version (I used 3.0.5, it fails with 3.3.1) and only with Java 7. Your dependencies are outdated and need to be replaced, requiring some code adaptions. Even in times where everybody thinks that RESTful services are the answer to everything, I am of the opinion that "classical" SOAP-based Web Services have the right to coexist.

Comment by petr_dolezal [ 11/Nov/15 ]

Voting for this issue as well (and I'd vote for related JAX_WS-396 if not closed already). I'm trying to run Metro in an OSGi container using the bundles from osgi/ folder supplied in the Metro 2.3.1 release and I'm having really tough time. Again.

Originally, we wrapped Metro and other problematic libraries in a single monolithic bundle. It was few years ago, when the OSGi support was weak for most libraries. However, although it works, this approach is not really viable, it has some limitations and brings other problems. Therefore we were separating the bundled parts from the monolithic behemoth step after step, as the upgrades of the libraries allowed. The remaining part now is basically the web-related stuff and Metro is the the major reason why we were not able to finish the separation so far. Now we need to upgrade a part of our dreadful monolith, so we attempted again to break its hard core and finally get rid of it.

My setup starts from quite small core based on Equinox (Mars) with basic Jetty 9 parts, running on JRE 8. Then I tried to add Metro and it began. It seems that Metro requires really many other bundles, which are often difficult to find. Some of imported packages (even not optional!) look very dubious: I really don't understand why a WS framework requires javax.mail (just one example) or why a web service client application running in an OSGi container must provide the Servlet API.

I have the suspicion that the release might be tried with Glassfish, where it perhaps works fine, because Glassfish is capable of providing all those dependencies, although that are not usually needed. But for other, more light-weight containers these dependencies provide a very difficult obstacle.

OK, my humble request calls for adapting Metro, so that it can be deployed easily into a generic OSGi container that provides minimal, but sufficient support for running a web service or for acting as a web service client.

My situation can be replicated easily. Although we use Equinox as the OSGi container, any other comparable container can be used; e.g., Felix is very easy to use. Just download the container and supply following bundles. And then try to make even the Metro bundles resolved/active. Being desperate, I started to mark some imports as optional and even then it took non-trivial effort to make it start at least.

Here is the set of bundles that I start with, webservices-osgi.jar is the only troublemaker then:

// Bundle list: bundle symbolic name, version, file name
//
// Runtime support
// Mostly for javax.* bundles (although not complete yet, but these look essential)
javax.el, 2.2.0.v201303151357, javax.el_2.2.0.v201303151357.jar
javax.jws, 2.0.0.v201005080400, javax.jws_2.0.0.v201005080400.jar
javax.servlet.jsp, 2.2.0.v201112011158, javax.servlet.jsp_2.2.0.v201112011158.jar
javax.servlet, 3.1.0.v201410161800, javax.servlet_3.1.0.v201410161800.jar
javax.xml.stream, 1.0.1.v201004272200, javax.xml.stream_1.0.1.v201004272200.jar
javax.xml.ws, 2.1.0.v200902101523, javax.xml.ws_2.1.0.v200902101523.jar
javax.xml, 1.3.4.v201005080400, javax.xml_1.3.4.v201005080400.jar
org.apache.bcel, 5.2.0.v201005080400, org.apache.bcel_5.2.0.v201005080400.jar
org.apache.xalan, 2.7.1.v201005080400, org.apache.xalan_2.7.1.v201005080400.jar
org.apache.xerces, 2.9.0.v201101211617, org.apache.xerces_2.9.0.v201101211617.jar
org.apache.xml.resolver, 1.2.0.v201005080400, org.apache.xml.resolver_1.2.0.v201005080400.jar
org.apache.xml.serializer, 2.7.1.v201005080400, org.apache.xml.serializer_2.7.1.v201005080400.jar
org.objectweb.asm.all, 5.0.4, asm-all-5.0.4.jar

// Jetty
org.eclipse.jetty.continuation, 9.3.5.v20151012, jetty-continuation-9.3.5.v20151012.jar
org.eclipse.jetty.deploy, 9.3.5.v20151012, jetty-deploy-9.3.5.v20151012.jar
org.eclipse.jetty.http, 9.3.5.v20151012, jetty-http-9.3.5.v20151012.jar
org.eclipse.jetty.io, 9.3.5.v20151012, jetty-io-9.3.5.v20151012.jar
org.eclipse.jetty.jmx, 9.3.5.v20151012, jetty-jmx-9.3.5.v20151012.jar
org.eclipse.jetty.schemas, 3.1.0.M0, jetty-schemas-3.1.jar
org.eclipse.jetty.security, 9.3.5.v20151012, jetty-security-9.3.5.v20151012.jar
org.eclipse.jetty.server, 9.3.5.v20151012, jetty-server-9.3.5.v20151012.jar
org.eclipse.jetty.servlet, 9.3.5.v20151012, jetty-servlet-9.3.5.v20151012.jar
org.eclipse.jetty.servlets, 9.3.5.v20151012, jetty-servlets-9.3.5.v20151012.jar
org.eclipse.jetty.util, 9.3.5.v20151012, jetty-util-9.3.5.v20151012.jar
org.eclipse.jetty.webapp, 9.3.5.v20151012, jetty-webapp-9.3.5.v20151012.jar
org.eclipse.jetty.xml, 9.3.5.v20151012, jetty-xml-9.3.5.v20151012.jar

// Web Services
// Here the problems start
jaxb-api, 2.2.12.b140109_1041, jaxb-api.jar
com.sun.xml.bind.jaxb-osgi, 2.2.10.b140802_1033, jaxb-osgi.jar
stax2-api, 3.1.1, stax2-api.jar
org.glassfish.metro.webservices-api-osgi, 2.3.1, webservices-api-osgi.jar
org.glassfish.metro.webservices-osgi, 2.3.1, webservices-osgi.jar
woodstox-core-asl, 4.2.0, woodstox-core-asl.jar





[METRO-21] MessageDumpingFeature is showing 'greater than' signs that are character entities in the response as the actual signs, Created: 22/Feb/13  Updated: 28/Apr/15

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.2.1-1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: BasVandenBroek Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour
Environment:

JDK 1.6 update 32



 Description   

If a webservice returns this value:

<SomeResult><somefaketag></SomeResult>

The MessageDumpingFeature will actually log it as this:

<SomeResult><somefaketag></SomeResult>

As you can see the smaller than sign (<) is fine but it somehow shows the 'greater than' character entity as the actual sign.

I will add a testproject. I did not include webservices-rt.jar itself due to the size. If you run this project you can include this yourself in the lib folder and fix the .classpath. I used Metro 2.2.1-1.
The project starts a Jetty server which serves as a webservice, it just returns a hardcoded string. This webservice is called and the response is logged.

Instructions:
Run the main method in Test.java and check the logging.



 Comments   
Comment by BasVandenBroek [ 22/Feb/13 ]

I seem to be unable to attach my testproject to this ticket..
Also the ticket text is now showing the full greater than and smaller than signs. I will try to use the ampersand symbol as well so you can see the symbol variants.

If a webservice returns this value:

<SomeResult>&lt;somefaketag&gt;</SomeResult>

The MessageDumpingFeature will actually log it as this:

<SomeResult>&lt;somefaketag></SomeResult>

Comment by Martin Grebac [ 22/Feb/13 ]

Hi, could you post the attachment some place else and just provide link?

Comment by BasVandenBroek [ 22/Feb/13 ]

Attachment uploaded to http://www.herosh.com/download/11087232/metrologgingbug.zip.html

Comment by BasVandenBroek [ 24/Feb/13 ]

Just wondering what happened to the option to add a testproject? I was able to do so for a previous ticket. Anyway I hope you are able to download the testproject from herosh.

Comment by BasVandenBroek [ 20/Dec/13 ]

Hello guys, can I get an update on the status of this bug?

Comment by BasVandenBroek [ 28/Apr/15 ]

Ok, I guess I can assume the Metro project to be dead?





[METRO-30] Adding MessageDumpingFeature sometimes causes the body of the message to disappear! Created: 14/Aug/14  Updated: 28/Apr/15

Status: Open
Project: metro
Component/s: code
Affects Version/s: 2.1, 2.1.1, 2.2, 2.2.1, 2.2.1-1, 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: BasVandenBroek Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows, Unix. Various versions of JDK 1.6 and 1.7.



 Description   

When adding a MessageDumpingFeature when calling service.createDispatch, in some cases the body is removed from the soap request when the web service is called. This obviously does not happen in all cases but we've had various cases where it does occur. I have made a test project that reproduces this issue



 Comments   
Comment by BasVandenBroek [ 14/Aug/14 ]

I can not add a test project to the ticket directly, but you can download it here: http://www.herosh.com/download/876/metromessagedumpingbug_withoutwebservices-rt.zip.html

This is an Eclipse project that reproduces the entire issue. All you have to do is add the webservice-rt.jar because it's too big to include, and maybe fix the classpath.

Please let me know if there is a better alternative to adding an attachment to this ticket.

Comment by BasVandenBroek [ 26/Sep/14 ]

Can I please get a reply?

Comment by BasVandenBroek [ 28/Apr/15 ]

Ok, I guess I can assume the Metro project to be dead?





[METRO-28] Metro 2.3 / WCF. Nested class variables with same name as class return null from service endpoint. Created: 28/Jul/14  Updated: 28/Aug/14

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mtostenson Assignee: Martin Grebac
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8.1 Pro, Java 1.7.0, Metro 2.3



 Description   
Summary

MetroHello WebService

This is a simple jax-ws bottom-up WebService implementation that produces a bug in Metro 2.3.

The issue occurs when a WCF consumer class receives an object from the endpoint that contains a nested class instance whose name matches that of the class: it comes back null.

MetroHello.java
package com.michaelt.ws;

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.RPC)
public interface MetroHello {
	
	@WebMethod Hello getNewHello();
	
	@WebMethod Hello sayHelloWorld(Hello hello);

}

When sayHelloWorld method below sends the Hello object back to WCF consumer, its "world" member variable is null.

MetroHelloImpl.java
package com.michaelt.ws;

import javax.jws.WebService;

@WebService(endpointInterface="com.michaelt.ws.MetroHello")
public class MetroHelloImpl implements MetroHello {
	
	@Override
	public Hello getNewHello() {
		return new Hello();
	}
	
	@Override
	public Hello sayHelloWorld(Hello pHello) {
		pHello.world.message = "Hello World";
		return pHello;
	}
	
}

The problem arises when there is a nested class instance whose name matches the class like the example of "World world" below.

Hello.java
package com.michaelt.ws;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Hello {
	
	// The endpoint will always return this as null
	public World world = new World();
	
}

When "world" is renamed to anything else, it does not return null.

World.java
package com.michaelt.ws;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class World {
	
	public String message;
	
}
Cause

Metro 2.3 vs. Metro 2.0.1

In this scenario, the cause of the problem can be found in the .xsd's generated by Metro. This issue doesn't exist in older Metro versions, and it has to do with the xml definition of the nested class being referenced in version 2.3. Notice the difference inside the body of the <sequence> tag between the two versions.

Metro 2.3
<xs:schema version="1.0" targetNamespace="http://ws.michaelt.com/">
	<xs:element name="hello" type="tns:hello"/>
	<xs:element name="world" type="tns:world"/>
	<xs:complexType name="hello">
		<xs:sequence>
			<xs:element ref="tns:world" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="world">
		<xs:sequence>
			<xs:element name="message" type="xs:string" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
</xs:schema>

The ref attribute in 2.3 is possibly confused by member variable "world"?

Metro 2.0.1
<xs:schema version="1.0" targetNamespace="http://ws.michaelt.com/">
	<xs:element name="hello" type="tns:hello"/>
	<xs:element name="world" type="tns:world"/>
	<xs:complexType name="hello">
		<xs:sequence>
			<xs:element name="world" type="tns:world" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="world">
		<xs:sequence>
			<xs:element name="message" type="xs:string" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
</xs:schema>


 Comments   
Comment by snowtoad2 [ 28/Aug/14 ]

Is this issue tracking site active? Has anyone been able to review this specific issue?





[METRO-29] jaxbcontext.class. please make sure that you are specifying the proper classloader Created: 31/Jul/14  Updated: 31/Jul/14

Status: Open
Project: metro
Component/s: www
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: balkrishna Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

We are using Metro web service 2.2.1 in our code, we are getting the following ClassCastException.
From the error it looks like it is using the JAXBContext.class from webservices-api.jar whereas during runtime it is expecting JAXB class from jdk1.7.0_17.

As per Metro guidelines we have to package the webservices-api.jar in our application ear to make it Metro compliant.

Please let me know if there is a solution to this issue as we cannot make our webservices Metro compliant until this issue is resolved.

javax.xml.bind.JAXBException: ClassCastException: attempting to cast zip:C:/RPS_workspace/rps/rpa/rpa-netserver/java/rpa1/Weblogic/servers/AdminServer/tmp/_WL_user/RPA/gamr3e/APP-INF/lib/webservices-api-2.2.1-1.jar!/javax/xml/bind/JAXBContext.class to jar:file:/C:/Program%20Files/Java/jdk1.7.0_17/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class. Please make sure that you are specifying the proper ClassLoader.
at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:115)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:251)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:432)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)

We are using WebLogic 12c server.

Regards,
BalKrishna.






[METRO-27] If web application is available on multiple port (say 8080 and 8081) then if i publish a web service on 8090 port then it is accessible on both port. It should not be accessible from other ports. Created: 24/Apr/14  Updated: 24/Apr/14

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.2.1-1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: amityvipin Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 8gb ram



 Description   

If web application is available on multiple port (say 8080 and 8081) then if i publish a web service on 8090 port then it is accessible on both port. It should not be accessible from other ports.






[METRO-26] I am unable to publish webservice on HTTPS protocol. It say that is is not supported. Created: 24/Apr/14  Updated: 24/Apr/14

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.2.1-1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: amityvipin Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 8GB Ram.



 Description   

I am unable to publish webservice on HTTPS protocol. It say that is is not supported.






[METRO-25] If i publish a web service on version SOAP 1.1 and then edit it in SOAP 1.2 or vice versa. Now if i try to check the WSDL for the webservice it shows old WSDL with SOAP 1.1 binding. Created: 24/Apr/14  Updated: 24/Apr/14

Status: Open
Project: metro
Component/s: code
Affects Version/s: 2.2.1-1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: amityvipin Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Window 7, 8GB Ram



 Description   

If i publish a web service on version SOAP 1.1 and then edit it in SOAP 1.2 or vice versa. Now if i try to check the WSDL for the webservice it shows old WSDL with SOAP 1.1 binding.

But if i start my application it works perfectly. It was earlier works perfectly with metro 2.1 version. I recently upgraded to 2.3(latest version) as per your site.






[METRO-24] Cannot call web services which return non-XML responses Created: 01/Apr/14  Updated: 01/Apr/14

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.2.1, 2.2.1-1, 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nhinds Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Web services which return non-XML data no longer return any data when called via the metro web service library. This worked in metro 1.5, 1.6.2, 2.0, 2.1 and 2.2, but does not work against 2.2.1, 2.2.1-1 or 2.3.

This appears to be because Packet.getMessage() now returns a MessageWrapper object, instead of the real Message object. This in turn means that XMLMessage.getDataSource() can't see that UnknownContent objects implement MessageDataSource, and ends up calling UnknownContent.writePayloadTo(XMLStreamWriter) (which does nothing) instead of UnknownContent.getDataSource().



 Comments   
Comment by nhinds [ 01/Apr/14 ]

Here is a testcase which passes when run with Metro 1.5/1.6.2/2.0/2.1/2.2 and fails when run with metro 2.2.1/2.2.1-1/2.3:

import static org.junit.Assert.assertSame;
import static org.junit.Assert.assertTrue;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

import javax.activation.DataSource;
import javax.activation.FileDataSource;
import javax.xml.namespace.QName;
import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;
import javax.xml.ws.Dispatch;
import javax.xml.ws.Service;
import javax.xml.ws.Service.Mode;
import javax.xml.ws.handler.MessageContext;
import javax.xml.ws.http.HTTPBinding;

import org.junit.Test;

import com.sun.xml.ws.api.SOAPVersion;
import com.sun.xml.ws.api.message.Message;
import com.sun.xml.ws.api.message.Messages;
import com.sun.xml.ws.api.message.Packet;
import com.sun.xml.ws.encoding.xml.XMLMessage;
import com.sun.xml.ws.encoding.xml.XMLMessage.MessageDataSource;

public class NonXmlDispatchIssueTest {
	@Test
	public void callNonXmlResourceViaJavaxXmlAPI() throws IOException {
		final List<String> failures = new ArrayList<String>();

		final Service service = Service.create(new QName("dummy", "value"));
		final QName portName = new QName("dummy", "port");
		service.addPort(portName, HTTPBinding.HTTP_BINDING, "http://google.com");
		final Dispatch<Source> dispatch = service.createDispatch(portName, Source.class, Mode.MESSAGE);
		dispatch.getRequestContext().put(MessageContext.HTTP_REQUEST_METHOD, "GET");

		final Source response = dispatch.invoke(null);

		if (response instanceof StreamSource) {
			final StreamSource streamSource = (StreamSource) response;
			final int firstRead = streamSource.getReader() != null ? streamSource.getReader().read() : streamSource.getInputStream().read();
			if (firstRead == -1) {
				failures.add("Calling a non-XML URL should return some data");
			}
		} else {
			failures.add("Source should be a StreamSource");
		}

		assertTrue("Failures: " + failures, failures.isEmpty());
	}

	@Test
	public void callNonXmlResourceViaComSunXmlAPI() throws IOException {
		final List<String> failures = new ArrayList<String>();

		final Service service = Service.create(new QName("dummy", "value"));
		final QName portName = new QName("dummy", "port");
		service.addPort(portName, HTTPBinding.HTTP_BINDING, "http://google.com");
		final Dispatch<Message> dispatch = service.createDispatch(portName, Message.class, Mode.MESSAGE);
		dispatch.getRequestContext().put(MessageContext.HTTP_REQUEST_METHOD, "GET");

		final Message response = dispatch.invoke(Messages.createEmpty(SOAPVersion.SOAP_11));

		if (!(response instanceof MessageDataSource)) {
			failures.add("Message should implement MessageDataSource or XMLMessage.getDataSource will not work");
		}

		final DataSource dataSource = XMLMessage.getDataSource(response, null);
		if (dataSource.getInputStream().read() == -1) {
			failures.add("Calling a non-XML URL should return some data");
		}

		assertTrue("Failures: " + failures, failures.isEmpty());
	}

	@Test
	public void getDataSourceFromMessageWrapper() {
		final DataSource inputDataSource = new FileDataSource("");
		final Packet packet = new Packet(new XMLMessage.UnknownContent(inputDataSource));
		final DataSource outputDataSource = XMLMessage.getDataSource(packet.getMessage(), null);
		assertSame("Should be able to retrieve the original DataSource", inputDataSource, outputDataSource);
	}
}





[METRO-23] Decoupled endpoint in AcksTo address never receives sequenceacknowledgements Created: 03/Mar/14  Updated: 03/Mar/14

Status: Open
Project: metro
Component/s: code
Affects Version/s: 2.2.1-1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: GerhardBoer Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7



 Description   

When using metro with a decoupled endpoint, so we can use the asynchronous functionality of WSRM, the sequenceacknowledgements never arrive at the destination.

The other responses (CreateSequenceResponse, CloseSequenceResponse and TerminateSequenceResponse) do arrive at this endpoint, but the SequenceAcknowledgement is lost.

When looking through the code i found the following:
class: ClientTube , starting from linenumber 145

// TODO P3 we should also take into account addressable clients
final WsmcRuntimeProvider wsmcRuntimeProvider = context.getImplementation(WsmcRuntimeProvider.class);
if (configuration.isMakeConnectionSupportEnabled()) {
assert wsmcRuntimeProvider != null;

this.rmSourceReference = wsmcRuntimeProvider.getWsmcAnonymousEndpointReference();
wsmcRuntimeProvider.registerProtocolMessageHandler(createRmProtocolMessageHandler(rc));
} else {
this.rmSourceReference = configuration.getAddressingVersion().anonymousEpr;
}

This looks like it means that the source is always anonymous.

For this project the use of MakeConnection is not a possibilty, because we want the users to have as little dependencies as possible.

Is this something which has not been added yet, or do i need to look somewhere else to send the sequenceacknowledgements to a decoupled endpoint?






[METRO-22] java.lang.ClassCastException: org.glassfish.api.invocation.ComponentInvocation cannot be cast to com.sun.ejb.EjbInvocation Created: 11/Feb/14  Updated: 11/Feb/14

Status: Open
Project: metro
Component/s: None
Affects Version/s: 2.2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: D.J.LiuXiaoyu Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 glassfish 4.0



 Description   

Using EJB's applications with WS-RM,the bellow exception occurs.

[2014-02-11T09:31:02.551+0800] [glassfish 4.0] [SEVERE] [] [com.sun.xml.ws.server.sei.TieHandler] [tid: _ThreadID=405 _ThreadName=rm-server-tube-communicator-fiber-executor-thread-1] [timeMillis: 1392082262551] [levelValue: 1000] [[
org.glassfish.api.invocation.ComponentInvocation cannot be cast to com.sun.ejb.EjbInvocation
java.lang.ClassCastException: org.glassfish.api.invocation.ComponentInvocation cannot be cast to com.sun.ejb.EjbInvocation
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:117)
at com.sun.proxy.$Proxy401.sayHello(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.webservices.InvokerImpl.invoke(InvokerImpl.java:82)
at org.glassfish.webservices.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:88)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:136)
at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.run(Fiber.java:813)
at com.sun.xml.ws.api.server.ThreadLocalContainerResolver$2$1.run(ThreadLocalContainerResolver.java:112)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)






Generated at Tue Jan 24 09:25:47 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.