Tag Archives: JAX-WS

JAX-WS Hello World Example – Document Style

via JAX-WS Hello World Example – Document Style | Examples Java Code Geeks.

In this example we are going to see how to create, deploy and consume Web Services using JAX-WS. JAX-WS is a fine tool for creating Web Services and it’s included in the JDK since JDK 1.6.

You are going to see how easy it is to create and deploy Web Services using Document Style. What you need to run this example is only JDK 1.6 or above and that’s that.

The basic architecture of a JAX-WS Web Service consists of two main parts:

  1. A Web Service Endpoint: It is a connection point where pages and Web Services are exposed to consumers and clients.
  2. A Web Service Client: The program that makes use of the published Web Service from the above Endpoint.

JAX-WS Attachment With MTOM

via JAX-WS Attachment With MTOM | Examples Java Code Geeks.

In this tutorial we are going to see how to use JAX-WS along with Message Transmission Optimization Mechanism (MTOM) in order to transfer images from a Web Service endpoint to a Client and vise versa. So, in this example we are going to create a Web Service that a client can use in order to download or upload an image. As we know, Web Services uses SOAP messages to communicate with clients that want to use the service. SOAP is an XML based protocol, so it uses XML-Binary Optimized Packaging (XOP) in order to transmit binary data (like an image) over XMl.

It would be very useful to read JAX-WS Hello World Example – RPC Style before proceeding to this example.

Creating SOAP Web Services using JAX-WS

via Creating SOAP Web Services using JAX-WS – JAXenter.

This article explains how to create SOAP-based web services using the JAX-WS API and deploy it with Tomcat. The tutorial follows a step-by-step approach to writing a client using Java’s wsimport utility.

The web service shown in this article is deployed live here.

There are various ways of creating web services. In this post we are going to create a SOAP based web service using JAX-WS, which is Java API for XML Web Services and we will deploy it under Tomcat.

One important point to remember is, both SOAP and REST style web services can be built using JAX-WS. There is a common misconception that JAX-WS is used for creating SOAP based web services and JAX-RS is used for creating REST style web services.

JAX-WS API is very rich and provides a handful of annotations to make developers life easy.


via Wildfly, Apache CXF and @SchemaValidation | Roberto Cortez Java Blog.

Over the last few days, I have been working on an application migration from JBoss 4 toWildfly 8. The application is using different technologies, but we are going to focus here on XML Web Services, JAX-WS. Yeah, I know that they are not trendy anymore, but these were developed a long time ago and need to be maintained for compatibility issues.

Anyway, the path to migrate these services was not so easy. I’m sharing some of the problems and fixes with the hope that these could help other developers out there stuck with the same problems.

Logging JAX-WS SOAP messages in Spring

via Logging JAX-WS SOAP messages in Spring | JDev.

Whenever you’re using JAX-WS within Spring you’ll probably want to log the incoming and outgoing SOAP messages – if only for debugging during development. So the first thing to do is increase the log levels, right? Unfortunately this will have no effect. What you will have to do is to make use of the javax.xml.ws.handler.HandlerResolver interface. So how do we do this?

Apache Camel CXF Example

via Apache Camel CXF Example | Examples Java Code Geeks.

In this article, I am going to show you an example of Apache Camel CXF. We will explore Camel’s capabilities for interacting with SOAP web services, which are commonly used in integration technology. The CXF component provides integration with Apache CXF for connecting to Java XML Web Services (JAX-WS) hosted in CXF and what is Apache CXF? Apache CXF is an open-source, fully featured Web services framework. And where does the name CXF comes from? It originated as the combination of two open-source projects: Celtix and XFire so CXF was derived by combining “Celtix” and “XFire”.

In this example, we will use CXF to create Camel routes that request external web services. We will also use CXF to act as a web service listener.

Before we start with our example, Let’s look into the setup details.

This example uses the following frameworks:

  1. Maven 3.2.3
  2. Apache Camel 2.15.1
  3. Apache CXF 3.0.4
  4. Spring 4.1.5.RELEASE
  5. Eclipse  as the IDE, version Luna 4.4.1.

JEP 212: Resolve Lint and Doclint Warnings


Relates to

8039501: Fix fallthrough lint warnings in jdk libraries

8032976: Fix serial lint warnings in jdk libraries

8044613: Fix finally lint warnings in jdk libraries

8046270: Fix overrides lint warnings jdk libraries

8039096: Fix raw and unchecked lint warnings in jdk libraries


The JDK code base contains numerous lint and doclint errors as reported by javac. These warnings should be resolved, at least for the fundamental parts of the platform.


Operationally, the goal is to have at least the packages for the fundamental packages in the platform (those discussed on core-libs, awt-dev, swing-dev, 2d-dev, etc.) compile cleanly under javac‘s lint and doclint warnings. It is desirable for other packages, such as those comprising JAXP, JAX-WS, and CORBA to also compile cleanly with all warning enabled.

Success Metrics

A successful build of the sources in question when the -Xlint:all option is used for the javac command. A slightly weaker goal that may be acceptable is for all the source-related lint options to be enabled, but not the lint options for non-source properties. For example, some lint options concern properties of the javac command line rather than the sources being compiled.


This JEP proposes to complete efforts to fix warnings that have been underway in JDK 8 and JDK 9 as well as to formalize a subset of source-code improvements previously proposed to jdk9-dev. Most of the warnings are resolved by modifying the interior of method bodies. Resolving some of rawtypes warnings involves changing method signatures, such as changing a parameter type from a raw java.lang.Class to ajava.lang.Class<?> or some more specific type. Any API changes will stay within the general evolution policy of the JDK.


A successful compile / build is the primary test for most changes, but the existing regression tests should continue to pass. Where a Java SE API has a signature change, the corresponding JCK signature test will need to be updated accordingly.


Resolving the deprecation warnings in the JDK would be eased if importing a deprecated type does not trigger a deprecation warning.