Tue, 09 Apr 2013 14:51:13 +0100
8010393: Update JAX-WS RI to 2.2.9-b12941
Reviewed-by: alanb, erikj
Contributed-by: miroslav.kos@oracle.com, martin.grebac@oracle.com
ohair@286 | 1 | /* |
alanb@368 | 2 | * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved. |
ohair@286 | 3 | * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
ohair@286 | 4 | * |
ohair@286 | 5 | * This code is free software; you can redistribute it and/or modify it |
ohair@286 | 6 | * under the terms of the GNU General Public License version 2 only, as |
ohair@286 | 7 | * published by the Free Software Foundation. Oracle designates this |
ohair@286 | 8 | * particular file as subject to the "Classpath" exception as provided |
ohair@286 | 9 | * by Oracle in the LICENSE file that accompanied this code. |
ohair@286 | 10 | * |
ohair@286 | 11 | * This code is distributed in the hope that it will be useful, but WITHOUT |
ohair@286 | 12 | * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
ohair@286 | 13 | * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
ohair@286 | 14 | * version 2 for more details (a copy is included in the LICENSE file that |
ohair@286 | 15 | * accompanied this code). |
ohair@286 | 16 | * |
ohair@286 | 17 | * You should have received a copy of the GNU General Public License version |
ohair@286 | 18 | * 2 along with this work; if not, write to the Free Software Foundation, |
ohair@286 | 19 | * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
ohair@286 | 20 | * |
ohair@286 | 21 | * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
ohair@286 | 22 | * or visit www.oracle.com if you need additional information or have any |
ohair@286 | 23 | * questions. |
ohair@286 | 24 | */ |
ohair@286 | 25 | |
ohair@286 | 26 | package com.sun.xml.internal.ws.api.pipe; |
ohair@286 | 27 | |
ohair@286 | 28 | import com.sun.xml.internal.ws.api.message.Message; |
ohair@286 | 29 | import com.sun.xml.internal.ws.api.message.Packet; |
ohair@286 | 30 | import com.sun.xml.internal.ws.api.pipe.helper.AbstractFilterPipeImpl; |
ohair@286 | 31 | import com.sun.xml.internal.ws.api.pipe.helper.AbstractPipeImpl; |
ohair@286 | 32 | |
ohair@286 | 33 | import javax.annotation.PreDestroy; |
ohair@286 | 34 | import javax.xml.ws.Dispatch; |
ohair@286 | 35 | import javax.xml.ws.Provider; |
ohair@286 | 36 | import javax.xml.ws.WebServiceException; |
ohair@286 | 37 | import javax.xml.ws.handler.Handler; |
ohair@286 | 38 | import javax.xml.ws.handler.LogicalHandler; |
ohair@286 | 39 | import javax.xml.ws.handler.MessageContext; |
ohair@286 | 40 | import javax.xml.ws.handler.soap.SOAPHandler; |
ohair@286 | 41 | |
ohair@286 | 42 | /** |
ohair@286 | 43 | * Abstraction of the intermediate layers in the processing chain |
ohair@286 | 44 | * and transport. |
ohair@286 | 45 | * |
ohair@286 | 46 | * <h2>What is a {@link Pipe}?</h2> |
ohair@286 | 47 | * <p> |
ohair@286 | 48 | * Transport is a kind of pipe. It sends the {@link Packet} |
ohair@286 | 49 | * through, say, HTTP connection, and receives the data back into another {@link Packet}. |
ohair@286 | 50 | * |
ohair@286 | 51 | * <p> |
ohair@286 | 52 | * More often, a pipe is a filter. It acts on a packet, |
ohair@286 | 53 | * and then it passes the packet into another pipe. It can |
ohair@286 | 54 | * do the same on the way back. |
ohair@286 | 55 | * |
ohair@286 | 56 | * <p> |
ohair@286 | 57 | * For example, XWSS will be a {@link Pipe} |
ohair@286 | 58 | * that delegates to another {@link Pipe}, and it can wrap a {@link Packet} into |
ohair@286 | 59 | * another {@link Packet} to encrypt the body and add a header, for example. |
ohair@286 | 60 | * |
ohair@286 | 61 | * <p> |
ohair@286 | 62 | * Yet another kind of filter pipe is those that wraps {@link LogicalHandler} |
ohair@286 | 63 | * and {@link SOAPHandler}. These pipes are heavy-weight; they often consume |
ohair@286 | 64 | * a message in a packet and create a new one, and then pass it to the next pipe. |
ohair@286 | 65 | * For performance reason it probably makes sense to have one {@link Pipe} |
ohair@286 | 66 | * instance that invokes a series of {@link LogicalHandler}s, another one |
ohair@286 | 67 | * for {@link SOAPHandler}. |
ohair@286 | 68 | * |
ohair@286 | 69 | * <p> |
ohair@286 | 70 | * There would be a {@link Pipe} implementation that invokes {@link Provider}. |
ohair@286 | 71 | * There would be a {@link Pipe} implementation that invokes a service method |
ohair@286 | 72 | * on the user's code. |
ohair@286 | 73 | * There would be a {@link Dispatch} implementation that invokes a {@link Pipe}. |
ohair@286 | 74 | * |
ohair@286 | 75 | * <p> |
ohair@286 | 76 | * WS-MEX can be implemented as a {@link Pipe} that looks for |
ohair@286 | 77 | * {@link Message#getPayloadNamespaceURI()} and serves the request. |
ohair@286 | 78 | * |
ohair@286 | 79 | * |
ohair@286 | 80 | * <h2>Pipe Lifecycle</h2> |
ohair@286 | 81 | * {@link Pipe}line is expensive to set up, so once it's created it will be reused. |
ohair@286 | 82 | * A {@link Pipe}line is not reentrant; one pipeline is used to process one request/response |
ohair@286 | 83 | * at at time. The same pipeline instance may serve request/response for different threads, |
ohair@286 | 84 | * if one comes after another and they don't overlap. |
ohair@286 | 85 | * <p> |
ohair@286 | 86 | * Where a need arises to process multiple requests concurrently, a pipeline |
ohair@286 | 87 | * gets cloned through {@link PipeCloner}. Note that this need may happen on |
ohair@286 | 88 | * both server (because it quite often serves multiple requests concurrently) |
ohair@286 | 89 | * and client (because it needs to support asynchronous method invocations.) |
ohair@286 | 90 | * <p> |
ohair@286 | 91 | * Created pipelines (including cloned ones and the original) may be discarded and GCed |
ohair@286 | 92 | * at any time at the discretion of whoever owns pipelines. Pipes can, however, expect |
ohair@286 | 93 | * at least one copy (or original) of pipeline to live at any given time while a pipeline |
ohair@286 | 94 | * owner is interested in the given pipeline configuration (in more concerete terms, |
ohair@286 | 95 | * for example, as long as a dispatch object lives, it's going to keep at least one |
ohair@286 | 96 | * copy of a pipeline alive.) |
ohair@286 | 97 | * <p> |
ohair@286 | 98 | * Before a pipeline owner dies, it may invoke {@link #preDestroy()} on the last |
ohair@286 | 99 | * remaining pipeline. It is "may" for pipeline owners that live in the client-side |
ohair@286 | 100 | * of JAX-WS (such as dispatches and proxies), but it is a "must" for pipeline owners |
ohair@286 | 101 | * that live in the server-side of JAX-WS. |
ohair@286 | 102 | * <p> |
ohair@286 | 103 | * This last invocation gives a chance for some pipes to clean up any state/resource |
ohair@286 | 104 | * acquired (such as WS-RM's sequence, WS-Trust's SecurityToken), although as stated above, |
ohair@286 | 105 | * this is not required for clients. |
ohair@286 | 106 | * |
ohair@286 | 107 | * |
ohair@286 | 108 | * |
ohair@286 | 109 | * <h2>Pipe and State</h2> |
ohair@286 | 110 | * <p> |
ohair@286 | 111 | * The lifecycle of pipelines is designed to allow a {@link Pipe} to store various |
ohair@286 | 112 | * state in easily accessible fashion. |
ohair@286 | 113 | * |
ohair@286 | 114 | * |
ohair@286 | 115 | * <h3>Per-packet state</h3> |
ohair@286 | 116 | * <p> |
ohair@286 | 117 | * Any information that changes from a packet to packet should be |
ohair@286 | 118 | * stored in {@link Packet}. This includes information like |
ohair@286 | 119 | * transport-specific headers. |
ohair@286 | 120 | * |
ohair@286 | 121 | * <h3>Per-thread state</h3> |
ohair@286 | 122 | * <p> |
ohair@286 | 123 | * Any expensive objects that are non-reentrant can be stored in |
ohair@286 | 124 | * instance variables of a {@link Pipe}, since {@link #process(Packet)} is |
ohair@286 | 125 | * non reentrant. When a pipe is copied, new instances should be allocated |
ohair@286 | 126 | * so that two {@link Pipe} instances don't share thread-unsafe resources. |
ohair@286 | 127 | * This includes things like canonicalizers, JAXB unmarshallers, buffers, |
ohair@286 | 128 | * and so on. |
ohair@286 | 129 | * |
ohair@286 | 130 | * <h3>Per-proxy/per-endpoint state</h3> |
ohair@286 | 131 | * <p> |
ohair@286 | 132 | * Information that is tied to a particular proxy/dispatch can be stored |
ohair@286 | 133 | * in a separate object that is referenced from a pipe. When |
ohair@286 | 134 | * a new pipe is copied, you can simply hand out a reference to the newly |
ohair@286 | 135 | * created one, so that all copied pipes refer to the same instance. |
ohair@286 | 136 | * See the following code as an example: |
ohair@286 | 137 | * |
ohair@286 | 138 | * <pre> |
ohair@286 | 139 | * class PipeImpl { |
ohair@286 | 140 | * // this object stores per-proxy state |
ohair@286 | 141 | * class DataStore { |
ohair@286 | 142 | * int counter; |
ohair@286 | 143 | * } |
ohair@286 | 144 | * |
ohair@286 | 145 | * private DataStore ds; |
ohair@286 | 146 | * |
ohair@286 | 147 | * // create a fresh new pipe |
ohair@286 | 148 | * public PipeImpl(...) { |
ohair@286 | 149 | * .... |
ohair@286 | 150 | * ds = new DataStore(); |
ohair@286 | 151 | * } |
ohair@286 | 152 | * |
ohair@286 | 153 | * // copy constructor |
ohair@286 | 154 | * private PipeImpl(PipeImpl that, PipeCloner cloner) { |
ohair@286 | 155 | * cloner.add(that,this); |
ohair@286 | 156 | * ... |
ohair@286 | 157 | * this.ds = that.ds; |
ohair@286 | 158 | * } |
ohair@286 | 159 | * |
ohair@286 | 160 | * public PipeImpl copy(PipeCloner pc) { |
ohair@286 | 161 | * return new PipeImpl(this,pc); |
ohair@286 | 162 | * } |
ohair@286 | 163 | * } |
ohair@286 | 164 | * </pre> |
ohair@286 | 165 | * |
ohair@286 | 166 | * <p> |
ohair@286 | 167 | * Note that access to such resource often needs to be synchronized, |
ohair@286 | 168 | * since multiple copies of pipelines may execute concurrently. |
ohair@286 | 169 | * |
ohair@286 | 170 | * <p> |
ohair@286 | 171 | * If such information is read-only, |
ohair@286 | 172 | * it can be stored as instance variables of a pipe, |
ohair@286 | 173 | * and its reference copied as pipes get copied. (The only difference between |
ohair@286 | 174 | * this and per-thread state is that you just won't allocate new things when |
ohair@286 | 175 | * pipes get copied here.) |
ohair@286 | 176 | * |
ohair@286 | 177 | * |
ohair@286 | 178 | * <h3>VM-wide state</h3> |
ohair@286 | 179 | * <p> |
ohair@286 | 180 | * <tt>static</tt> is always there for you to use. |
ohair@286 | 181 | * |
ohair@286 | 182 | * |
ohair@286 | 183 | * |
ohair@286 | 184 | * <h2>Pipes and Handlers</h2> |
ohair@286 | 185 | * <p> |
ohair@286 | 186 | * JAX-WS has a notion of {@link LogicalHandler} and {@link SOAPHandler}, and |
ohair@286 | 187 | * we intend to have one {@link Pipe} implementation that invokes all the |
ohair@286 | 188 | * {@link LogicalHandler}s and another {@link Pipe} implementation that invokes |
ohair@286 | 189 | * all the {@link SOAPHandler}s. Those implementations need to convert a {@link Message} |
ohair@286 | 190 | * into an appropriate format, but grouping all the handlers together eliminates |
ohair@286 | 191 | * the intermediate {@link Message} instanciation between such handlers. |
ohair@286 | 192 | * <p> |
ohair@286 | 193 | * This grouping also allows such implementations to follow the event notifications |
ohair@286 | 194 | * to handlers (i.e. {@link Handler#close(MessageContext)} method. |
ohair@286 | 195 | * |
ohair@286 | 196 | * |
ohair@286 | 197 | * <pre> |
ohair@286 | 198 | * TODO: Possible types of pipe: |
ohair@286 | 199 | * creator: create message from wire |
ohair@286 | 200 | * to SAAJ SOAP message |
ohair@286 | 201 | * to cached representation |
ohair@286 | 202 | * directly to JAXB beans |
ohair@286 | 203 | * transformer: transform message from one representation to another |
ohair@286 | 204 | * JAXB beans to encoded SOAP message |
ohair@286 | 205 | * StAX writing + JAXB bean to encoded SOAP message |
ohair@286 | 206 | * modifier: modify message |
ohair@286 | 207 | * add SOAP header blocks |
ohair@286 | 208 | * security processing |
ohair@286 | 209 | * header block processor: |
ohair@286 | 210 | * process certain SOAP header blocks |
ohair@286 | 211 | * outbound initiator: input from the client |
ohair@286 | 212 | * Manage input e.g. JAXB beans and associated with parts of the SOAP message |
ohair@286 | 213 | * inbound invoker: invoke the service |
ohair@286 | 214 | * Inkoke SEI, e.g. EJB or SEI in servlet. |
ohair@286 | 215 | * </pre> |
ohair@286 | 216 | * |
ohair@286 | 217 | * @see AbstractPipeImpl |
ohair@286 | 218 | * @see AbstractFilterPipeImpl |
ohair@286 | 219 | * @deprecated |
ohair@286 | 220 | * Use {@link Tube}. |
ohair@286 | 221 | */ |
ohair@286 | 222 | public interface Pipe { |
ohair@286 | 223 | /** |
ohair@286 | 224 | * Sends a {@link Packet} and returns a response {@link Packet} to it. |
ohair@286 | 225 | * |
ohair@286 | 226 | * @throws WebServiceException |
ohair@286 | 227 | * On the server side, this signals an error condition where |
ohair@286 | 228 | * a fault reply is in order (or the exception gets eaten by |
ohair@286 | 229 | * the top-most transport {@link Pipe} if it's one-way.) |
ohair@286 | 230 | * This frees each {@link Pipe} from try/catching a |
ohair@286 | 231 | * {@link WebServiceException} in every layer. |
ohair@286 | 232 | * |
ohair@286 | 233 | * Note that this method is also allowed to return a {@link Packet} |
ohair@286 | 234 | * that has a fault as the payload. |
ohair@286 | 235 | * |
ohair@286 | 236 | * <p> |
ohair@286 | 237 | * On the client side, the {@link WebServiceException} thrown |
ohair@286 | 238 | * will be propagated all the way back to the calling client |
ohair@286 | 239 | * applications. (The consequence of that is that if you are |
ohair@286 | 240 | * a filtering {@link Pipe}, you must not catch the exception |
ohair@286 | 241 | * that your next {@link Pipe} threw. |
ohair@286 | 242 | * |
ohair@286 | 243 | * @throws RuntimeException |
ohair@286 | 244 | * Other runtime exception thrown by this method must |
ohair@286 | 245 | * be treated as a bug in the pipe implementation, |
ohair@286 | 246 | * and therefore should not be converted into a fault. |
ohair@286 | 247 | * (Otherwise it becomes very difficult to debug implementation |
ohair@286 | 248 | * problems.) |
ohair@286 | 249 | * |
ohair@286 | 250 | * <p> |
ohair@286 | 251 | * On the server side, this exception should be most likely |
ohair@286 | 252 | * just logged. On the client-side it gets propagated to the |
ohair@286 | 253 | * client application. |
ohair@286 | 254 | * |
ohair@286 | 255 | * <p> |
ohair@286 | 256 | * The consequence of this is that if a pipe calls |
ohair@286 | 257 | * into an user application (such as {@link SOAPHandler} |
ohair@286 | 258 | * or {@link LogicalHandler}), where a {@link RuntimeException} |
ohair@286 | 259 | * is *not* a bug in the JAX-WS implementation, it must be catched |
ohair@286 | 260 | * and wrapped into a {@link WebServiceException}. |
ohair@286 | 261 | * |
ohair@286 | 262 | * @param request |
ohair@286 | 263 | * The packet that represents a request message. Must not be null. |
ohair@286 | 264 | * If the packet has a non-null message, it must be a valid |
ohair@286 | 265 | * unconsumed {@link Message}. This message represents the |
ohair@286 | 266 | * SOAP message to be sent as a request. |
ohair@286 | 267 | * <p> |
ohair@286 | 268 | * The packet is also allowed to carry no message, which indicates |
ohair@286 | 269 | * that this is an output-only request. |
ohair@286 | 270 | * (that's called "solicit", right? - KK) |
ohair@286 | 271 | * |
ohair@286 | 272 | * @return |
ohair@286 | 273 | * The packet that represents a response message. Must not be null. |
ohair@286 | 274 | * If the packet has a non-null message, it must be |
ohair@286 | 275 | * a valid unconsumed {@link Message}. This message represents |
ohair@286 | 276 | * a response to the request message passed as a parameter. |
ohair@286 | 277 | * <p> |
ohair@286 | 278 | * The packet is also allowed to carry no message, which indicates |
ohair@286 | 279 | * that there was no response. This is used for things like |
ohair@286 | 280 | * one-way message and/or one-way transports. |
ohair@286 | 281 | */ |
ohair@286 | 282 | Packet process( Packet request); |
ohair@286 | 283 | |
ohair@286 | 284 | /** |
ohair@286 | 285 | * Invoked before the last copy of the pipeline is about to be discarded, |
ohair@286 | 286 | * to give {@link Pipe}s a chance to clean up any resources. |
ohair@286 | 287 | * |
ohair@286 | 288 | * <p> |
ohair@286 | 289 | * This can be used to invoke {@link PreDestroy} lifecycle methods |
ohair@286 | 290 | * on user handler. The invocation of it is optional on the client side, |
ohair@286 | 291 | * but mandatory on the server side. |
ohair@286 | 292 | * |
ohair@286 | 293 | * <p> |
ohair@286 | 294 | * When multiple copies of pipelines are created, this method is called |
ohair@286 | 295 | * only on one of them. |
ohair@286 | 296 | * |
ohair@286 | 297 | * @throws WebServiceException |
ohair@286 | 298 | * If the clean up fails, {@link WebServiceException} can be thrown. |
ohair@286 | 299 | * This exception will be propagated to users (if this is client), |
ohair@286 | 300 | * or recorded (if this is server.) |
ohair@286 | 301 | */ |
ohair@286 | 302 | void preDestroy(); |
ohair@286 | 303 | |
ohair@286 | 304 | /** |
ohair@286 | 305 | * Creates an identical clone of this {@link Pipe}. |
ohair@286 | 306 | * |
ohair@286 | 307 | * <p> |
ohair@286 | 308 | * This method creates an identical pipeline that can be used |
ohair@286 | 309 | * concurrently with this pipeline. When the caller of a pipeline |
ohair@286 | 310 | * is multi-threaded and need concurrent use of the same pipeline, |
ohair@286 | 311 | * it can do so by creating copies through this method. |
ohair@286 | 312 | * |
ohair@286 | 313 | * <h3>Implementation Note</h3> |
ohair@286 | 314 | * <p> |
ohair@286 | 315 | * It is the implementation's responsibility to call |
ohair@286 | 316 | * {@link PipeCloner#add(Pipe,Pipe)} to register the copied pipe |
ohair@286 | 317 | * with the original. This is required before you start copying |
ohair@286 | 318 | * the other {@link Pipe} references you have, or else there's a |
ohair@286 | 319 | * risk of infinite recursion. |
ohair@286 | 320 | * <p> |
ohair@286 | 321 | * For most {@link Pipe} implementations that delegate to another |
ohair@286 | 322 | * {@link Pipe}, this method requires that you also copy the {@link Pipe} |
ohair@286 | 323 | * that you delegate to. |
ohair@286 | 324 | * <p> |
ohair@286 | 325 | * For limited number of {@link Pipe}s that do not maintain any |
ohair@286 | 326 | * thread unsafe resource, it is allowed to simply return <tt>this</tt> |
ohair@286 | 327 | * from this method (notice that even if you are stateless, if you |
ohair@286 | 328 | * got a delegating {@link Pipe} and that one isn't stateless, you |
ohair@286 | 329 | * still have to copy yourself.) |
ohair@286 | 330 | * |
ohair@286 | 331 | * <p> |
ohair@286 | 332 | * Note that this method might be invoked by one thread while another |
ohair@286 | 333 | * thread is executing the {@link #process(Packet)} method. See |
ohair@286 | 334 | * the {@link Codec#copy()} for more discussion about this. |
ohair@286 | 335 | * |
ohair@286 | 336 | * @param cloner |
ohair@286 | 337 | * Use this object (in particular its {@link PipeCloner#copy(Pipe)} method |
ohair@286 | 338 | * to clone other pipe references you have |
ohair@286 | 339 | * in your pipe. See {@link PipeCloner} for more discussion |
ohair@286 | 340 | * about why. |
ohair@286 | 341 | * |
ohair@286 | 342 | * @return |
ohair@286 | 343 | * always non-null {@link Pipe}. |
ohair@286 | 344 | */ |
ohair@286 | 345 | Pipe copy(PipeCloner cloner); |
ohair@286 | 346 | } |