[jira] Created: (CXF-2045) Custom headers lost when using Cxf Interceptors
Custom headers lost when using Cxf Interceptors
---
Key: CXF-2045
URL: https://issues.apache.org/jira/browse/CXF-2045
Project: CXF
Issue Type: Bug
Components: Core, REST
Affects Versions: 2.2
Environment: Java 1.5
Jetty 6.1
Reporter: Gabo Manuel
All changes to the header through the Message object in the out interceptor are
not received by client.
Server.java
public class RetestRestServer {
String basepath = "/someValue";
int port = 8080;
@SuppressWarnings("unchecked")
protected RetestRestServer() throws Exception {
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(AccountService.class);
sf.setResourceProvider(AccountService.class,
new SingletonResourceProvider(new AccountService()));
sf.setAddress("http://localhost:"+port+basepath+"/rest/Accounts/";);
List out = new ArrayList(1);
in.add(new RestOutHandler());
sf.setOutInterceptors(in);
sf.create();
}
public static void main(String args[]) throws Exception {
new RetestRestServer();
System.out.println("Server ready...");
}
}
RestOutInterceptor.java
public class RestOutHandler extends AbstractPhaseInterceptor{
private static Logger logger = Logger.getLogger(RestOutHandler.class);
public RestOutHandler() {
super(Phase.POST_PROTOCOL);
}
public void handleMessage(Message message) throws Fault {
Map> responseHeaders = (Map>)message.get(Message.PROTOCOL_HEADERS);
if (responseHeaders == null) {
responseHeaders = new HashMap>();
message.put(Message.PROTOCOL_HEADERS, responseHeaders);
}
responseHeaders.put("header1", Arrays.asList(new
String[]{"headerValue"}));
logger.debug("out message headers: " + responseHeaders);
}
}
AccountService.java
@Consumes("*/xml")
@Produces("text/xml")
@WebService(serviceName="AccountService", portName="AccountServicePort")
public class AccountService{
private static Logger logger = Logger.getLogger(AccountService.class);
@GET
@Path("/")
@WebMethod
public String getAccount(
@QueryParam("serialNumber")
@WebParam(name="serialNumber")
long serialNumber) {
logger.info("get Account received: " + serialNumber);
return "get Account received: " + serialNumber;
}
}
Please advise if more info is needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2046) Response entity is enclosed in "Result" tags for classes implementing ExceptionMapper
Response entity is enclosed in "Result" tags for classes implementing
ExceptionMapper
-
Key: CXF-2046
URL: https://issues.apache.org/jira/browse/CXF-2046
Project: CXF
Issue Type: Bug
Components: REST
Affects Versions: 2.2
Environment: Java 1.5
Jetty 6.1
Reporter: Gabo Manuel
Environment and objects involved is the same as that in another issue:
https://issues.apache.org/jira/browse/CXF-2045
Additional objects involved:
public class RuntimeExceptionMapper implements
ExceptionMapper{
private static Logger logger =
Logger.getLogger(RuntimeExceptionMapper.class);
public Response toResponse(RuntimeException fault) {
StringBuffer sb = new StringBuffer();
sb.append("Generate some custom message to hide the real problem from
end user.");
ResponseBuilder rb = Response.status(500);
rb.type(MediaType.TEXT_PLAIN_TYPE);
rb.entity(sb.toString());
logger.fatal(fault);
Response resp = rb.build();
logger.info("entity: " + resp.getEntity().toString());
return resp;
}
}
Logs captured by TCPMon
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Content-Length: 69
Server: Jetty(6.1.11)
Generate some custom message to hide the real problem from end
user.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2043) CXF failed to deal with attachment if client sends in attachment with "Multipart/Related" instead of "multipart/related" as Content-type
[
https://issues.apache.org/jira/browse/CXF-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CXF-2043:
-
Assignee: Willem Jiang
> CXF failed to deal with attachment if client sends in attachment with
> "Multipart/Related" instead of "multipart/related" as Content-type
>
>
> Key: CXF-2043
> URL: https://issues.apache.org/jira/browse/CXF-2043
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.1.4
> Environment: Solaris 10, WinXP Pro
>Reporter: Joe Luo
>Assignee: Willem Jiang
> Attachments: multipart.patch
>
>
> Here is source code from cxf-2.1.x-fixes branch for
> *org.apache.cxf.attachment.AttachmentUtil.java*
> {code}
> public static boolean isTypeSupported(String contentType, List
> types) {
> if (contentType == null) {
> return false;
> }
> for (String s : types) {
> if (contentType.indexOf(s) != -1) {
> return true;
> }
> }
> return false;
> }
> {code}
> So if a client sends in a SOAP request with attachment with *Content-Type* as
> "Multipart/Related" instead of "multipart/related", then this method will
> always return *false* as result. The spec says that the Content-Type should
> be case-insensitive. It should not matter whether the client sends in
> "Multipart/Related" or "multipart/related".
> I have attached a patch to fix this. Basically, I just simply modified this
> method to:
> {code}
> public static boolean isTypeSupported(String contentType, List types)
> {
> if (contentType == null) {
> return false;
> }
> for (String s : types) {
> if (contentType.toLowerCase().indexOf(s) != -1) {
> return true;
> }
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2043) CXF failed to deal with attachment if client sends in attachment with "Multipart/Related" instead of "multipart/related" as Content-type
[
https://issues.apache.org/jira/browse/CXF-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CXF-2043.
---
Resolution: Fixed
Fix Version/s: 2.1.5
2.2
Trunk
http://svn.apache.org/viewvc?rev=744237&view=rev
2.1.x
http://svn.apache.org/viewvc?rev=745035&view=rev
> CXF failed to deal with attachment if client sends in attachment with
> "Multipart/Related" instead of "multipart/related" as Content-type
>
>
> Key: CXF-2043
> URL: https://issues.apache.org/jira/browse/CXF-2043
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.1.4
> Environment: Solaris 10, WinXP Pro
>Reporter: Joe Luo
>Assignee: Willem Jiang
> Fix For: 2.2, 2.1.5
>
> Attachments: multipart.patch
>
>
> Here is source code from cxf-2.1.x-fixes branch for
> *org.apache.cxf.attachment.AttachmentUtil.java*
> {code}
> public static boolean isTypeSupported(String contentType, List
> types) {
> if (contentType == null) {
> return false;
> }
> for (String s : types) {
> if (contentType.indexOf(s) != -1) {
> return true;
> }
> }
> return false;
> }
> {code}
> So if a client sends in a SOAP request with attachment with *Content-Type* as
> "Multipart/Related" instead of "multipart/related", then this method will
> always return *false* as result. The spec says that the Content-Type should
> be case-insensitive. It should not matter whether the client sends in
> "Multipart/Related" or "multipart/related".
> I have attached a patch to fix this. Basically, I just simply modified this
> method to:
> {code}
> public static boolean isTypeSupported(String contentType, List types)
> {
> if (contentType == null) {
> return false;
> }
> for (String s : types) {
> if (contentType.toLowerCase().indexOf(s) != -1) {
> return true;
> }
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1695) Service listings for JAX-RS endpoints
[ https://issues.apache.org/jira/browse/CXF-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674217#action_12674217 ] Andreas Sahlbach commented on CXF-1695: --- Why is this an "Improvement"??? This is clearly a bug, because that's a feature that does not work at all if you have just one REST service implemented. It does not work but fails with an NPE visible to the End-User. IMHO this should be a "major bug" the way it currently fails. > Service listings for JAX-RS endpoints > - > > Key: CXF-1695 > URL: https://issues.apache.org/jira/browse/CXF-1695 > Project: CXF > Issue Type: Improvement > Components: REST >Reporter: Anthony Schexnaildre >Priority: Minor > > The /services path does not work for listing JAX-RS services. Ultimately > listing these endpoints along with the SOAP endpoints, et el, would be ideal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1695) Service listings for JAX-RS endpoints
[ https://issues.apache.org/jira/browse/CXF-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-1695: -- Priority: Major (was: Minor) Sure - I've updated the level. The questions is what should be the default 'view', once the link pointing to a given JAXRS endpoint is selected - 1.JavaDocs ? - 2.WADL ? - 3.Human readable description in the form of tables showing what methods are suppoted, content-type/accept values, etc We expect some WADL support coming in but most likely for 2.2.1 or so. Option 1 is probably the simplest one, while option 3 can be done on top of 2. All options can be implemented as blocking CXF JAXRS RequestFilter implementations handling query like _javadocs, _wadl, _info Unfortunately it's unlikely I will be able to allocate the time till 2.2 gets released on this issue. Thus a patch will be welcomed if it's critical > Service listings for JAX-RS endpoints > - > > Key: CXF-1695 > URL: https://issues.apache.org/jira/browse/CXF-1695 > Project: CXF > Issue Type: Improvement > Components: REST >Reporter: Anthony Schexnaildre > > The /services path does not work for listing JAX-RS services. Ultimately > listing these endpoints along with the SOAP endpoints, et el, would be ideal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1695) Service listings for JAX-RS endpoints
[ https://issues.apache.org/jira/browse/CXF-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674234#action_12674234 ] Daniel Kulp commented on CXF-1695: -- Until JAX-RS supports something like WADL, it would be fine by me to just NOT show any of the jaxrs services. Just show the jaxws stuff. > Service listings for JAX-RS endpoints > - > > Key: CXF-1695 > URL: https://issues.apache.org/jira/browse/CXF-1695 > Project: CXF > Issue Type: Improvement > Components: REST >Reporter: Anthony Schexnaildre > > The /services path does not work for listing JAX-RS services. Ultimately > listing these endpoints along with the SOAP endpoints, et el, would be ideal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1695) Service listings for JAX-RS endpoints
[ https://issues.apache.org/jira/browse/CXF-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674245#action_12674245 ] Andreas Sahlbach commented on CXF-1695: --- Please take into account that I am relatively new to REST, so I may talk rubbish. :-) It would be nice if the content you are showing is depending to the accept header of the request. If it's "text/html" go for 3. If it's "application/xml" or something go for 2. But that's not the point of my initial comment. It's not acceptable that a product crashes hard with an NPE just by using it correctly. This is simply a bug and should be fixed. As already suggested: Just ignore the REST services for the first fix, but don't crash. Implementing the features you've mentioned would be very nice but that's clearly an improvement and can be done later. This issue should be split up into a bug and an improvement issue. This would be totally ok for me. > Service listings for JAX-RS endpoints > - > > Key: CXF-1695 > URL: https://issues.apache.org/jira/browse/CXF-1695 > Project: CXF > Issue Type: Improvement > Components: REST >Reporter: Anthony Schexnaildre > > The /services path does not work for listing JAX-RS services. Ultimately > listing these endpoints along with the SOAP endpoints, et el, would be ideal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2047) WSDLToJava generates webfault in wrong package
WSDLToJava generates webfault in wrong package -- Key: CXF-2047 URL: https://issues.apache.org/jira/browse/CXF-2047 Project: CXF Issue Type: Bug Components: Tooling Affects Versions: 2.0.10 Reporter: Yvan DeBoeck When a web service has a method that throws an exception (webfault) then the webfault exception class is generated in the package associated with the service and not in the package of the namespace of the exception. The package-namespace association is configured via -p I'll include an example soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2047) WSDLToJava generates webfault in wrong package
[ https://issues.apache.org/jira/browse/CXF-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yvan DeBoeck updated CXF-2047: -- Attachment: cxf_faultproblem.zip eclipse project of minimal example illustrating issue. The hello.Hello interface is an example of a WebFault specified in a different namespace then the WebService. first the wsdl is generated org.apache.cxf.tools.java2wsdl.JavaToWSDL with params: -createxsdimports -verbose -s generated -o hello.wsdl hello.Hello then the reverse with -p params for different packages per namespace org.apache.cxf.tools.wsdlto.WSDLToJava with params: -p http://fault=gen_fault -p http://hello=gen_hello -verbose -client -d generated hello.wsdl The HelloFault class is generated in package gen_hello instead of gen_fault. The HelloFaultDetails class is correctly generated in package gen_fault. (When the wsdl is generated without the option -createxsdimports, also the HelloFaultDetails class is wrongly generated in package gen_hello.) > WSDLToJava generates webfault in wrong package > -- > > Key: CXF-2047 > URL: https://issues.apache.org/jira/browse/CXF-2047 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.0.10 >Reporter: Yvan DeBoeck > Attachments: cxf_faultproblem.zip > > > When a web service has a method that throws an exception (webfault) then the > webfault exception class is generated in the package associated with the > service and not in the package of the namespace of the exception. The > package-namespace association is configured via -p > I'll include an example soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2047) WSDLToJava generates webfault in wrong package
[ https://issues.apache.org/jira/browse/CXF-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674356#action_12674356 ] Daniel Kulp commented on CXF-2047: -- This is actually correct per spec. The JAX-WS spec states that the Exception that is generated from the Fault message is in the namespace of the message (which in this case is the Service namespace). The fault bean is put into the package for it's schema. Thus, the behavior is correct per spec. > WSDLToJava generates webfault in wrong package > -- > > Key: CXF-2047 > URL: https://issues.apache.org/jira/browse/CXF-2047 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.0.10 >Reporter: Yvan DeBoeck > Attachments: cxf_faultproblem.zip > > > When a web service has a method that throws an exception (webfault) then the > webfault exception class is generated in the package associated with the > service and not in the package of the namespace of the exception. The > package-namespace association is configured via -p > I'll include an example soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2048) ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL Java client library is on classpath
ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL Java client library is on classpath --- Key: CXF-2048 URL: https://issues.apache.org/jira/browse/CXF-2048 Project: CXF Issue Type: Bug Components: Transports Affects Versions: 2.0.10 Environment: JDK 6 with Tibco EMS 4 SSL library on classpath Reporter: Ron Gavlin Priority: Critical My app is using CXF to make web service connections to external services that require client PKI authentication. The app also uses Tibco Java client libraries for JMS over SSL. The Tibco libs set the following Java system property: java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol This causes my CXF web service client to throw a class cast exception when it attempts to make a secure connection. Let me explain why this occurs.. The java.protocol.handler.pkgs system property is a list of package name prefixes used by Java to resolve protocol names into actual handler class names. As of v1.4, JSSE has been integrated into the J2SDK. Thus, the classes formerly in com.sun.net.ssl have been promoted to the javax.net.ssl package and are now a part of the standard JSSE API. For compatibility purposes the com.sun.net.ssl classes and interfaces still exist, but have been deprecated. Applications written using them can run in the J2SDK v1.4 and later without being recompiled. **Thus, setting the system property causes Java to use the deprecated implementation.** The problem with CXF comes in because it assumes the newer handler package structure when it attempts to decorate the underlying connection with your TLSClientParameters. A workaround should be implemented to support common, divergent subtype https implementations including com.sun.net.ssl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
