|
|
|
|
|
|
|
需要一种机制来验证从不可信客户端传入的 SOAP 请求。现在，WebLogic Server 提供了一种机制来验证传入 WebLogic Server Web Service 的请求。
请注意，验证是一项耗用性能的任务，应谨慎使用。可以采用以下方法之一来验证传入的 SOAP 请求：
在启动服务器时，采用命令行参数对服务器上的所有服务都启用验证：
-Dweblogic.wsee.validate_request=true
将 <validate-request>true</validate-request> 添加到 weblogic-webservice.xml，为特定 Web Service 启用验证。例如：
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-webservices xmlns="http://www.bea.com/ns/weblogic/90";;;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";;;>
<webservice-description> <webservice-description-name>HelloWorld</webservice-description-name>
<port-component-name>HelloWorldServiceImplSoapPort</port-component-name>
<service-endpoint-address> <webservice-contextpath>hello</webservice-contextpath> <webservice-serviceuri>/test</webservice-serviceuri>
</service-endpoint-address>
<!-- Note this validate request tag -->
<validate-request>true</validate-request>
</webservice-description>
|
|
|
|
|
WebLogic Server 不支持 JAX-RPC 1.1 Spec 所必需的稀疏数组和部分储值数组。
|
|
|
|
|
XMLBean 数据类型不支持将类型为 document-literal wrapped 的 Web Service 作为输入参数或返回值。
|
|
|
|
|
在 WebLogic Server 9.0 中，Cookie 用字符串表示，但是，Cookie 需要表示为映射（键值对），因为 Cookie 可由新值替换。
|
|
|
|
|
适用于 jwsc、wsdlc 和 clientgen：
在某些操作系统中进行生成和运行时，具有大写包名的 Web Service 接口、实现和参数类型可能会有问题。
|
|
|
|
|
当客户端将复杂类型的实例发送到某个服务时，该服务回送已接收的实例。如果复杂类型包含 any 元素，并且 any 内容包含数据，则该数据不会传递到该服务。
|
|
|
|
|
Web Service 描述语言 (WSDL) 编译器未生成可序列化的数据类型，因此数据无法传递到远程 EJB 或存储在 JMS 目标中。
|
|
|
|
|
WLHttpsTransport 导致了以下错误：
AsyncReponseService returned a 404
|
|
|
|
|
异步响应服务不支持 https 协议传输。结果，通过 https 传输传回的异步响应遇到了 404 错误，因为没有部署任何服务来处理该响应。
对 https 协议传输的支持已添加到异步响应服务中。
|
|
|
|
|
当 Web Service 将 XMLObject 用作参数时，在客户端尝试访问该服务的情况下，会引发一个 java.lang.IncompatibleClassChangeError 异常。
|
|
|
|
|
jwsc Ant 任务生成了缺少输入部分的 document-literal-wrapped Web Service 的 WSDL，导致生成了具有空正文的请求信封。
|
|
|
|
|
将安全策略与抽象标识声明（如默认的 Auth.xml）一起使用时，X509 标记会包括为受支持的标识标记，而无论是否在 WebServiceSecurity MBean 上启用了 UseX509ForIdentity 特性。
仅当 UseX509ForIdentity特性设置为 true时，会将 X509 标记作为该标识的受支持标记插入。
|
|
|
|
|
当源 xml 具有非 ascii 字符时，javax.xml.transform.Source 附件无效。
|
|
|
|
|
如果加密的数据包含特定的字符（如“&”），则签名引用验证会失败。
|
|
|
|
|
当通过 JMS 传输调用 Web Service 时，请求或附件中的非 ASIIC 数据可能会更改。
允许应用程序将请求作为 JMS BytesMessage 发送。默认情况下仍将其作为在以前版本中使用的消息类型 TextMessage 发送。需要发送非 ASIIC 数据或二进制附件的应用程序可使用 BytesMessage。JAX RPC 存根上有一个可用于设置 JMS 消息类型的属性。获得端口之后，即可执行以下操作之一，将 JMS 消息类型设置为 BytesMessage：
((Stub)port)._setProperty(WLStub.JMS_TRANSPORT_MESSAGE_TYPE, WLStub.JMS_BYTESMESSAGE) weblogic.wsee.util.JmsUtil.setJmsTransportBytesMessage((Stub)port)
为了将回调作为 BytesMessage 发回，应用程序必须在回调存根上设置 JMS_TRANSPORT_MESSAGE_TYPE 属性。
|
|
|
|
|
WebLogic Server 8.1 样式（版本一）转换服务要求客户端明确知道并回送转换 ID。转换 ID 由应用程序或客户端服务器分配，并且它不知道实际提供服务的位置。版本二的转换服务（开始于 9.0 版本）依赖于 WS 寻址，自动使转换 ID 回送到服务。转换 ID 在服务器端进行分配，并且将路由信息嵌入其自身。当 8.1 样式的转换客户端与群集环境中的 9.x 服务器对话时，该群集会没有足够的信息，无法将该请求路由到正确的服务器。
解决方案是使用群集范围的单元集服务 – 路径服务 – 来为 8.1 样式转换记录路由信息。
要使上述解决方案生效，还需要进行其他配置 – 必须在群集中的一个服务器上配置并部署路径服务。我们知道，该解决方案具有可缩放性，并且可从 8.1 进行单点失败回归。有了内置在路径服务中的缓存功能和 WLS 中的服务器迁移解决方案，回归会有所减轻。
|
|
|
|
|
如果模板化的策略、库策略和用户定义的策略都具有相同名称，则这些策略会以错误的顺序加载。用户定义的策略应优先加载，但却先加载了库策略。
|
|
|
|
|
在 WebLogic Server 9.2 之前的版本中， clientgen 无法处理一些数组，这些数组在 WSDL 描述中定义为其他数组的一维数组，如以下代码所示：
<s:complexType name="ArrayOfArrayOfString">
<s:complexContent>
<s:restriction base="enc:Array">
<s:sequence>
<s:element name="ArrayOfString"
type="enc2:ArrayOfString"
minOccurs="0"
maxOccurs="unbounded" />
</s:sequence>
<s:attribute ref="enc:arrayType"
wsdl:arrayType="enc2:ArrayOfString[]" />
</s:restriction>
</s:complexContent>
</s:complexType>
<s:complexType
name="ArrayOfArrayOfArrayOfArrayOfString">
<s:complexContent>
<s:restriction base="enc:Array">
<s:sequence>
<s:element
name="ArrayOfArrayOfArrayOfString"
type="enc2:ArrayOfArrayOfArrayOfString"
minOccurs="0"
maxOccurs="unbounded" />
</s:sequence>
<s:attribute ref="enc:arrayType"
wsdl:arrayType=
"enc2:ArrayOfArrayOfArrayOfString[]"/>
</s:restriction>
</s:complexContent>
</s:complexType>
|
|
|
|
|
|
|
|
|
|
当 Web Service 客户端尝试使用 HTTPs 访问仅支持 HTTP 传输的 Web Service 时，发生了 Invalid/unknown SSL header was received 错误。
要生成支持 HTTPs 的 Web Service，请在 JWS 中使用 @WLHttpsTransport 标注而不是 @WLHttpTransport 标注。
|
|
|
|
|
在 WebLogic Server 9.2 之前的版本中， clientgen 无法处理一些多维数组，这些多维数组的类型是以以下形式表示的：
<complexType name="ArrayOfString2D">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="string[][]"/>
</restriction>
</complexContent>
</complexType>
其中， wsdl:arrayType 是以以下形式表示的：
|
|
|
|
|
在 9.1 中，WebLogic Server 仅支持在以下位置将 WS-Policy 附加到 WSDL： wsdlPort、 wsdlBindingOperation、带有 wsp:PolicyReference WSDL 扩展的 wsdlBindingOperation 的输入或输出消息。
现在，根据 WSDL 1.1 规范和 WS-Policy 附件规范，WebLogic Server 支持将 WS-Policy 附加到以下位置： wsdl:portType、 wsdl:binding、 wsdl:operation、 wsdl:operation/wsdl:input 和 wsdl:operation/wsdl:output。
|
|
|
|
|
读取包含了不存在的 ws-policy 引用的 WSDL 文件时，未报告任何错误。
|
|
|
|
|
在 WebLogic Server 9.2 之前的版本中，如果客户端上的系统时钟时间略早于服务器上的系统时钟时间，则会针对很小的同步差异（小于时钟精度的差异）间歇地发出以下时间戳错误消息：
Message Created time in the future
例如，如果 clockPrecision 设置已设置为一分钟（默认值），并且客户端时钟时间碰巧早于服务器时钟时间 40 秒，则有 40/60 或 2/3 的时间会引发此消息。
已取消 clockPrecision 属性，并用更直观的 clockSkew 属性替换了该属性。ClockSkew 不会展示 clockPrecision 的任何概率 特性（如以上说明中的 2/3 所示），但它会表现一个相似的概念：服务器和客户端的时钟之间可允许的差异。
|
|
|
|
|
如果使用管理控制台或 WLST 更改时间戳设置，则您的应用程序需要重新部署。
|
|
|
|
|
在 WebLogic Server 9.0 中，服务器未能处理由通过 WebLogic Server 8.1 创建的客户端生成的加密 SOAP 消息，并出现以下异常：
weblogic.xml.dom.marshal.MarshalException: Unrecognized child element in SecurityTokenReference
现在，在 SecurityTokenReference节点中没有 X509Data 的情况下，WebLogic Server 允许使用 X509IssuerSerial。
|
|
|
|
|
当通过代理检索动态时，未正确设置 WSDL 地址位置中的 SSL 端口。
将地址正确设置为在 Cluster MBean 或 Web Server MBean 中设置的主机和 HTTPS 端口，而不是代理后面的内部服务器地址。
|
|
|
|
|
如果部署了使用 @RolesAllowed、 @RolesReferenced 或 @RunAs 标注来指定允许调用 Web Service 的角色的 Web Service，则访问该 Web Service（包括其动态 WSDL）的任何人都需要作为映射到该角色的用户对其自身进行身份验证。
客户端应用程序可使用 HttpTransportInfo 来进行身份验证。但是，clientgen 无法对其自身进行身份验证。
|
|
|
|
|
如果部署了使用 @UserDataConstraint 标注以强制使用 HTTPS 的 Web Service，则访问该 Web Service（包括其 WSDL）的任何人都需要指定包含受信任证书（包括该服务器的受信任证书）列表的信任存储。
调用 Web Service 的客户端应用程序可通过在存根中定义信任管理器来列出受信任的证书；但是，当前无法对 clientgen 执行此操作。
<clientgen
wsdl="https://${wls-ssl-server}/HttpsWeb/
HttpsWebService?WSDL" destDir="${clientclasses.dir}" packageName="ssl.web.client">
<sysproperty key="javax.net.ssl.trustStore" value="${stage.dir}/DemoTrust.jks"/> <sysproperty key=
"weblogic.wsee.client.ssl.
stricthostchecking"
value="false"/> </clientgen>
|
|
|
|
|
WebLogic Server 9.2 之前的EJB 实现的 Web Service 不支持 @UserDataConstraint 标注。
现在，可按照以下方式设置 @UserDataConstraint 标注：
@WLHttpsTransport
(portName="HttpsEjbPort",
contextPath="HttpsEjb",
serviceUri="HttpsEjbService") @UserDataConstraint(transport=UserDataConstraint.Transport.CONFIDENTIAL)
public class HttpsEjbService implements SessionBean {
此语法可将对 HttpsEjbService 的访问限制为仅 HTTPs 协议。
|
|
|
|
|
CDATA DOM 节点中 MS Windows 样式的换行符“ \r\n”已规范化为“
”，但被作为“ \n”输出到 SOAP 消息中。这导致了在接收端上收到不同的规范化结果，从而导致签名验证失败。
|
|
|
|
|
在 WebLogic Server 9.2 之前的版本中，如果在 Web Service 中使用了任何复杂的功能（例如，转换），则它将打包为基于 EJB 的 Web Service。在 WebLogic Server 9.2 中，复杂的 Web Service 会打包为基于 Servlet 的 Web Service。
更改希望将 9.2 Web Service 打包为 EJB 模块的生成脚本，以便现在这些脚本会希望将 Web Service 打包为 Servlet 模块（例如，一个 WAR 文件）。
|
|
|
|
|
在 WebLogic Server 9.1 中，当配置 RolesReferenced 标注时，链接特性是必需的。例如：
@RolesReferenced(@SecurityRoleRef
(role = "admin", link = "Admin" ))
|
|
|
|
|
在 WebLogic Server 9.1 中，必须在 RunAs 标注中设置 mapToPrincipal 特性。例如：
@RunAs(role="user", mapToPrincipals="foo")
现在， mapToPrincipals 特性是可选的，默认情况下为默认的安全角色（如果未指定）。
|
|
|
|
|
在代理服务器上，如果在服务器启动时会自动部署异步响应服务，则后续流量将不会路由到代理服务器面向的服务器上的异步响应服务。相反，流量会由代理服务器自身使用。
为了不部署异步响应服务，请将 weblogic.wsee.skip.async.response 属性设置为 true。
|
|
|
|
|
JAX-RPC 1.1 规范指定，字节数组的从 Java 到 XML 的映射应为 xsd:base64Binary。但是，在 WebLogic Server 9.2 之前的版本中，为 byte[] 生成的 Schema 类型不符合 JAX-RPC 1.1。
使用 JWSC 从包含使用 byte[]参数或返回类型的类启动 Java Web Service 时，生成的与 byte[] 参数相对应的 WSDL 类型是错误地生成的，如下所示：
<xs:complexType name="ArrayOfbyte_literal">
<xs:sequence>
<xs:element maxOccurs="unbounded"
minOccurs="0"
name="byte"
nillable="false" type="xs:byte"/>
</xs:sequence>
</xs:complexType>
然后，类型 ArrayOfbyte_literal 会作为 Document Literal Wrapped 操作包装元素中的类型使用，如下所示：
<xs:element
name="echoPrimitiveByteArray2Response">
<xs:complexType>
<xs:sequence>
<xs:element name="return"
type="arrayOfbyte_literal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
|
|
|
|
|
JWSC 已更改为针对 JAX-RPC 1.1 所需的 byte[] 生成 xsd:base64Binary 类型，如下所示：
<xs:element
name="echoPrimitiveByteArray2Response">
<xs:complexType>
<xs:sequence>
<xs:element name="return"
type="xs:base64Binary"/>
</xs:sequence>
</xs:complexType>
</xs:element>
因此，使用重新生成的服务的任何 JWS 客户端都需要通过来自 JWS 的新 WSDL 进行重新生成。
|
|
|
|
|
WebLogic Server 9.2 不支持在某种回调上使用自定义异常，这种回调具有与父 Web Service 的目标名称空间不匹配的包。
请确保在回调中使用的任何自定义异常都位于与父 Web Service 的目标名称空间相匹配的包中。
|
|
|
|
|
编码为 RPC LITERAL 时，WebLogic Server 无法对 SOAP12 进行正确处理。
|
|
|
|
|
无法在同时使用代理服务器的环境中使用 JMS 传输。这是因为在 JMS 传输时，Web Service 客户端始终使用 t3 协议来连接到 Web Service，而代理服务器仅接受 HTTP/HTTPS。
|
|
|
|
|
尝试使用 ParserFactory 创建 SAX 解析器实例时，将引发 NullPointerException。
|
|
|
|
|
处理使用复杂类型 http://www.w3.org/2001/XMLSchema{schema} 作为 Web Service 参数的 WSDL 时，clientgen 将失败。
|
|
|
|
|
使用混合大小写包名定义回调接口的 Web Service 将无法使用 jwsc 进行编译。
|
|
|
|
|
在 WebLogic Server 9.0 和 9.1 中，jwsc 任务无法将 XmlObject 作为输入参数处理。
|
|
|
|
|
JWSC 通常会生成 http://localhost:7001 作为 WSDL 中的默认 URL。
此问题已得到解决。如果将 UserDataConstraint 的值指定为 INTEGRAL 或 CONFIDENTIAL，则 JWSC 将生成 https://localhost:7002 作为 WSDL 中的默认 URL。（请注意，这是安全的 URL。）
|
|
|
|
|
WebLogic Server 9.2 不支持回调 Web Service 中的 JAX RPC 处理程序。
如果将 JAX RPC 处理程序和通过 WebLogic Workshop 8.1 创建的 Web Service 一起使用，则必须重新设计这样的应用程序，以便其不使用回调处理程序功能。
|
|
|
|
|
要编辑 wsrp-wsdl-template.wsdl，需要将以下支持文件从 wlp-wsrp-producer-web-lib.war 复制到您的 Web 应用程序中：
wlp_wsrp_v11_types.xsd wlp_wsrp_v1_types.xsd wsrp_v1_full.wsdl wsrp_v1_types.xsd wsrp-wsdl-template.wsdl wlp_wsrp_v1_bindings.wsdl wsrp_v1_bindings.wsdl wsrp_v1_interfaces.wsdl wsrp-wsdl-full.wsdl xml.xsd |
|
|
|
|
传输带附件的 SOAP 时，WebLogic Server 9.2 不支持块传输编码。
|
|
|
|
|
在 JWS 中使用 @WLHttpsTransport 无法生成符合 WS-I 的 wsdl。
现在已取消 @WLHttpsTransport。如果 JWS 端点需要限制为仅接受 HTTPS 传输，则使用 @WLHttpTransport 和 @UserDataConstraint。
|
|
|
|
|
WebLogic Server 9.2 不支持回调 Web Service 中的消息级安全。
必须重新设计通过 WebLogic Workshop 8.1 创建的使用 WS-Security 的 Web Service，以便不在回调中使用消息级安全。
|
|
|
|
|
WebLogic Server 9.2 不支持处理某些 Java 方法参数或返回参数，这些方法参数或返回参数是包含 XmlBean 属性的 JAX-RPC 样式的 JavaBean。例如，应用程序不能具有带类似以下代码的签名的方法： void myMethod(myJavaBean bean);
public class MyJavaBean {
private String stringProperty;
private XmlObject xmlObjectProperty;
String getStringProperty() {
return stringProperty;
}
void setStringProperty(String s) {
stringProperty = s;
}
XmlObject getXmlObjectProperty() {
return xmlObjectProperty;
}
void getXmlObjectProperty(XmlObject x) {
xmlObjectProperty = x;
}
|
|
|
|
|
JWSC 和 clientgen 使用名称 schemacom_bea_xml 和 META-INF 在 /tmp 目录中创建了临时目录，但是在执行 Web Service 之后没有删除这些目录。
|
|
|
|
|
在 WebLogic Server 9.1 中，必须在 RunAs 标注中设置 mapToPrincipals特性。例如：
@RunAs(role="user", mapToPrincipals="foo")
在 WebLogic Server 9.2 中， mapToPrincipals 特性是可选的，默认情况下为默认角色（如果未指定）。现有应用程序应继续与以前一样工作。
|
|
|
|
|
WebLogic Server 对 JAX-RPC-style 枚举类不支持 java2schema。
此问题已得到解决。WebLogic Server 可以为 JAX-RPC-style 枚举类正确生成 Schema 类型。
|
|
|
|
|
使用浏览器来请求 Web Service 的基本 URL（例如，http://localhost:7001/myservice/foo）时，单击“ WSDL Page”选项会导致 404 错误，而不是显示 wsdl 文件。
|
|
|
|
|
WebLogic Server 9.2 不支持在 Web Service 中的 URL 中使用双字节字符。
必须重新设计通过 WebLogic Workshop 8.1 创建的在 URL 中使用双字节字符的 Web Service，以便从 URL 中删除所有双字节字符。
|
|
|
|
|
在 JWS 回调中使用 2D XmlObject 参数产生了 IllegalArgumentException。
|
|
|
|
|
根据 JAXRPC 规范，应该将 byte[] 和 Byte[] 映射为 xsd:base64Binary 类型。此映射对 RPC 编码的 Web Service 不正确。
此问题已得到解决。Weblogic Server 可以根据 JAXRPC 规范为 RPC 编码的 Web Service 映射 byte[] 和 Byte[]。
|
|
|
|
|
将 SoapElement[] 作为 Web Service 参数和 @WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE) 一起使用，总是会导致在客户端上产生空数组。
不使用 @WildcardBinding 批注将 SOAPElement[] 的默认绑定更改为 WildcardParticle.ANYTYPE。将 SOAPElement[] 默认绑定设置为 WildcardParticle.ANY。
|
|
|
|
|
为 Web Service 客户端的 API 提供一种机制，以便为每个服务都设置密钥库实现双向 SSL。
要为每个连接都使用证书来实现 SSL，请使用 API，如下所示：
WlsSSLAdapter adapter = new WlsSSLAdapter();
adapter.setKeystore("./DemoIdentity.jks",
"DemoIdentityKeyStorePassPhrase".toCharArray(), "JKS" );
adapter.setClientCert("DemoIdentity","DemoIdentityPassPhrase".toCharArray());
adapter.setTrustManager( new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int
}); weblogic.wsee.connection.transport.https.HttpsTransportInfo info = new
weblogic.wsee.connection.transport.https.HttpsTransportInfo(adapter);
SimpleImplService service = new SimpleImplService_Impl(args[0] +
Simple port = service.getSimpleSoapPort();
|
|
|
|
|
当 WebLogic Server 8.1 客户端尝试调用部署在 WebLogic Server 9.2 上的 WebLogic Server 8.1 Web Service 时，不会发生套接口 ReadTimout。
|
|
|
|
|
当类型属于不同的名称空间时，WSDL 验证通常会失败。
|
|
|
|
|
当消息处理程序引发 SoapFaultException 时，将分配 EJB，但稍后并不会释放，从而导致 EJB 泄漏。
|
|
|
|
|
Weblogic Server 通常会生成默认成块的 SOAP 响应。
此问题已得到解决。用户可以禁用 SOAP 响应成块。
禁用成块后，将把响应缓存在内存缓冲区中。超过指定的缓冲区大小后，会继续将 SOAP 消息成块。
要禁用成块，请在 WebLogic Server 启动脚本中或启动 WebLogic Server 时设置属性 weblogic.wsee.NoFlush。例如 -Dweblogic.wsee.NoFlush=true
要控制缓冲区大小，请设置命令行参数 weblogic.wsee.http.response.BufferSize。例如 -Dweblogic.wsee.http.response.BufferSize=<buffer size in Bytes>
请注意，缓冲区大小应该是块大小的倍数，以便为实际缓冲区大小自动分配块大小倍数的一个值，该值可以比用户指定的值稍微大些。
|
|
|
|
|
在具有多个前端主机或端口的群集上部署服务时，会生成不正确的动态 WSDL 位置地址。
|
|
|
|
|
WebLogic Server 管理控制台不允许用户将多个策略（如 sign.xml 和 auth.xml）添加到单个 Web Service 操作。
|
|
|
|
|
在 WebLogic Server 9.2 域中从 JDK1.5.0_4 升级到 JDK 1.5.0_08 后，JWSC ANT 存在一个问题。
将 -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 添加到 Windows 上的 setDomainENV.cmd 文件（UNIX 上的 setDomainENV.sh）。 要运行 ant 任务，请将 ANT_OPTS 设置如下：set ANT_OPTS=-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 对于 ANT 文件中的 java 或 javac 任务的所有实例，请将 jvmarg 做相同设置。例如，对于 build.xml：
<java classname="examples.webservices.jws_basic.simple.Client"
<!--Note the jvmarg tag -->
line="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0" />
<classpath refid="client.class.path"/>
<arg line="http://${wls.hostname}:7001/jws_basic_simple/SimpleService"
|
|
|
|
|
根据 SOAP 1.2 规范，SOAP 消息中的内容类型应该是 Content-Type: application/soap+xml; charset="utf-8"。它会设置为 Content-Type: text/xml; charset="utf-8"。
|
|
|
|
|
会在 codec 处理程序之前调用全局 JAX-RPC 处理程序。
此问题已得到解决。对于 Web Service，会在 codec 处理程序之后调用全局 JAX-RPC 处理程序，以便 SOAPMessage 对全局 JAX-RPC 处理程序都可见。
|
|
|
|
|
与群集环境中的持久性存储对话找不到具有逻辑名称的存储。
|
|
|
|
|
在运行时不会验证无效或不支持的策略。因此，会将未在 WebLogic Server 上配置的用户映射为匿名用户，并且认为 Web Service 未受保护。这将导致授予未授权用户访问安全 Web Service。
|
|
|
