mulesoft / api-policies Goto Github PK

The transformation policy is not working in API Gateway 2.0. because is assuming that the runtime is including the class org.jboss.netty.buffer.ChannelBufferInputStream, but it is not. The policy can be fixed by replacing the previous invocation with java.io.InputStream.

I've seen the modifications you've done to this policy to work in 2.0. Most of the things are now working but there are still some changes to do:

1. "http.headers" does not exist anymore with new HTTP transport, all the inbound properties referenced from this map should be referenced directly:
   message.inboundProperties[http.headers]['Host'] -> message.inboundProperties['Host']
2. MULE_REMOTE_CLIENT_ADDRESS should be replaced with http.remote.address
3. "http.context.uri" should be replaced with "Host" and "http.request" with "http.request.uri""

All these new constants are in org.mule.module.http.api.HttpConstants class

As the policy is using a cxf:proxy-service, that component will provide you an invalid wsdl instead of giving you the one generated by the API Platform proxy's cxf:proxy-service (which modifies the wsdl of the user's web service) or the one generated by a cxf:jaxws-service. This is wrong, even if your webservice is secured, you must be able to retrieve the wsdl of it. The correct usage of this security component (if you have an API Platform proxy) would be to include it inside of the proxy's cxf:proxy-service (without using a policy).

The policy does not work properly in GW 2.0 because with the new Http Module. Class org.jboss.netty.buffer.ChannelBufferInputStream is not compatible anymore since netty transport was removed in 2.0. The policy shouldn't be dependent of any specific transport internals (unless it is unavoidable).
To avoid the dependency it could be changed as follows.
The original policy has:

<!-- continue only if the message payloadof InputStream data type is present -->
    <mule:message-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core" 
     onUnaccepted="payloadViolation">
   <mule:expression-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core" 
     expression="#[payload instanceof org.jboss.netty.buffer.ChannelBufferInputStream]" 
     name="PayloadFilter"/>
   </mule:message-filter>

And this should be fixed with:

<!-- continue only if the message payloadof InputStream data type is present -->
    <mule:message-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core" 
        onUnaccepted="payloadViolation">
    <mule:expression-filter xmlns:mule="http://www.mulesoft.org/schema/mule/core" 
       expression="#[payload instanceof java.io.InputStream]" name="PayloadFilter"/>
    </mule:message-filter>

CloudHub, AG 2.2.0
Tried applying the policy on an API.
The below response is produced

Execution of the expression "                                       
                                        app.registry['lock'].lock();
                                        if (!app.registry['sn'].contains(key))
                                            app.registry['sn'].store(key, payloadBck);
                                        app.registry['lock'].unlock();                                      
                                        " failed. (org.mule.api.expression.ExpressionRuntimeException). Message payload is of type: String

:

I tried it with my API.
I applied the response caching policy.
I hit the API many times but the subsequent request has greater response time compared to the first one.
Which is not the expected behavior.

/testAPI
-- | -- | -- | -- | --
|paramKey| Response Timeout
||1st Hit | 2nd Hit | 3rd Hit | 4th Hit
paramValue | 11236 ms | 8844 ms | 9099 ms | 9877 ms

This policy does not work properly in GW 2.0 and the previous versions. It attempts to remove headers (from the outbound properties map) as soon as they arrive to the app, but at that point:

• The outbound properties map is empty
• All the headers are located in the inbound properties map, which can not be modified.

Regarding to the proxies, as the inbound properties are copied to the outbound properties map just before making the request to the implementation api, the unwanted headers are sent anyway.