[jira] Created: (SMXCOMP-660) CXF-BC Component isn't JBI conform

CXF-BC Component isn't JBI conform
----------------------------------

                 Key: SMXCOMP-660
                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
             Project: ServiceMix Components
          Issue Type: Bug
          Components: servicemix-cxf-bc
    Affects Versions: servicemix-cxf-bc-2009.01
            Reporter: Christian Connert
            Priority: Critical


Hi,

I just noticed that the CXF-BC Component ain't standard conform. There are several problems:

1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.

2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.

3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.

kind regards

Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert reassigned SMXCOMP-660:
-----------------------------------------

    Assignee: Freeman Fang

Hi Freeman,

I hope you could help me to solve this issue.

Thanks

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54862#action_54862 ]

Christian Connert commented on SMXCOMP-660:
-------------------------------------------

Hi,

if i add an extra interceptor after the JbiInInterceptor (pre-invoke phase) and re-copy the wrappred as DocumentFragment I've no problem with auditing the messages (SMXCOMP-203) there are no exceptions. Thus I conclude the JbiInInterceptor should write all headers as DocumentFragment. At least for me it works fine and I think it's a good way to fix it.

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Attachment: cxfbc.patch

Good morning (at least in Austria),

After a hard hacking weekend i finally fixed the following bugs in the cxf-bc trunk:

1.) javax.jbi.messaging.protocol.headers are org.w3c.dom.DocumentFragment fragments now.
2.) SMXCOMP-203 -> transform saaj nodes to org.w3c.dom.Documents and attach as above
3.) JBI wrapping corrected (removes headers which are serialized as parts)
4.) Header propagation from BC-Provider to BC-Consumer (response) failed (no headers where propagated)

1 and 2 are fixed inside the JbiInInterceptor.
3 is fixed in the JbiInWsdl1Interceptor
4 is fixed in the CxfBcProvider and CxfBcProviderMessageObserver  (JbiInInterceptor at provider and JbiOutInterceptor at consumer endpoint)

Further I extended the provider and consumer to set custom properties (Map<String,Object>) for the endpoint (I needed this for WS-Security properties at a endpoint level).
I also added a extra Interceptor to remove soap headers based on a Set<QName>.

Finally I changed some code a bit to improve performance.

I'm using this extended version in ServiceMix 3.3.1 and it seems to work fine.

I hope the appended patch helps to solve this issues in future releases

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Environment:
System:
2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux

JAVA:
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

Server:
apache-tomcat-6.0.14

ServiceMix:
3.3.1 war

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55002#action_55002 ]

Freeman Fang commented on SMXCOMP-660:
--------------------------------------

Hi Christian,

Thanks for the patch.

I will review it when I get chance.

Freeman

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55003#action_55003 ]

Freeman Fang commented on SMXCOMP-660:
--------------------------------------

Hi Christian,
I just try "mvn install" with your patch to do a quick test to see if all tests pass.
But I end up with exception
--------------------------------------
Oct 27, 2009 4:45:35 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
WARNING: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Operation not bound on this message
        at org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.getOperation(JbiInWsdl1Interceptor.java:334)
        at org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:104)
        at org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:60)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
        at org.apache.servicemix.cxfbc.CxfBcProviderMessageObserver.onMessage(CxfBcProviderMessageObserver.java:122)
        at org.apache.cxf.transport.http.HTTPConduit$InterposedMessageObserver.onMessage(HTTPConduit.java:2216)
        at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
        at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
        at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.Server.handle(Server.java:320)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
Caused by: java.lang.Exception: Operation not bound on this message
        ... 20 more
java.lang.NullPointerException
        at org.apache.servicemix.cxfbc.CxfBcProviderMessageObserver.onMessage(CxfBcProviderMessageObserver.java:127)
        at org.apache.cxf.transport.http.HTTPConduit$InterposedMessageObserver.onMessage(HTTPConduit.java:2216)
        at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
        at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
        at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
        at org.mortbay.jetty.Server.handle(Server.java:320)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
2009-10-27 16:45:35,007 [oupled_endpoint] DEBUG log                            - RESPONSE /decoupled_endpoint  200
2009-10-27 16:45:35,007 [42197506@qtp1-0] DEBUG log                            - continuation still pending null
2009-10-27 16:45:35,008 [42197506@qtp1-0] DEBUG log                            - continuation RetryContinuation@1202988341,new
2009-10-27 16:45:44,975 [42197506@qtp1-0] DEBUG log                            - EOF
2009-10-27 16:45:44,976 [86954034@qtp0-0] DEBUG log                            - EOF
2009-10-27 16:45:44,976 [42197506@qtp1-0] DEBUG log                            - continuation RetryContinuation@1202988341,new
2009-10-27 16:45:44,976 [86954034@qtp0-0] DEBUG log                            - continuation RetryContinuation@1273032512,new

and test just hang there

So my quick quesion is did you pass all cxf bc tests with your patch?

Thanks
Freeman

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55011#action_55011 ]

Christian Connert commented on SMXCOMP-660:
-------------------------------------------


I must admin, that I didn't run any test,  since I had and still have some problems with it (a hole bunch of exceptions)
Thus I tested it by deploying it inside servicemix and running some fundamental tests (inside tomcat thus I couldn't test .

I know this might not be good enough, but since the bugs fixed by this patch
are rather nasty I would still try to integrate the patch.

I'll try to get the test running hand help to track down issues.

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55018#action_55018 ]

Christian Connert commented on SMXCOMP-660:
-------------------------------------------

I finally got the test working, at which test does it hang?
I'll report my result later.

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55018#action_55018 ]

Christian Connert edited comment on SMXCOMP-660 at 10/27/09 6:57 AM:
---------------------------------------------------------------------

I finally got the test working, at which test does it hang?


The tests completed (don't hang) with 25 Errors and 22 Failures from 85.
I guess thats not that bad :-).

      was (Author: mellowsnow):
    I finally got the test working, at which test does it hang?
I'll report my result later.
 

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55020#action_55020 ]

Freeman Fang commented on SMXCOMP-660:
--------------------------------------

Hi Christian,

No, that's not good.
I still get test hang from my side.

And even with no test hang,  all test  should pass, so we can assume this patch cause 25 Errors and 22 Failures.
Generally for an acceptable patch, it shouldn't break any exist tests. We need figure out why the tests are broken with your patch.

Freeman

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55022#action_55022 ]

Christian Connert commented on SMXCOMP-660:
-------------------------------------------

Hi Freeman,

I wasn't serious, I know that a patch shouldn't break the existing infrastructure. Thus I'll investigate further.
Never then less, even if the patch currently isn't and may won't be accepted what will you do about those bugs?
I think this are some essential problems (special breaking the JBI standard and the header propagation).

I'll work on with this version and see where it gets me.

So long

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55022#action_55022 ]

Christian Connert edited comment on SMXCOMP-660 at 10/27/09 8:30 AM:
---------------------------------------------------------------------

Hi Freeman,

I wasn't serious, I know that a patch shouldn't break the existing infrastructure. Thus I'll investigate further.
Never then less, even if the patch currently isn't and may won't be accepted what will you do about those bugs?
I think this are some essential problems (special breaking the JBI standard and the header propagation).

I'll work on with this version and see where it gets me.

So long

Christian

p.s.: could it be that some thest are broken (e.g. I've no /wsdl/calculator.wsdl file)?

      was (Author: mellowsnow):
    Hi Freeman,

I wasn't serious, I know that a patch shouldn't break the existing infrastructure. Thus I'll investigate further.
Never then less, even if the patch currently isn't and may won't be accepted what will you do about those bugs?
I think this are some essential problems (special breaking the JBI standard and the header propagation).

I'll work on with this version and see where it gets me.

So long

Christian
 

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55022#action_55022 ]

Christian Connert edited comment on SMXCOMP-660 at 10/27/09 8:38 AM:
---------------------------------------------------------------------

Hi Freeman,

I wasn't serious, I know that a patch shouldn't break the existing infrastructure. Thus I'll investigate further.
Never then less, even if the patch currently isn't and may won't be accepted what will you do about those bugs?
I think this are some essential problems (special breaking the JBI standard and the header propagation).

I'll work on with this version and see where it gets me.

So long

Christian

      was (Author: mellowsnow):
    Hi Freeman,

I wasn't serious, I know that a patch shouldn't break the existing infrastructure. Thus I'll investigate further.
Never then less, even if the patch currently isn't and may won't be accepted what will you do about those bugs?
I think this are some essential problems (special breaking the JBI standard and the header propagation).

I'll work on with this version and see where it gets me.

So long

Christian

p.s.: could it be that some thest are broken (e.g. I've no /wsdl/calculator.wsdl file)?
 

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55023#action_55023 ]

Christian Connert commented on SMXCOMP-660:
-------------------------------------------

Hi,

I fixed my classpath problems and run the test again, this time one by one in eclipse. I had the following 9 errors and no hangs:

1.) CxfBcComponentTest.testEndpointDOCWithExternalConsumerAndCxfSe -> assertEquals(header1.value.getId(), "retffang"); -> NullPointerException
2.) CxfBcDecoupledProviderTest.testDecoupledProvider -> CXFSe endpoint mtomEnabled
3-4.) CxfBcProviderMtomTest all methods ->  CXFSe endpoint mtomEnabled
5-8.) CxfBcProviderTest all methods -> CXFSe endpoint mtomEnabled
9.) CxfBCSESystemTest.testCalculatrorWithDifferentServiceEndpointNmae -> Could not find route for exchange (JBI route)

I need to state, that I slightly modified the maven dependencies (because I use Servicemix 3.3.1 and want a stable version of CXF):

Parent version 3
servicemix-shared-version 2009.01
servicemix-cxf-se-version 2009.01
cxf-version 2.2.3

This change included specifying a version for jencks (2.1), slf4j-api (1.5.8), slf4j-log4j12 (1.5.8), log4j (1.2.14) and removing jcl104-over-slf4j from the dependencies.

Thus the errors 2 - 8 are easy to explain and are caused by the 2009.01 CXF-SE component.
For 1 and 9 I've no explanation yet.

If I have some time I'll redo the test with the original pom.

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Attachment: cxfbc_1.patch

Hi Freeman,

After removing the mtomEnabled attributes in the config I to experienced the same hang as you in the CxfBcDecoupledProviderTest.testDecoupledProvider. I added another patch which solves the issue.
Thanks for pointing it out.

The error of the CxfBcComponentTest.testEndpointDOCWithExternalConsumerAndCxfSe -> (assertEquals(header1.value.getId(), "retffang"); ) is casued by the cxf 2.2.3 HolderOutInterceptor (wrong index), thus it should be no problem.

Which leaves the mtom Tests, but as said befor I'm unable to run them.

For the last two test (CxfBcProviderTest all methods and
CxfBCSESystemTest.testCalculatrorWithDifferentServiceEndpointNmae) I don't known why they fail. Thus now only 4 tests fail.

Could you run the test at yours with the new patch?
What is the purpose of the 4 failed test methods?

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc_1.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Attachment:     (was: cxfbc.patch)

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc_1.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Attachment:     (was: cxfbc_1.patch)

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Comment: was deleted

(was: Hi Freeman,

After removing the mtomEnabled attributes in the config I to experienced the same hang as you in the CxfBcDecoupledProviderTest.testDecoupledProvider. I added another patch which solves the issue.
Thanks for pointing it out.

The error of the CxfBcComponentTest.testEndpointDOCWithExternalConsumerAndCxfSe -> (assertEquals(header1.value.getId(), "retffang"); ) is casued by the cxf 2.2.3 HolderOutInterceptor (wrong index), thus it should be no problem.

Which leaves the mtom Tests, but as said befor I'm unable to run them.

For the last two test (CxfBcProviderTest all methods and
CxfBCSESystemTest.testCalculatrorWithDifferentServiceEndpointNmae) I don't known why they fail. Thus now only 4 tests fail.

Could you run the test at yours with the new patch?
What is the purpose of the 4 failed test methods?

Christian

)

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/activemq/browse/SMXCOMP-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Connert updated SMXCOMP-660:
--------------------------------------

    Attachment: cxfbc.patch

This final patch resolves the issues and passes all tests.

Christian

> CXF-BC Component isn't JBI conform
> ----------------------------------
>
>                 Key: SMXCOMP-660
>                 URL: https://issues.apache.org/activemq/browse/SMXCOMP-660
>             Project: ServiceMix Components
>          Issue Type: Bug
>          Components: servicemix-cxf-bc
>    Affects Versions: servicemix-cxf-bc-2009.01
>         Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> JAVA:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Server:
> apache-tomcat-6.0.14
> ServiceMix:
> 3.3.1 war
>            Reporter: Christian Connert
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: cxfbc.patch
>
>
> Hi,
> I just noticed that the CXF-BC Component ain't standard conform. There are several problems:
> 1.) The JbiInInterceptor is supposed to write the (soap) headers to the NormalizedMessage (javax.jbi.messaging.protocol.headers). Accordingly to the JBI Spec. the headers should be stored within a Map<String,org.w3c.dom.DocumentFragment>. But in fact the JbiInInterceptor just puts the header.getObject() in the map. Which results in a ClassCastException in other components (like JMS). The objects are some DOM ElementImpl.
> 2.) I'm very unhappy with the fix (https://issues.apache.org/activemq/browse/SMXCOMP-203 states) which removes the WS-Security header from the propagated headers. It's not necessary that the security is implemented with cxf. Thus I think that this fix is not correct. It would be better to e.g. use some other saaj implementation (for instance axis2). Further it might help to at some xerces jar into the class path, but I haven't tested it yet.
> 3.) If useJBIWrapper==true the JbiInWsdl1Interceptor warps the message within JBI parts. That is correct. If headers are specified in the WSDL then these headers are added as separate parts. But it never removes the headers, which where added as part, from the SoapMessage, thus the JbiInInterceptor will put them into the javax.jbi.messaging.protocol.headers map. I think this is not like it should be. Servicemix soap does remove the headers form the underlying message and only puts unspecified (not part of the WSDL) headers into the javax.jbi.messaging.protocol.headers map.
> kind regards
> Christian

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.