[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-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-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-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-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)






[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-19] Move buildnumber-maven-plugin into a separate Maven profile. Created: 13/Dec/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: metro
Component/s: code
Affects Version/s: current
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: gmazza Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The bottom of each Metro download page for a specific Metro version gives a Subversion URL to check out the source code for hacking/debugging our web services. For example, bottom of here: http://metro.java.net/2.2.1-1/ tells us to run "svn export https://svn.java.net/svn/wsit~svn/tags/2.2.1-1 -r 7272 metro-sources". However, we cannot presently build the project via "mvn clean package" or import the project into our Eclipse IDE via "mvn eclipse:eclipse" because of the buildnumber-maven-plugin defined in metro-sources/pom.xml. Unless I comment out that plugin, I get this error:

"[ERROR] Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.0-beta-4:create (default) on project metro-project: Cannot get the revision information from the scm repository :
[ERROR] Exception while executing SCM command. svn: '/media/work1/blog-samples/metro-sources' is not a working copy"

If I comment-out this plugin, the build works fine. I suspect this plugin is primarily for the Oracle team when they're making their new releases, not for the ordinary users who want to debug their Metro web services using Metro sources. I recommend placing this particular plugin in a new Maven profile, inactive by default, so your Oracle team can activate the profile for your work while letting the regular community run "mvn clean install" etc. to quickly get the sources built. Thanks!



 Comments   
Comment by Martin Grebac [ 14/Dec/12 ]

Added <revisionOnScmFailure>false</revisionOnScmFailure> to the plugin config, so this should be solved within next release.





[METRO-18] ClassCastException while using tubes Created: 08/May/12  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: metro
Component/s: None
Affects Version/s: current
Fix Version/s: None

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

Glassfish 3.1.1, Metro 2.3, Windows


Tags: incomplete, security

 Description   

We see some failures in security area with tube message handling. We use glassfish 3.1.1 and latest metro.

Exception:

[#|2012-05-07T10:10:28.829+0200|INFO|glassfish3.1.1|com.sun.xml.wss.jaxws.impl.SecurityClientTube|_ThreadID=66;_ThreadName=Thread-2;|Response exception processed in Tube [ com.sun.xml.wss.jaxws.impl.SecurityClientTube ] Instance [ 6 ] Engine [ Metro/2.3-SNAPSHOT (trunk-7036; 2012-03-08T14:22:01+0000) JAXWS-RI/2.2.7-promoted-b26 JAXWS/2.2 svn-revision#unknown: Stub for ] Thread [ Ejb-Async-Thread-9 ]:
javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.sun.xml.ws.api.message.MessageWrapper cannot be cast to com.sun.xml.ws.security.message.stream.LazyStreamBasedMessage
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:365)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1073)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:978)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:949)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:824)
at com.sun.xml.ws.client.Stub.process(Stub.java:436)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:174)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:154)
at $Proxy337.queryActivationKeys(Unknown Source)
at com.test.SequenceNumberServiceAdapter.fetch(SequenceNumberServiceAdapter.java:39)
at com.test.RequestHandler.get(RequestHandler.java:26)
at com.test.SequenceNumberService.fetchAndSend(SequenceNumberService.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:57)
at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:101)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassCastException: com.sun.xml.ws.api.message.MessageWrapper cannot be cast to com.sun.xml.ws.security.message.stream.LazyStreamBasedMessage
at com.sun.xml.wss.jaxws.impl.SecurityTubeBase.verifyInboundMessage(SecurityTubeBase.java:442)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientResponsePacket(SecurityClientTube.java:434)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processResponse(SecurityClientTube.java:362)
... 46 more



 Comments   
Comment by Martin Grebac [ 09/May/12 ]

Please verify with latest metro 2.2.1 promoted builds - we're actively working on 2.2.1 codebase now, will get back to 2.3 later on.

Comment by Martin Grebac [ 09/May/12 ]

Also, please add a testcase if you still see the failures with recent builds.





[METRO-17] [PERF] gmbal objects consuming large part of heap Created: 28/Oct/11  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: metro
Component/s: code
Affects Version/s: None
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Jennifer Chou Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive svn_patch.zip     File wscallstack.rtf    
Issue Links:
Dependency
depends on GLASSFISH-18131 New public flag isAMXReady() Closed
blocks GLASSFISH-17044 [PERF] gmbal objects consuming large ... Open

 Description   

The gmbal API call in metro (and in GlassFish WebServicesContainer.java)

mom = ManagedObjectManagerFactory.createFederated(MONITORING_SERVER);

is causing a large number of gmbal instances to be created and is affecting GlassFish performance. See http://java.net/jira/browse/GLASSFISH-17044.
Attached is the call stack.

To reproduce follow the steps in GLASSFISH-17044, except deploy a web service instead of an app with an EJB.

The fix should be to defer the gmbal API calls until there is a JMX client connection.

From Naman: JMX service would start on 8686 (on DAS). So you can check localhost:8686 for the same. From quicklook workspace you can find the sample for the same.

In GlassFish monitoring (StatsProviderManagerDelegateImpl), we defer the gmbal API calls by extending MBeanListener.CallbackImpl and overriding mbeanRegistered method. This method is called when AMX DomainRoot is loaded (when there is a JMX connection, for example). AMX DomainRoot needs to be ready before any other mbeans can be registered.

Fix should be targeted for GlassFish 3.1.2.



 Comments   
Comment by Joe Di Pol [ 15/Dec/11 ]

A test build with a fix was provided to the performance team on Dec 15th. The report from them when running with the fix:

"the server restart time (with SPECjEnterprise deployed) goes down by 9.5%, and the footprint is reduced by 15% – 24MB of gmbal-related classes no longer show up in the heap dump."

So the fix looks good.

Comment by Michal Gajdos [ 16/Dec/11 ]

Attached a patch for review. The zip file consists of 3 svn diffs (jaxws, wsit, glassfish). These patches can be applied to the following repositories:

JAXWS:
https://svn.java.net/svn/jax-ws~sources/branches/jaxws22/jaxws-ri

WSIT:
https://svn.java.net/svn/wsit~svn/trunk/wsit

GlassFish:
https://svn.java.net/svn/glassfish~svn/branches/3.1.2

When Metro is used as a standalone application/library the behaviour remains unchanged (Gmbal objects are created immediately). If Metro is used in GlassFish with no JMX connection created the Gmbal API calls and creation of objects are postponed. At the moment a JMX client is remotely connected to the GlassFish all postponed Gmbal objects are created and from this moment Metro will create these objects and process Gmbal calls immediately.

Comment by Martin Grebac [ 09/Jan/12 ]

Integrated to GF.





[METRO-15] xhr error Created: 22/Mar/10  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: current

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

Operating System: All
Platform: All


Issuezilla Id: 15

 Description   

Hello,

I believe that I have discovered an issue around MTOM/XOP SOAP response
generation. I have tested Metro 1.1. and 1.4 with Firefox 3.6 and IE8.

It could be also a browser issue.

The problem is the Content-Type HTTP response header. It seems to be not parsed
in the browser xhr object properly resulting in XML response null.
(http://www.w3.org/TR/soap12-mtom/ 3.2. Serialization of a SOAP message)

In the header there comes something like this:

multipart/related;start="<rootpart*8d077d6b-19a4-4725-9ee2-f87f841541ad@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:8d077d6b-19a4-4725-9ee2-f87f841541ad";start-info="text/xml"

kind regards,
P.



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

Hi, do you have a testcase for this? Did you try with later releases of metro?





[METRO-14] War works on Tomcat, but doesn't on GlassFish Created: 15/Apr/09  Updated: 13/Nov/12  Resolved: 13/Nov/12

Status: Resolved
Project: metro
Component/s: code
Affects Version/s: current
Fix Version/s: 2.2

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

Operating System: All
Platform: Macintosh


Attachments: File WebApplication9.war    
Issuezilla Id: 14
Tags: metro2_2-waived

 Description   

Please see attached war file.

I do have Tomcat 5.5 with Metro 1.4, and GF 2.1 with Metro 1.4 installed. I'm
able to deploy the war to Tomcat, but not able to deploy to GF - getting the
exception below. This is blocking the tools integration.

com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to
parse runtime descriptor: runtime modeler error: Wrapper class
test.jaxws.Operation is not found. Have you run APT to generate them?
com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:118)
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4632)
org.apache.catalina.core.StandardContext.start(StandardContext.java:5312)
com.sun.enterprise.web.WebModule.start(WebModule.java:353)
com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
java.util.concurrent.FutureTask.run(FutureTask.java:123)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
java.lang.Thread.run(Thread.java:613)

Caused by: com.sun.xml.ws.model.RuntimeModelerException: runtime modeler error:
Wrapper class test.jaxws.Operation is not found. Have you run APT to generate them?
com.sun.xml.ws.model.RuntimeModeler.getClass(RuntimeModeler.java:287)
com.sun.xml.ws.model.RuntimeModeler.processDocWrappedMethod(RuntimeModeler.java:596)
com.sun.xml.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:543)
com.sun.xml.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:371)
com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:258)
com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:322)
com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:188)
com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:253)
com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147)
com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:108)
... 12 more



 Comments   
Comment by snajper [ 15/Apr/09 ]

Created an attachment (id=1)
War file

Comment by Martin Grebac [ 12/Dec/11 ]

Old issue, Updating priority, Marking as waived for 2.2, need to retest with latest metro.

Comment by Martin Grebac [ 13/Nov/12 ]

Works fine with GF 3.1.2 and latest metro.





[METRO-13] Instructions on endorsed directory outdated Created: 11/Dec/08  Updated: 14/Dec/12  Resolved: 14/Dec/12

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: 2.2.1-1

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

Operating System: All
Platform: All


Issuezilla Id: 13

 Description   

It should be made clear that the instructions at
https://metro.dev.java.net/guide/Using_JAX_WS_2_1_with_JavaSE6.html
only apply to Java SE 6 updates 0 to 3.



 Comments   
Comment by Martin Grebac [ 14/Dec/12 ]

AFAICT the paragraph is clear now.





[METRO-12] 1.3.1 download button points to 1.3 Created: 29/Oct/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: current

Type: Bug Priority: Critical
Reporter: ritzmann Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12

 Description   

The download button on the right-hand side of the main metro web page
metro.dev.java.net points to the Metro 1.3 folder instead of 1.3.1.






[METRO-11] No error check done on Policy elements (at least in security) Created: 28/Oct/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Closed
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: current

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

Operating System: All
Platform: All


Issuezilla Id: 11

 Description   

I just wasted 15 minutes or so because I had the following in the WSDL:

<sc:ValidatorConfiguration wspp:visibility="private"
certificateValidator="test.ValidatorImpl" />

... whereas the system expected

<sc:ValidatorConfiguration wspp:visibility="private">
<sc:Validator wspp:visibility="private" name="certificateValidator"
classname="test.ValidatorImpl"/>
</sc:ValidatorConfiguration>

Users are supposed to make mistakes like this, and it's a tool's responsibility
to catch a problem and report an error. As an example, the JAXB RI reports any
such incorrect attribute on any schema elements.

This is made worse by issue #4, which would have otherwise helped me catch this
problem in IDE or other schema-aware XML editors.

"you are not supposed to edit WSDL manually" is not an excuse — NetBeans
doesn't provide UI for all these configurations.



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

The error reporting was improved.





[METRO-9] Policy error check should produce line number and system ID Created: 28/Oct/08  Updated: 29/Oct/08  Resolved: 29/Oct/08

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kohsuke Assignee: metro-issues
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9

 Description   

Sometimes policy code succeeds in reporting an error (the following is a result
of intentionally putting a bogus element in the policy), but for this to be
useful, it also needs to report a line number and system ID, so that the
developer can see where the mistake is made.

That's an error handling 101.

------
Oct 28, 2008 11:54:55 AM [com.sun.xml.ws.policy.EffectiveAlternativeSelector]
selectBestAlternative
WARNING: WSP0075: Policy assertion
"

{http://schemas.sun.com/2006/03/wss/client}

NoSuchThing" was evaluated as "UNKNOWN".



 Comments   
Comment by kohsuke [ 28/Oct/08 ]

Assigning it to Fabian. I understand that he is the maintainer of the policy code.

Comment by ritzmann [ 28/Oct/08 ]

Please submit these bugs under wsit.dev.java.net in the future.

A policy on the client side typically is a merge of multiple policies. When you
have a policy like this on the server:
<wsp:Policy>
<SomeAssertion/>
</wsp:Policy>

and a policy like this on the client:
<wsp:Policy>
<NoSuchThing/>
</wsp:Policy>

The client will see:
<wsp:Policy>
<SomeAssertion/>
<NoSuchThing/>
</wsp:Policy>

We would have to maintain a reference to the source location for every single
assertion. It is also possible to merge policies with the same assertions in
them. The resulting policy will only contain one instance of that assertion. In
that case we would have to maintain a list of references to the source
locations for the assertion. In most cases, when the policy parsing code is
invoked through the JAX-WS WSDL parser, we do not have access to the location
of the WSDL document that contains the policies at all.

Comment by kohsuke [ 28/Oct/08 ]

Yes, the policy code needs to remember where every single assertions came from,
and yes, that's what we do elsewhere — javac remembers line and column number
for every AST node, XJC and wsimport remembers where every binding came from,
JAXP schema validator remembers where each declaration came from, and so is the
rest of the WSDL model in the JAX-WS runtime.

And I could be wrong, but WSDLParserExtension gives you XMLStreamReader, which
has the location information via XMLStreamReader.getLocation(). So you do have
the location information, don't you.

Comment by ritzmann [ 29/Oct/08 ]

Copied to WSIT issue tracker:
https://wsit.dev.java.net/issues/show_bug.cgi?id=1049





[METRO-8] Inconsistency in AsymmetricBindingProcessor Created: 28/Oct/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: current

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

Operating System: All
Platform: All


Issuezilla Id: 8

 Description   

AsymmetricBindingProcessor.process method reads:

public void process()throws PolicyException{
Token st = getSignatureToken();
Token et = getEncryptionToken();
if(st != null)

{ primarySP = new SignaturePolicy(); .... }

if(et != null)

{ primaryEP = new EncryptionPolicy(); .... }

....
addPrimaryTargets();

and the addPrimaryTargets method reads:

protected void addPrimaryTargets()throws PolicyException{
SignaturePolicy.FeatureBinding spFB =
(SignaturePolicy.FeatureBinding)primarySP.getFeatureBinding();
EncryptionPolicy.FeatureBinding epFB =
(EncryptionPolicy.FeatureBinding)primaryEP.getFeatureBinding();

So this code results in NPE in addPrimaryTargets() if either 'st' or 'et' are
null in the process method.

Therefore this code is inconsistent — if a signature token and an encryption
token has to be always present, then such an error check should be performed
earlier (in the constructor) and a graceful error message should be reported to
the user, pointing to the wrong WSDL.

If either of those can be indeed null, then the addPrimaryTargets() method
shouldn't choke with NPE.



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

This I see fixed in current version of the code.





[METRO-7] Metro 1.3.1 missing in Maven Created: 28/Oct/08  Updated: 29/Oct/08  Resolved: 29/Oct/08

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: kohsuke Assignee: ritzmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7

 Description   

Even though https://metro.dev.java.net/ cites 1.3.1 as the latest version, those
jar files are missing from the Maven repositories.



 Comments   
Comment by ritzmann [ 28/Oct/08 ]

We are currently working on automating the Maven uploads so that this will not
happen in the future. I'll look into making the upload manually.

Comment by ritzmann [ 29/Oct/08 ]

Done.





[METRO-6] Source jars missing in Maven repositories Created: 28/Oct/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: kohsuke Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6

 Description   

Metro only pushes binary jar files but not source jars. This substantially
reduces the debuggability of Metro, and lowers the likelihood that we get
contributions/patches from external developers.



 Comments   
Comment by ritzmann [ 28/Oct/08 ]

Do you have a pointer to the conventions that Maven normally uses to create
source bundles?

This will likely take some time to implement since the build scripts that
create source bundles have fallen into disrepair.

Comment by kohsuke [ 28/Oct/08 ]

See http://download.java.net/maven/1/com.sun.xml.bind/java-sources/ as an example.

In Maven jargon, a source jar has the "sources" classifier (or in plain English,
it ends with "-sources.jar"), and contains .java files where you normally expect
class files. Unlike source bundles often seen in the wild from Ant builds, there
shall be no build script, no "src" directory or any other intermediate
directories. Just source files in the package structure.

Compared to the source bundle, which normally retains the original source tree
structure, build script, and associated jar files, the source jar takes a
different form.

For a starter, it's OK for the source jar to be incomplete. If you can point me
to the part of the build script in WSIT that pushes jars to Maven repository,
I'm happy to take a shot at fixing this.

Comment by ritzmann [ 29/Oct/08 ]

We typically run something like "ant jar" from the wsit main directory,
followed by a "mvn -f etc/maven/pom.xml deploy". The POMs simply pick up the
JARs from the Ant run. We have a src-zip target in the main build.xml but what
it zips is in parts incomplete and in other parts more than what we have in the
deployed JARs. (And the contents certainly do not follow Maven conventions.)

Comment by kohsuke [ 29/Oct/08 ]

Which branch of WSIT workspace should I attempt a fix in?

Comment by ritzmann [ 29/Oct/08 ]

HEAD

Comment by Martin Grebac [ 09/Dec/11 ]

All the artifacts source/javadoc are deployed and synced to central starting with 2.2.





[METRO-5] webservices-api POM is missing dependencies Created: 28/Oct/08  Updated: 29/Oct/08  Resolved: 29/Oct/08

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: kohsuke Assignee: ritzmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5

 Description   

See
http://maven.dyndns.org/2/javax/xml/webservices-api/1.4-SNAPSHOT/webservices-api-1.4-SNAPSHOT.pom
for example.

It's missing dependencies to API jars that are presumably in GF. This prevents
the stand-alone use of Metro from Maven.

If having this kind of dependency in POM is problematic for GFv3 builds, then
that probably means we need two sets of groupId/artifactId, one for stand-alone
Metro use and the other for GFv3 use.

The missing dependency below:

<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
</dependency>



 Comments   
Comment by ritzmann [ 28/Oct/08 ]

We already have a separate set specifically for GF V3 builds that contains only
OSGi bundles. This is a genuine bug.

Comment by ritzmann [ 29/Oct/08 ]

Fixed on 1.4 branch and trunk.





[METRO-3] nbproject for rt build depends on missing xmldsig.jar Created: 07/Aug/08  Updated: 22/Aug/08  Resolved: 22/Aug/08

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: pbw Assignee: ritzmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3

 Description   

When opened in NetBeans the rt project from the metro 1.3 snapshot bundle has a
dependency on the library ../lib/xmldsig.jar. This jar is not present in the lib
directory, nor is it needed for the build.



 Comments   
Comment by ritzmann [ 07/Aug/08 ]

Taking issue. Thanks for the hint. It'll take a few days to resolve because the
1.3 branch is in maintenance mode now. There is a 1.3 release bundle available
now (with the same bug).

Comment by ritzmann [ 07/Aug/08 ]

Actually assigning this to me.

Comment by ritzmann [ 07/Aug/08 ]

And setting it to started again...

Comment by ritzmann [ 19/Aug/08 ]

This issue is addressed in the next bugfix release (Metro 1.4). If you need to
work with Metro 1.3 source code, do this:

  • Open the WSIT Runtime project in NetBeans.
  • Right-click on the project in the Projects navigator and select Properties.
  • Select the Libraries category.
  • In the list of compile-time libraries, search for the entry "Broken
    reference: xmldsig.jar". Select that reference and click the Remove button.
  • Press OK and allow NetBeans to regenerate the build-impl.xml.
Comment by ritzmann [ 22/Aug/08 ]

There will be a 1.3 maintenance release and I committed the fix to the 1.3
branch.





[METRO-2] Metro 1.2 jars not loaded in Java.net Maven 2 Repo Created: 16/May/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Closed
Project: metro
Component/s: www
Affects Version/s: 1.2
Fix Version/s: 2.0

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

Operating System: All
Platform: All


Issuezilla Id: 2

 Description   

The Metro 1.2 release is NOT completely deployed in the Java.net Maven 2
repository. The webservices-extra-api.jar and webservices-extra.jar are missing.

Also, the Group Id for these is confusing. Some packages are on com.sun.xml.ws,
others are in javax.xml. I would think the api packages should all be part of
javax.xml.ws as the group id, or since they are not the RI, use com.sun.xml.ws
for everything.

Please fix this asap, as I need to have these installed in order to keep using
Metro.



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

We're deploying all the artifacts to maven with later releases of metro.





[METRO-1] Release notes for Metro 1.1 based on JAX-WS RI release notes Created: 03/Jan/08  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Resolved
Project: metro
Component/s: www
Affects Version/s: current
Fix Version/s: current

Type: Bug Priority: Minor
Reporter: pbwest Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1

 Description   

The release notes for Metro 1.1 contain inaccurate information. For example, in
the Tools section:
Running on JDK6

  • Copy METRO_HOME/lib/jaxws-api.jar to JDK6_HOME/jre/lib/endorsed directory
  • Copy METRO_HOME/lib/jaxb-api.jar to JDK6_HOME/jre/lib/endorsed directory

Should that be METRO_HOME/lib/webservices*api.jar?

In addition, it is not clear that the webservices*jar files in the metro 1.1 lib
supersede the set of jars that was previously required.



 Comments   
Comment by Martin Grebac [ 09/Dec/11 ]

Latest guides/release notes do not face the issue.





Generated at Tue Apr 25 13:39:28 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.