| 1 | issuekey | title | description | storypoint |
|---|
| 2 | MULE-6432 | Implement true multicast functionality for <all> processor | Currently <all> processes messages sequentially. It could be an issue if message processors inside <all> take long time to respond (e.g. multiple request-response endpoints). We discussed it with MikeS and agreed that the behavior should be configurable (e.g. <all multicast="true">) - if set to true, <all> will spawn multiple threads inside. If one of the MPs inside <all> throws an Exception, it should return MuleExceptionMessage which should be included in the response collection, then Exception Strategy should be invoked. | 8 |
| 3 | MULE-5990 | Does Mule support XA transaction on XA resources used by a Spring object component ? | As you should know, a common use case is the bridge pattern : * read a message from an inbound endpoint (from a JMS queue or/and a database through JDBC). * writing the message to an outbound endpoint (to a JMS queue or/and a database through JDBC). {code:xml} <service name="myBridgeService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"/> </inbound> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox" /> <jdbc:outbound-endpoint queryKey="insertMessageStmt" /> </multicasting-router> </outbound> </service> {code} What happens then if something goes wrong when writing the result to the outbound endpoint (eg. jdbc endpoint)? If you don't use XA Transaction on inbound and outbound endpoints, the message will not be rollbacked to the inbound endpoint in case of an Exception. So you will have to solve this issue by configuring <xa-transaction> on each endpoint with the appropriate transaction strategy. {code:xml} <service name="myBridgeService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"> <xa-transaction action="ALWAYS_BEGIN" /> </jms:inbound-endpoint> </inbound> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox"> <xa-transaction action="ALWAYS_JOIN" /> </jms:outbound-endpoint> <jdbc:outbound-endpoint queryKey="insertMessageStmt"> <xa-transaction action="ALWAYS_JOIN" /> </jdbc:outbound-endpoint> </multicasting-router> </outbound> </service> {code} But what happens now if you have a component between inbound and outbound enpoints ? {code:xml} <service name="myDaoService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"> <xa-transaction action="ALWAYS_BEGIN" /> </jms:inbound-endpoint> </inbound> <component> <spring-object bean="messageDao" /> </component> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox"> <xa-transaction action="ALWAYS_JOIN" /> </jms:outbound-endpoint> <jdbc:outbound-endpoint queryKey="insertMessageStmt"> <xa-transaction action="ALWAYS_JOIN" /> </jdbc:outbound-endpoint> </multicasting-router> </outbound> </service> {code} In most cases, the Spring object component (eg. messsageDao) will execute complicated business operations (from a currently existing business API) and also use a DataSource to execute several SQL select and update statements before returning a result to the outbound. These JDBC operations will be handled likely by Spring JdbcTemplate or even HibernateTemplate. As far as I understand, Mule is fully responsible to handle enlistment/delistment and close of XA resources (see _org.mule.transaction.XaTransaction_). So by default, XA resources used by a Spring object component will not be handled by Mule and will not participate in the XA transaction started from Mule. For completeness... I've also found a unit test for this usecase in Mule distribution under MULE_HOME/src/mule-3.1.2-src.zip/org/mule/test/integration/transaction/XATransactionsWithSpringDAO.java. When you execute this test, you will have a successful result but the XA resource used by the dao bean is not enlisted nor delisted in/from the transaction started from Mule. | 8 |
| 4 | MULE-6087 | Include validation module in Mule core distribution | Emiliano created a validation module, something that's missing inside mule. Validation module support built-in validators. Also it supports different types of exceptions for each validation allowing to generate a different response for each kind of exception. Module: http://mulesoft.github.com/mule-module-validation/ | 8 |
| 5 | MULE-6118 | until-successful should set exception payload with last exception received before sending to DLQ | The title says it all... See this thread for discussions: http://forum.mulesoft.org/mulesoft/topics/until_successful_exceptions_handling Deprecate DLQ (includes doc changes) | 5 |
| 6 | MULE-6145 | until-successful should support synchronous use cases | Imagine a simple synchronous HTTP proxy use case, e.g.: <flow> <http:inbound-endpoint.../> <http:outbound-endpoint.../> </flow> If outbound endpoint is wrapped in until-successful, the flow won't work anymore. until-successful must support synchronous scenarios as well. | 8 |
| 7 | MULE-6172 | Upgrade apache-commons-pool | Since error handling in current version of Apache commons-pool is buggy (borrowConnection method throws a NoSuchElementException losing the original cause) we may need to update the library. Version 1.6 DOES NOT fix the issue. However, current code in trunk tackles the issue (we'll have to wait for a new release). | 3 |
| 8 | MULE-6251 | Add a default object store for non internal usages | Current version provides object stores default (persistent/in memory) to use while processing events internally but there is no object store which could be used by users as default. | 3 |
| 9 | MULE-6355 | soapVersion ignored on CXF proxy | Invoking this proxy with a Soap 1.2 message fails with a WARNing in the logs and a SOAP fault for the caller: {code:xml} <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Body> <soap:Fault> <faultcode xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/">ns1:VersionMismatch</faultcode> <faultstring>A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> {code} NB. Removing the soapVersion attribute and invoking the same proxy with a SOAP 1.1 message works with intense happiness. | 8 |
| 10 | MULE-6367 | FTP Inbound endpoint fails when reading empty file | Put an empty file into FTP inbound path | 5 |
| 11 | MULE-6386 | Outbound endpoint with scheduled dispatch job delivers messages again and again | If you send test messages to vm://test.in (say every second with a different payload for ex 1 2 3 ...) you'll notice that what's delivered to vm://accumulatedMessageHandler is: {{1 2 3 4 5}} then {{1 2 3 4 5 6 7 8 9 10}} then {{1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16}} (in a random order but the idea is here) | 5 |
| 12 | MULE-6441 | Inconsistent behaviour of foreach with inside flowvar | The index of the foreach inside the flow of the flowref is not consistent. It seems that there is a lack of atomicity with the invocation variables causing as a result jump of indexes of the iteration and overwrite of invocation variables. In the example below my payload is the result of a sql query so an ArrayList<CaseInsensitiveHashMap>. I save the value of each row in a flow variable to make it always available in next operations (the original project has more flowRef). The problem comes out because in the contained flow accessed by the flowRef, the invocation variable carrying the index of the iteration and also the name of the element that I saved is not consistent during each iteration. Sometimes some idexes are jumped and also the element of my array tooks more time the same value. | 5 |
| 13 | MULE-6468 | Messages generated from http-messages.properties should be escaped when returned to the client as http response | Currently if you send the the following http request: {code} GET /unionstation/ens/form HTTP/1.1 Accept: */* Accept-Language: en-us UA-CPU: x86 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: staging-unionstation.optuminsight.com Authorization: <sCrIpT>alert(88585)</sCrIpT> Pragma: no-cache Referer: https://staging-unionstation.optuminsight.com:443/unionstation/ens/form X-Scan-Memo: Category="Audit"; Function="createStateRequestFromAttackDefinition"; SID="CF1B85D9856FC7300BE04E08AE969344"; PSID="1D12AD7B110413DEBB8E6634539F76CF"; SessionType="AuditAttack"; CrawlType="None"; AttackType="HeaderParamManipulation"; OriginatingEngineID="1354e211- 9d7d-4cc1-80e6-4de3fd128002"; AttackSequence="3"; AttackParamDesc="Authorization"; AttackParamIndex="6"; AttackParamSubIndex="0"; CheckId="(null)"; Engine="Cross+Site+Scripting"; Retry="False"; SmartMode="NonServerSpecificOnly"; AttackString="%3csCrIpT%3ealert(88585)%3c%2fsCrIpT%3e"; AttackStringProps="Attack"; Connection: Keep-Alive Cookie: CustomCookie=WebInspect76158ZX7B636566555940D48015FD4B8FB9C0F6Y76AF UnitedHealth Group 5Report Date: 9/28/2012 Vulnerability (Legacy) {code} you will receive the following response: {code} HTTP/1.1 403 Forbidden Date: Thu, 27 Sep 2012 07:55:26 GMT Server: Mule Core/3.3.0 http.status: 403 X-MULE_ENCODING: UTF-8 WWW-Authenticate: Basic realm="X12Files" Content-Type: text/plain; charset=UTF-8 Content-Length: 116 Connection: close Http Basic filter doesnt know how to handle header <sCrIpT>alert(88585)</sCrIpT>. Message payload is of type: String {code} containing potential malicious javascript code that the browser will run. Anytime a message is returned to the client the inputs should be parsed to prevent this kind of problems | 8 |
| 14 | MULE-6471 | Default exception strategy is not being called | I have the following flow: {code:xml} <flow name="storeUser" doc:name="storeUser" > <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" path="save" doc:name="HTTP"/> <objectstore:store config-ref="ObjectStore" key="#[json:user]" value-ref="#[payload]" doc:name="Storing the User" /> <async doc:name="Async"> <scripting:component doc:name="Groovy"> <scripting:script engine="Groovy"> <scripting:text><![CDATA[Thread.sleep(10000)]]></scripting:text> </scripting:script> </scripting:component> <vm:outbound-endpoint exchange-pattern="one-way" address="vm://sendMail" doc:name="VM"/> </async> <tracking:custom-event event-name="Stored User" doc:name="Stored user Info"> <tracking:meta-data key="user" value="#[json:user]"/> </tracking:custom-event> <catch-exception-strategy > <set-payload value="#[string: Could not store the user]" doc:name="An Exception ocurred...."/> </catch-exception-strategy> </flow> {code} When I post with an invalid JSON, the return is "Could not store the User" However when I do: {code:xml} <flow name="storeUser" doc:name="storeUser" > <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" path="save" doc:name="HTTP"/> <objectstore:store config-ref="ObjectStore" key="#[json:user]" value-ref="#[payload]" doc:name="Storing the User" /> <async doc:name="Async"> <scripting:component doc:name="Groovy"> <scripting:script engine="Groovy"> <scripting:text><![CDATA[Thread.sleep(10000)]]></scripting:text> </scripting:script> </scripting:component> <vm:outbound-endpoint exchange-pattern="one-way" address="vm://sendMail" doc:name="VM"/> </async> <tracking:custom-event event-name="Stored User" doc:name="Stored user Info"> <tracking:meta-data key="user" value="#[json:user]"/> </tracking:custom-event> <default-exception-strategy> <set-payload value="#[string: Could not store the user]" doc:name="An Exception ocurred...."/> </default-exception-strategy> </flow> {code} The exception is not handled | 1 |
| 15 | MULE-6501 | XsltTransformer forcefully evaluate expressions in context-property into Strings | This arbitrary limitation prevents passing DOM nodes as XSL parameters :( It comes from the fact the XSL transformer uses the deprecated {{parse}} method in: {code:java} protected Object evaluateTransformParameter(String key, Object value, MuleMessage message) throws TransformerException { if (value instanceof String) { return muleContext.getExpressionManager().parse(value.toString(), message); } return value; } {code} | 8 |
| 16 | MULE-6512 | MuleMessageToHttpResponse.createResponse shouldn't use SimpleDateFormat | We should use JodaTime's DateTimeFormatter since it is thread-safe (we can use one static instance) and faster than creating a new one each time. | 2 |
| 17 | MULE-6566 | Per App Classloader should clean all native libraries from the classloader on redeploy | Case example: SAP application in mule with all libraries (jco + jco native lib + sap transport lib) in the application's lib directory On redeploy the JVM aborts with error: Invalid memory access of location 0x1f3c7d10 eip=0x1f3c7d10 The problem seems to be that the native library wasn't properly unloaded and when the jco jar tries to load it again the JVM aborts execution. | 5 |
| 18 | MULE-6604 | Upgrade Jackson to 1.9.11 | This version works with 1.8.0 and there are some deprecated methods in 1.9.11, so there is a need for an upgrade. | 1 |
| 19 | MULE-6628 | Should be able to replace Log4j for another logging implementation | http://www.mulesoft.org/documentation/display/MULE3USER/Configuring+Logging says in the section titled "I don't want to use Log4j" that the log4j jar can be removed so long as SLF4J is wired to another logging implementation. Removing the Log4j jar results in WrapperManager Error: Error in WrapperListener.start callback. java.lang.NoClassDefFoundError: org/apache/log4j/spi/RepositorySelector WrapperManager Error: java.lang.NoClassDefFoundError: org/apache/log4j/spi/RepositorySelector WrapperManager Error: at java.lang.Class.getDeclaredConstructors0(Native Method) WrapperManager Error: at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) WrapperManager Error: at java.lang.Class.getConstructor0(Class.java:2699) WrapperManager Error: at java.lang.Class.getConstructor(Class.java:1657) WrapperManager Error: at org.mule.module.reboot.MuleContainerWrapper.start(MuleContainerWrapper.java:53) WrapperManager Error: at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:3925) WrapperManager Error: Caused by: java.lang.ClassNotFoundException: org.apache.log4j.spi.RepositorySelector WrapperManager Error: at java.net.URLClassLoader$1.run(URLClassLoader.java:202) WrapperManager Error: at java.security.AccessController.doPrivileged(Native Method) WrapperManager Error: at java.net.URLClassLoader.findClass(URLClassLoader.java:190) WrapperManager Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:306) WrapperManager Error: at java.lang.ClassLoader.loadClass(ClassLoader.java:247) WrapperManager Error: ... 6 more This is due to the patch done to fix MULE-5264 which causes MuleContainer to have a direct reference to Log4j's RepositorySelector. Simply moving the reference and the call to setRepositorySelector to some other class which is not accessed via a static reference should solve the problem. | 5 |
| 20 | MULE-6642 | REST Document Resource Definition | http://corp.wiki.mulesource.com/display/WP/Simplified+REST+Service+Creation | 8 |
| 21 | MULE-6645 | REST Swagger Definition Generation | http://corp.wiki.mulesource.com/display/WP/Simplified+REST+Service+Creation | 8 |
| 22 | MULE-6646 | REST Browsable Web UI Generation | http://corp.wiki.mulesource.com/display/WP/Simplified+REST+Service+Creation | 5 |
| 23 | MULE-6647 | Remove all examples, except the new hello world and existing loan broker, from ESB stand-alone distribution | * Packaged examples should be modified as per the following plan: https://docs.google.com/a/mulesoft.com/spreadsheet/ccc?key=0ArwrJmCfHowWdDNCdnJYeldHcDI5M0dYaTRsWUwxd2c#gid=2 * This requires the following additional work: - Creation of the two new identified examples. - Modification of target examples to use latest 3.4 features. Beyond specifics identified on spreadsheet this includes adding in-studio documentation for all examples. - Modification of documentation for target examples. - Removal of examples tagged as Archive from Studio. - Modification of docs to reflect an Archived examples section. - Placement of all examples in GIT and tagging as active versus archived. - From the ESB stand-alone distribution point of view: Remove all examples except the new hello world and existing loan broker. | 5 |
| 24 | MULE-6649 | Addition of DB2 and MS SQL Server to the list of databases on Studio JDBC connector configuration window - ESB Work | Today we show MySQL, Derby, and Oracle. However, MS SQL and DB2 are RDBMS's with very large footprints. As such, we should add these two databases to the set that shows up on the JDBC connector's configuration screen. | 3 |
| 25 | MULE-6657 | NIO and WebSocket Completion | As a Mule ESB user, I would like to be able to turn on the use of the NIO stack through a deploy.properties toggle. As a Mule ESB user, I would like to be able to use the new WebSocket components within my flows. | 8 |
| 26 | MULE-6659 | Testing Mule 3.4 Pairing with GA Registry | As a Mule user, I would like to configure my Mule instance to be paired with my Registry account through my registry key so that I may be able to manage my ESB instance's endpoints with the registry. User should be configure the registry key for their registry account for an ESB instance. From there on: The HTTP endpoints of all apps deployed to the ESB instance should be manageable with the paired registry instance. Detailed specs described here: http://corp.wiki.mulesource.com/display/PRODMGMT/Registry+Interaction+and+License+Management+Support | 3 |
| 27 | MULE-6661 | Testing - Mule 3.4 Dynamic Lookup with GA Registry | As a Mule user, I would like to use the dynamic lookup component within my flows. Detailed specs defined here: http://corp.wiki.mulesource.com/display/WP/Dynamic+Router+%28supports+Registry+Dynamic+Endpoint+Resolution%29 | 1 |
| 28 | MULE-6673 | Update Spring version used in Mule to 3.2 | Update the version of Spring we are using to 3.2 | 5 |
| 29 | MULE-6699 | Intercepting Are not generating message processor path | This is currently breaking debugger, since all MP that executes after an intercepting MP are not being executed. | 5 |
| 30 | MULE-6700 | mule-common dependency should be on a fixed version | We should be on a fixed version rather than a SNAPSHOT. mule-common is at 0.11.0-SNAPSHOT so we'll go with 0.11.0. | 1 |
| 31 | MULE-6710 | REST Representations definition | Multiple representation support for apikit | 8 |
| 32 | MULE-6711 | APIkit example application | Create an example application to showcase apikit functionality | 8 |
| 33 | MULE-6713 | GitHub migration | - svn repo migration to github - bamboo plans update | 8 |
| 34 | MULE-6814 | APIkit REST Controller Resource | REST Controller Resource | 8 |
| 35 | MULE-6815 | APIkit Tech Debt | APIkit Tech Debt | 3 |
| 36 | MULE-6714 | Deprecate Services (and anything else we can) | Deprecate Services (and anything else we can) | 5 |
| 37 | MULE-6718 | When setting a basic authorization filter if no authorizations headers are set in the request, an exception is thrown and there is no request from the browser to add the keys. | When setting a basic authorization filter if no authorizations headers are set in the request, an exception is thrown and there is no request from the browser to add the keys. Steps to reproduce: Deploy app in a 3.4.0-RC2 mule instance. In a browser go to http://localhost:4567/authenticate Expected: a pop-up requesting for authentication should appear. Actual: The response is "Registered authentication is set to org.mule.transport.http.filters.HttpBasicAuthenticationFilter but there was no security context on the session. Authentication denied on endpoint http://localhost:4567/authenticate. Message payload is of type: String" | 5 |
| 38 | MULE-6723 | Restarting a Mule app cause loss of JMS messages even when using transactions | # Start a local ActiveMQ instance listening on port 61616 with in and out queues # Deploy transactional-jms.zip # ab -n 1000 -c 10 http://localhost:8080/help # Wait for messages to be put to in queue # Restart Mule app Expected: All messages are copied from in queue to out queue Actual: About 100 messages are lost | 3 |
| 39 | MULE-6732 | HTTP(S) transport generates everlasting temporary files | When doing a multipart upload it may create a temporary file. It will remain on the disk drive because the file is not being deleted once the outputstream is closed. A deleteOnExit flag would not be effective for never-closing applications. This eventually leads to "java.io.IOException: No space left on device". The location where this file is being created may be seen at https://github.com/mulesoft/mule/blob/mule-3.x/transports/http/src/main/java/org/mule/transport/http/multipart/MultiPartInputStream.java#L135 | 5 |
| 40 | MULE-6745 | Update License.txt, , and 3rd party list | * As a developer I want to be able to read accurate content of the LICENSE.txt file bundled with Mule ESB Standalone. | 3 |
| 41 | MULE-6746 | Fix the 3.x site build | javadoc generation is failing. check log here: http://bamboo.mulesoft.org/browse/MULE3X-MULE3XSITE-SITE | 5 |
| 42 | MULE-6749 | ReplyToHandlers do not work with Dynamic Outbound Endpoints | ReplyToHandler in the case of Ajax (AjaxReplyToHandler) depends on the MessageSourceURI to actually send the message back to the caller. If a dynamic outbound endpoint is introduced in the middle which replaces the event's MessageSourceURI it breaks the replyTo. See the following flow (modified version of the Order Processing example shipped with Studio): {code} <flow name="orderProxy" doc:name="orderProxy"> <ajax:inbound-endpoint channel="/orders/soap" responseTimeout="10000" connector-ref="ajaxServer" doc:name="/orders/soap"/> <outbound-endpoint exchange-pattern="request-response" address="http://#[string:0.0.0.0:1080/orders]" connector-ref="HttpConnector" doc:name="Generic"/> <object-to-string-transformer doc:name="Object to String"/> </flow> {code} produces the following error: {code} {"timestamp":"Wed, 20 Mar 2013 00:03:58 GMT","id":"370","data":{},"channel":"/orders/soap","clientId":"k9lc8wpz6dr1fsvppi"} java.lang.reflect.InvocationTargetException sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.mortbay.cometd.BayeuxService.doInvoke(BayeuxService.java:357) org.mortbay.cometd.BayeuxService.invoke(BayeuxService.java:309) org.mortbay.cometd.BayeuxService.access$400(BayeuxService.java:59) org.mortbay.cometd.BayeuxService$AsyncListen.deliver(BayeuxService.java:393) org.mortbay.cometd.ClientImpl.notifyMessageListener(ClientImpl.java:214) org.mortbay.cometd.ClientImpl.doDelivery(ClientImpl.java:194) org.mortbay.cometd.ChannelImpl.deliverToSubscriber(ChannelImpl.java:502) org.mortbay.cometd.ChannelImpl.doDelivery(ChannelImpl.java:464) org.mortbay.cometd.ChannelImpl.doDelivery(ChannelImpl.java:494) org.mortbay.cometd.ChannelImpl.doDelivery(ChannelImpl.java:494) org.mortbay.cometd.AbstractBayeux$PublishHandler.handle(AbstractBayeux.java:1293) org.mortbay.cometd.AbstractBayeux.handle(AbstractBayeux.java:287) org.mortbay.cometd.continuation.ContinuationCometdServlet.service(ContinuationCometdServlet.java:171) org.mule.transport.ajax.container.MuleAjaxServlet.service(MuleAjaxServlet.java:107) org.mortbay.cometd.AbstractCometdServlet.service(AbstractCometdServlet.java:265) org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) org.mortbay.jetty.Server.handle(Server.java:326) org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945) org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: org.mule.api.MessagingException: Endpoint scheme must be compatible with the connector scheme. Connector is: "ajax", endpoint is "http://0.0.0.0:1080/orders" (java.lang.IllegalArgumentException). Message payload is of type: String org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:35) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:93) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:105) org.mule.processor.AsyncInterceptingMessageProcessor.process(AsyncInterceptingMessageProcessor.java:98) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:93) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:105) org.mule.interceptor.AbstractEnvelopeInterceptor.process(AbstractEnvelopeInterceptor.java:55) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:105) org.mule.processor.AbstractFilteringMessageProcessor.process(AbstractFilteringMessageProcessor.java:44) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:105) org.mule.construct.AbstractPipeline$1.process(AbstractPipeline.java:102) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:93) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:57) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:29) org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:90) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:85) org.mule.construct.AbstractPipeline$3.process(AbstractPipeline.java:194) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:93) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:57) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:29) org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:90) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:85) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.SimpleMessageProcessorChain.doProcess(SimpleMessageProcessorChain.java:47) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:57) org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:66) org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:29) org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:90) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:46) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:43) org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:85) org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:220) org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:202) org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:194) org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:181) org.mule.transport.ajax.AjaxMessageReceiver$ReceiverService.route(AjaxMessageReceiver.java:76) ... 32 more Caused by: java.lang.IllegalArgumentException: Endpoint scheme must be compatible with the connector scheme. Connector is: "ajax", endpoint is "http://0.0.0.0:1080/orders" org.mule.endpoint.AbstractEndpointBuilder.doBuildOutboundEndpoint(AbstractEndpointBuilder.java:254) org.mule.endpoint.AbstractEndpointBuilder.buildOutboundEndpoint(AbstractEndpointBuilder.java:122) com.mulesoft.habitat.agent.endpoint.AnypointEnabledEndpointFactory.getOutboundEndpoint(AnypointEnabledEndpointFactory.java:44) org.mule.transport.ajax.AjaxReplyToHandler.processReplyTo(AjaxReplyToHandler.java:66) org.mule.routing.requestreply.AbstractReplyToPropertyRequestReplyReplier.processReplyTo(AbstractReplyToPropertyRequestReplyReplier.java:69) org.mule.routing.requestreply.AbstractReplyToPropertyRequestReplyReplier.process(AbstractReplyToPropertyRequestReplyReplier.java:45) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:27) ... 104 more {code} | 8 |
| 43 | MULE-6759 | Http dispatcher thread leak | There is a leak of HTTP message dispatcher threads. Steps to reproduce: 1) Copy hello example app to <mule_home>apps folder 2) Start mule 3) Send a request: http://localhost:8888/?name=Ross 4) Remove the hello example app's anchor file and wait for the app to be undeployed 5) Obtain a thread dump of the mule process Expected result: No hello app related threads are in the list of live threads Actual result: There are two: A) One named XXX.processing.time.monitor which is related to MULE-5276 B) One named http-request-dispatch-XXX (which is only created if previous point 3 is executed) The number of B) threads is increased every time you repeat the deploy/exercise/undeploy steps NOTE: http-request-dispatch-XXX should be named using the name of the application, ie something like hello-http-request-dispatch-XXX | 5 |
| 44 | MULE-6760 | ProcessorChain and SubFlows are intercepting when they shouldn't | Currently ProcessorChain and SublFlows are Intercepting this affects debugger because notifications are generated wrong. | 5 |
| 45 | MULE-6765 | Chaining more than one HTTP outbound endpoint will use the HTTP method of the first one | If I have a config file as follows: {code} <flow ...> ... <http:outbound-endpoint method="GET" .../> <http:outbound-endpoint method="POST" .../> <http:outbound-endpoint method="GET" .../> ... </flow> {code} The second outbound-endpoint will always do a GET because if the input payload is of type HTTPMethod, then it takes the value from there. | 13 |
| 46 | MULE-6788 | Upgrade CXF to 2.5.9 | We should upgrade cxf to get the latest security patches. | 5 |
| 47 | MULE-6789 | NullPointerException during JMS Reconnect Attempt | If you configure an xa enabled connector to a JMS broker and the jms broker goes down, the following exception get thrown: {code} DEBUG 2013-02-19 10:34:55,584 [MuleServer.2] org.mule.retry.notifiers.ConnectNotifier: java.lang.NullPointerException at org.mule.transport.AbstractPollingMessageReceiver.schedule(AbstractPollingMessageReceiver.java:97) at org.mule.transport.AbstractPollingMessageReceiver.doStart(AbstractPollingMessageReceiver.java:62) at org.mule.transport.TransactedPollingMessageReceiver.doStart(TransactedPollingMessageReceiver.java:102) at org.mule.transport.AbstractTransportMessageHandler$3.onTransition(AbstractTransportMessageHandler.java:316) at org.mule.lifecycle.AbstractLifecycleManager.invokePhase(AbstractLifecycleManager.java:141) at org.mule.transport.ConnectableLifecycleManager.fireStartPhase(ConnectableLifecycleManager.java:51) at org.mule.transport.AbstractTransportMessageHandler.start(AbstractTransportMessageHandler.java:312) at org.mule.transport.AbstractConnector$5.doWork(AbstractConnector.java:1579) at org.mule.retry.policies.AbstractPolicyTemplate.execute(AbstractPolicyTemplate.java:67) at com.mulesoft.mule.retry.async.RetryWorker.run(RetryWorker.java:74) at org.mule.work.WorkerContext.run(WorkerContext.java:310) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang.Thread.run(Thread.java:662) {code} Step to reproduce: * run the attached config * tear down the activemq broker and start it again | 8 |
| 48 | MULE-6796 | Allow MEL expressions in cxf:property of cxf:ws-config | It would be nice to be able to use MEL expressions for the values of properties in the ws-config so we can set properties based upon the message being processed. | 3 |
| 49 | MULE-7001 | Write initial draft of shared ports spec | We are having a number of critical users requests for being able to deploy multiple apps on the same Mule instance using the same IP/Port endpoint. This story is to do some analysis to identify the possible solutions for addressing this problem space. | 8 |
| 50 | MULE-6800 | Thread leak on Mule redeployments for embedded | When Mule is running embedded in a container, after redeploying an application, there is a thread which still lives from the previous deployment and gets created again with the new one: Mule.log.slf4j.ref.handler. Steps to reproduce: 1. Deploy a Mule embedded app in Tomcat (bookstore-admin.war from the examples, for instance). 2. Check the thread count and look for the mentioned thread 3. Re-deploy the app 4. Check the thread count, it should have gone up by 1 and there should be 2 threads called Mule.log.slf4j.ref.handler | 5 |
| 51 | MULE-6826 | Fix flaky unit test: DateTimeTestCase | DateTimeTestCase has many test that are flaky because they depend on the current system time. For example: {code} @Test public void seconds() { assertEquals(Calendar.getInstance(TimeZone.getTimeZone("UTC")).get(Calendar.SECOND), now.getSeconds()); } {code} Problem is that there are two different calls to obtain the current second, so they could obtain different values from time to time. Same problem exist in many tests, but as they are checking for minutes, hours, days, weeks, etc they less probable to fail, but they are still flaky in theory. | 1 |
| 52 | MULE-6829 | cxf_operation is wrong when using proxy-client of a soap 1.1 request | When processing a soap 1.1 request, the org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor looks for the soap action in soapMessage.get(Message.PROTOCOL_HEADERS).get(SoapBindingConstants.SOAP_ACTION). If Mule doesn't set this beforehand, cxf doesn't find it. This is a problem because the SoapActionInInterceptor will then fail to set the BindingOperationInfo for the request and thus the StaxDataBindingInterceptor will not know which BindingOperationInfo to use so it just picks the first one of its list (which is probably wrong!) and bam! we're executing the wrong operation. Processing soap 1.2 requests (which is much more prevalent) doesn't have this problem. | 5 |
| 53 | MULE-6831 | Applications deleted when deployment fails | When mule starts and a application fails to deploy, both zip and app's folder are deleted. To reproduce: copy the attached app to the apps folder and start mule. After the app is deployed with failure the app zip and folder should be deleted after some seconds (5 by default). | 8 |
| 54 | MULE-6843 | Move OAuth from DevKit to ESB | * Move generated DevKit code to ESB and expose an interface that DevKit can use * Improve user experience when trying to configure an OAuth connector http://corp.wiki.mulesource.com/display/WP/Making+OAuth+user+experience+smoother | 13 |
| 55 | MULE-6844 | Connector Auto-Paging | See here: http://corp.wiki.mulesource.com/pages/viewpage.action?pageId=27132117 This will require some in-iteration investigation. | 5 |
| 56 | MULE-6845 | Define Polling Watermarks | Right now, when a poll needs to deal with updated objects, we use watermarks as an approach to filter out elements that were already processed. The only way to do that right now is to implement the logic manually which forces the user to deal with object stores, default values, repeated logic, dev time dependencies, etc. This story is a container of all the features required for watermark | 3 |
| 57 | MULE-6846 | Define filter, split, aggregate and route record level data strategy | Basic requirements: http://corp.wiki.mulesource.com/pages/viewpage.action?pageId=27132117 | 5 |
| 58 | MULE-6849 | ReplyToDestination is not properly configured in some scenarios | ReplyToParameterProcessor which is used to move the replyToDestination info from the message to the event is not always invoked before other processing occurs. This causes that the message processed inside the flow is not sent back to the client. | 8 |
| 59 | MULE-6852 | Default object store for until-successful | until-successful needs to be configured with an objectstore by default so it works out of the box very easily. | 3 |
| 60 | MULE-6858 | Filename-wildcard filter to fails with SFTP | MULE-6743 modified the scope of originalFilename property: originally it was stored in the outbound scope, but it was changed to inbound. Filename wildcard filter was also changed to read that property from the inbound scope. However the SFTP transport is still storing the property in the outbound scope, making the filter to work incorrectly (not processing file that should be processed). After the mentioned changes, file transport is storing the property in INBOUND and OUTBOUND, FTP is storing it in INBOUND, and SFTP is doing it only in OUTBOUND. | 2 |
| 61 | MULE-6861 | Watermark / Binding object store items to flow variables | h1. Watermarking Right now, when a poll needs to deal with updated objects, we use watermarks as an approach to filter out elements that were already processed. Watermarks require a value to be persisted across flow invocations. Typically, this value will have a default the first time used, and will be used as part of a query or outbound request. Based on how the flow processes the results, the value may be updated. This can be done using several steps: - Fetch a value form a persistent object store and save it as a flow variable - Refer to the flow variable when doing a query / outbound request - Update the variable based (either once - i.e. the watermark is the date of the query, or per record - i.e. the watermark is the highest id from an object) - At the end of the processing, persist the value to the persistent object store This pattern is very common in synchronisation flows. Enough common to deserve better support. To make this easier out of the box we will add a new optional parameter to <poll> that will provide the watermarking variable persistence out of the box. Watermark Example: {code:xml} <flow name="pollSalesforce"> <poll frequency="10m"> <watermark key="lastModifiedDate" default-expression="#[lastYear()]" object-store-ref="myOS" /> <sfdc:search query="Select Id,Name from Account where LastModifiedDate >= #[flowVars['lastModifiedDate']]"/> <foreach> <set-variable name="accountLastModified" value="max(payload['LastModifiedDate']], flowVars['accountLastModified'])"/> </foreach> ..... </flow> {code} h2. Watermark properties * variable (required): This attribute signals both the object store key that will be used to store this watermark as also the name of the flowVar in which its value will be exposed to the user. * default-expression (required): In case that the key above can't be found on the object store, the default expression is used to generate a value. This is useful for the first run of the flow * update-expression (optional): The result of this expression will be used to update the watermark once the execution is finished. It defaults to the value of the variable parameter. * objectStore-ref (optional): A reference to the object store you wish to use to store the watermarks. If not provided, the default user object store will be used h2. Watermark behaviour * It is bound to the poll * It is bound to synchronous flows only. If not then it execution must fail * When executed, it goes to the configured object store looking for a value of the given key. If found, that value is exposed through a flowVar using the same key. * If no value is found for that key in the object store, then the default-expression is executed and that value is exposed through the flowVar. * Watermark will also fire a notification interceptable by the event tracking module. The underlaying tracking event will be enriched with the watermark value. * The message processors will be executed. * If the flow was correctly executed, then the watermark will be updated. * After updating the object store, another notification is fired to the event tracking system so that the new value can also be recorded there * If the intercepted processors throw any exceptions, then the watermark will not be updated. Since the watermark is stored in the object store, the user can always use a exception strategy to put a custom value in case of failure. * In case the watermark value is not serializable then fail the store of the watermark in the object store | 5 |
| 62 | MULE-6864 | SFTP: Jsch issue in java 1.7 and Kerberos | There is a known issue with JSch running in java 1.7 and connecting to a server with Kerberos enabled. When trying to connect to that server, it will request the password to be manually entered. The issue is described in the following page: https://issues.apache.org/bugzilla/show_bug.cgi?id=53437 Setting "PreferredAuthentications" property to "publickey,password,keyboard-interactive" in the SftpClient solves the problem. | 3 |
| 63 | MULE-6866 | Upgrade to Groovy 2.3.6 | Upgrade Mule's Groovy dependency to Groovy 2.3.6. | 8 |
| 64 | MULE-6896 | Ability to handle record level errors in for-each | As an user, I want to catch exceptions at a record level in a for-each/batch element so I can continue processing and put my individual records on a DLQ. | 8 |
| 65 | MULE-6872 | Poll 2.0 | For studio, we want to be able to start, stop and execute polls via an API. | 8 |
| 66 | MULE-6873 | Aggregator Improvements | Should be possible to not use MuleMessage collection Should be possible to use multiple aggregators TBD in more detail by Pablo | 8 |
| 67 | MULE-6889 | Concurrent Modification Exception when using the Async Message Proccessor inside a foreach | It's getting more usual in iApps that we get a collection of elements, and we want to process each element asynchronously. For that reason, we are using the "for-each" message processor, and inside it, we throw an "Async" with a "Flow-Ref" to the flow that process each element. The problem is that it's seems to be a bug that randomly (let's say 4 our of 10) throws a java.util.ConcurrentModificationException. As you can see in the log output, this exception is thrown while the Async is copying the event to create a new one to fire a new thread. The exact error is located at DefaultMuleEvent.java:938, where it says: message.getInvocationPropertyNames(). So, what i guess it's happening here is that when creating a new event, the copy is saving some kind of reference to the same maps instead of creating a new ones. Then, if some new flow var is created in the process item flow, while the async is still firing new thread (that means, copy new events), they are getting mixed up and crash. I'm attached a simple Studio 3.4 GA based project where you can reproduce the bug. Just run the app, and you will see the exception in the console. If you see the following log: "Tenant ID: merlo - RUNNING - Waiting for: 1" and you don't see any exception, please turn down and run the app again. As i said, it doesn't happen 100% of times. | 2 |
| 68 | MULE-6894 | Split collection processor | Spec TBD | 8 |
| 69 | MULE-6898 | Create Mule API to inject Poll a different scheduler | Poll elements have a single scheduler strategy (it uses sheduledWithFixDelay) we want users to be able to determine a different scheduler strategy as part of the story MULE-6872 | 5 |
| 70 | MULE-6899 | Provide an API to stop/start and execute schedulers | We need external systems to be able to stop/start and execute schedulers at any given time. | 2 |
| 71 | MULE-6900 | Change Poll schema to accept a scheduler strategy | New poll schema will accept scheduler strategies: <poll> <schedulers:simple frequency="1000"/> </poll> | 5 |
| 72 | MULE-6903 | UntilSuccessful doesn't correctly validate payload is Serializable | When ensuring that the message payload is Serializable, the validation is not property done when the message is a DefaultMuleMessage and the payload isn't consumable | 1 |
| 73 | MULE-6906 | Add utility methods to execute flows in FunctionalTestCase | Right now FunctionalTestCase only provides one testFlow() method which does't really fit all use cases. FunctionalTestCase could be improve adding the runFlow() family of methods that Devkit generates when archetyping a CloudConnector. This would be better for a user testing their applications and would also help the effort of moving code from Devkit to mule | 1 |
| 74 | MULE-6918 | Add dynamic round robin routing support | Related to MULE-6653 where support for dynamic router was implemented for 'first successful' and 'all' strategies. A new strategy should be added for round robin. The new dynamic-round-robin will round robin through the routes to dispatch the message, maintaining a state to keep track of the next message processor that needs to be processed. The state should be maintained based on a route resolver identifier, the goal behind it is to keep track of the iteration for each configuration of the router. By default it should assume the route resolver has no state if it does not implement an IdentifiableDynamicRouteResolver (which is an interface that extends DynamicRouteResolver) | 5 |
| 75 | MULE-6920 | Race condition on startup of Mule Context | If you start 2 MuleContexts in two threads in parallel, you might run into a race condition. On startup, Mule verifies the JDK version. It reads the "Supported JDK Versions" from the MANIFEST.MF file. This is not thread-safe and one mule context can fail to start because it thinks that there are "null" supported JDKs. Workaround is to synchronize the starts of the two mule contexts externally. | 1 |
| 76 | MULE-6954 | Merge 3.4.1 changes from ASR from Dynamic Round Robin | Merge the Pull request from Eva needed for ASR. | 1 |
| 77 | MULE-6956 | Watermark - unable to access default user Object Store instance | *Steps* with this flow {code} <poll frequency="1000" doc:name="Poll"> <watermark variable="watermarkKey" default-expression="initialized" update-expression="#[payload]" /> </poll> {code} watermark does not access the default user Object Store | 1 |
| 78 | MULE-6959 | Race condition creating MVELExpressionLanguage instances | Constructor of MVELExpressionLanguage is updating the expression language configured in the DefaultExpressionManager. This creates a reace condition when there are more than one instance created and multiple threads using the expression manager. In those cases, some threads can get a NPE. This is a problem using Data Mapper as they extend the MVELExpressionLanguage. There is a second problem having MVELExpressionLanguage constructor setting the expression language: after a DM component, the expression language use in the app will continue to be the expression language from DM, not the original mvel | 5 |
| 79 | MULE-6960 | Allow poll execution with properties | Mule should provide an API to execute polls with inbound properties. | 5 |
| 80 | MULE-6965 | Erro during mule message serialization when using byte array as payload | Attached configuration works well on standalone mode, but when switch to cluster mode I got this exception: INFO 2013-06-18 16:04:26,722 [[pepe].connector.file.mule.default.receiver.01] org.mule.transport.file.FileMessageReceiver: Lock obtained on file: /private/tmp/test/file.txt ERROR 2013-06-18 16:04:26,904 [[pepe].inputFlow.stage1.01] org.mule.exception.DefaultSystemExceptionStrategy: Caught exception in Exception Strategy: java.lang.String cannot be cast to org.mule.api.MuleEvent java.lang.ClassCastException: java.lang.String cannot be cast to org.mule.api.MuleEvent org.mule.processor.SedaStageInterceptingMessageProcessor.dequeue(SedaStageInterceptingMessageProcessor.java:134) org.mule.processor.SedaStageInterceptingMessageProcessor.run(SedaStageInterceptingMessageProcessor.java:209) org.mule.work.WorkerContext.run(WorkerContext.java:311) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) | 8 |
| 81 | MULE-6968 | Http endpoint with path="" or path="/" do not attend requests at root level | enpoints #2 and #3 behave differently than #1 that shows the correct behavior. 1) <http:inbound-endpoint port="8000" host="localhost"> 2) <http:inbound-endpoint port="8000" host="localhost" path=""> 3) <http:inbound-endpoint port="8000" host="localhost" path="/"> only #1 answers requests to http://localhost:8000/ #2 and #3 throw the following error: Cannot bind to address "http://localhost:8000/" No component registered on that endpoint | 8 |
| 82 | MULE-6980 | jackson-xc wrong version | Mule comes with jackson libraries for JSON support. However jackson-xc is the wrong version. If you check in $MULE_HOME/opt you will find most jackson libraries are version 1.9.11: lib/opt/jackson-core-asl-1.9.11.jar lib/opt/jackson-jaxrs-1.9.11.jar lib/opt/jackson-mapper-asl-1.9.11.jar But jackson-xc is version 1.7.1 lib/opt/jackson-xc-1.7.1.jar This makes Mule behave very weirdly when using JSON. When some class from jackson-xc is used, some methods may not match the signatures and the flow just stops. No exception is logged, no information displayed, nothing... Of course its easy to put the correct version in lib\user, but would be better if the OOTB installation just works. | 3 |
| 83 | MULE-6986 | http:static-resource-handler fails when request path is '/' | Given a http:inbound-endpoint with no context path, and a http:static-resource-handler with a resourceBase set, expect that visiting http://server:port should redirect or service http://server:port/index.html. Noted the following issues: 1) Server actually sends a 302 redirect to '//', which is not handled well by modern browsers (Chrome) 2) Visiting http://server:port// actually returns the contents of index.html 3) As a side-issue, visiting http://server:port/index.html if resourceBase does not have a trailing slash results in a file not found error (does not add the necessary slash) Looking at the source here: https://github.com/mulesoft/mule/blob/8de5e6b1de40e8d5f792e8e0f0b9d1de7506c2d8/transports/http/src/main/java/org/mule/transport/http/components/StaticResourceMessageProcessor.java The issue is that the request path is stripped back from '/' to '' here: {code} String path = event.getMessage().getInboundProperty(HttpConnector.HTTP_REQUEST_PATH_PROPERTY); String contextPath = event.getMessage().getInboundProperty(HttpConnector.HTTP_CONTEXT_PATH_PROPERTY); // Remove the contextPath from the endpoint from the request as this isn't part of the path. path = path.substring(contextPath.length()); {code} And so the following code fails to match on 'path.endsWith': {code} if (file.isDirectory() && path.endsWith("/")) { file = new File(resourceBase + path + defaultFile); } {code} And the subsequent code block to redirect is used. The functional test cases don't catch this because the context path is not the same as the request path. | 5 |
| 84 | MULE-6988 | The jetty transport does not have an option to configure the number of acceptor threads | The jetty transport does not have an option to configure the number of acceptor threads It should be configurable at connector level in an xml app. | 2 |
| 85 | MULE-6998 | Incorrect maven dependency for drools | Drools (mule-module-drools) needs the jasper-jdt jar, but does not declare a dependency for it. For a drools project to work, you also need to declare a dependency for mule-transport-ajax. mule-transport-ajax declares a dependency for org.apache.tomcat:jasper:jar which will also bring in jorg.apache.tomcat:jasper-jdt:jar But mule-transport-ajax shouldn't be required for using drools with Mule. | 3 |
| 86 | MULE-7003 | Add support for EE's Batch Module | Implement a new module that allows processing of large data sets at a record level. Specification available in issue DI-4 (http://corp.wiki.mulesource.com/display/WP/Batch+Module) | 21 |
| 87 | MULE-7005 | ServerNotification completing work after listener failure | As a user I register a notification listener in the ServerNotificationManager, if that listener throws an exception, then the ServerNotificationManager finishes, causing that we don't have any notification anymore. This is the error that mule is showing: ERROR 2013-09-05 13:05:44,935 [[notification-server-down].Mule.01] org.mule.work.DefaultWorkListener: Work caused exception on 'workCompleted'. Work being executed was: org.mule.context.notification.ServerNotificationManager@59fe1da2 | 8 |
| 88 | MULE-7012 | HTTP/HTTPS outbound endpoints ignore the keep-alive attribute | The HTTP outbound endpoint has an attribute keep-alive that controls the use of persistent HTTP outbound connections. This attribute is currently ignored. An endpoint configured with exchange-pattern="one-way" always keeps outbound connections alive. If the request-response exchange pattern is used, a new connection is created in each request. This behavior should depend on the keep-alive attribute of the endpoint. In the following example the keep-alive attribute is set to false but the endpoint keeps alive the connection: {code} <flow name="test"> <vm:inbound-endpoint path="doGet" exchange-pattern="one-way" /> <http:outbound-endpoint address="http://localhost:8080/" method="GET" keep-alive="false" exchange-pattern="one-way" /> </flow> {code} | 13 |
| 89 | MULE-7013 | Deprecate keepSendSocketOpen attribute in HTTP connector | The HTTP Connector has an attribute 'keepSendSocketOpen' that is inherited from the TCP connector. This attribute is a TCP setting that should not exist in the HTTP connector (to keep outbound connections open the keep-alive attribute in the outbound endpoint should be used). Add documentation for this change. | 8 |
| 90 | MULE-7022 | Add nexus profile to distributions pom. | Add nexus profile to distributions pom. | 1 |
| 91 | MULE-7027 | ExpiringGroupMonitoringThread must process event groups only when the node is primary | ExpiringGroupMonitoringThread is used on the EventCorrelator to detect EventGroup that expired and must be deleted. This thread is always started as part of the EventCorrelator and that means that in a cluster environment, every node will have a thread running. This causes problems when different nodes try to process the same event group simultaneously. | 5 |
| 92 | MULE-7029 | Several exceptions thrown when pooling in the objectstore | -create an app at box.com with a folder -configure the app with the corresponding client id and client secret from the box app - deploy the app in mule and hit https://localhost:10090/auth to do the oauth dance -go to the logs expected: INFO 2013-09-20 16:07:35,209 [[mule-6992].BoxCall.stage1.09] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,322 [[mule-6992].BoxCall.stage1.15] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,342 [[mule-6992].BoxCall.stage1.01] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,673 [[mule-6992].BoxCall.stage1.11] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,687 [[mule-6992].BoxCall.stage1.06] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,720 [[mule-6992].BoxCall.stage1.07] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,746 [[mule-6992].BoxCall.stage1.16] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,791 [[mule-6992].BoxCall.stage1.04] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:35,823 [[mule-6992].BoxCall.stage1.12] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:36,111 [[mule-6992].DoStuff.stage1.03] org.mule.api.processor.LoggerMessageProcessor: Operation success INFO 2013-09-20 16:07:36,127 [[mule-6992].BoxCall.stage1.08] org.mule.api.processor.LoggerMessageProcessor: Operation success what is happening: go to the logs and some exceptions like the ones listed below will appear | 1 |
| 93 | MULE-7030 | Need to support XPATH 3.0 in the xpath filter | Xpath 2.0 is supported in the XSLT transformers but not in filters right now. This will only apply for xpath expressions not jxpath According to [~philip.parker] AFAIK we only support xpath version 1.0 in flows using MEL, it seems we may support version 2.0 in xslt transformation, in DM I think we support version 3.0. All of these really should be aligned to the same version. Since xpath 2.0 came out in 2007 I think we should be using that as a minimum, if not we should be using 3.0 to take advantage of the newer functions. As we move onto the bigger customers and SOAP WS, they may well want to use XML. | 13 |
| 94 | MULE-7031 | Add getObjectStoreManager() in MuleContext | Add a method in the MuleContext for easy access to the ObjectStoreManager | 1 |
| 95 | MULE-7043 | Cannot put a Foreach after an OAuth authorize | Creating a simple flow that do the authorization and calls get-contacts and iterate through the payload. INFO 2013-09-23 18:12:12,291 [[google-contacts-paged-test].connector.http.mule.default.receiver.02] org.mule.api.processor.LoggerMessageProcessor: Authorized... ERROR 2013-09-23 18:16:09,797 [[google-contacts-paged-test].connector.http.mule.default.receiver.02] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : Object "org.mule.modules.google.contact.wrappers.GoogleContactEntry" not of correct type. It must be of type "{interface java.lang.Iterable,interface java.util.Iterator,interface org.mule.routing.MessageSequence,interface java.util.Collection}" (java.lang.IllegalArgumentException). Message payload is of type: GoogleContactEntry Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. Object "org.mule.modules.google.contact.wrappers.GoogleContactEntry" not of correct type. It must be of type "{interface java.lang.Iterable,interface java.util.Iterator,interface org.mule.routing.MessageSequence,interface java.util.Collection}" (java.lang.IllegalArgumentException) org.mule.util.collection.EventToMessageSequenceSplittingStrategy:61 (null) 2. Object "org.mule.modules.google.contact.wrappers.GoogleContactEntry" not of correct type. It must be of type "{interface java.lang.Iterable,interface java.util.Iterator,interface org.mule.routing.MessageSequence,interface java.util.Collection}" (java.lang.IllegalArgumentException). Message payload is of type: GoogleContactEntry (org.mule.api.MessagingException) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor:35 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.lang.IllegalArgumentException: Object "org.mule.modules.google.contact.wrappers.GoogleContactEntry" not of correct type. It must be of type "{interface java.lang.Iterable,interface java.util.Iterator,interface org.mule.routing.MessageSequence,interface java.util.Collection}" at org.mule.util.collection.EventToMessageSequenceSplittingStrategy.split(EventToMessageSequenceSplittingStrategy.java:61) at org.mule.util.collection.EventToMessageSequenceSplittingStrategy.split(EventToMessageSequenceSplittingStrategy.java:26) at org.mule.routing.CollectionSplitter.splitMessageIntoSequence(CollectionSplitter.java:33) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** | 3 |
| 96 | MULE-7044 | Make poll schedulers part of the same namespace | When poll was enhanced to support different schedulers in Andes, the simple scheduler ended up being defined in the mule schema, and the cron scheduler ended up being part of the schedulers schema. In order to improve consistency, we want to have all the schedulers distributed by the ESB in the same schema. Move the default scheduler bean definition to the scheduler namespace. | 3 |
| 97 | MULE-7052 | Create bitronix transaction manager module and integrate with existent transports | Create a module to use bitronix transaction manager in mule. Integrate the module with existent mule transports | 13 |
| 98 | MULE-7057 | Finalize shared resources spec + create tasks to implement feature | The initial draft of the shared resources spec is here: https://docs.google.com/a/mulesoft.com/document/d/15Pt1N4ylouxk-nFiAFAtfnOiqYyn5fnJn4X3iJtF9tI/edit?usp=drive_web Now that sufficient time has passed, we should finalize the specification, and scope out the amount of work it takes to implement the feature in Mule. Acceptance criteria for this Jira is that more Jiras are created with story points allocated to implement the feature. | 13 |
| 99 | MULE-7062 | It is not possible to send outbound attachments over http | It is not possible to send an attachment over an outbound http, as before the endpoint sends out the data, it fails with: ERROR 2013-10-17 16:15:06,384 [[rubbish-attachments].connector.http.mule.default.receiver.03] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : Name must not be null (java.lang.IllegalArgumentException) Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. Name must not be null (java.lang.IllegalArgumentException) org.apache.commons.httpclient.methods.multipart.PartBase:64 (null) 2. Name must not be null (java.lang.IllegalArgumentException) (org.mule.api.transformer.TransformerException) org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest:372 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transformer/TransformerException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.lang.IllegalArgumentException: Name must not be null org.apache.commons.httpclient.methods.multipart.PartBase.<init>(PartBase.java:64) org.apache.commons.httpclient.methods.multipart.FilePart.<init>(FilePart.java:93) org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest.createMultiPart(ObjectToHttpClientMethodRequest.java:478) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** | 8 |
| 100 | MULE-7063 | Add Spring Security LDAP to Mule Distribution | Add Spring Security LDAP dependency to the standalone distribution. | 2 |
| 101 | MULE-7067 | Improve the way webapps are deployed in the Jetty transport | Remove the WebAppDeployer class, use WebAppProvider from newer Jetty versions instead. | 8 |
| 102 | MULE-7069 | Update Cometd version in Ajax transport | The current Cometd version used in the Ajax transport uses Jetty 6. Update Cometd in order to remove all references to Jetty 6 and use Jetty 8. Update ajax tests that use old jetty version. | 3 |
| 103 | MULE-7070 | Test Servlet API 3.0 support in Jetty Transport | Jetty 8 supports servlet API 3.0. Test that webapps developed with this api can be correctly deployed in Mule using the jetty transport. | 8 |
| 104 | MULE-7071 | Update mule-jetty.xsd that contains references to old Jetty classes in its comments | The mule-jetty.xsd file still contains references to old Jetty clases (org.mortbay) in the comments. Update this file. | 2 |
| 105 | MULE-7073 | Evaluate Mule's gaps to work on a FIPS 140-2 compatible environment | As part of the FIPS 140 analysis, it was found that mule hardcodes the security providers used for SSL configuration. Create the set of tasks and acceptance criteria needed to address this. | 5 |
| 106 | MULE-7074 | Need a way to add message properties other thread | DM needs to be able to add flowVars in a asynch way to the message. See https://www.mulesoft.org/jira/browse/EE-3479 | 8 |
| 107 | MULE-7078 | Create API for record level partial error handling | Both Batch module, connectors, devkit and advanced applications will need some common ground to make partial error handling work: Devkit and connectors will need classes that return bulk operation status on a record per record basis Batch module will need to read partial error classes and treat them accordingly for marking record level errors. Advanced applications may define their own components that may return partial error information. Munit, debugger, batch module and advanced applications will also need to work on a uniform definition of record: Munit to provide means to set record level variables or assert record state Debugger to provide information about record state Batch module to register MEL extensions accessing the record, and in general to provide record level scopes. Advanced applications may eventually define custom steps (this extension is not planned on the initial release), needing to tap into the record scope objects. A small API maven module has to be introduced, so that it may be used as a dependency on the other projects as needed. This module should have the -api suffix, and have a version scheme independent from mule. | 1 |
| 108 | MULE-7082 | Implement new summary module for calculating aggregation functions over streams | Implement new module according to spec at https://github.com/mulesoft/mule/wiki/%5B3.5.-M3%5D-Summarizers | 5 |
| 109 | MULE-7084 | Deprecate dev.ee repository in favour of repository.mulesoft.org | Change distribution management repositories to: https://repository-aster.mulesoft.org/nexus/content/repositories/ And build repositories to: https://repository.mulesoft.org/nexus/content/repositories/ | 5 |
| 110 | MULE-7088 | Improve the way Mime types are registered for outbound http attachments | The HTTP transport uses javax.activation to handle outbound attachments. Mime types are registered by the email transport (through a static initialization block in the class DefaultDataContentHandlerFactory). Therefore, if this class is not loaded, there are no mime types available and there is an error when sending outbound attachments through HTTP (for example: javax.activation.UnsupportedDataTypeException: no object DCH for MIME type text/plain). In the normal use of Mule this problem doesn't happen because all transports are in the classpath, but there should not be a dependency between the HTTP transport and the email transport. See HttpOutboundAttachmentFunctionalTestCase. If the mule-transport-email dependency is removed from the http transport pom, this test fails. | 8 |
| 111 | MULE-7089 | Write spec for new summarizer feature | Write a spec for a new feature that is compliant with the following story: Add a new message processor that would allow to totalise element attributes over a collection or stream. The element should be able to extract a value based on an expression, and then calculate on these summarizer functions: add, average, count, max, min over the value. The result should be saved into a flow variable also defined in the element. This processor should work with streams like auto paging collections. For these cases, the options are to lazily calculate the elements as the stream is consumed or to consume the whole stream. The former should be he default, and there should be an attribute allowing to change the behaviour. | 3 |
| 112 | MULE-7090 | Make Mule rely on platform configured JCE provider instead of fixing on a predefined version | TlsConfiguration gets defaults for several properties using an AutoDiscoverySecurityProviderFactory, which in turn provides defaults based on the JVM flavour in use. In particular, it sets the default JCE Provider to use, the JCE Provider implementation class, the default Keystore type, and the default SSL protocol type being use. This has several problems: * It doesn't allow to properly setup JCE providers as part of the platform configuration, something required to use a FIPS 140-2 compliant JCE provider * It fixes on old versions of the providers and doesn't leverage improvements made in the platforms, like IBM's improved JCE driver (currently we use a JCE provider that is 6+ years old on IBM JVMs) * It fixes the SSL/TLS versions supported, which causes SSL endpoints to support SSL3 (considered deprecated) but no TLS The java platform provides sensible defaults for all these, which get updated as the security landscape evolves, and which can be defined as part of the JVM configuration. Remove the "discovery" of defaults, and use platform defaults for operations in and depending on TlsConfiguration. Acceptance criteria: It should be possible to use any JCE provider defined in the JVM environment in order to support FIPS compliant providers. Endpoints should rely on the registered JCE provider for SSL and use the default ssl type instead of hardcoding one (As FIPS providers will disable several modes and only allow TLS 1.0+). | 5 |
| 113 | MULE-7091 | IllegalStateException when doing OAuth dance with InMemoryObjectStore | OAuth dance works fine with PersistentObjectStores but when using in-memory ones this error is obtained: ******************************************************************************** Message : Failed to invoke fetch-access-token. Message payload is of type: String Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. Only owner thread can write to message: Thread[[splunkfulfillmentqa].connector.http.mule.default.receiver.02,5,main]/Thread[[splunkfulfillmentqa].httpscon.receiver.02,5,main] (java.lang.IllegalStateException) org.mule.DefaultMuleMessage:1626 (null) 2. Failed to invoke fetch-access-token. Message payload is of type: String (org.mule.api.MessagingException) org.mule.devkit.processor.DevkitBasedMessageProcessor:134 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.lang.IllegalStateException: Only owner thread can write to message: Thread[[splunkfulfillmentqa].connector.http.mule.default.receiver.02,5,main]/Thread[[splunkfulfillmentqa].httpscon.receiver.02,5,main] at org.mule.DefaultMuleMessage.newException(DefaultMuleMessage.java:1626) at org.mule.DefaultMuleMessage.checkMutable(DefaultMuleMessage.java:1612) at org.mule.DefaultMuleMessage.assertAccess(DefaultMuleMessage.java:1541) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** | 1 |
| 114 | MULE-7097 | Provide a way to specify valid cipher specs for SSL on transports that support the protocol | SSL/TLS negotiate the actual cryptographic functions used on a session by session basis. In strict environments, it's necessary to remove older and weaker variants of many algorithms. It should be possible to setup the list of cipher specs allowed on secure connections. This setup should happen at server or at least application level, and the default should be to use whatever the cipher specs defined by default by the current provider. Note that this should affect not only https, but any other transport using tis, like pops, imaps, etc. | 8 |
| 115 | MULE-7098 | Create automated test cases for xa transaction recovery | Create automated test cases for xa transaction recovery. | 13 |
| 116 | MULE-7101 | Add pool configuration elements for JMS and JDBC in bitronix | It must be possible to configure a JMS ConnectionFactory pool and JDBC DataSource pool explicitly through XML configuration. | 8 |
| 117 | MULE-7103 | Add support for specifying as a system property, FIPS compliant security model | Add a system property mule.security.model that when used may alter the security setup of mule and it's modules. The default value should be 'default', and should result in the actual behaviour. Using a value that is not recognised should result in a fatal error preventing mule to be successfully initialised. The second supported value should be 'fips140-2', and should result in: * The pgp module being disabled - that is, using php module constructs should raise an error * Any TLS cipher suite NOT defined in the following list should be disabled: (note that the provider may not support all the suites described below - if it doesn't support any of these, an error should be raised). List of approved suites for FIPS: SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | 5 |
| 118 | MULE-7108 | Need to decouple Pipeline interface from MessageProcessorPath generation | In order to be able to implement EE-3510 need to fix this issue. | 2 |
| 119 | MULE-7109 | Allow each until-successful processor to have its own threading profile | It is using the mule common work manager. So the behaviour of it is affected by other threads in mule that are not related to until successful. It also makes hard to customise the threading profile for the until successful. Each until successful should have it own threading profile. This is a subset related to MULE-7035 | 8 |
| 120 | MULE-7113 | Add selectors functionality on Watermark | Implement selectors functionality on watermark as described in https://github.com/mulesoft/mule/wiki/%5B3.5-M1%5D-Watermark | 3 |
| 121 | MULE-7119 | MEL DateTime is not serializable | DateTimes should be serializable so that they can work with watermark. | 1 |
| 122 | MULE-7121 | OAuth support throws raw exception when authorization code not found | When receiving the Oauth callback an exception of type java.lang.Exception is thrown if no authorization code is found on the response (which is often the case when the user denys authorization). Because the exception is a raw type, there's no way to catch it and take a specific action. A new exception type should be created to that purpose and that exception should be thrown | 1 |
| 123 | MULE-7123 | MuleExceptions are not all Serializable | The Exception interface is Serializable, however some implementations of MuleException contain non-serializabe fields which violates the Exception contract and causes errors when trying to persist the Exception in an ObjectStore. All non-serializable fields in any implementation of MuleException should be marked as transient | 1 |
| 124 | MULE-7128 | Need to support short lived queues | So far, all queues in Mule start and stop with the mule context, meaning that once a queue is created it remains active until the owning application stops. This model does not fit the Batch module, which creates queues when a job instance is started and then needs to discard it when the job instance finishes. The clear() method that was added in 3.5.0-ME allows reclaiming the storage but the QueueManager still keeps in-memory resources that are never freed. Therefore the QueueManager interface needs to add the following method: void disposeQueue(Queue); This method frees all resources currently held by the queue including the storage (meaning that queue.clear() will be invoked automatically) Additionally, another common need when dealing with short lived queues is the ability to easily create/retrieve queues with custom configurations. To do that, the QueueSession interface will gain the following method: Queue getQueue(String name, QueueConfiguration queueConfiguration); | 2 |
| 125 | MULE-7137 | DefaultMessageProcessor chain needs to decouple from Pipeline | DefaultMessageProcessorChain decides how to handle VoidMuleEvent on whether the flowConstruct is a Service or a Flow. This is done by testing the flowConstruct to be an instance of Pipeline. Now that the batch module has been introduced, we have a new type of FlowConstruct which is not a Service but not a Pipeline either, which causes errors when one-way outbound endpoints are used in batch. DefaultMessageProcessorChain should be changed so that it takes decisions based on the flowConstruct being an instance of Service only | 3 |
| 126 | MULE-7140 | Create domain concept in mule, basic resource sharing, and domain deployment feature | This task includes: - Add domain concept within mule code base. - Behaviour of domain deployment / undeployment / redeployment including notifications - Class loading changes for domain class loader - Create resource based on a domain configuration file - Add logging functionality so domain resources log in their own file | 13 |
| 127 | MULE-7142 | Create mule domain + domain applications project creation using maven artifact. | This should be kind of an extension of MULE-7138 but should also allow to have a multi module project where one of the project is defined as the domain and the other projects are mule applications that belong to that domain. This artifact should create a package containing the domain + the apps that during deployment it will first create the domain and then deploy the applications. | 8 |
| 128 | MULE-7145 | Redeploy domain when domain config resource is updated | When the domain configuration file gets updated, then the domain must be redeploy. Domain redeploy must also include redeployment of the applications of the domain. The sequence should be: - Acknowledge domain resources has changed. - Undeploy domain applications - Undeploy domain - Redeploy using the updated configuration - Redeploy domain applications | 5 |
| 129 | MULE-7156 | QueueProducer should have a variable generic type | QueueProducer class is tied to Serializable as a generic type. it should allow any T | 1 |
| 130 | MULE-7157 | Allow creating ConsumerIterator instances without selecting a Consumer | In 3.5.0-M3, ConsumerIterator has only one constructor which receives a Consumer. It can be confusing for a dev to choose the right Consumer implementations besides of generating unnecessary coupling between the streaming framework and whichever component using it. It'd be great for a developer to be able to only provide the Producer and let the system choose which Consumer implementation is a best fit | 1 |
| 131 | MULE-7162 | Add support for HTTP connector sharing | Allow an http connector to be shared using it as a shared resources in a domain configuration. | 5 |
| 132 | MULE-7165 | Request Body is not closed in the HttpMessageReceiver | With the changes made in HTTP in 3.4 there's an issue were from time to time a request is accepted but the sockets gets unexpectedly closed. This doesn't happen with the OldHttpMessageReceiver class. We found that the difference on how the response is handled between both implementation is that in the OldHttpMessageReceiver the request's body if closed after successfully sending the response (something that the new receiver is not doing). After we added this code to the new receiver the issue was solved. Unfortunately we weren't able to reproduce this issue in our side, so we cannot create a test case to confirm the fix. The code we need to add is found in the line 210 of the org.mule.transport.http.OldHttpMessageReceiver class: if (request.getBody() != null) { request.getBody().close(); } | 3 |
| 133 | MULE-7185 | Analyze proper solution to MULE-6432 (true asynchronous <all> | We should decide the proper approach for implementing a truly asynchronous <all> message processor. | 8 |
| 134 | MULE-7196 | Integrate the current Web Services Component to Mule | In order to run user testing we need to integrate the current component to Mule. | 3 |
| 135 | MULE-7191 | DefaultMuleMessage should instantiate transient fields when deserealized | We're working in a new serialization mechanism for Mule that will not require objects to implement Serializable or to provide a default constructor. This relies on ASM, Objenesis and other non standard instantiaton methods that have as a side effects that transient fields initialized in line not being initialized. For example: private transient Map<String, DataHandler> inboundAttachments = new ConcurrentHashMap<String, DataHandler>(); When the MuleMessage is initialized through Objenesis, inboundAttachments will be null since a new constructor is added via ASM which ignores the transient fields. Since this constructor will only be used when serializing and DefaultMuleMessage implements the DeserializationPostInitialisable interface, the initAfterDeserialisation method should instantiate these fields if they are null | 1 |
| 136 | MULE-7192 | CollectionSplitter uses wrong type of List | CollectionSplitter uses a LinkedList to split payloads of type Collection. An ArrayList would be way more efficient since the size of the collection is known. | 1 |
| 137 | MULE-7194 | Improper handling of UnknownHostException in Outbound TCP | The problem is that when a hostname cannot be resolved (bad hostname is provided, or DNS is down, etc), Mule's connection pooling system will interpret it as localhost. In the case where the local host happens to be listening on the same port, it can result in messages being routed to the wrong place, whereas they should have failed to connect due to the bad hostname. This is caused by: 1. In the constructor of org.mule.transport.tcp.TcpSocketKey, an InetSocketAddress is constructed. If host resolution fails, the object is created anyway. 2. In org.mule.transport.tcp.TcpSocketFactory, 'getAddress()' is called on the socket key and passed directly into socket.connect(...). 3. In the case that step (1) failed, 'getAddress()' will return null. socket.connect(...) interprets null to be localhost. | 1 |
| 138 | MULE-7197 | Producer interface should not be tied to List<T> | the Producer interface has a return type of List<T> for the produce() method. This was fine for its original intent but as its uses keep growing we need something more generic. The method signature should change to simple T produce() and replace T with a List when necessary | 2 |
| 139 | MULE-7198 | Build fails due to error downloading dependencies of jBPM module. | When attempting to build running "mvn clean install -DskipTests" all downloads required for the jBPM module fail. Tested renaming the jbpm4 folder in my local maven repository to force the download. Attaching logs. Build was successful after changing URL of the Atlassian Repository in the pom file for the module to https (the current URL uses http). | 1 |
| 140 | MULE-7202 | Remove installer specific behaviour from SwitchVersion script | Remove installer code from this file: https://github.com/mulesoft/mule/blob/mule-3.x/buildtools/scripts/SwitchVersion.groovy | 1 |
| 141 | MULE-7203 | Move ws-proxy from patterns/core into a new web services module | The new web services component will use the "ws" namespace. This namespace is already used by the patterns-core module (it is deprecated, replaced by the "patterns" namespace, they both support defining a web service proxy). Before adding the code of the web services consumer, we need to: - Create the ws module, and move the web service proxy implementation into it. - Make patterns-core depend on ws so that we still support defining a web service proxy through the "pattern" namespace. - Deprecate the web service proxy from the pattern namespace, suggesting to use the one from the ws namespace. - Use the ws namespace in the new ws module (move the xsd and namespace handler from patterns-core). | 1 |
| 142 | MULE-7204 | Race condition when compiling MEL expressions | MVEL requires using a different ParseContext on each thread when executed concurrently. In order to accommodate that, MVELExpressionLanguage creates a canonical ParseContext, which is copied on each execution. The problem is that MVELExpressionExecutor compiles MVEL expressions using the canonical ParseContext, leading to a ConcurrentModificationException, that triggered sometimes on MVELExpressionLanguageTestCase.testConcurrentEvaluation. | 5 |
| 143 | MULE-7205 | Review maven configuration to avoid executing test that depend on external services | Doing a clone of the mule projects and then a mvn clean install should ALWAYS work. No matter the environment were I'm running it. | 8 |
| 144 | MULE-7206 | Analyse the changes to have MULE_HOME and MULE_BASE | We need to review the cost and the impact of making the change for MULE-7182 to have Studio starting their apps in the same way Mule Starts them | 8 |
| 145 | MULE-7207 | Create Scatter-Gather component for parallel multicasting | The <all> router currently in Mule makes a good job at doing message multicasting. However, since its processing is sequential, it's not a good fit for some use cases. Implement a scatter-gather component as described in https://github.com/mulesoft/mule/wiki/%5BMULE-3.5-February-2014%5D-Scatter-Gather for parallel multicasting | 8 |
| 146 | MULE-7210 | Outbound endpoint fails to route when sending form-data to an endpoint that uses https protocol | The https outbound endpoint when sending a request with headers doing a post, it throws a timeout. This issue does not happen with the runtime Mule 3.4.1 Steps to reproduce: - Run the attached app - Send a Post to the following endpoint http://localhost:8081/oauth2/token, adding a header to it, for example key: hello , value: world Expected result: Mule sends the request without problems, showing this result: {code} { "error": "invalid_client", "error_description": "The client credentials are invalid" } {code} Actual result: Mule fails when sending the request through the outbound endpoint, sending the following response to the client: {code} Failed to route event via endpoint: DefaultOutboundEndpoint{endpointUri=https://api.box.com/oauth2/token, connector=HttpsConnector { name=HTTP_HTTPS lifecycle=start this=62170429 numberOfConcurrentTransactedReceivers=4 createMultipleTransactedReceivers=true connected=true supportedProtocols=[https] serviceOverrides= <none> } , name='endpoint.https.api.box.com.oauth2.token', mep=REQUEST_RESPONSE, properties={}, transactionConfig=Transaction{factory=null, action=INDIFFERENT, timeout=0}, deleteUnacceptedMessages=false, initialState=started, responseTimeout=10000, endpointEncoding=UTF-8, disableTransportTransformer=false}. Message payload is of type: PostMethod {code} Stacktrace: {code} ERROR 2014-01-03 19:32:27,481 [[restproxy350december].connector.http.mule.default.receiver.05] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : Failed to route event via endpoint: DefaultOutboundEndpoint{endpointUri=https://api.box.com/2.0/folders/0, connector=HttpsConnector { name=HTTP_HTTPS lifecycle=start this=62170429 numberOfConcurrentTransactedReceivers=4 createMultipleTransactedReceivers=true connected=true supportedProtocols=[https] serviceOverrides=<none> } , name='endpoint.https.api.box.com.2.0.folders.0', mep=REQUEST_RESPONSE, properties={}, transactionConfig=Transaction{factory=null, action=INDIFFERENT, timeout=0}, deleteUnacceptedMessages=false, initialState=started, responseTimeout=10000, endpointEncoding=UTF-8, disableTransportTransformer=false}. Message payload is of type: PostMethod Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. Read timed out (java.net.SocketTimeoutException) java.net.SocketInputStream:-2 (null) 2. Failed to route event via endpoint: DefaultOutboundEndpoint{endpointUri=https://api.box.com/2.0/folders/0, connector=HttpsConnector { name=HTTP_HTTPS lifecycle=start this=62170429 numberOfConcurrentTransactedReceivers=4 createMultipleTransactedReceivers=true connected=true supportedProtocols=[https] serviceOverrides=<none> } , name='endpoint.https.api.box.com.2.0.folders.0', mep=REQUEST_RESPONSE, properties={}, transactionConfig=Transaction{factory=null, action=INDIFFERENT, timeout=0}, deleteUnacceptedMessages=false, initialState=started, responseTimeout=10000, endpointEncoding=UTF-8, disableTransportTransformer=false}. Message payload is of type: PostMethod (org.mule.api.transport.DispatchException) org.mule.transport.http.HttpClientMessageDispatcher:151 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/DispatchException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.net.SocketTimeoutException: Read timed out java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(SocketInputStream.java:150) java.net.SocketInputStream.read(SocketInputStream.java:121) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) {code} | 8 |
| 147 | MULE-7211 | Fix Flaky Tests in Mule | Epic to track fixing of flaky tests in Mule | 5 |
| 148 | MULE-7213 | MVEL Version upgrade | As a user of Mule 3.5.0, I would like Mule to depend on the latest version of MVEL (used for DataMapper and MVEL) to stay up-to-date with the latest MVEL bug fixes/enhancements. The latest version seems to be 2.1.8 | 5 |
| 149 | MULE-7497 | Add Oracle configuration for database connector | Add Oracle configuration for database connector | 8 |
| 150 | MULE-7217 | Migrated Tests to new Web Services Consumer module | Migrated Tests to new Web Services Consumer module | 2 |
| 151 | MULE-7218 | Get SOAP action working correctly | Today the SOAP Action works for .NET WS. This has to work across all technologies. | 5 |
| 152 | MULE-7219 | Configure Exchange Pattern based on WSDL Operation MEP | Configure Exchange Pattern based on WSDL Operation MEP | 13 |
| 153 | MULE-7220 | Use an expression for the service address | Use an expression for the service address so that dynamically invoke different services - e.g. in different locations. (different env's). | 2 |
| 154 | MULE-7221 | Should be able to add custom soap headers | Should be able to add custom soap headers | 3 |
| 155 | MULE-7222 | An exception to be thrown when a SOAPFault is returned | An exception to be thrown when a SOAPFault is returned so that I can handle it using exception strategies | 3 |
| 156 | MULE-7228 | Confusing log message in EventProcessingThread | EventProcessingThread has confusing log messages like: logger.debug("Stopping expiring group monitoring"); logger.debug("Expiring group monitoring fully stopped"); Since this is an abstract class with different types of uses, those messages are confusing and should be changed to something that gives information about the actual thread that's executing | 1 |
| 157 | MULE-7230 | Changes in HttpMuleMessageFactory and AbstractMuleMessageFactory breaks 3.4.x devkit's generated code | Changes introduced in HttpMuleMessageFactory and AbstractMuleMessageFactory are affecting 3.4.x devkit's generated code, where the constructor of HttpMuleMessageFactory was using the MuleContext as a parameter. The old behaviour should remain as a connector built in 3.4.x wouldn't work in a new (3.5) Mule version. As a side note: from now on (3.5.0-dolomite) devkit will use the new way of creating the factory. | 3 |
| 158 | MULE-7235 | Define a global configuration element for the web service consumer | Currently the web service consumer receives all its properties as attributes in the message processor. We need to define a global configuration element with some of these attributes, that may can be referenced by the message processor, to avoid repeating XML code in mule applications where more than one WS or operation within the same WS is consumed. | 8 |
| 159 | MULE-7236 | Add support for attachments in web service consumer | It should be possible to add MTOM attachments to a SOAP request, and also to extract attachments from the response and add them to the Mule message. | 8 |
| 160 | MULE-7237 | Implement security timestamp in web service consumer | Add support for ws-security timestamp in the web service consumer component. | 5 |
| 161 | MULE-7238 | Implement security username token profile in web service consumer | Add support for ws-security username token profile in the web service consumer component. | 5 |
| 162 | MULE-7239 | loader.override being ignored in 3.5.0-cascade - Cloudhub(Dec 2013) runtime | The Connector is using CXF 2.6.0 dependencies, and it has defined a plugin.properties with the follow line loader.override=org.apache.cxf,org.apache.ws,org.apache.xml In 3.5 with Cloudhub (Dec 2013) runtime environment the same application fails because is invoking one operation that is not defined in cxf 2.5.9. The same application is working correctly on Mule Studio 3.4. The Demo Application can be found in here (https://docs.google.com/a/mulesoft.com/file/d/0B9Ow2Z2e_0YmOTlLSURNdmwxZXFDcFM4MU4wODB0VllYcjFz/edit). The connector version that is working can be located in here (https://github.com/mulesoft/ms-dynamics-crm-connector/tree/mule-module-ms-dynamics-crm-1.7.1) | 8 |
| 163 | MULE-8268 | Add support for inline named parameters inside database message processors | Add support for named parameters inside database message processors. (select, insert, etc) Example: {code} <db:select> <db:parameterized-sql>select * from Test where id = :id</db:parameterized-sql> <db:in-param name="id" value="#[payload.id]"/> </db:select> {code} | 3 |
| 164 | MULE-7242 | Define the type of the payload of the web service consumer | Currently the web service consumer adds an AutoTransformer so that the payload in the response is set as a String. Ideally the payload should be an XMLStreamReader but this doesn't work with DataMapper. Using the transformer and converting to a String may cause performance issues. If the payload is XMLStreamReader, a transformer can be added after the WSConsumer but this breaks data sense. Define the correct approach. | 3 |
| 165 | MULE-7252 | Restart applications automatically even after failure | When using Studio, it saves my changes to disk and Mule restarts my application automatically - which is wonderful, because I can rapidly prototype my application. However, if I make a syntax error, Mule will cease to redeploy my application after that, forcing me to restart Mule completely. Mule should auto-redeploy applications, even if the last deployment failed. (If we can't make that the default for 3.5, we should add a flag to support this in Studio) | 8 |
| 166 | MULE-7253 | Allow BTM to configure username and password for JMS | The Bitronix Connection Factory should be able to receive a username and password to be used for JMS connections. | 5 |
| 167 | MULE-7255 | Release mule-mvel2 v2.1.8-MULE001 | Release a new version of mule-mvel2, and upload it to codehaus repos. Version is tagged with label: mule-mvel2-2.1.8-MULE001 in the git repository. Besides, we need to create build plan in Bamboo CE | 2 |
| 168 | MULE-7256 | WS consumer throws NullPointerException when defining an empty security element | When defining a global configuration element for WS consumer that has an empty security element (defined but empty), a null pointer is thrown upon initialisation. <ws:consumer-config ...> <ws:security> </ws:security> </ws:consumer-config> | 1 |
| 169 | MULE-7258 | Request reply does not work when using specific connector | When the inbound endpoint of a request-reply router uses an specific connector, different to the default one for that transport, then it does not work since it cannot find the endpoint. <request-reply> <vm:outbound-endpoint path="persistentQueue" connector-ref="sharedPersistentVmConnector"/> <vm:inbound-endpoint path="persistentQueueResponse" connector-ref="sharedPersistentVmConnector"/> </request-reply> Adding the connector as attribute of the path makes it work: <request-reply> <vm:outbound-endpoint path="persistentQueue" connector-ref="sharedPersistentVmConnector"/> <vm:inbound-endpoint path="persistentQueueResponse?connector=sharedPersistentVmConnector" connector-ref="sharedPersistentVmConnector"/> </request-reply> To solve this problem the replyTo property must be generated with the specific connector if available. | 8 |
| 170 | MULE-7259 | move scatter-gather config elements to the top | scatter-gather component has two config elements: threading-profile and custom-aggregation-strategy. Right now, those share a sequence with the inner message processors in which its defined that these elements go on the bottom. For consistency with other components, they should be moved to the top, so that what used to be: <scatter-gather timeout="5000"> <flow-ref name="A" /> <vm:outbound-endpoint path="foo" /> <sfdc:upsert ..... /> <custom-aggregation-strategy [class="org.my.CustomAggregationStrategy" | ref="beanReference"] /> <threading-profile maxThreadsActive="5" /> </scatter-gather> Should now be: <scatter-gather timeout="5000"> <custom-aggregation-strategy [class="org.my.CustomAggregationStrategy" | ref="beanReference"] /> <threading-profile maxThreadsActive="5" /> <flow-ref name="A" /> <vm:outbound-endpoint path="foo" /> <sfdc:upsert ..... /> </scatter-gather> | 1 |
| 171 | MULE-7261 | Add support for domain bundle zip file deployment | Add support for deploying a mule domain bundle file. Domain bundle includes not only the domain but the apps to deploy in that domain. | 8 |
| 172 | MULE-7263 | MULE_REMOTE_CLIENT_ADDRESS variable gets the wrong value when http requests are proxied | If an http request is proxied, the MULE_REMOTE_CLIENT_ADDRESS will have the address of the proxy instead of the client address. The X-Forwarded-For header contains a comma separated list of addresses, the first of which is the original client. Mule should look if the http headers contain an X-Forwarded-For header, and in such case populate the MULE_REMOTE_CLIENT_ADDRESS from it's first element if such element is a valid IP address. Additionally, when this situation is detected, add a new INBOUND property called MULE_PROXY_ADDRESS that contains the proxy address | 5 |
| 173 | MULE-7264 | DevkitSupport module should use apache commons StringUtils instead of Spring | Replace usage of org.springframework.util.StringUtils for org.apache.commons.lang.StringUtils to prevent class loading issues when older projects are using prior versions of Spring | 1 |
| 174 | MULE-7269 | Review flaky tests in 3.x builds. | Most of the slow test builds are failing because of flaky tests. We need to review them, test them locally and ignore them if necessary, saving the logs from the failures to later fix them. | 8 |
| 175 | MULE-7270 | WS consumer returns an invalid xml document when the payload contains multiple namespaces | If a soap envelope contains a body which uses at least two different namespaces, and one of those is not used in the top element, the resulting xml document doesn't declare all the namespaces, and thus is not valid. Example response that is not processed correctly: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:enterprise.soap.xxxx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <loginResponse> <result> ... <passwordExpired>false</passwordExpired> <sandbox>false</sandbox> ... <roleId xsi:nil="true"/> ... </result> </loginResponse> </soapenv:Body> </soapenv:Envelope> fails because it's returned as: <?xml version="1.0" encoding="UTF-8"?> <loginResponse xmlns="urn:enterprise.soap.sforce.com"> <result> ... <passwordExpired>false</passwordExpired> <sandbox>false</sandbox> ... <roleId xsi:nil="true"/> ... </result> </loginResponse> Note that the xsi namespace is not imported. | 8 |
| 176 | MULE-7273 | Proxy service does not rewrite schema locations in the WSDL | When proxying a web service, the proxy service will publish the final service WSDL rewriting the port locations. That's been addressed in the JIRA MULE-7152. However, the schema location is not rewritten, and even if it is, the proxy needs to handle proxying a request that is not a SOAP request. Attached is an application with a proxy and a web service which WSDL has an import schema. | 8 |
| 177 | MULE-7280 | Anchor file is created before application gets deployed | Anchor file is created after application unzip but application is still not initialized. Problem is in ArtifactArchiveInstaller#installArtifact To reproduce: # Create a zipped app with the below configuration. # Copy zipped file to ${MULE_HOME}/apps # Start mule using this command {{bin/mule start; if [ -f ${MULE_HOME}/apps/application-name-anchor.txt ] ; then curl http://127.0.0.1:8811/in ; fi }} You should receive and {{in}} message in the console but you get {{curl: (7) couldn't connect to host}} | 5 |
| 178 | MULE-7282 | Upgrade schema versions to 3.5 | Upgrade the schema version to 3.5 | 2 |
| 179 | MULE-7283 | Avoid hung threads on tests cases | Currently there are several tests that left running threads once they ends. These threads consume resources and could interfere with other tests. This task aims to add checks at top level tests hierarchy in order to detect those tests leaving running threads, and then correct the them. | 13 |
| 180 | MULE-7285 | If an error occurs while configuring a just created mule context, inside DefaultMuleContextFactory, this context is not disposed | Several methods inside DefaultMuleContextFactory class create MuleContext objects and then configure them. If the configuration phase raises an exception, the created mule context is not returned and the could not be disposed. | 2 |
| 181 | MULE-7286 | The class EventCorrelator.ExpiringGroupMonitoringThread has an expiryMonitor member that is not disposed at dispose phase. | The dispose method of the EventCorrelator class is not taking into account the expiry monitor inside its inner class ExpiringGroupMonitoringThread. | 2 |
| 182 | MULE-7288 | Allow new DB module config to be share between applications | Allow the new DB config elements to be shared between applications using them as a domain resource. This will allow to share DataSource connections between applications. | 3 |
| 183 | MULE-7289 | When trying to deploy app with to non existent domain NullPointerException is logged instead of an error | Try to deploy the attached application or any application to a non existent domain. | 5 |
| 184 | MULE-7290 | It shouldn't be allowed to deploy an application to more than one domain | Try to deploy an application to more than one domain by putting this lines into mule-deploy.properties: {noformat} domain=default domain=default2 {noformat} | 5 |
| 185 | MULE-7291 | Disposing a domain do not undeploy application | # Deploy an application to a domain # Delete domain anchor file Expected: application gets undeployed Actual: application remains deployed | 5 |
| 186 | MULE-7292 | Shouldn't share an HTTP connector without specifying it inside domain | To share a connector it should be mandatory to declare it in mule-domain-config.xml and reference it from the endpoint in connector-ref. Consider the attached applications and domain. | 5 |
| 187 | MULE-7293 | TransientRegistry does not dispose all registered objects on dispose. | When the dispose method is called on a TransientRegistry instance, the current registered objects are not disposed. Also, if different objects are registered using the same key, just the last object is kept and previous ones are lost. They should also be disposed at dispose phase. | 2 |
| 188 | MULE-7294 | Modifying path of http inbound endpoint when sharing connector makes other application to fail | Steps: # Copy domain to Mule installation # Deploy both applications # curl http://127.0.0.1/in/loco succeeds (first app) # curl http://127.0.0.1/in2/loco succeeds (second app) # Change path of first application from in to in1 # curl http://127.0.0.1/in2/loco Expected: curl succeed Actual: curl fails | 5 |
| 189 | MULE-7296 | Domain initialization result (failure or success) should be shown in a box at the end of the log when starting | Currently, domain initialization status is shown in the logs when performed. But, in the same way that applications, it should be shown in a summary box at the end of server start. | 5 |
| 190 | MULE-7297 | NullPointerException when tyring to override a class with loader.override | When trying o override a class with loader.override=-com.mulesoft.test.Dummy get a NullPointerException. Deploy the attached application in mule standalone using bin/mule -M-Dhttp.port=XXXX | 5 |
| 191 | MULE-7299 | Initial preparations for the Mule 4 development branch | This task will track changes made in the mule-4.x branch in order to accomodate code cleanup tasks. The scope includes: - Upgrading minimum JDK to 7 - Removing any JDK 6 specific code or modules - Get a full maven build to run Out of scope (to be tracked in other tasks) - Removing classes and methods deprecated in mule-3.x | 8 |
| 192 | MULE-7300 | Default domain shouldn't be configurable | You shouldn't be able to configure default domain by adding alibrary or putting mule-domain-config.xml inside it. To reproduce unzip the attached domains.zip file in MULE_HOME and run bin/mule. | 5 |
| 193 | MULE-7301 | Application using the same socket but not sharing connectors deploys but fails to receive requests | Deployed two apps sharing an http connector and one not sharing but with an inbound endpoint listening in the same socket than the two others. The three applications get deployed but only the first two can listen for requests. # Copy attached applications to apps directory # Copy attached domain to domains directory # Start mule by running bin/mule -M-Dhttp.port=XXXX # curl http://127.0.0.1:XXXX/in1/loco (Success) # curl http://127.0.0.1:XXXX/in2/loco (Success) # curl http://127.0.0.1:XXXX/in3/loco (Fails) <- Third application | 5 |
| 194 | MULE-7302 | HTTP inbound endpoints listen for requests in a different path | When http inbound endpoint listens to *in* path, if you send a request to path *inxxx* it receives it. To reproduce deploy this configuration using bin/mule -M-Dhttp.port=YYYY and run curl http://127.0.0.1:YYYY/inxxx {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:test="http://www.mulesoft.org/schema/mule/test" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/test http://www.mulesoft.org/schema/mule/test/current/mule-test.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd"> <flow name="main"> <http:inbound-endpoint host="127.0.0.1" port="${http.port}" path="in" /> <test:component appendString=" Received 2"/> </flow> </mule> {code} | 5 |
| 195 | MULE-7303 | WS-Consumer wsdl doesn't allow resource paths | The web service consumer requires the location of a wsdl file as part of it's configuration. The location is parsed as a URL and if not valid, it is parsed as a file path. The convention in mule is to treat these fields as resource paths, which would allow URLs, absolute files, but will also look for resource files (relative to the current classpath, and possibly inside a jar). Change the behavior so that the wsdl location is treated as a reouce location. | 1 |
| 196 | MULE-7307 | Disallow multiple transaction manager to be used within an application | Currently if multiple transaction manager are configured in mule, as mule only supports one, it will just peek the first one. To avoid confusion to users we must not allow users to configure multiple transaction managers. | 3 |
| 197 | MULE-7311 | Lack of synchronization causes multiple expiration requests on Aggregator groups | The test EventCorrelatorTestCase.processesExpiredGroupInPrimaryNode fails intermitently due to a lack of synchronization in the access to an object store between different threads, that sporadically leads to a group expiry being triggered several times. This may be a problem if the correlation is setup to process the group at expiration instead of giving an error. The problem is mitigated when using persistent object stores as I/O synchronisation is creating an adhoc happens-after causality. | 8 |
| 198 | MULE-7842 | Jersey version upgrade | Mule is using old jersey libraries (1.6) that would need to be upgraded to latest to develop new agent. Dependent on this library are: - current agent - some example and test classes - mule-module-jersey in CE | 13 |
| 199 | MULE-7313 | OAuth2 authorize MessageProcessor enters a loop if it's the last processor in the flow | Consider the following flow: <flow name="authorizeFlow"> <http:inbound-endpoint path="authorize" port="8081" exchange-pattern="request-response"> <google-calendars:authorize /> </flow> That results in google's OAuth login screen showing up. After authorization, the browser is continuously redirected to the same page over and over again. However, if the flow is changed to this: <flow name="authorizeFlow"> <http:inbound-endpoint path="authorize" port="8081" exchange-pattern="request-response"> <google-calendars:authorize /> <logger message="authorized!" /> </flow> It starts to work perfectly after any message processor is placed after the authorization one. This is probably and issue due to the fact that authorize MP's are intercepting but in the first example there's nothing to intercept. | 5 |
| 200 | MULE-7314 | Poll: watermark gives a wrong warning message when no results are returned from the query inside the poll | When polling Salesforce to retrieve data using the watermark feature, a warning message saying that the watermark is null appears if the query does not bring back any data. For example, the following Salesforce query: SELECT Email,FirstName,LastName,LastModifiedDate FROM Contact WHERE LastModifiedDate > #[flowVars['timestamp']] Then the following warning appears even though the watermark value is not null: WARN Watermark [pool-13-thread-1]: Watermark value is null and will be ignored | 1 |
| 201 | MULE-7458 | Make the pgp module work on a FIPS environment | As part of making Mule FIPS 140-2 compliant, users should be able to allow the PGP module to be FIPS-compliant. We should investigate the possibility of using platform's cryptography provider instead of Bouncy Castle for PGP module. If it is easy to do, we should execute the task of removing Bouncy Castle dependencies (create another Jira first). Setting FIPS mode on in Mule should allow the PGP module to use only FIPS-compliant modules. | 5 |
| 202 | MULE-7316 | Fix flaky FlowSyncAsyncProcessingStrategyTestCase. | This is a flaky that was ignored. | 5 |
| 203 | MULE-7318 | CXF: Make proxy-service and proxy-client handle multiple ports to support SOAP 1.1 and 1.2 messages in the same flow | Nowadays, if you want to create a proxy, you have to specify the port name and the soapVersion for each binding. This information is provided by the wsdl, so it shouldn't be required, the proxies should detect them automatically. As a consequence, if you have an API with multiple ports, one of them receiving a SOAP 1.1 envelope, and other one receiving a SOAP 1.2 envelope, and if you don't specify the port and the soapVersion in both proxies (service and client) you will not be able to send a SOAP 1.2 message. This means that a simple proxy cannot be used with both types of SOAP versions. | 8 |
| 204 | MULE-7320 | New database module Streaming feature is not working with large queries | When the Streaming option of the new database module is activated, there is an error with large queries. Additionally, no error message is shown and no results are returned. Config: <poll doc:name="Poll"> <fixed-frequency-scheduler frequency="1000" timeUnit="MINUTES" /> <watermark variable="timestampdb" default-expression="#['2010-02-11 14:25:12']" selector="MAX" selector-expression="#[payload.last_modified]"/> <db:select config-ref="MySQL_Config" doc:name="Query Database" > <db:parameterized-query><![CDATA[SELECT first_name,last_name,email,last_modified FROM contact WHERE last_modified > "#[flowVars['timestampdb']]"]]></db:parameterized-query> </db:select> </poll> Same configuration without watermark was also tested and same behavior resulted. | 8 |
| 205 | MULE-7321 | Deprecate <all> in favor of <scatther-gather> | Now that we have an implementation of the scatter gather pattern, deprecate the <all> element in favor of it. There is a slight variation in functionality, but for most cases scatter-gather will be prefered, and the advanced cases were you need to evaluate the same payload sequentially, yet fail at the first failure, can be accomplished using wire-taps. This task requires: - Issuing a warning when parsing <all> in an xml definition. - Changing mule schema's documentation to flag the deprecation in doc - Deprecate class implementing the all router. | 5 |
| 206 | MULE-7322 | MuleApplicationContext renamed to MuleArtifactContext breaks backwards compatibility | On Mule 3.5-M4, MuleApplicationContext was renamed to MuleArtifactContext. This class is used in other projects, and will break them. Provide a deprecated MuleApplicationContext to avoid breaking these apps. | 3 |
| 207 | MULE-7323 | ExpressionSplitterXPathTestCase has wrong assertions | ExpressionSplitterXPathTestCase has tests which are broken but, as the assertions are not ok, they seem to pass. Lines: XMLUnit.compareXML(EXPECTED_MESSAGE_1, results.get(0).toString()); XMLUnit.compareXML(EXPECTED_MESSAGE_2, results.get(1).toString()); Should be: assertTrue(XMLUnit.compareXML(EXPECTED_MESSAGE_1, results.get(0).toString()).identical()); assertTrue(XMLUnit.compareXML(EXPECTED_MESSAGE_2, results.get(1).toString()).identical()); | 1 |
| 208 | MULE-7326 | Can't use WebService consumer with operation without parameters | Consider the documentation attached: The endpoint localhost:8081/ consumes a web services that takes a ZIP as an input parameter. That operation works perfectly. However, in localhost:8081/test I'm trying to consume an operation which doesn't take any parameters. There's no way to make this work because: 1) WS consumer is expecting me to generate the soap envelope using datamapper, however, I don't have a payload to transform so I'm forced to create a dummy map 2) Because the operation is expecting no parameters, the XML that DataMapper generates looks like this: <?xml version="1.0" encoding="UTF-8"?> 3) The above results in WS consumer returning this error, basically because there's no envelope to consume: org.mule.api.transport.DispatchException: COULD_NOT_READ_XML_STREAM. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of type: PostMethod Error put aside, it doesn't make sense to me that: * It seems like the only easy way to generate the SOAP envelopes is through DataMapper, which is not a CE feature like WS Consumer is * How do I create a valid envelope when the operation takes no parameters? * Because envelope generation depends on datamapper, I have to drop the WS Consumer box in the canvas before the DataMapper one. It's not natural for the developer to think the flow from right to left. * Shouldn't WS consumer be capable of auto generating the envelope, at least when it requires no parameters? | 5 |
| 209 | MULE-7328 | Can't use WS consumer with message properties | Consider the attached configuration in which I'm trying to receive a ZIP as an http query param and then use that zip to invoke a weather web service. It is impossible to do so unless I use that message property to create a map in the payload and then use datamapper to create the invocation body. I should have to be forced to create completely artificial set-payload and datamapper message processors for doing something as simple as asking for the weather of a ZIP number. I should't have to write the SOAP body myself either. Any of these two options defeat the purpose of the component. I should be able to just pass the ws:consumer whatever attributes the invocation takes and it should be able to construct the body. | 8 |
| 210 | MULE-7329 | Number of JMS consumers decreases to 1 after reconnection | After reconnection the number of JMS consumers goes from 4 to 1 (In fact to 0, but goes to 1 after queueing a message). Steps: # Install the attached mule-config.xml # Start an ActiveMQ broker # Copy activemq-all-5.9.0.jar to lib/user # bin/mule -M-Dhttp.port=8811 # Wait for deployment # Go to activemq console and verify that there are 4 consumers on queue *in* # Verify that application works running: curl http://127.0.0.1:8811/jms1 and seeing that one message is queued in queue *out* # Restart activemq broker # Wait for console to be up ## Expected: 4 consumers on queue in ## Actual: 0 consumers # bin/mule -M-Dhttp.port=8811 ## Expected: 4 consumers on queue in ## Actual: 1 consumers I've tried setting {{numberOfConsumers="4"}} in the connector but works in the same way It's a regression since in 3.4.1 and before works as expected Tried to load the application with 1000 requests and the consumer's number remains the same mule-config: | 5 |
| 211 | MULE-7331 | JMS inbound do not reconnect to queue after broker restart | When restarting ActiveMQ a JMS inbound endpoint do not reconnect. To reproduce: # Install the attached mule-config.xml # Start an ActiveMQ broker # Copy activemq-all-5.9.0.jar to lib/user # bin/mule -M-Dhttp.port=8811 # Wait for deployment # Verify that application works running: curl http://127.0.0.1:8811/jms1 and seeing that one message is queued in queue out # Restart activemq broker # curl http://127.0.0.1:8811/jms1 ## Expected: one message is queued on queue out ## Actual: out queue has no message besides the one before restarting | 1 |
| 212 | MULE-7335 | Transformer resolution in TypeBasedTransformerResolver fails depending on which order transformers are found | TypeBasedTransformerResolver uses registry to lookup all the transformers that are compatible with a given transformation. Then it searches on the obtained list of transformers looking for the best match to execute the transformation. Problem its that the transformers are not ordered, so the best match calculation fails to obtain a transformer when the two first transformers have the same weight but different implementation classes. In this case, if the best transformer is a third one, then it won't be found because the resolution will fail on the previous ones. | 5 |
| 213 | MULE-7336 | Avoid transformer lookup inside registry to improve performance | Transformer resolution inside MuleRegistryHelper implies two different lookup operations: one for TransformerResolver and another for Transformers. Both lookup operations have a high cost as they imply that prototype beans will be created during the search process. Performance can be improved, in particular avoiding high contention on the application classLoader, if the mentioned lookup are not executed. | 8 |
| 214 | MULE-7338 | New Database Message Processor: Template tag is not accepting dynamic-query as a child element | Steps to reproduce: 1.- Execute the followed Mule config: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:jdbc-ee="http://www.mulesoft.org/schema/mule/ee/jdbc" xmlns:context="http://www.springframework.org/schema/context" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ee/jdbc http://www.mulesoft.org/schema/mule/ee/jdbc/current/mule-jdbc-ee.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-current.xsd"> <db:generic-config name="MySQL_Generic_Config_UsingDS" url="jdbc:mysql://172.16.20.163:3306/studio?user=root&password=*****" driverClassName="com.mysql.jdbc.Driver" doc:name="Generic Config" /> <db:template-query name="Template_Query" doc:name="Template Query"> <db:dynamic-query><![CDATA[SELECT * FROM Users]]></db:dynamic-query> </db:template-query> <flow name="SELECT-FT" doc:name="SELECT-FT"> <logger level="INFO" doc:name="Logger" /> <db:select config-ref="MySQL_Generic_Config_UsingDS" doc:name="Database" > <db:template-query-ref name="Template_Query"/> </db:select> <logger level="INFO" doc:name="Logger" /> </flow> </mule> {code} Issue: You get the followed SAXParserException {code} Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'db:dynamic-query'. One of '{"http://www.mulesoft.org/schema/mule/core":annotations, "http://www.mulesoft.org/schema/mule/db":parameterized-query, "http://www.mulesoft.org/schema/mule/db":template-query-ref, "http://www.mulesoft.org/schema/mule/db":in-param}' is expected. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388) ... 24 more {code} | 1 |
| 215 | MULE-7342 | New Database Messsage Processor: rename <db:output-param /> to <db:out-param /> | To be consistent with the db:in-param, the output parameter should be named db:out-param. Studio is already generating the XML as <db:out-param /> | 1 |
| 216 | MULE-7343 | Fail to expand properties when using property placeholder shared in a domain | Steps: # Deploy the below application and domain # Put domain.properties in domain root dir # bin/mule * Expected: Mule starts and flow listens on 127.0.0.1:8811/in1 and 127.0.0.1:8811/in2 * Actual: Mule fails to start because $[http.port] is an invalid value for port * Note: I put domain.properties file in domain root directory because in domain/classes it is not found | 5 |
| 217 | MULE-7346 | New Database Message Processor: NPE when parsing queries in Templates | Steps to reproduce: 1.- Create and run the followed Mule config: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:context="http://www.springframework.org/schema/context" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-current.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd"> <db:mysql-config name="MySQL_Config_UsingDS" host="172.16.20.163" port="3036" user="root" password="mulemanishere" database="studio" doc:name="MySQL Config" /> <db:template-query name="Template_DELETE" doc:name="Template Query" doc:description="with doc here"> <db:parameterized-query><![CDATA[DELETE FROM Customers WHERE CustomerName='Alfreds Futterkiste' AND ContactName='Maria Anders';]]></db:parameterized-query> <db:in-param name="myDeleteParmeter" defaultValue="#[flowVars['hola']]" /> </db:template-query> <db:template-query name="Template_SELECT" doc:name="Template Query"> <db:parameterized-query><![CDATA[SELECT * FROM Users]]></db:parameterized-query> <db:in-param name="myParameter1" defaultValue="lala" /> <db:in-param name="myParameter2" defaultValue="#[payload.parameter2]" /> </db:template-query> <db:template-query name="Template_STORE_PROCEDURE" doc:name="Template Query"> <db:parameterized-query><![CDATA[USE AdventureWorks2012; GO EXEC sp_procoption @ProcName = '<procedure name>', @OptionName = ] 'startup', @OptionValue = 'on';]]></db:parameterized-query> <db:in-param name="myParameter" defaultValue="storeProcedure" /> <db:in-param name="myParameter2" defaultValue="storeProcedure2" /> </db:template-query> <db:template-query name="Template_UPDATE" doc:name="Template Query"> <!-- <db:dynamic-query><![CDATA[UPDATE Customers SET ContactName='Alfred Schmidt', City='Hamburg' WHERE CustomerName='Alfreds Futterkiste';]]></db:dynamic-query> --> </db:template-query> <flow name="SELECT-FT" doc:name="SELECT-FT"> <logger level="INFO" doc:name="Logger" /> <db:select config-ref="MySQL_Config_UsingDS" doc:name="Database"> <db:template-query-ref name="Template_SELECT" /> <db:in-param name="myParameter3" value="bla3" /> <db:in-param name="myParameter4" value="#[message.payload.ble4]" /> </db:select> <logger level="INFO" doc:name="Logger" /> </flow> </mule> {code} Issue: when running the application you get the followed NPE {code} INFO 2014-02-18 12:37:34,663 [main] org.mule.module.db.sqlexecutor.parser.SimpleSqlCommandParser: Parsing SQL: DELETE FROM Customers WHERE CustomerName='Alfreds Futterkiste' AND ContactName='Maria Anders'; INFO 2014-02-18 12:37:34,669 [main] org.mule.module.db.sqlexecutor.parser.SimpleSqlCommandParser: Parsing SQL: SELECT * FROM Users INFO 2014-02-18 12:37:34,671 [main] org.mule.module.db.sqlexecutor.parser.SimpleSqlCommandParser: Parsing SQL: USE AdventureWorks2012; GO EXEC sp_procoption @ProcName = '<procedure name>', @OptionName = ] 'startup', @OptionValue = 'on'; ERROR 2014-02-18 12:37:34,691 [main] org.mule.module.launcher.application.DefaultMuleApplication: null java.lang.NullPointerException at org.mule.module.db.config.CommandDefinitionBeanDefinitionParser.parseSqlReference(CommandDefinitionBeanDefinitionParser.java:69) at org.mule.module.db.config.CommandDefinitionBeanDefinitionParser.doParse(CommandDefinitionBeanDefinitionParser.java:62) at org.mule.config.spring.parsers.AbstractMuleBeanDefinitionParser.parseInternal(AbstractMuleBeanDefinitionParser.java:297) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73) at org.mule.config.spring.MuleHierarchicalBeanDefinitionParserDelegate.parseCustomElement(MuleHierarchicalBeanDefinitionParserDelegate.java:85) at org.mule.config.spring.MuleHierarchicalBeanDefinitionParserDelegate.parseCustomElement(MuleHierarchicalBeanDefinitionParserDelegate.java:127) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:190) at org.mule.config.spring.MuleBeanDefinitionDocumentReader.parseBeanDefinitions(MuleBeanDefinitionDocumentReader.java:51) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:111) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174) at org.mule.config.spring.MuleArtifactContext.loadBeanDefinitions(MuleArtifactContext.java:106) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451) at org.mule.config.spring.SpringRegistry.doInitialise(SpringRegistry.java:86) at org.mule.registry.AbstractRegistry.initialise(AbstractRegistry.java:105) at org.mule.config.spring.SpringXmlConfigurationBuilder.createSpringRegistry(SpringXmlConfigurationBuilder.java:133) at org.mule.config.spring.SpringXmlConfigurationBuilder.doConfigure(SpringXmlConfigurationBuilder.java:88) at org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:43) at org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:69) at org.mule.config.builders.AutoConfigurationBuilder.autoConfigure(AutoConfigurationBuilder.java:101) at org.mule.config.builders.AutoConfigurationBuilder.doConfigure(AutoConfigurationBuilder.java:52) at org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:43) at org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:69) at org.mule.context.DefaultMuleContextFactory.createMuleContext(DefaultMuleContextFactory.java:80) at org.mule.module.launcher.application.DefaultMuleApplication.init(DefaultMuleApplication.java:170) at org.mule.module.launcher.artifact.ArtifactWrapper$2.execute(ArtifactWrapper.java:62) at org.mule.module.launcher.artifact.ArtifactWrapper.executeWithinArtifactClassLoader(ArtifactWrapper.java:129) at org.mule.module.launcher.artifact.ArtifactWrapper.init(ArtifactWrapper.java:57) at org.mule.module.launcher.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:25) at org.mule.tooling.server.application.ApplicationDeployer.main(ApplicationDeployer.java:121) {code} | 1 |
| 218 | MULE-7347 | CXF: proxy-service does not automatically recognise the port of a service | If the proxy-service receives the information of: -wsdlLocation -namespace -service but it does not receive the port name, this information is not automatically retrieved from the wsdl. This happens even if the service has only one port. There is an attached project where you can see that if you specify the port, this works fine, but if you don't use this property, you receive the following stacktrace: {code} ERROR 2014-02-18 14:14:17,050 [main] org.mule.module.launcher.application.DefaultMuleApplication: null java.net.ConnectException: Connection refused java.net.PlainSocketImpl.socketConnect(Native Method) java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) java.net.Socket.connect(Socket.java:579) java.net.Socket.connect(Socket.java:528) sun.net.NetworkClient.doConnect(NetworkClient.java:180) sun.net.www.http.HttpClient.openServer(HttpClient.java:432) sun.net.www.http.HttpClient.openServer(HttpClient.java:527) sun.net.www.http.HttpClient.<init>(HttpClient.java:211) sun.net.www.http.HttpClient.New(HttpClient.java:308) sun.net.www.http.HttpClient.New(HttpClient.java:326) sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996) sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932) sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850) sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1300) org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XMLParser.parse(Unknown Source) org.apache.xerces.parsers.DOMParser.parse(Unknown Source) org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:249) org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:192) org.mule.module.cxf.support.ProxyServiceConfiguration.getEndpointName(ProxyServiceConfiguration.java:50) org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getEndpointName(ReflectionServiceFactoryBean.java:1843) org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getEndpointName(ReflectionServiceFactoryBean.java:1835) org.mule.module.cxf.builder.AbstractInboundMessageProcessorBuilder.build(AbstractInboundMessageProcessorBuilder.java:189) org.mule.module.cxf.builder.AbstractInboundMessageProcessorBuilder.build(AbstractInboundMessageProcessorBuilder.java:62) org.mule.module.cxf.config.FlowConfiguringMessageProcessor.initialise(FlowConfiguringMessageProcessor.java:92) org.mule.processor.chain.AbstractMessageProcessorChain.initialise(AbstractMessageProcessorChain.java:79) org.mule.construct.AbstractFlowConstruct.initialiseIfInitialisable(AbstractFlowConstruct.java:314) org.mule.construct.AbstractPipeline.doInitialise(AbstractPipeline.java:214) org.mule.construct.AbstractFlowConstruct$1.onTransition(AbstractFlowConstruct.java:109) org.mule.construct.AbstractFlowConstruct$1.onTransition(AbstractFlowConstruct.java:103) org.mule.lifecycle.AbstractLifecycleManager.invokePhase(AbstractLifecycleManager.java:138) org.mule.construct.FlowConstructLifecycleManager.fireInitialisePhase(FlowConstructLifecycleManager.java:78) org.mule.construct.AbstractFlowConstruct.initialise(AbstractFlowConstruct.java:102) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:606) org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1612) org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1553) org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1483) org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:524) org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461) org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295) org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292) org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:626) org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932) org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) org.mule.config.spring.SpringRegistry.doInitialise(SpringRegistry.java:85) org.mule.registry.AbstractRegistry.initialise(AbstractRegistry.java:105) org.mule.config.spring.SpringXmlConfigurationBuilder.createSpringRegistry(SpringXmlConfigurationBuilder.java:133) org.mule.config.spring.SpringXmlConfigurationBuilder.doConfigure(SpringXmlConfigurationBuilder.java:88) org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:43) org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:69) org.mule.config.builders.AutoConfigurationBuilder.autoConfigure(AutoConfigurationBuilder.java:101) org.mule.config.builders.AutoConfigurationBuilder.doConfigure(AutoConfigurationBuilder.java:52) org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:43) org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:69) org.mule.context.DefaultMuleContextFactory.createMuleContext(DefaultMuleContextFactory.java:80) org.mule.module.launcher.application.DefaultMuleApplication.init(DefaultMuleApplication.java:170) org.mule.module.launcher.artifact.ArtifactWrapper$2.execute(ArtifactWrapper.java:62) org.mule.module.launcher.artifact.ArtifactWrapper.executeWithinArtifactClassLoader(ArtifactWrapper.java:129) org.mule.module.launcher.artifact.ArtifactWrapper.init(ArtifactWrapper.java:57) org.mule.module.launcher.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:25) org.mule.tooling.server.application.ApplicationDeployer.main(ApplicationDeployer.java:121) INFO 2014-02-18 14:14:17,055 [main] org.mule.module.launcher.application.DefaultMuleApplication: App 'withoutport' never started, nothing to dispose of Exception in thread "main" org.mule.module.launcher.DeploymentInitException: ConnectException: Connection refused org.mule.module.launcher.application.DefaultMuleApplication.init(DefaultMuleApplication.java:177) org.mule.module.launcher.artifact.ArtifactWrapper$2.execute(ArtifactWrapper.java:62) org.mule.module.launcher.artifact.ArtifactWrapper.executeWithinArtifactClassLoader(ArtifactWrapper.java:129) org.mule.module.launcher.artifact.ArtifactWrapper.init(ArtifactWrapper.java:57) org.mule.module.launcher.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:25) org.mule.tooling.server.application.ApplicationDeployer.main(ApplicationDeployer.java:121) {code} This bug depends on the api that you are using. For example, if you use this one: http://www.webservicex.net/FedACH.asmx?WSDL, which is a .net based API, the port is automatically detected when it is not specified. | 8 |
| 219 | MULE-7348 | Fix EchoTestCase. | This is a flaky test. It's from an example and the problem seems to be that it needs to use a dynamic port. | 3 |
| 220 | MULE-7351 | New Database: Date type is currently mapped to POJO, causing error when doing a DataSense fetch in Studio | Date type is currently mapped to POJO, causing error when doing a DataSense fetch in Studio whenever one of the columns selected is of this type. The error is shown in the screenshot attached. | 5 |
| 221 | MULE-7352 | Watermark should fail to start if update expression is not an expression | It doesn't make sense for the watermakr use case to have constants as update expressions, thus, the user should be warn and the application should not start if such an error occurs. Right now, Watermark just evaluates that expression as a constant resulting in useless watermark values. | 1 |
| 222 | MULE-7353 | Cannot share caching-connection-factory | So far you cannot share caching-connection-factory. | 5 |
| 223 | MULE-7354 | Selector watermark is not thread safe | When using watermark with a selector, the same selector instance is reused across invocations which means that if two polls are executed concurrently values would be overwritten. Right now this is a non issue because watermark only runs on synchronous flows. However, it makes affects code reusability and this will potentially break if we decide to support async watermark or if CloudHub centralised scheduler decides to fire concurrently for different tenants | 2 |
| 224 | MULE-7361 | RequestContext.getEvent() returns null inside poll | When a flow has a poll as a message source, the RequestContext is only set with the event after the poll listener has been executed. So, if inside the poll there's a MP depending on the RequestContext, it fails with NPE | 1 |
| 225 | MULE-7362 | Allow MEL expressions to safely access nested null properties | Consider an object a with property b The expresion "a.b.c" will fail if a.b is null. MVEL was enhanced to include a null safe get flag that would make that expression return null. Change Mule to set that mode of operation. | 2 |
| 226 | MULE-7363 | New Database: defaultValue of named parameter in SQL template should default to null | The defaultValue of a named parameter in SQL template should default to null. The user should not need to specify it in xml or Studio. | 2 |
| 227 | MULE-7364 | New Database: Add attribute to specify additional parameters that are appended to JDBC connection | Use case -- when connecting to a MySQL database, a required connection attribute for DataSense to work correctly is: generateSimpleParameterMetadata=true This should be surfaced within Studio in the advanced tab, as indicated in STUDIO-4591. However, before this can happen, the <xyz-config .../> database element | 3 |
| 228 | MULE-7365 | Fix MtomClientTestCase. | This is a flaky test. | 3 |
| 229 | MULE-7366 | Mule logs switch to DEBUG level when application uses the Salesforce Connector | When deploying an application using the salesforce connector, logging level is downgraded to DEBUG. Also, all logging goes to the console and no file is generated for the app on the logs folder. The same app running from Studio doesn't show this behavior. This issue greatly affects performance and readability of the logs | 8 |
| 230 | MULE-7367 | Clean pom files to support faster build cycles | We follow a build cycle of running tests of increasingly time in steps. In order to improve build times, refactor poms so that features can be disabled when needed. We will settle to standarize on the following switches: -DskipVerifications --> will disable running style checkers, licence checkers, and enforcer plugin -DskipIntegrationTests --> Will disable integration tests -DskipArchetypeTests --> Will skip archetype tests (which require archetypes to be already installed) Running unit vs functional tests will not be modified yet and will use our custom surefire plugin | 8 |
| 231 | MULE-7368 | SoapAction header is not being set in WS Consumer for Soap 1.2 web services | The Web Service Consumer component is not adding the Soap Action header when consuming a Soap 1.2 web service. Example: http://wsf.cdyne.com/WeatherWS/Weather.asmx?WSDL If you consume the GetWeatherInformation operation through the WeatherSoap port, the Soap Action header is sent and everything works OK. If you consume the same operation through the WeatherSoap12 port, the server returns an error indicating that the SOAP Action header is invalid. | 3 |
| 232 | MULE-7369 | New Database: Include generateSimpleParameterMetadata as a MySQL connection attribute by default | Note: This is a temporary solution until MULE-7364 is fixed. For 3.5.0-M4, we should include generateSimpleParameterMetadata=true by default for MySQL connections for Datasense purposes. | 2 |
| 233 | MULE-7373 | Devkit intercepting message processors fail if they are the last element of a chain | Then an intercepting message processor is the last in a chain, it's listener is null. AbstractListeningMessageProcessor, which is the base class for all intercepting message processors created by the devkit, assumes that it will always receive a non-null listener, and fails with a NPE on the process(...) methods that will attempt to call method process of the listener. This is reproduced by putting any devkit intercepting component as the last element of a flow or scope, or at unit testing level, if you don't set the listener but try to use any of the SourceCallback methods. | 1 |
| 234 | MULE-7374 | The serviceAddress attribute should be required in WS consumer | The serviceAddress attribute should be required. Currently if it is not set, an exception with an error message that is not clear is thrown. | 1 |
| 235 | MULE-7376 | NullPointerException while initialising body | When trying to consume the login operation from https://www.mulesoft.org/jira/rpc/soap/jirasoapservice-v2 , the attached NPE is found when WS Consumer MP is initialised | 5 |
| 236 | MULE-7377 | WS Consumer ignores imports in WSDL | I'm trying to consume the login operation from https://www.mulesoft.org/jira/rpc/soap/jirasoapservice-v2. That operation relies on an Array type defined in an import. WS Consumer fails to detect if that operation has parameters or not because it ignores the import and thus it cannot resolve the type | 5 |
| 237 | MULE-7380 | Expiration doesn't work on object store | This simple test reproduce that expiration policies don't work on the object store. {code} final String TOKEN_LAUTARO = "lautaro"; ObjectStoreManager osManager = muleContext.getObjectStoreManager(); ObjectStore<Boolean> store = osManager.getObjectStore("RefreshTokenStore", false, 0, 5*1000, 5*1000); store.store(TOKEN_LAUTARO, true); Thread.sleep(6*1000); store.contains(TOKEN_LAUTARO); //returns true, when it should be false {code} Expected behavior is that last line return false but returns true. | 1 |
| 238 | MULE-7382 | RefreshTokenManager's ObjectStore is not expiring entries | RefreshTokenManager has an expirable object store to make sure that an access token is not refreshed more than one time in the lapse of one minute. That store should expire its entries after one minute but it's not doing so. | 3 |
| 239 | MULE-7383 | Logging of message reception is written to domain log instead of app log when sharing http connector | When an http endpoint receives a request it should be logged in application log, but it is logged in domain log. | 3 |
| 240 | MULE-7384 | Stopping an application that shares an http connector makes the other application endpoint to stop | # Deploy the two applications and domain # Start mule # curl http://127.0.0.1:8080/in1 and curl http://127.0.0.1:8080/in2 returns the expected # rm $MULE_HOME/apps/app2-anchor.txt # wait for app to get undeployed * Error: curl http://127.0.0.1:8080/in1 fails to connect | 3 |
| 241 | MULE-7386 | Shared connector MBean appears under application MBean and should be under the domain one | There is currently no MBean for Domains, we should have one and shared resources should not be in each individual domain application. | 5 |
| 242 | MULE-7387 | Add methods to handle schedulers and sub-flows in FunctionalTestCase | Need to add methods to manually: * Stop all schedules * Run a scheduler on demand * get a sub flow * get all schedulers | 1 |
| 243 | MULE-7390 | XSLT transformer is vulnerable to XXE | The current implementation of the XSLT transformer is vulnerable to the following threat: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing Currently, there is no way to prevent this since it would require to: * Set the property 'javax.xml.stream.isSupportingExternalEntities' to false for the xmlInputFactory. Currently no property can be set XML factory at all. * Set the attribute of the transformer 'useStaxSource'. When this parameter is false (default) the XML factory is ignored. This attribute can't be set right now. We need to disable XXE by default and add an attribute which allows it when needed to keep backwards compatibility. Steps to reproduce: 1. Run the attached configuration. 2. Post the following XML to the endpoint http://localhost:9000/test: <!DOCTYPE spi_doc_type[ <!ENTITY spi_entity_ref SYSTEM 'file:////etc/passwd'>]> <root> <elem>&spi_entity_ref;</elem> <something/> </root> 3. Inspect the content of the output and log. It will show the content of the /etc/passwd file. If you don't have it, you can change it to a file that you have in your filesystem. | 5 |
| 244 | MULE-7391 | Simplify stored procedure results processing | Current stored procedure message processor returns an iterator of statements results (resultset, output params, etc). The reason of that is that we don't know in advance how many results we are going to obtain from a statement and that many DB cannot maintain multiple open resultsets. That makes us unable to process resultSets in streaming mode. The problem is that this makes complex to process result both in streaming on/off modes. The proposed improvement is to return different results depending on whether streaming is enabled or not. * Streaming false Maps of results ResultSet (resultset1, resultset2..) List of maps UpdateCount (updateCount1,.....) integer Output parameter (the name of the parameter) value will result value of the param Map "resultSet1" -> resultSet "updateCount1" -> updateCount * Streaming true Iterator of results ResultSet (resultset1, resultset2..) iterator of maps UpdateCount (updateCount1,.....) integer Output parameter (the name of the parameter) value will result value of the param iterator.next -> resultset iterator.next -> updateCount With this change we loose some consistency because the result changes depending on the value of an attribute, but we gain on simplicity of use for the normal case. | 5 |
| 245 | MULE-7394 | Mule common's sources and javadoc aren't deployed to maven repo | Mule common's sources and javadoc aren't deployed to maven repo. Maven command should add sources:jar and javadoc:jar. This is important since connector developer may use classes inside those jars and javadoc + sources are a must for usability. | 1 |
| 246 | MULE-7395 | Add migration guide on CE distribution | Add migration guide to the CE distribution | 1 |
| 247 | MULE-7396 | Cache and provide the StreamCloser through the MuleContext | MuleContext should have a method getStreamCloser():StreamCloser so that it's easy to get it and we have an easy way to cache it | 1 |
| 248 | MULE-7398 | WebService Consumer does not distinguish between 1.1 and 1.2 services | According to wsdl spec version 1.1 mandates the use of the SOAPAction header. Version 1.2 removes its use. Our consumer effectively assumes that the service is of type 1.1 and so attempts to set the SOAPAction header. This can upset a service of type 1.2 which may return an error like "Server did not recognize the value of HTTP Header SOAPAction: ." Try to consume the service at http://webservicex.net/ws/WSDetails.aspx?CATID=2&WSID=74 for example using both the 1.1 and 1.2 request versions. 1.2 will fail. The way to address this in the cxf Proxy client was to make sure no SOAPAction was present in the outgoing request. | 5 |
| 249 | MULE-7401 | Include the security model used at mule container startup console | Part of the changes made for 3.5 included creating a way of definning the security model to be used. The problem is that there's no feedback to the use on the security model except than the side effects derived from it. Make Mule container display the security model used when starting up. | 2 |
| 250 | MULE-7402 | Fixed unused and undeclared dependencies in maven | Running mvn dependency:analyze shows a lot of warnings due to unused dependencies and transitive dependencies used directly but undeclared Fix the project descriptors of the modules to include needed dependencies and remove unused ones. | 8 |
| 251 | MULE-7404 | Reduce the number of distributions | Mule builds the following distributions: deb-package embedded profiler scripting standalone standalone-light studio - Remove the distributions deb-package, profiler and scripting - Verify if embedded can be removed and replaced by requiring people to use maven - Verify is standalone-light can be removed (it's standalone without source code), or we can change standalone distribution to skip source code - we do publish source code for each artifact so the information is there for IDEs. - Verify if the Studio distribution can be removed. | 5 |
| 252 | MULE-7406 | New database: streaming is useless if statement fetch size is not configured | Streaming mode is intended to avoid OutOfMemory exceptions when processing big resultSets and the idea is to return an iterator as the result of a query so the user can request records on demand. Statements have a fetchSize attribute that indicates the size of the chunk of records that will be returned on each database round trip. For example, fetchSize=5 and a resultset of 20 records will imply 4 chunks of 5 records each. The problem is that when fetchSize is not configured properly, the resultset won't be paged and it will be completely loaded into memory, ie: making streaming useless. | 2 |
| 253 | MULE-7407 | Modify README file for Maven generated Mule app using appkit | When creating a new Mule application using appkit, the README generated is outdated. Please modify the README according to this document: https://docs.google.com/a/mulesoft.com/document/d/1Mlr1IxjLZ_q_Qx9CkMmI9pLNT4FNChIAWRCEjtJBB-Y/edit?usp=sharing | 1 |
| 254 | MULE-7408 | StageName generation should be decoupled from Flow | Right now, the Flow is responsible for generating stage names for resources that leave on its pipeline. That makes it imposible for components relying on such names (such as async) to exists in a FlowConstruct that is not an instance of Flow. This should be refactored so that other types of FlowConstruct can contain an async block | 3 |
| 255 | MULE-7411 | SXC filter router fails due to uninitialised transformer | Due to the fix of MULE-7390, XmlToXMLStreamReader is now initialisable. SxcFilteringOutboundRouter is using an instance of that Transformer without invoking its initialise() method which causes it to fail. SxcFilteringOutboundRouter should properly initialise the transformer | 1 |
| 256 | MULE-7412 | Echo example fails to start because does not find mule-app.properties | To reproduce # copy echo example zip app from distribution to app directory # Run bin/mule # See error in log | 3 |
| 257 | MULE-7413 | Bulk mode in insert/update/delete message processors should accept collection payloads only | When bulkMode=true and payload is not a collection, insert/update/delete message processors are resolving queries using the default values in the query definition. That causes the execution of the query just once, but with null parameter values. Those message processors should accept only collections as payload/source. | 2 |
| 258 | MULE-7414 | Use MVEL Dynamic Optimizer to evaluate MEL Expressions | We need to fix a concurrency Bug and Fix a bug with ASM optimizer when assigning new map entries. Blocked by: https://jira.codehaus.org/browse/MVEL-302 https://jira.codehaus.org/browse/MVEL-303 https://jira.codehaus.org/browse/MVEL-305 | 5 |
| 259 | MULE-7416 | DB: Insert with bulk mode set to true does not return the correct metadata | The new db component is not returning the correct datasense metadata when using the insert operation with the bulk mode set to true. Example: INSERT INTO TABLE TB1 VALUES(PAYLOAD.ID, PAYLOAD.NAME) with BULK = TRUE the expected metadata should be List<{id, name}>. Today it is returning {id, name} | 2 |
| 260 | MULE-7418 | DB Connector throws NPE when advanced-udate fails because connection error | # Copy derbyclient-10.9.1.0.jar to lib/user # Deploy the attached config # curl http://localhost:8080/in * Expected: curl returns 0 * Actual: curl returns {{null (java.lang.NullPointerException). Message payload is of type: String}} | 8 |
| 261 | MULE-7419 | Session is lost when a message is returned by a jms request-response outbound-endpoint | If you invoke a flow starting with a jms request-response inbound endpoint and within that flow you set a session var, you'd expect that session var to be propagated back to the outbound endpoint that invoked it. To reproduce the issue please run the test case attached as a maven project. | 8 |
| 262 | MULE-7424 | New Database: Rename advanced-update to execute-ddl | Rename advanced-update to execute-ddl. Also update the google doc spec | 1 |
| 263 | MULE-7425 | xpath function should not have any side effects on the message | when the xpath() function is not given a source parameter, the result of the evaluation is put on the message payload, which is fine. However, when the source parameter is provided, the payload should not be modified because that causes undesired side effects when using the function in filters or choice routers. When a source is provided, the evaluation result should be set on the source itself | 3 |
| 264 | MULE-7426 | WS consumer not generating payload for a SOAP 1.2 web service with no parameters | Currently the WS consumer detects if a web service doesn't require any input parameters, and in that case ignores the payload and generates automatically the SOAP body with the request. This is working correctly for SOAP 1.1 web services but not with 1.2 web services (in that case the payload is still used as SOAP body). | 3 |
| 265 | MULE-7428 | Fix VM underlaying implementation | Current queues implementation stores the queue content in the transient object store or in the persistent object store if the queue is persistent. We end up with a queue implementation based on a Map which doesn't make any sense. This also causes performance issues. Transactions are not reliable. We don't have a transaction log for local tx or for XA txs. | 13 |
| 266 | MULE-7429 | Fix UntilSuccessfulWithQueuePersistenceObjectStoreTestCase recoversFromPersistedQueue test | This test is testing on some build runs, and it relies on writing a file directly into an object store folder as part of it's execution. | 2 |
| 267 | MULE-7431 | AbstractMessagingExceptionStrategy accessing an incorrect Even when using RequestContext | When a collection message is sent to a subflow and an exception is raised inside it, the exception is not properly raised because is replaced by a "java.lang.IllegalStateException: Payload was invalidated calling setPayload and the message is not collection anymore." instead of keep the original one. | 3 |
| 268 | MULE-7435 | Fix ListSchema.groovy script | This script prints lots of errors. | 3 |
| 269 | MULE-7436 | New Database: code cleanup | Clean up xsd schema for database connector. After the schema is published, docs will take the schema and include it in their db reference docs page: http://www.mulesoft.org/documentation/display/EARLYACCESS/Database+Connector+Reference Included in this Jira is also completing support for Derby and doing any necessary cleanup there. | 3 |
| 270 | MULE-7439 | Replace StringBuffer with StringBuilder whenever possible | Because Mule started on the JDK 1.4 era, there're a lot of uses of StringBuffer. In most cases, there's no need for the contention that it generates and it should be replaced with StringBuilder | 1 |
| 271 | MULE-7440 | New database: query template's parameter types are not resolved | All queries in the DB connector are defined using a template which is not related to a particular DB instance. The template defines the SQL query, the type of the query and the parameter definition and default values. Parameter defined in the template have an "UNKNOWN" type, because they are not related to a DB instance. Because parameters have unknown type, DB connector uses an specific JDBC API call to set/get the parameter values. This causes errors when the driver is not able to convert the parameter values to the type expected in the DB. | 8 |
| 272 | MULE-7442 | Bulk Update fails using a file as a source when the file was generated in Windows due to \r at the end of the line | Bulk Update fails using a file as a source when the file was generated in Windows due to \r at the end of the line. The following works when line endings are Unix style but it does not work when line endings are Windows style: INSERT INTO contact (id, first_name, last_name, email, last_modified) VALUES (1,'Juancito','Perez','juanperez@gmail.com','2014-02-18 12:13:35'); INSERT INTO contact (id, first_name, last_name, email, last_modified) VALUES (2,'pedro','perez','pedroperez@gmail.com','2014-02-11 14:53:21'); | 2 |
| 273 | MULE-7443 | Move SimpleLoggingTable to core | Move SimpleLoggingTable to core so that it can be reused by other modules without the need to depend on the launcher | 1 |
| 274 | MULE-7446 | New Database: Rename bulk-update to bulk-execute | Rename bulk-update to bulk-execute | 1 |
| 275 | MULE-7457 | MuleProcessController should be able to work in Windows | MuleProcessController should be able to work in Windows | 8 |
| 276 | MULE-7459 | Echo example mvn build fails because of test error. | # Download mule-ee-distribution-standalone-3.5.0-M5-20140325.085332-72.tar.gz # Extract # cd examples/echo # mvn test | 3 |
| 277 | MULE-7460 | New Database: Allow users to specify a JDBC parameter types for a query template | In the new database connector, sometimes queries fail if no type is specified for a particular parameter. It should be possible for users to specify the type of parameter in a SQL query. This will fix the issue Jake Morgan ran into on the ESB chat around the IBM DB2 database. As a first step, we should implement parameter type specification for parameters defined within a query template. | 8 |
| 278 | MULE-7461 | New Database: Remove constraint for generateSimpleParameterMetadata in MySQL database by always returning generic object | Remove constraint for generateSimpleParameterMetadata in MySQL database by always returning generic object. In general, we should not have any database come configured OOTB with a custom connection attribute. | 1 |
| 279 | MULE-7462 | New Database: Change behavior of streaming within stored procedure | Instead of having what is described in MULE-7391, when streaming=true, still return a map of results, but have iterators within each resultSet returned. | 5 |
| 280 | MULE-7463 | Monitored ObjectStores should behave consistently | Monitored object stores do not behave consistently: * PartitionableExpirableObjectStore instances trim to max size by applying a Least recently used algorithm. However, MonitoredObjectStoreWrapper does it by applying a Last recently used algorithm. * Additionally, it is allowed to create objects stores that are: completely unbounded, TTL bounded only, TTL and size bounded, but you can't create one that's size bounded only. Expected behavior should be: * Managed object stores always trim to size in a consistent way using LRU. * I can have an ObjectStore that's bounded size wise but unbounded TTL wise | 3 |
| 281 | MULE-7465 | XPATH Expression Language - Dom4J creates separate text-nodes | h2. Overview *1 - XML Document* {code:xml} <sswa2smtp> <operationType>email</operationType> <toAddress>prachurya.barua@bt.com</toAddress> <subject>Voice Circuit Details</subject> <content>hi</content> </sswa2smtp> {code} *2 - Message property set using an xpath expression* {code:xml} <add-message-property key="toAddressesOldWay" value="#[xpath:/*/toAddress/text()]"/> {code} *3 - Other properties set using MEL xpath function* {code:xml} <add-message-property key="toAddressesXPath" value="#[xpath('/*/toAddress').text]"/> <add-message-property key="toAddress" value="#[xpath('//*[local-name()=\'toAddress\']').getStringValue()]" /> <add-message-property key="subjectXPath" value="#[xpath('/*/subject').text]"/> {code} *4 - An array is assigned to the toAddressesOldWay property* SESSION scoped properties: subjectXPath=Voice Circuit Details toAddress=prachurya.barua@bt.com *{color:red}toAddressesOldWay=[prachu, rya.barua@bt.com]{color}* toAddressesXPath=prachurya.barua@bt.com h2. Explanation The method *characters* of class *org.dom4j.io.SAXContentHandler* can generate multiple text nodes if *mergeAdjacentText* property is set to false. An excellent explanation of the reasons of why this happen can be found [here|http://www.mail-archive.com/dom4j-user@lists.sourceforge.net/msg02690.html]. The effect of this problem is that certain xpath expression, most notably related to the use of the text() selector, can return an array of text nodes instead of a single text node. This can lead to incomplete text values or wrong comparisons. This problem was discovered while dealing with a message properties transformer, where new message properties are added using xpath expressions to retrieve some values from an XML payload (this payload is converted to a DOM Document by means of the XmlToDomDocument transformer). This problem also affect the Expression Filter when using an xpath evaluator (uncomment the expression-filter element in the attached Mule configuration file to see it in action). References to the Dom4j issue are reported in [Dom4j Case #117 - Problem with XPath and retrieving text |http://sourceforge.net/p/dom4j/bugs/117/?page=0] Please find attached the Custom transformer that shows how to set the MergeAdjacentText property, the source code of xerces 2.9.1 and the xerces' binaries built with debugging information enabled (the binaries commonly distributed by Apache Xerces project have the debugging info stripped out). For the CustomXmlToDomDocument transformer to work, uncomment the custom-transformer element in the attached Mule configuration file. Please take notice that the return class must be set to org.dom4j.Document. h2. Workarounds *1 - Use any of the following equivalent xpath expressions:* {code} #[xpath:/child::sswa2smtp/child::toAddress[text()]] #[xpath:/sswa2smtp/toAddress[text()]] #[xpath:/child::*/toAddress[text()]] #[xpath:/*/toAddress[text()]] #[xpath:/descendant::toAddress[text()]] #[xpath:string(/*/toAddress)]" #[xpath://toAddress] {code} *2 - Use the attached CustomXmlToDomDocument transformer:* {code:xml} <custom-transformer class="com.mulesoft.support.CustomXmlToDomDocument" doc:name="CustomXmlToDomDocument" returnClass="org.dom4j.Document"/> {code} | 3 |
| 282 | MULE-7473 | Remove deprecated methods on Transformer interface | Remove deprecated methods and replace uses | 8 |
| 283 | MULE-7478 | All test log4j.properties should have the rootLogger at WARN level | Many modules define their own log4j.properties, but some set the rootLogger to INFO which becomes too verbose. They should always be set to WARN | 1 |
| 284 | MULE-7480 | Add profile for system tests | We need a profile for system tests (aka Standalone tests), execute only when profile system is active. | 1 |
| 285 | MULE-7481 | Add extension point in MuleLockFactory | MuleLockFactory delegates into a LockProvider to actually build the lock. Upon initialisation, it grabs such provider from the registry. An extension point is needed so that a provider can be passed into it before initialisation. If such provider is not given, then it fallbacks to the current behavior of taking it from the registry | 1 |
| 286 | MULE-7482 | Create Connector aware PagingDelegate concept | Create the concept of connection aware and process aware PagingDelegate for cases in which a connection manager PagingDelegate is needed | 1 |
| 287 | MULE-7485 | Registered transformers in bootstrap.properties won't be found when the key is different than transformer.{x} | Registered transformers in bootstrap.properties won't be found when the key is different than transformer.{x} If you define your transformer in the bootstrap.properties file as FooTransformer=org.mule.bar.FooTransformer This transformer won't be found by using the lookupTransformer/s methods. And therefore a failure will happen if the transformation is needed. | 13 |
| 288 | MULE-7488 | Handles .NET ?singleWsdl wrong | If http://demo.bromose.eu/DemoService.svc?singleWsdl is used, the flow gets a 400 response code. http://demo.bromose.eu/DemoService.svc?Wsdl is used, the flow works | 3 |
| 289 | MULE-7490 | Improve mule test cases to use a temporary folder for each test case | Improve mule test cases so each of them use a temporary folder for the application working directory. This will probably reduce flakiness of test cases storing information in disk and also will allow to run test in parallel in the future. | 5 |
| 290 | MULE-7492 | Add a tool for matching exceptions by its stack trace | Sometimes it's needed to know if two exceptions have the same stack trace. To do this, we need to be able to compare the full stack traces but discarding the exception (and its causes) messages since they may contain invocation specific data. We need a tool that can generate an exception's full stack trace without any messages | 1 |
| 291 | MULE-7494 | Test cases override DefaultObjectStoreFactoryBean static delegate causing other tests to fail when split and aggregate operations are used. | Test cases override DefaultObjectStoreFactoryBean static delegate causing other tests to fail when split and aggregate operations are used. | 5 |
| 292 | MULE-7557 | Upgrade Http transport to use HttpClient v4 for improved outbound performance | Profile+Tune HTTP Proxy based on findings from PERF-65 | 5 |
| 293 | MULE-7500 | WS Consumer fails when there is an invocation property "operation" defined | When a message contains an invocation property called "operation" and a WS consumer is present, the execution of the WS consumer fails because CXF uses the value of the "operation" variable. | 3 |
| 294 | MULE-7501 | Provide a way to log the SOAP envelope that is being sent in WS Consumer | Currently it is hard to debug WS consumer because there is no way to log the SOAP envelope that is being sent. Provide a way to do this and consider how to integrate it with Studio debugger. | 5 |
| 295 | MULE-7502 | Exception thrown by one-way outbound endpont in a Catch ES causes infinite loop | If a System Exception is thrown inside a Catch Exception Strategy, and the flow that references it is asynchronous, and infinite loop is created, the application will retry to execute the exception strategy infinite times. I've attached to the jira a test case that reproduces the issue | 8 |
| 296 | MULE-7906 | Upgrade Jython library to latest version | As part of upgrading 3rd party libraries, we should upgrade Jython. Support has helped a few customers do this: See https://na6.salesforce.com/5008000000U2R8d?srKp=500&srPos=0 | 8 |
| 297 | MULE-7509 | Transactional Queue Recovery fails when recovery queue has transient queue config. | When executing local tx recovery and there's a transient config for a recovery queue mule fails with a NotImplementedException | 5 |
| 298 | MULE-7510 | MEL behavior is not consistent betsween maps and pojos for proeprty access | With changes made for 3.5, MEL was changed so that property access for maps didn't fail (to be consistent with value access though map[key] syntax). This caused an inconsistency, as the same expression a.b will fail or return null depending on the actual type of a. In order to be consistent, we have decided to make property access return null in all cases. We will also revert back the changes that implied null safe property access by default, and keep asking users to use the .? explicitely). | 3 |
| 299 | MULE-7512 | Synchronous until-successfull waits in milliseconds instead of seconds | When in synchronous mode, the until successful is waiting for the exact value of the seconds-between-retries attribute. Expected: a value of 10 on a synchronous until-successful waits ten seconds between each retry Obtained: it only waits 10 milliseconds | 1 |
| 300 | MULE-7513 | deprecate until-successful's secondsBetweenRetries in favor of millisBetweenRetries | Seconds between retries is fine for the asynchronous case, but when doing a synchronous wait, there're cases in which just a millisecond wait is required. This enhancement consists on: * deprecate secondsBetweenRetries attribute. Using it results in a warning message in the logs. It is to be mark as deprecated in the java code and the xsd * add a millisBetweenRetries property which is the new correct way of using the component * For backwards compatibility, setting secondsBetweenRetries will implicitly set millisBetweenRetries with an equivalent value * Setting both attributes at the same time will result in exception | 2 |
| 301 | MULE-7518 | Parameterized query broken when CDATA is preceded by a new line | Parameterized query cannot be parsed when it contains a CDATA element that is preceded by a new line. org.mule.api.config.ConfigurationException: Unexpected exception parsing XML document from URL [file:/Users/pablokraan/devel/workspaces/muleFull/mule/modules/db/target/test-classes/integration/template/cdata-template-query-config.xml]; nested exception is org.mule.module.db.internal.parser.QueryTemplateParsingException: SQL text cannot be empty (org.mule.api.lifecycle.InitialisationException) org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:49) org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:69) org.mule.context.DefaultMuleContextFactory$1.configure(DefaultMuleContextFactory.java:84) org.mule.context.DefaultMuleContextFactory.doCreateMuleContext(DefaultMuleContextFactory.java:217) org.mule.context.DefaultMuleContextFactory.createMuleContext(DefaultMuleContextFactory.java:76) org.mule.tck.junit4.AbstractMuleContextTestCase.createMuleContext(AbstractMuleContextTestCase.java:234) org.mule.tck.junit4.AbstractMuleContextTestCase.setUpMuleContext(AbstractMuleContextTestCase.java:143) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:46) org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28) Caused by: org.mule.api.lifecycle.InitialisationException: Unexpected exception parsing XML document from URL [file:/Users/pablokraan/devel/workspaces/muleFull/mule/modules/db/target/test-classes/integration/template/cdata-template-query-config.xml]; nested exception is org.mule.module.db.internal.parser.QueryTemplateParsingException: SQL text cannot be empty org.mule.registry.AbstractRegistry.initialise(AbstractRegistry.java:113) org.mule.config.spring.SpringXmlConfigurationBuilder.createSpringRegistry(SpringXmlConfigurationBuilder.java:133) org.mule.config.spring.SpringXmlConfigurationBuilder.doConfigure(SpringXmlConfigurationBuilder.java:88) org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:43) ... 17 more Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from URL [file:/Users/pablokraan/devel/workspaces/muleFull/mule/modules/db/target/test-classes/integration/template/cdata-template-query-config.xml]; nested exception is org.mule.module.db.internal.parser.QueryTemplateParsingException: SQL text cannot be empty org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:412) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174) org.mule.config.spring.MuleArtifactContext.loadBeanDefinitions(MuleArtifactContext.java:106) org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537) org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:451) org.mule.config.spring.SpringRegistry.doInitialise(SpringRegistry.java:86) org.mule.registry.AbstractRegistry.initialise(AbstractRegistry.java:105) ... 20 more Caused by: org.mule.module.db.internal.parser.QueryTemplateParsingException: SQL text cannot be empty org.mule.module.db.internal.parser.SimpleQueryTemplateParser.doParse(SimpleQueryTemplateParser.java:101) org.mule.module.db.internal.parser.SimpleQueryTemplateParser.parse(SimpleQueryTemplateParser.java:61) org.mule.module.db.internal.config.domain.query.QueryTemplateBeanDefinitionParser.parseParameterizedQuery(QueryTemplateBeanDefinitionParser.java:154) org.mule.module.db.internal.config.domain.query.QueryTemplateBeanDefinitionParser.doParse(QueryTemplateBeanDefinitionParser.java:67) org.mule.config.spring.parsers.AbstractMuleBeanDefinitionParser.parseInternal(AbstractMuleBeanDefinitionParser.java:297) org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59) org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73) org.mule.config.spring.MuleHierarchicalBeanDefinitionParserDelegate.parseCustomElement(MuleHierarchicalBeanDefinitionParserDelegate.java:85) org.mule.config.spring.MuleHierarchicalBeanDefinitionParserDelegate.parseCustomElement(MuleHierarchicalBeanDefinitionParserDelegate.java:127) org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1428) org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:190) org.mule.config.spring.MuleBeanDefinitionDocumentReader.parseBeanDefinitions(MuleBeanDefinitionDocumentReader.java:51) org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140) org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:111) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) ... 29 more | 1 |
| 302 | MULE-7520 | Avoid writing app log entries in container log file when not using an specific log4j config file for the app. | When a log4j config file is not attached to an app, a default file appender is created but the app is still sending its output to the container log file. App default logging should only send app logs to default app log file. | 3 |
| 303 | MULE-7524 | Encoded characters not working when using expressions for dynamic endpoints | When using encoded characters (e.g. %40 for @) in conjunction with expressions it fails. For example this works: <sftp:outbound-endpoint user="testuser" password="mule%40123" path="/Users/testuser/tmp/" host="localhost" port="22" outputPattern="file.txt" /> But this doesn't: <sftp:outbound-endpoint user="testuser" password="mule%40123" path="/Users/testuser/tmp/#[header:targetSubDir]" host="localhost" port="22" outputPattern="file.txt" /> Attached there's a project with a test case to reproduce this problem. | 3 |
| 304 | MULE-7530 | Create OOTB database connector for IBM DB2 | Create OOTB database connector for IBM DB2 | 8 |
| 305 | MULE-7536 | Mule is still creating old default domain classloader instead of using new one | Mule still has the lib/shared/default folder. This causes to use the old domain class loader infrastructure instead of the new one. This folder must be removed and a default folder must be created in domains. | 3 |
| 306 | MULE-7538 | Application fails to start when having 16 or more connectors with asynch reconnection that fail to connect | The problem is that the work manager used for reconnection is the one defined inside the DefaultMuleContext. This work manager is not configurable so it can handle 16 threads at most. The problem is that when a reconnection fails all the time uses 1 of the threads. So if you have more than 16 reconnections going on the number 17 will never get the chance to execute. | 1 |
| 307 | MULE-7540 | Migrate snapshot repositories to mulesoft.org | Migrate snapshot repositories from codehaus to mulesoft.org repositories | 5 |
| 308 | MULE-7543 | Deprecate jdbc transport | Due the creation of the new DB module, we should deprecate the old jdbc transport as studio has already done. | 1 |
| 309 | MULE-7544 | Change derby config to use embedded driver by default | Current version of derby-config element uses standalone derby driver by default, but derby is mostly used to make quick tests, so using the embedded driver is a better choice. | 1 |
| 310 | MULE-7548 | Lifecycle does not start a QueueManager in the right order | QueueManager must be started before any Flow. That's not happening for all QueueMAnager, it's only happening for TransactionalQueueManager | 3 |
| 311 | MULE-7556 | Add OOTB support in new DB connector for TRUNCATE operation | OOTB users have to use a DELETE statement if they need to purge a table, which is way less efficient than TRUNCATE. Supporting TRUNCATE is important for our ETL story. | 8 |
| 312 | MULE-7559 | Mule build reactor is building embedded distribution before other modules | Mule Embedded distribution is being build before modules and transports that are in it, so, build is failing. | 3 |
| 313 | MULE-7571 | Persistent queue logs and data remove after shutdown | After mule shutdown mule queues logs and data are being removed. The problem is that dispose of the queue manager is removing everything. There's a another issue to solve which is that during undeploy of an app, the app data store in .mule/app-name folder is not being cleared. There seems to be two kind of dispose needed. One for undeploy of an app. And another just for shutting down the server. | 3 |
| 314 | MULE-7574 | Possible contention on DefaultStreamCloserService. | When running a batch job(ee feature), it was seen that periodically the threads gets locked as shown into the given stack-trace. We should add a way to improve this with a cache or another work-arround. | 1 |
| 315 | MULE-7575 | Aggregator result has invalid session variables values | When using a persistent store in an aggregator the session variables values do not have the latests value after the message aggregation. We should prioritise latest stored event session variables values over the ones provided by previous events. If not when execution inside a collection splitter and aggregator is synchronous the merge of the mule events results in a session with not the latests values. | 3 |
| 316 | MULE-7577 | OAuth regression - RC1 OAuth connectors not working at all | I found the issue in the org.mule.security.oauth.util.HttpUtilImpl#post(String, String) method. The refactor made to improve the exception error (MULE-7521) modified the way of working with the OutputStreamWriter (look for "out" variable). After doing the #write(String) there is no flush(), hence the stream is not filled with the API response, and the response is always an error. The code is: {code} //.. try { out = new OutputStreamWriter(conn.getOutputStream()); out.write(body); int responseCode = conn.getResponseCode(); //.. } //.. {code} when it should be {code} //.. try { out = new OutputStreamWriter(conn.getOutputStream()); out.write(body); out.flush();//magic happens here int responseCode = conn.getResponseCode(); //.. } //.. {code} This should solve all the issues with OAuth support for DevKit connectors. | 1 |
| 317 | MULE-7578 | Improve HttpUtilTestCase | HttpUtilTestCase passes regardless HttpUtilImpl flushes the output stream or not, which caused a bug. That test/functionality should be improved | 2 |
| 318 | MULE-7617 | Design a stable API so that extensions can be added to the ESB | This involves designing a stable API that can be used to create ESB extensions. The initial scope of extensions will be operation blocks that represent an arbitrary operation on the payload. The goal of this API is to isolate any such extension as much as possible from the ESB classes, allowing to specify operations at an abstract level, that can be automatically mapped to XML constructs in an automated fashion, and provides enough metadata so that both the runtime and tooling can leverage the new operations without further work. This task is exploratory. The scope is to define a small subset of the API, and determine the registration and consumption mechanism as a proof of concept. Note that this API has two different parts, one consumed by extension modules, and one consumed by the ESB/Tools, and we look to provide API stability on both surfaces. | 8 |
| 319 | MULE-7588 | LifeCycle is inconsistent across registries | Because the LifeCycle manager handles individual objects instead of the mule context as a whole, there're differences in how the life cycle is applied to objects in the TransientRegistry in opposition to the ones in the SpringRegistry: * Objects in the TransientRegistry have a correct life cycle * Objects in the Spring registry that were registered by Mule's bootstrap, receive the Start and Stop phases correctly. They don't receive the dispose phase and the init one is invoked by Spring directly as an init-method, not through the life cycle execution. * Because default Spring registry objects don't receive the init through standard life cycle phase, they cannot be started before the TransientRegistry * Objects manually added to the spring registry by an app, don't receive the initialise nor dispose phases * LifeCycle is applied on Spring registry objects once they're all available in the application context. However, objects in the TransientRegistry get their lifecycle as they're registered, making it impossible for component A to reference component B if A is not registered first. This issue greatly depends on MULE-7587 | 13 |
| 320 | MULE-7589 | VM transactions should support multithreading | VM transactions have as a known limitation around concurrency. Only the thread that started the transaction should be able to use it and/or close it. For highly concurrent use cases, it'd be great if scenarios like the following would be supported: Thread 1: Opens transaction A and polls one element from it Thread 2: Opens transaction B over the same queue and polls one element from it Thread 2: writes to the queue in the context of transaction A Thread 1: writes to the queue in the context of transaction B Thread 2: commits/rollbacks the transaction A Thread 1: commits/rollbacks the transaction B | 8 |
| 321 | MULE-7591 | Mule fails to start if UntilSuccessful has a persistent object store with stored events | Consider the attached application. The mule event is persisted successfully when entering the until-successful block but upon an unexpected restart of the mule instance, the message could not be de-serialized again and an error in the logger is displayed with the following line: ERROR 2014-05-07 19:02:19,572 [WrapperListener_start_runner] org.mule.util.store.PartitionedPersistentObjectStore: Could not restore partition under directory /Users/juancavallotti/Documents/MuleEE/EE/mule342/.mule/objectstores/objectstore/d036c03b-d630-11e3-a6c7-ef75e8a7e5bc This happens because when the object store is open, it tries to cache the keys. Because the MuleEvent has a reference to its owning flow construct, a circular reference is created since the deserialized event tries to fetch the flow construct which triggered its loading. Steps to reproduce: Run the attached app and an ActiveMQ instance. Stop activeMQ place a non-empty file in /tmp/test/inbound/1 (you may configure a more convenient folder). stop mule start activemq start mule Observe the logger line Observe that the message that should have been recovered from the persistent object store is not delivered to the broker. Expected behavior: Persistent object store should lazily cache its entry upon its first use. Workaround: Temporal workaround until this gets fixed is to set the lazy-init property to true in the spring bean that creates the object store | 3 |
| 322 | MULE-7593 | Scatter-gather throws IllegalStateException when using only one message processor | Scatter-gather throws IllegalStateException when using only one message processor how to reproduce: deploy attached app and hit http://localhost:8081 | 1 |
| 323 | MULE-7594 | Scatter-gather throws exception when using a one-way outbound endpoint. | Using a one-way outbound endpoint in a scatter-gather with no message processors after it causes an exception. Tried VM and HTTP. I'm attaching the configuration to reproduce the issue. Using a request reply one or adding a message processor after the endpoint fixes it. | 1 |
| 324 | MULE-7596 | Database bulk operations don't work with objects that don't implement Collection | The update bulk operation of the database module fails with collections that implement Collection but not Iterable. This causes a problem with Connector Query results which are usually Iterable or Iterator to allow lazy loading results, yet not implementing the Collection interface. | 1 |
| 325 | MULE-7597 | scatter gather should require at least two routes | Scatter gather should fail at start time it it doens't have at least two routes configured. Having only one route doesn't make sense for a parallel multicast. | 1 |
| 326 | MULE-7599 | Add GPG signature to artifacts | Need to add GPG signature to deploy to Maven Central | 1 |
| 327 | MULE-7608 | New Database: Add support for user defined data types | Add support for user defined data types within new database connector. | 13 |
| 328 | MULE-7611 | MEL expression using dot notation .'variable-name' always returns null if first value at first access is null, even after value changes | The following three logs: <logger message="X-USER-ID (MEL []) = #[message.inboundProperties['x-user-id']]"/> <logger message="X-USER-ID (MEL .) = #[message.inboundProperties.'x-user-id']"/> <logger message="X-USER-ID (OLD) = #[header:INBOUND:x-user-id]"/> consistently work for 1st and 3rd. The second one using the dot notation consistently fails forever if first invocation fails after server restart and consistently succeeds forever if first invocation succeeds after server restart. | 8 |
| 329 | MULE-7612 | Database row handler should use column aliases instead of column names | Every resultset in the database connector is processed using InsensitiveMapRowHandler to covert each resultSet's row into a map. Map is created using each column's name as the key and this creates a problem when a query containg multiple columns with the same name. The solution on SQL side is to use aliases to differentiate each column, so the Database row mapping must use the column aliases instead of the names. | 3 |
| 330 | MULE-7615 | RandomAccessFileQueueStore.getLength() is slow. | The problem is the use of RandomAccessFile.getLength() inside RandomAcccesFileQueueStore. | 3 |
| 331 | MULE-7620 | Define unified way to define the exception handler in execution scopes in mule | Currently exception handler is defined by: - Flow - Transactional scope - Exception strategies - Outbound endpoint (when using LaxAsync) due bug fix. In some places the exception handler is retrieve by doing: event.getFlowConstruct().getExceptionListener() (AsyncInterceptingMessageProcessor). This is bad design because the MuleEvent should not have a reference to the FlowConstruct and the exception handler should not be retrieved from the MuleEvent. The MuleEvent contains dynamic information related to the current message while the exception handler must be defined statically by the flow configuration. The recommendation is that each scope or execution block (new Threads running part of the flow) should have statically defined the exception handler to use. | 13 |
| 332 | MULE-7621 | Review mule logging consistency and analyse the effort to make it consistent and improve underlying technology | We need to review our logs implementation | 13 |
| 333 | MULE-7624 | Fix JMX agent tests in management module | As we changed the management module to run all the tests in the same JVM, a couple of tests failed becuase they create an RMI registry on a fixed port and interfere with each other. Change those tests so that they use a dynamically allocated port and run fine on the same jvm instance | 3 |
| 334 | MULE-7627 | CloserService generates debug log message without checking logger state | If no closer is found for a stream, the StreamCloserService logs a message with debug level, even if the logger is not in debug mode. Additionally, that message contains the stream which in some cases can result in the stream being consumed and/or the thread blocking, as shown in the attached log | 1 |
| 335 | MULE-7631 | CopyOnWriteCaseInsensitiveMap KeyIterator class implementation issue | Due to the way the KeyIterator class is implemented, calling next() followed by remove() removes not the element the iterator "is on", but the following one. In line #181 of the class CopyOnWriteCaseInsensitiveMap, the array is evaluated to the original index, but any subsequent call to remove is performed on the incremented index. | 2 |
| 336 | MULE-7635 | Add capabilities concept into extension API | Add the concept of capabilities and Capable objects into the extensions api. An object is capable if it provides optional support for additional capabilities. A capability is identified by a class type. Implementations are not required to implement any capability at all, even if they support this interface. Capabilities are used to provide a future-proof path to incorporate changes that may otherwise break backwards compatibility. | 1 |
| 337 | MULE-7636 | MuleProcessController default timeout is wrongfully configured | by default it's 0, and it should be something like 60000. | 1 |
| 338 | MULE-7637 | Implement HTTP Outbound performance improvements | We need to implement the changes needed to improve http outbound performance based on the performance outcome for the proxy scenarios. | 8 |
| 339 | MULE-7638 | OOM when recovering VM transactions | When a transactional persistent queue is recovered and the size of the queue doesn't fit into memory then there's an OOM exception trying to recovery the pending transactions. | 8 |
| 340 | MULE-7640 | Add introspection capabilities in the extensions API | Introspection is the capability of an extension to be automatically discovered and described by mule | 8 |
| 341 | MULE-7644 | Upgrade build plans to Java 7 for compilation and test Mule | We are dropping java 6 support in Mule 3.6, so we need to migrate our build plans to compile and test Mule to run on Java 7. We also need to remove the Java 6 builds. | 8 |
| 342 | MULE-7645 | Create Java 8 test build | We need to create builds to run the test suite of Mule on Java 8. This should be Oracle and Open JDK. Review if we should use IBM JDK 8 Beta or wait till it's final. - Create build for Mule Common with Oracle JDK 8 (We need to run Mule Common tests with JDK 8) - Create builds for CE and EE with Oracle JDK 8 - Create builds for CE and EE with Open JDK 8 - Optionally create builds for CE and EE with IBM JDK 8 (currently in beta AFAIK) Consider the possibility of having Mule builds parametrized and configure Java 7 as the default JDK and override with Java 8. | 13 |
| 343 | MULE-7646 | Spike on new HTTP transport underlying technology | We need to do a spike, and validate which underlying technology should be used for the new HTTP transport. | 8 |
| 344 | MULE-7649 | VM persisted messages disappear after an unexpected shutdown. | After an unexpected shutdown, the vm queues continues processing but most messages are lost. Reproduce: - Deploy the app - Send and http request to: http://localhost:8080/vm with the required headers, as an example: ammount=10000, recordSize=2K - Wait for "all persisted" message shown in the app logs. - Kill the instance using kill -9 pid, using the one returned by "ps -ax | grep 'mule.home=' | grep -v grep | awk '{ print $1}'", not MULE_HOME/bin/mule status wich returns the tanuki pid. - Mule will automatically restart. - Check app logs to see what is processed. Expected: only a few messages are lost, the countdown should get to 1. Actual: only a few messages finishes processing after the restart. | 8 |
| 345 | MULE-7650 | DynamicClassLoader leaking classloaders | Apparently DynamicClassLoader is holding a strong reference to MuleApplicationClassLoader when it should not. This is the GC root path for the leaked MuleApplicationClassLoader instance. {code} org.mule.module.launcher.MuleApplicationClassLoader parent of org.mule.mvel2.optimizers.dynamic.DynamicClassLoader classLoader of org.mule.mvel2.optimizers.dynamic.DynamicOptimizer [603] of java.lang.Object[5120] elementData of java.util.Vector classes of org.mule.module.reboot.MuleContainerSystemClassLoader contextClassLoader of java.lang.Thread [Stack Local, Thread] "Mule.app.deployer.monitor.1.thread.1" native ID: 0x6403 {code} To reproduce deploy any mule app, then undeploy it and check that there is a leaked MuleApplicationClassLoader instance. | 8 |
| 346 | MULE-7651 | Implement plan to improve surfacing of schema reference in documentation | Implementation of Schema Documentation Modernisation Plan articulated here: https://docs.google.com/a/mulesoft.com/document/d/1pLy1BBRQRrzltz-o8PKU9WN1IFEMdGvwkOdabSkRf6s/edit | 13 |
| 347 | MULE-7661 | org.mule.api.security.tls.TlsConfiguration#getSslContext() no longer visible | org.mule.api.security.tls.TlsConfiguration#getSslContext used to have public visibility in mule 3.4.x and was being used from mule extensions. In 3.5.0, it's visibility was reduced to private breaking backwards compatibility with those extensions. The method must be restored as public | 1 |
| 348 | MULE-7663 | tls-default.conf entries are ignored sometimes | When creating a SocketFactory for a https transport, the protocols declared in tls-default.conf are intersected with the default ones from the JDK. Because of this, protocols like SSLv2Hello cannot be enabled when running Mule 3.5.0 in JDK7. What should actually happen is that those protocols should be intercepted against the supported ones. | 5 |
| 349 | MULE-7673 | DatabaseMuleArtifactTestCase broken after maven changes | DatabaseMuleArtifactTestCase was broken by the manven changes related to not forking the JVM anymore when running test. | 5 |
| 350 | MULE-7674 | mule frezes with 100% CPU utilization if accessing property of non-existing property | If flowVars contains no element `user` then expression `#[flowVars['user']['name']]` will freeze mule (thread) eating your CPU @ 100%. | 8 |
| 351 | MULE-7675 | DeploymentService API modification for domains | As a Mule user I would like to: * Deploy a domain with mule API * Undeploy a domain and all its apps * Redeploy a domain and update all the apps | 2 |
| 352 | MULE-7684 | Enable dependency injection on registry elements | Enable dependency injection (leveraging JSR 330 annotation as much as possible) in order to replace lifecycle calls and xxxAware interfaces Design a way for objects that contain other objects that must undergo though DI that doesn't depend on the parent object calling or delegating on each lfecycle hook to the child elements. This will bring either Spring, Guice or Dagger as a core dependency. Keep that dependency as small as possible (i.e. bringing as little modules as needed). Objects should not use container specific annotations (i.e. spring annotations) - when a non JSR330 annotation is needed, create one specific for mule and use it. | 21 |
| 353 | MULE-7687 | mule does not propagate system properties when started with "restart" command | bin/mule restart -M-Ddefault.port=1337 expected: app deployed what happens: deployment error because system properties are not propagated. | 5 |
| 354 | MULE-7688 | Give Extensions API the ability to automatically provide XML config support | We need a new component in the Extensions API which uses the introspection API already developed and: Hooks from the compile phase and automatically generates the XSD Provides a generic BeanDefinitionParser capable of parsing any extension | 21 |
| 355 | MULE-7691 | Revise xml libraries bundled in mule in a jdk7 environemnt | As we bumped the required jdk version to java 7, it may be necessary to revise if these libraries are needed at all (as they are included in the jdk): jaxb-api-2.1.jar jaxb-impl-2.1.9.jar jaxb-xjc-2.1.9.jar | 3 |
| 356 | MULE-7692 | Create way to process JMS messages in a guaranteed order without needing to override a Java class | Several customers want to know how they can enable message sequencing in MuleESB (making sure that inbound messages are delivered in the same order to the various endpoints in a flow). Using the resequencer is not a pattern as the number of messages could be infinite. There is currently no way to do this in a cluster. You can however extend the message receiver in the JMS transport. Albin did this for Boeing and they seemed satisfied with the solution. https://github.com/albinkjellin/jms-single-consumer We should implement this, or a more elegant version of it, in the product itself. | 8 |
| 357 | MULE-7697 | com.arjuna.ats.arjuna.exceptions.ObjectStoreException when executen esireferenceimplementation on windows | how to verify: execute in windows: mvn clean verify -fae -Psystem -Dmule.timeout=120000 -Dwmq.host=wmq7vm.mulesoft.com -Dwmq.port=1422 -Dwmq.queue.manager=QM_QA -Dwmq.queue.in=IN -Dwmq.queue.out=OUT -Dwmq.username=mqm -Dwmq.password= -Dtest.timeout.sec=60000 -nsu on directory tests/system/referenceimplementation and check mule logs (log into 172.16.20.25 and go to C:\ee\tests\system\referenceimplementation) this worked before the fix made on https://www.mulesoft.org/jira/browse/MULE-7590 | 5 |
| 358 | MULE-7701 | Fix flacky test UntilSuccessfulTestCase.testPermanentDeliveryFailureDLQ | Fails on CI with message: Error Message Wanted but not invoked: outboundEndpoint.process(<any>); -> at org.mule.routing.UntilSuccessfulTestCase.testPermanentDeliveryFailureDLQ(UntilSuccessfulTestCase.java:193) Actually, there were zero interactions with this mock. Stacktrace Wanted but not invoked: outboundEndpoint.process(<any>); -> at org.mule.routing.UntilSuccessfulTestCase.testPermanentDeliveryFailureDLQ(UntilSuccessfulTestCase.java:193) Actually, there were zero interactions with this mock. org.mule.routing.UntilSuccessfulTestCase.testPermanentDeliveryFailureDLQ(UntilSuccessfulTestCase.java:193) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:606) org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:46) org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28) Standard Output ================================================================================ = Testing: testPermanentDeliveryFailureDLQ = ================================================================================ | 5 |
| 359 | MULE-7703 | Add a way to configure default threading profile | Default threading profile configuration is hardcoded in org.mule.api.config.ThreadingProfile. Having a way to configure this value per server will be useful to set a different default threading profile per distribution. | 3 |
| 360 | MULE-7704 | DB connector fails to create a pooled connection when DB driver is deployed in the mule application | DB connector uses C3P0 in order to provide connection pooling. When a pooling profile is used, the driver must be deployed on the mule server, otherwise the pool will be unable to create connections. To reproduce, create an application with the attached config and copy the mysql driver inside the app/lib folder. Then hit http://localhost:8081 and get the attached exception. | 5 |
| 361 | MULE-7706 | Provide support for RedHat KIE technologies (jBPM and Drools version 6) | Create a new module to provide support for Drools and JBPM version 6. | 13 |
| 362 | MULE-7710 | Optimize default wrapper.conf | For every perf run I made, I turn on verbose GC, set it to 2GB, and occasionally switch it to CMS GC. Let's consider putting these in. We could add them in and comment them out by default. e.g. wrapper.java.additional.4=-XX:+PrintGCApplicationStoppedTime wrapper.java.additional.5=-XX:+PrintGCDetails wrapper.java.additional.6=-XX:+PrintGCDateStamps wrapper.java.additional.7=-XX:+PrintTenuringDistribution wrapper.java.additional.8=-XX:ErrorFile=%MULE_HOME%/logs/err.log wrapper.java.additional.9=-Xloggc:%MULE_HOME%/logs/gc.log wrapper.java.additional.10=-XX:+HeapDumpOnOutOfMemoryError wrapper.java.additional.11=-XX:+AlwaysPreTouch wrapper.java.additional.12=-Xms2048m wrapper.java.additional.13=-Xmx2048m #wrapper.java.additional.14=-XX:+UseConcMarkSweepGC #wrapper.java.additional.15=-XX:SurvivorRatio=16 #wrapper.java.additional.16=-XX:CMSInitiatingOccupancyFraction=65 #wrapper.java.additional.17=-XX:NewSize=1024m #wrapper.java.additional.18=-XX:MaxNewSize=1024m #wrapper.java.additional.19=-XX:PermSize=128m | 2 |
| 363 | MULE-7715 | Support XML definition of Beans in extensions configurations | Some extensions make use of beans on their configuration. It should be possible to create those beans directly on the config definition without the need of defining a spring bean. At the same time, the same extension mike take lists or sets of beans. Those should be supported also. For example, assuming that the heisenberg extension has a configuration Bean of type Door, and a list/set of type Ricin. As a user, I should be able to define this: <heisenberg:config> <heisenberg:ricin-packs> <heisenberg:ricin-pack microgramsPerKilo="22"> <heisenberg:destination victim="Lidia" address="Stevia coffe shop" /> </heisenberg:ricin-pack> </heisenberg:ricin-packs> <heisenberg:next-door address="pollos hermanos" victim="gustavo fring"> <heisenberg:previous victim="Krazy-8" address="Jesse's"/> </heisenberg:next-door> </heisenberg:config> | 8 |
| 364 | MULE-7716 | Generated XSD for Mule extensions should include map class javadocs to schema documentation | When Extension XSD is generated in the compile phase, it should be possible to use an annotation scanner to extract the extension's javadocs to use them as schema documentation. It is acceptable for this to not happen when building the schema for test case purposes | 8 |
| 365 | MULE-7718 | Add test support for extensions | Need test infrastructure for extensions, so that we can guarantee that * the extensions manager will be available every time it's needed an * The xsd is regenerated on each run so that a developer doesn't need to do so automatically every time | 5 |
| 366 | MULE-7719 | Create parent module for extensions | Create a parent artifact for extensions to agglutinate all the created extensions. The purpose of this parent artifact is not only about organising modules, it's also to define a parent pom which will hook up from the compiling phase to automatically generate the schema definition and spring handlers | 5 |
| 367 | MULE-7720 | Define Extensions execution API | Just like we defined an introspection API for mule extensions, we now need an API to execute operations on those extensions. This task is about defining, designing and documenting that API. Not implementing it. | 13 |
| 368 | MULE-7741 | Add reconnection support for database connector | Add reconnection support for database connector | 8 |
| 369 | MULE-7721 | Create a maven property for groovy-all version | This dependency in pom.xml has a harcoded version, we should use a property. <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>1.8.6</version> And also verify that there is no other places where we use the hardcoded version | 2 |
| 370 | MULE-7723 | Remove unsued configuration builders | We have code to support creating a mule flow / service using a jruby script, groovy or Guice. The actual creating of the script requires advance knowledge of mule internals and it's not useful. Nobody is using it and also we don't support it in our IDE. We should only keep the spring configuration builders | 5 |
| 371 | MULE-7724 | release profile doesn't build javadoc jar | Running {{mvn -P release install}} doesn't build javadoc jars at least for mule-core. It only builds: * mule-core-3.5.1-sources.jar * mule-core-3.5.1-tests.jar * mule-core-3.5.1.jar | 5 |
| 372 | MULE-7730 | Create javadoc jars on the release profile | Currently, we don't create javadoc jars as part of the release profile, requiring us to manually create and deploy them. Modify the build descriptors to create the javadoc files for each module. Note that besides this, there must still be a way to create the aggregated javadocs to be published online. | 3 |
| 373 | MULE-7731 | JMS transport should reuse javax.jms.Session, javax.jms.MessageProducer instances by default | All Mule JMS transport must reuse javax.jms.Session, javax.jms.MessageProducer by default without relying on a specific connection factory implementation. | 3 |
| 374 | MULE-7733 | jms:caching-connection-factory should be deprecated for 3.6 | <jms:caching-connection-factory> should be deprecated, unless there is another reason to keep this but this element must continue to be fully supported in config in 3.6 | 3 |
| 375 | MULE-7736 | Ensure internal SEDA queues are bound by default to avoid OutOfMemoryException's | A default size for maxQueueSize must be defined, at least for the case where the queue is in-memory. We need to determine if: i) this default is best defined on the processing strategy or object store. ii) if it’s best to use a static default, or if it is best to determine the default based on heap size or some other parameter. In ii), a related concern to keep in mind here is whether or not we can have a mechanism for Mule self-tuning that we can include as EE-only. | 3 |
| 376 | MULE-7740 | Bundle scripting pack with Mule CE by default | Mule CE currently doesn't bundle the scripting libraries (i.e. Jython) by default. Instead, users have to download a separate scripting pack: https://repository.mulesoft.org/nexus/content/repositories/releases/org/mule/distributions/mule-scripting-pack/3.5.0/mule-scripting-pack-3.5.0.zip We should evaluate whether or not it is feasible/practical to bundle this scripting pack together with the base Mule CE build, and do so if seen fit. The Mule EE distribution currently comes with these scripting libraries bundled with the deistribution afiak. | 5 |
| 377 | MULE-7744 | Update all-modules, all-transports and all-examples dependencies | all-modules, all-transports and all-examples are Maven modules aggregating several Mule ESB submodules. But are not up to date. We need to update their dependency list to solve this problems: h3. Modules not in all-modules * guice * launcher * logging * reboot h3. Transports not in all-transports * axis h3. Examples not in all examples * errorhandler * geomail * loanbroker-bpm * loanbroker-legacy * notifications | 2 |
| 378 | MULE-7748 | Seda queues with persistent profile fail in Windows | When using a queue asynchronous with a persistent queue store, and when using windows it fails because the name of the file to store the queue data is invalid. See: http://forum.mulesoft.org/mulesoft/topics/anypoint_studio_default_persistent_queue_store_java_io_ioexception_the_filename_is_incorrect | 5 |
| 379 | MULE-7751 | Update maven-deploy plugin to 2.8 | Artifact deployment repo is defined in the distributionManagement section of the mule main pom.xml file. Sometimes we need to stage changes in other repositories in order to make tests that do not affect the rest of the community. The maven deploy plugin provides a way to override the deployment repo, but only in version 2.8 it allows specifying separate snapashot and release repos. | 3 |
| 380 | MULE-7753 | Remove maven archtetypes and ant tools | Remove Maven archetypes, archetype tests and bobberplus (archetype builder). Transport, Module, Catalog, Patterna rchetypes are outdated and unmaintained. Application archetype has evolved into it's own project in AppKit. | 3 |
| 381 | MULE-7755 | Remove patterns | Remove patterns and pattern support for Mule 4. They are too complex to create an maintain, and we strive to replace them with a simpler scheme. - Check parent pom, all-modules, all-transports - Check impact in XML (if the module added XML syntax, document that those elements will not be supported anymore) - Check assemblies (CE and EE) - Check dependencies from integration and functional tests - Make sure to create the PR to be merged in mule-4.x branch | 8 |
| 382 | MULE-7756 | Remove guice module | The guice module has not gained much traction, and as we redesign the Inversion of Control across mule-core, we wil revise IoC containers again. | 5 |
| 383 | MULE-7757 | Remove OGNL module | The module has not been maintained and it's functionality overlaps with MEL. We should deprecate it in 3.6 and remove it in Mule 4 - Check parent pom, all-modules, all-transports - Check impact in XML (if the module added XML syntax, document that those elements will not be supported anymore) - Check assemblies (CE and EE) - Check dependencies from integration and functional tests - Make sure to create the PR to be merged in mule-4.x branch | 5 |
| 384 | MULE-7758 | Remove SXC module | Deprecate the module in 3.6 and remove it in Mule 4.0 Document functionality removed. - Check parent pom, all-modules, all-transports - Check impact in XML (if the module added XML syntax, document that those elements will not be supported anymore) - Check assemblies (CE and EE) - Check dependencies from integration and functional tests - Make sure to create the PR to be merged in mule-4.x branch - Log in NamespaceHandler a deprecation message telling how to replace it. - Log in module classes a deprecation message telling how to replace it. - Create a DOCS JIRA - Create a Studio JIRA | 5 |
| 385 | MULE-7759 | AMQP transport. Define specs document. | AS A product owner or community member I WANT to be able to review the specs SO THAT I can and contribute with my feedback | 8 |
| 386 | MULE-7760 | AMQP transport. Define connector schema | AS A user I WANT I want to be able to rely on a defined schema to write my AMQP integrations SO THAT I have exact knowledge of how I’m syntactically supposed to use the transport and to have help from my IDE to autocomplete and detect errors. | 8 |
| 387 | MULE-7761 | AMQP transport. Create connector skeleton. | AS A developer I WANT I want to have a base project skeleton SO THAT there is a basement to build on with agreed placeholders for endpoints, connectors, transactions that should be stable. | 8 |
| 388 | MULE-7762 | AMQP transport. Create configuration element (connector). | AS A user I WANT I want to be able to configure the transport in a single point SO THAT I can configure the common transport attributes in a single reusable place | 8 |
| 389 | MULE-7763 | AMQP transport. Create inbound receiver (consume) | AS A user I WANT I want to be able consume continuously amqp messages SO THAT a MuleEvent is created and delivered to a flow when a messages arrives to a queue and is comsumed | 8 |
| 390 | MULE-7764 | AMQP transport. Create inbound requestor (request) | AS A user I WANT I want to be able consume instantly amqp messages SO THAT I can consume messages at any point of the flow | 5 |
| 391 | MULE-7766 | AMQP Transport. Integration testing. | AS A user I WANT I want the transport to be tested against a real broker and a real application. SO THAT I can be sure the transport works on real world usage. | 8 |
| 392 | MULE-7769 | Implement log4j2 on Mule | We need to upgrade to log4j2 ir oder to leverage the performance improvements of asynchronous logging. | 21 |
| 393 | MULE-7771 | Fix DateTimeTimeTestCase.seconds flakyness. | This test is flaky. | 5 |
| 394 | MULE-7772 | Create script for uploading to Maven Central | Upload the script to upload to maven central. | 1 |
| 395 | MULE-7777 | Add GPG Maven Plugin to Mule Common | Add the plugin, default skipping signature and configure release build plan to enable GPG signature. | 3 |
| 396 | MULE-7783 | AMQP transport. Receive and incorporate spec feedback. | AMQP transport. Receive and incorporate spec feedback. | 8 |
| 397 | MULE-7787 | Do performance testing of log4j2 implementation | MULE-7769 implemented asynchronous logging through log4j2. Please do performance testing over it | 5 |
| 398 | MULE-7788 | Create automated tests for log separation | MULE-7769 revamped mule's logging infrastructure. This code already contains some unit tests about its behavior, but actually verifying that 2 apps deployed in mule have their logs separated, that they are properly rolled over, etc requires an external system test | 8 |
| 399 | MULE-7789 | Update mule-transports-http to tomcat 6+ | PR-514 mule-transports-http depends on tomcat 5.5.23 for cookie processing. Upgraded to tomcat 6 version used by mule elsewhere using ${tomcatVersion}. Tomcat moved this into coyote. Verified working in tomcat 6+. Defaulted httpOnly to false in this instance since it was not part of tomcat 5 and not part of cookie from commons-httpclient and thus was naturally already false. In tomcat 6, httpOnly is configurable and default in tomcat 7+. This seemed most appropriate way to get onto tomcat 6+ as tomcat 5 is end of life and solved use case we had running mule within tomcat 7 & 8. See pull request on github PR #514, jira request Mule-6705, and jira request Mule-5100. | 8 |
| 400 | MULE-7796 | IllegalArgumentException when trying to load external query | When trying to load an external SQL Query within the new database connector with the following config {code} <db:template-query name="Template_Query" doc:name="Template Query"> <db:parameterized-query file="myquery.sql" /> </db:template-query> {code} I get the attached stacktrace. | 3 |
| 401 | MULE-7797 | ArrayIndexOutOfBoundsException when mixing the order of in/out parameters in DB module. | When mixing the order of in-out parameters on a stored procedure call, the module throws an ArrayIndexOutOfBoundsException. Please look at the following post to get more insight on the issue: http://forum.mulesoft.org/mulesoft/topics/stored_procedure_with_two_out_param_using_database_connector The sample configuration that is failing is the following one: <db:stored-procedure config-ref="Oracle_Database_Configuration_Just_append_To_Or_Something" doc:name="Oracle CSP Database"> <db:parameterized-query><![CDATA[call PKG_LOCATION.P_LOAD_MEETINGS(:P_CLIENT_NO, :P_ZIP, :P_PAGE_NUMBER, :P_PAGE_SIZE, :P_TOTAL_RECORDS, :P_SITE_ID, :OUT_CURSOR)>]]></db:parameterized-query> <db:in-param name="P_CLIENT_NO" type="NUMERIC" value="59616"/> <db:in-param name="P_ZIP" type="VARCHAR" value="10010"/> <db:in-param name="P_PAGE_NUMBER" type="NUMERIC" value="1"/> <db:in-param name="P_PAGE_SIZE" type="NUMERIC" value="1"/> <db:out-param name="P_TOTAL_RECORDS" type="NUMERIC"/> <db:in-param name="P_SITE_ID" type="NUMERIC" value="1"/> <db:out-param name="OUT_CURSOR"/> </db:stored-procedure> | 3 |
| 402 | MULE-7800 | Deployment service does not update app status after deployment failure | Deploy and application (as attached). Call the deployment service to list the applications (deploymentService.getApplications()) The app I just deployed status is CREATED. This is a problem to notify the deployment status on an app on any administration console. If an app could not be deployed the status should be failed or it should be destroyed so administration consoles (CH, Hybrid or any user script on top of the mule agent) can identify a failure scenario | 8 |
| 403 | MULE-7807 | Running unit tests on clean working directory with an empty repository fails because missing jar | {code} git co git@github.com:mulesoft/mule.git cd mule mvn -Punit -Dmule.test.timeoutSecs=30 {code} This fails because unpacking embedded distribution dependencies is binded to generate-sources phase, but jars are still not available (because we are running test phase). Apparently Maven dependency plugin when jar is not available and has to resolve the dependency, resolves the artifact file as the classes directory for the dependency, so every file in that module is available to the current module. As we are trying to unpack it fails because the classes directory is not a jar file. | 3 |
| 404 | MULE-7809 | Remove incorrect assertion from Test createHttpServerConnectionWithHttpConnectorProperties | Test org.mule.transport.http.HttpServerConnectionTestCase.createHttpServerConnectionWithHttpConnectorProperties asserts that socket packet size is set on a newly created socket to the value specified by configuration. But the value as specified by the JDK documentation is just a suggestion, and the test is currently failing on CI: org.mule.transport.http.HttpServerConnectionTestCase.createHttpServerConnectionWithHttpConnectorProperties Error Details expected:<1024> but was:<1148> Stack Trace java.lang.AssertionError: expected:<1024> but was:<1148> org.junit.Assert.fail(Assert.java:93) org.junit.Assert.failNotEquals(Assert.java:647) org.junit.Assert.assertEquals(Assert.java:128) org.junit.Assert.assertEquals(Assert.java:472) org.junit.Assert.assertEquals(Assert.java:456) org.mule.transport.http.HttpServerConnectionTestCase.createHttpServerConnectionWithHttpConnectorProperties(HttpServerConnectionTestCase.java:263) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:606) org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:46) org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28) Standard Output ================================================================================ = Testing: createHttpServerConnectionWithHttpConnectorProperties = ================================================================================ | 3 |
| 405 | MULE-7810 | Functional test not ran when outside test/functional directory | When I try to run FileReceiverMoveDeleteTestCase test from root directory it fails because the test is not found, but when I run it from transports/file it runs fine. Using this command: {{mvn test -Pfunctional -Dtest=FileReceiverMoveDeleteTestCase}} | 3 |
| 406 | MULE-7811 | Clean up opensource AMQP connector | Old AMQP transport should be clean up, current issues fixed, current pull requests merged/refused. | 13 |
| 407 | MULE-7817 | ClassLoader leak due to wrong use of DEFAULT_THREADING_PROFILE | MuleWorkManager is created based on the DEFAULT_THREADING_PROFILE. Because that default threading profile implements MuleContextAware, it ends up holding a reference to the application's muleContext. This causes the muleContext not to be collected and ultimately the classLoader is not collected. DEFAULT_THREADING_PROFILE should never be assigned directly. Only copies should be used. | 4 |
| 408 | MULE-7818 | Logging infrastructure should not keep a reference to any classloaders | No logging context should keep a reference to any classloader object. Otherwise, that classloader will fail to be collected if the logger is held on a static field | 4 |
| 409 | MULE-7823 | App with a jetty config fails to deploy when using log4j2 implementation for login. | When deploying an app that has a jetty endpoint/configuration, it fails to be deploy. Replacing the jetty endpoint with http and deleting its configuration enables to app to be successfully deployed. App that reproduced the issue is attached. | 8 |
| 410 | MULE-7829 | upgrade log4j2 version to 2.0.2 | log4j 2.0.2 was release and it contains some fixes, some of which we requested. We should upgrade | 3 |
| 411 | MULE-7832 | Create jar for Maven plugin | Create jar library for new Maven plugin that contains logic for creating zip files. The jar will take compiled classes and resources files, and create the deployable zip. This jar will/should be used by Studio. | 5 |
| 412 | MULE-7833 | Ensure that Maven plugins for Development & QA are compatible | We currently have the muleesb-maven-plugin and the appkit plugins. We should make sure these plugins fit well together in the complete SDLC. | 3 |
| 413 | MULE-7835 | Release appkit project (Mule ESB Maven Tools) | Release Mule ESB Maven Tools project to the community. | 5 |
| 414 | MULE-7836 | Create Mule ESB Maven Tools Project | Move/rename appkit to Mule ESB Maven Tools See EE-3893 for justification. | 2 |
| 415 | MULE-7840 | Upgrade JUnit version to 4.11 | This means getting hamcrest upgraded to 1.3. It requires using mockito-core instead of mockito-all and depends on whether anything breaks here since mockito is using hamcrest 1.1. | 8 |
| 416 | MULE-7843 | Allow extensions code to be splitted in several units | As described in the execution section of the spec, a extension's developer needs to have the option to spread the configurations and operations across several classes which instances have their own lifecycle. | 8 |
| 417 | MULE-7845 | Basic functionality for new HTTP Connector - Outbound part | We need to implement the basic functionaility for doing http request calls. This includes: - http request global config - http request operation - http request builder - http request basic authentication and digest authenticaton - message mapping form Mule Message to HTTP request - message mapping from HTTP response to Mule Message | 21 |
| 418 | MULE-7846 | Fix cloudbees builds - part 1 | Define how to work with repos. Fix disk size problem. Works issues to replace Bamboo with Cloudbees | 21 |
| 419 | MULE-7848 | VM fails in getSize() when log level = DEBUG | While trying to debug an issue with Batch I set the log level to "DEBUG" and this prevented the application from working at all. Attached you will find an application to reproduce it. Simply import the app in Studio, run it and hit the endpoint http://localhost:9000/test If you either remove the log4j.properties file or set the level to INFO it works fine. I checked the code and it's triggered from line 64 in org.mule.util.queue.DualRandomAccessFileQueueStoreDelegate: {code} if (logger.isDebugEnabled()) { logger.debug(String.format("Queue %s has %s messages", queueName, getSize())); } {code} This results into this when level = DEBUG: {code} java.lang.NullPointerException org.mule.util.queue.DualRandomAccessFileQueueStoreDelegate.size(DualRandomAccessFileQueueStoreDelegate.java:143) org.mule.util.queue.AbstractQueueStoreDelegate.getSize(AbstractQueueStoreDelegate.java:153) org.mule.util.queue.DualRandomAccessFileQueueStoreDelegate.<init>(DualRandomAccessFileQueueStoreDelegate.java:66) {code} | 8 |
| 420 | MULE-7847 | Upgrade JSCH to version 0.151 | "Verify:false" exception is still encountered in Mule 3.5.1 with Jsch 0.150, according to their release note it may require version 0.151 http://www.jcraft.com/jsch/ChangeLog Australian Post is still in 3.4.0 and has reported this issue(https://na6.salesforce.com/5008000000ZO4Qe), I have tried to use loader.override to include jsch 0.151 in the application but "verify:false" exception is still sporadically encountered during the load test. If I replace the jsch.jar to 0.151 in /lib/opt, then the issue seems to be resolved. I have run the load test for an hour and I did not encounter the exception. Please advise 1. Is there any impact to upgrade jsch jar to 0.151 in Mule's default distribution? 2. Is there any way to patch the issue without replacing the jsch.jar from <Mule_Home>/lib/opt? We would need to patch both the standalone and cloudhub deployment runtime. Some other customers in Cloudhub are also heavily using SFTP, they can't replace the jsch jar in the Cloudhub runtime themselves. Many thanks! | 8 |
| 421 | MULE-7979 | Deployment Service tracks applications before they are successfully deployed | Deployment service tracks applications as deployed before they have actually been deployed. This leads to retrieving an application from the list that has a context which has not been initialized yet or even that failed to deploy. In gateway we are retrieving all applications with getApplications, and verifying that the muleContext is not null. | 1 |
| 422 | MULE-8003 | Register core extensions as domain deployment listeners if it applies | When a core extension is initialized, if it implements the DeploymentListener interface, it's added to the collection of deployment listeners but not to the collection of domain deployment listeners. In the Gateway we are registering the core extensions as deployment listeners and setting the endpoint message notification on the context when the mule context creation notification is fired, but when the domain's mule context is deployed, the core extensions are not registered as listeners and the notification is never fired. | 5 |
| 423 | MULE-7859 | getApplications() method in MuleDeploymentService should include more apps | The getApplications() method in MuleDeploymentService only returns applications that were successfully deployed or that failed to start. Applications that failed to be installed or initialised are not returned but kept in a zoombies map. This is inconsistent. The method should return all applications for which deployment has been attempted, and per MULE-7800, it should have a status marking which ones failed. This makes for more useful and predictable behaviour while eliminating the need for the zoombies map. Finally, notice that the javadoc for that method says that it only returns deployed applications. That comment does not reflect the actual behaviour of the method not its real intent. That javadoc should be fixed also. | 5 |
| 424 | MULE-7860 | Include muleesb-maven-plugin in mule esb maven tools project | We need to include muleesb-maven-plugin (https://github.com/mulesoft/muleesb-maven-plugin) in mule-esb-maven-tools project. This required: - Review if it should be a separate plugin or can be part of an existent plugin - if it should be a different plugin then: - Finding a good name for the plugin and renaming it. - Review if app deployment to local server should be removed from previous plugin and added to the new one. - Review plugin capabilities - decide if it should be a single plugin or multiple plugins (local standalone, remote standalone, CH, local cluster, remote cluster) - Add documentation by example for every configuration scenario. - Review with Studio team how this plugin can impact Anypoint Studio. - Change group Id, artifact Id, verson and package names according to mule-esb-maven-tools naming conventions. | 8 |
| 425 | MULE-7861 | Document different testing options for Mule Applications and domains. | We need to properly document different testing options for mule apps and domains. This includes: FunctionalTestCase, FunctionalTestCase using domains, FunctionalTestCase using domains and several applications, MUnit, FakeMuleServer tests, Multiprocess unit test, Test against apps deployed in a real container (standalong, CH, cluster). We need to recommend when to use each of them and how to integrate them with maven and CI. | 8 |
| 426 | MULE-7863 | Spike on Extensions API execution model - Part 1 | Do a spike on being able to execute operations through the extensions API | 13 |
| 427 | MULE-7864 | Implement success and failure status codes in the outbound part of the HTTP connector | Implement the success-status-code-validator and failure-status-code-validator elements in the <http:request> element as defined in the spec. | 3 |
| 428 | MULE-7865 | Add support for OAuth in the HTTP connector (Authorization code) | Implement OAuth support for the outbound part of the HTTP connector. Support only the authentication-code grant type for now. | 13 |
| 429 | MULE-7866 | Allow to configure SSL in the outbound part of the HTTP connector | Currently the HTTP connector only supports the <http:ssl-default-config /> element to enable HTTPS requests. Provide a way to configure SSL with more detail in the outbound part, and also consider moving it to the ssl namespace as defined initially in the spec. | 8 |
| 430 | MULE-7867 | Support streaming in the outbound part of the HTTP connector | Add streaming support to the outbound part of the HTTP connector, having the same behavior as the outbound endpoint in the HTTP transport. | 8 |
| 431 | MULE-7868 | Create repo and CI plan for mule artifact builder project | For project created in MULE-7832: - Create a github project - Create a CI plan - Publish the artifact to a repo - Consume the artifact from mule-esb-maven-tools project | 3 |
| 432 | MULE-7869 | Implement composition of request builders in the HTTP connector | Allow to compose many request builders inside a request builder element as defined in the spec. | 5 |
| 433 | MULE-7870 | Be able to provide socket configuration for the outbound part of the HTTP connector | Implement the socket-configuration element inside the request-config to be able to configure the sockets that will be used by the connector. | 8 |
| 434 | MULE-7871 | Spike on NTLM authentication for the outbound part of the HTTP connector | Add support for NTLM authentication in the request-config element. | 8 |
| 435 | MULE-7872 | Create HTTP connector listener | Create HTTP Listener Element. This will be only the listener element without any inner element support. This task includes: - Support for listener XML element. - Mapping from HTTP request to Mule Message - Mapping from Mule Message To HTTP Response | 8 |
| 436 | MULE-7873 | Add support for HTTP Response builder and HTTP Response Error Builder | Add support for HTTP listener child element http response builder and http error response builder. All features from the HTTP connector spec for this elements should be supported. | 8 |
| 437 | MULE-7874 | Add support for HTTP listener config element | Add basic support for HTTP listener global configuration element. This task only includes support for the element and not the inner element. This task also includes HTTP listener element support for referencing a global listener config. | 8 |
| 438 | MULE-7875 | Fix Mule ESB Maven Tools Gaps and issues | Fix Mule ESB Maven Tools Gaps and issues. | 5 |
| 439 | MULE-7876 | Fix cloudbees builds - part 2 | Define how to work with repos. Fix disk size problem. Works issues to replace Bamboo with Cloudbees | 21 |
| 440 | MULE-7877 | Web Service Consumer cannot handle wsdl that import other wsdl that overrides namespace | When using a WSDL file that imports another WSDL file, where in the second one the same namespace is used for a different definition, an error is raised when the WSC is started: {code} java.lang.RuntimeException: org.mule.common.metadata.MetaDataGenerationException: org.apache.xmlbeans.XmlException: error: src-resolve.a: Could not find type 'PatientID@http://tempuri.org/'. Do you mean to refer to the type named PatientID@urn:epicsystems-com:EMPI.2009.Services? java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507) at org.mule.tooling.webservice.consumer.datasense.SOAPMetadataStrategy.getMetadata(SOAPMetadataStrategy.java:54) at org.mule.tooling.webservice.consumer.datasense.SOAPMetadataStrategy.getMetadata(SOAPMetadataStrategy.java:32) at org.mule.tooling.ui.modules.core.metadata.DataSenseEditorController.doUpdate(DataSenseEditorController.java:45) at org.mule.tooling.ui.modules.core.widgets.ClickHandlerRegistry.proceed(ClickHandlerRegistry.java:62) at org.mule.tooling.ui.modules.core.widgets.meta.DefaultDialogController.doUpdate(DefaultDialogController.java:20) at org.mule.tooling.properties.editor.EntityEditPartPropertiesEditor.apply(EntityEditPartPropertiesEditor.java:108) at org.mule.tooling.properties.views.MulePropertiesView$EditorPartListener$1.run(MulePropertiesView.java:634) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3946) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3623) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) Caused by: java.lang.RuntimeException: org.mule.common.metadata.MetaDataGenerationException: org.apache.xmlbeans.XmlException: error: src-resolve.a: Could not find type 'PatientID@http://tempuri.org/'. Do you mean to refer to the type named PatientID@urn:epicsystems-com:EMPI.2009.Services? at org.mule.tooling.webservice.consumer.datasense.RetrieveWsdlMetadataRunnable.run(RetrieveWsdlMetadataRunnable.java:84) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: org.mule.common.metadata.MetaDataGenerationException: org.apache.xmlbeans.XmlException: error: src-resolve.a: Could not find type 'PatientID@http://tempuri.org/'. Do you mean to refer to the type named PatientID@urn:epicsystems-com:EMPI.2009.Services? at org.mule.common.metadata.XmlMetaDataFieldFactory.createFields(XmlMetaDataFieldFactory.java:98) at org.mule.common.metadata.DefaultXmlMetaDataModel.<init>(DefaultXmlMetaDataModel.java:46) at org.mule.tooling.webservice.consumer.datasense.RetrieveWsdlMetadataRunnable.createMetaData(RetrieveWsdlMetadataRunnable.java:92) at org.mule.tooling.webservice.consumer.datasense.RetrieveWsdlMetadataRunnable.loadInputMetadata(RetrieveWsdlMetadataRunnable.java:172) at org.mule.tooling.webservice.consumer.datasense.RetrieveWsdlMetadataRunnable.run(RetrieveWsdlMetadataRunnable.java:70) ... 1 more Caused by: org.apache.xmlbeans.XmlException: error: src-resolve.a: Could not find type 'PatientID@http://tempuri.org/'. Do you mean to refer to the type named PatientID@urn:epicsystems-com:EMPI.2009.Services? at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225) at org.mule.common.metadata.util.XmlSchemaUtils.getSchemaTypeSystem(XmlSchemaUtils.java:34) at org.mule.common.metadata.XmlMetaDataFieldFactory.findRootElement(XmlMetaDataFieldFactory.java:216) at org.mule.common.metadata.XmlMetaDataFieldFactory.createFields(XmlMetaDataFieldFactory.java:89) ... 5 more {code} | 1 |
| 441 | MULE-7878 | Enable TLS protocol versions 1.1 and 1.2 by default | As Mule 3.6 requires Java 7, enable by default protocolo TLS versions 1.1 and 1.2 so that secure socket connections can leverage them. They were not enabled by default due to Java 6 compatibility, which doesn't implement them, but while they are not the default in Java 7, they are always supported. This change will mostly be around setting up the correct definition in tls-default configuration file. | 3 |
| 442 | MULE-7885 | Add support for attachments in the HTTP connector | The new HTTP connector should be able to handle multipart requests. If the Mule message contains outbound attachments, the request should be multipart. If the response is multipart, then the parts should be mapped as inbound attachments in the response. | 8 |
| 443 | MULE-7887 | DEPLOYMENT_FAILED status should be applied to applications that fail to start | The status DEPLOYMENT_FAILED was added per issue MULE-7800. That status is applied to applications that failed to be installed or initialised. The same status should be applied to applications that fail to start. | 2 |
| 444 | MULE-7896 | maven bundle local repository generation | Add description | 8 |
| 445 | MULE-7897 | Test pax-exam using bundle repository | Create a Pax-exam version of FunctionalTestCase in order to run mule tests inside an OSGi container. Detect and report issues and things to improve | 8 |
| 446 | MULE-7899 | Move tests from core/spring-config/vm to the new testing framework as needed | Add description | 13 |
| 447 | MULE-7903 | Fix UntilSuccessfulTestCase flaky test. | We need to fix testSuccessfulDeliveryAckExpression and check for other flaky tests. | 8 |
| 448 | MULE-7909 | No error thrown when FTP inbound attempts to read a file larger than JVM Maxheap | When a FTP inbound connector with streaming="false" tries to read / copy a file on the FTP server that is larger than the available Maxheapsize of the Mule JVM, the file transfer fails - but with no error or warning. My test case. Filezilla FTP Server running on windows, hosting a 750mb file. Mule 3.5.1 running on Mac set to JVM Maxheapsize 512mb. {code:xml} <ftp:connector name="FTP" pollingFrequency="10000" validateConnections="true" doc:name="FTP" /> <file:connector name="File" autoDelete="true" streaming="false" validateConnections="true" doc:name="File"/> <catch-exception-strategy name="Catch_Exception_Strategy1"/> <flow name="14639-large-ftp-amsFlow1" doc:name="14639-large-ftp-amsFlow1"> <ftp:inbound-endpoint host="192.168.150.134" port="21" user="mule123" password="mule123" connector-ref="FTP" responseTimeout="10000" doc:name="FTP"/> <set-variable variableName="thefilename" value="#[message.inboundProperties.originalFilename]" doc:name="Setting filename"/> <logger level="INFO" doc:name="log file name" message="#[flowVars['thefilename']]"/> <file:outbound-endpoint path="/Users/dchan/Downloads" outputPattern="#[flowVars['thefilename']]" responseTimeout="10000" doc:name="File" connector-ref="File"/> </flow> <flow name="14639-large-ftp-amsFlow2" doc:name="14639-large-ftp-amsFlow2"> <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP"/> <set-payload value="PING OK" doc:name="Set Payload"/> <logger message="#[payload]" level="INFO" doc:name="Logger"/> </flow> {code} Mule continuously attempts to copy the file as per the polling frequency. Mule should present either a warning or error when the file transfer fails. Issue is reproducible with both Studio and 3.5.1 Standalone server. In the customers case, they report that their mule application eventually stops processing, potentially because of a lot of files / thread exhaustion. I could not reproduce this in a test environment. Customer is unable to enable streaming due to https://www.mulesoft.org/jira/browse/SE-1204 | 1 |
| 449 | MULE-7912 | Thread exception when registering mule notification listeners | I created an app that contains a bean that registers mule notification listeners. Those listeners log some attributes of the mule message (never write something in the mule message). They might or might not run in a separate thread (that does not make the difference). If that bean is enabled, we get this exception: java.lang.IllegalStateException: Only owner thread can write to message: Thread[pool-12-thread-1,5,main]/Thread[[releasesmoketest-final].automatedRun.stage1.02,5,main] org.mule.DefaultMuleMessage.newException(DefaultMuleMessage.java:1662) org.mule.DefaultMuleMessage.checkMutable(DefaultMuleMessage.java:1648) org.mule.DefaultMuleMessage.assertAccess(DefaultMuleMessage.java:1577) org.mule.DefaultMuleMessage.setExceptionPayload(DefaultMuleMessage.java:999) org.mule.exception.AbstractMessagingExceptionStrategy.handleException(AbstractMessagingExceptionStrategy.java:64) org.mule.execution.HandleExceptionInterceptor.execute(HandleExceptionInterceptor.java:37) org.mule.execution.HandleExceptionInterceptor.execute(HandleExceptionInterceptor.java:14) org.mule.execution.BeginAndResolveTransactionInterceptor.execute(BeginAndResolveTransactionInterceptor.java:54) org.mule.execution.ResolvePreviousTransactionInterceptor.execute(ResolvePreviousTransactionInterceptor.java:44) org.mule.execution.SuspendXaTransactionInterceptor.execute(SuspendXaTransactionInterceptor.java:50) org.mule.execution.ValidateTransactionalStateInterceptor.execute(ValidateTransactionalStateInterceptor.java:40) org.mule.execution.IsolateCurrentTransactionInterceptor.execute(IsolateCurrentTransactionInterceptor.java:41) org.mule.execution.ExternalTransactionInterceptor.execute(ExternalTransactionInterceptor.java:48) org.mule.execution.RethrowExceptionInterceptor.execute(RethrowExceptionInterceptor.java:28) org.mule.execution.RethrowExceptionInterceptor.execute(RethrowExceptionInterceptor.java:13) org.mule.execution.TransactionalErrorHandlingExecutionTemplate.execute(TransactionalErrorHandlingExecutionTemplate.java:109) org.mule.execution.TransactionalErrorHandlingExecutionTemplate.execute(TransactionalErrorHandlingExecutionTemplate.java:30) org.mule.processor.AsyncInterceptingMessageProcessor$AsyncMessageProcessorWorker.doRun(AsyncInterceptingMessageProcessor.java:182) org.mule.work.AbstractMuleEventWork.run(AbstractMuleEventWork.java:36) org.mule.work.WorkerContext.run(WorkerContext.java:286) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:745) | 2 |
| 450 | MULE-7918 | Upgrade Spring to 4.1.1 | Upgrade Spring framework to version 4.1.1 on the mule-4.x development branch. | 8 |
| 451 | MULE-7919 | Upgrade Json Schema validator to support draft-04 rfc | Current validator fully supports json schema draft 03 but has very limited suport of draft 04, besides having several issues fixed in later versions. The update will require changes in mule as the validator was modularized an repackaged in a different way. Check for latest stable version here: https://github.com/fge/json-schema-validator | 8 |
| 452 | MULE-7920 | SimpleLog mode should have custom logic for locating configuration file | OOTB, log4j2 looks for its configuration file using this algorithm: * Scan all classpath looking for file log4j2-test.xml * If not found, repeat looking for log4j2.xml When Mule is running with its default logging infrastructure, this logic is overridden so that the search is not performed on all classpath but: * First on the application classpath * If not found on the domain classpath * If not found, on the configuration folder When running in simple log mode, all of Mule's custom logic is not applied and we fallback to log4j2 default implementation, which causes issues because we cannot guarantee that any other jar in the classpath includes such a file, causing the wrong file to be picked up. When runnning in simple mode, log separation should be disabled but our custom search algorithm should still be applied. Additionally, in both cases we should generate a log line informing the path in which we found the file. | 3 |
| 453 | MULE-7923 | Better support for sequential processing in scatter-gather | Scatter Gather replaces the <all> router which was deprecated in 3.5.0. However, it doesn't behave that well on sequential use cases as its predecesor. That's because if you configure a threading pool of just one, the processing is not sequential just across the routers but across all executions of the flow. Another misbehaving use case is the one in which the routes are extremely fast, like just a couple of ms each. In that case, the overall response gain is lower than the time penalty of managing the threads. To accommodate for these use cases we need to better support the sequential case of scatter gather, its threading profile type should change from asynchronousThreadingProfileType to threadingProfileType. This will enable a doThreading option which when set to false will execute always on the same thread, behaving similar to the old <all> router. | 1 |
| 454 | MULE-7927 | Add helper properties for http listener element | Add http listener helper properties. This properties are created to simplify usability and provide extra information about the processed request. | 8 |
| 455 | MULE-7928 | Add TLS support for HTTP listener | Add support for SSL in new HTTP Connector. | 5 |
| 456 | MULE-7929 | WS Consumer support for using new HTTP Connector | Add support for the new HTTP connector in WS Consumer | 13 |
| 457 | MULE-7931 | HTTP Listener response streaming support | Add support for sending streaming a response in new HTTP Connector. This implies sending Transfer-Encoding: chunck. | 5 |
| 458 | MULE-7932 | Allow to customise protocol in new HTTP Connector | Allow to the user to change the HTTP protocol to use in the new HTTP Connector | 3 |
| 459 | MULE-7930 | Validate HTTP Proxy scenario using new HTTP Connector | Build and validate a template created with http:request and http:listener for a proxy scenario. | 5 |
| 460 | MULE-7946 | Remove dependencies no longer needed with JDK 1.7 | Now that JDK 1.7 is the minimum required JDK version for running Mule, the following dependencies should not be needed anymore: * saaj-api * jaxb-api * jaxb-impl * javax.mail: (including geronimo companion) * jaxb-xjc * retrotranslator * servlet-api * geronimo-jaxrpc_1.1_spec * geronimo-ejb_2.1_spec * geronimo-j2ee-connector_1.5_spec Verify that we can indeed remove these libraries and if so go ahead and take them away from the distribution | 5 |
| 461 | MULE-7947 | Perform spike on upgrading XSLT support | Perform a spike on upgrading our XSLT support by using newer libraries which provide more up to date features and performance. For this spike to be considered successful, we should not only gain in functionality and performance, but we also need to remain backwards compatible with the behaviour of Mule 3.5.x | 8 |
| 462 | MULE-7948 | Perform spike on upgrading XPath function | Perform a spike on upgrading our XPath support following these requirements: * Support Xpath2 * Provide a new xpath2() MEL function which behaves more consistently than its current brother and deprecates it * Can be leveraged to other transformers or elements currently present in Mule (research which ones) * Be backwards compatible with Mule 3.5.x | 8 |
| 463 | MULE-7949 | Upgrade Guava to the v18 | Upgrade Guava to the latest version which at the moment of filing this issue is v18 | 3 |
| 464 | MULE-7950 | Upgrade apache commons libraries to latest versions | The following apache commons libraries can be upgraded. * commons-codec * commons-beanutils * commons-exec * commons-dbcp * commons-net | 5 |
| 465 | MULE-7951 | Upgrade test dependencies | The following libraries are used in our test infrastructure and can be upgraded. * activemq * derby * mockito-core * xmlunit * ftpserver-core * ftplet-api * mysql-connector * postgres * jmockit (check if we really need this one) | 8 |
| 466 | MULE-7969 | Add source and target attributes to the http:request element | The http:request element should have the attributes source and target. Currently the default behavior is to read the body from the payload, and then set the payload with the body of the response. This should be configurable by setting these new attributes. | 8 |
| 467 | MULE-7970 | Add followRedirects attribute to the http:request element | The user should be able to configure in the request element if redirects should be followed or not, as defined in the spec for the new HTTP connector. | 5 |
| 468 | MULE-7971 | Fix flaky test UntilSuccessfulTestCase | org.mule.routing.UntilSuccessfulTestCase.testPermanentDeliveryFailureDLQ was ignored because it was flaky and was making build fail all the time. We need to fix flakiness and remove Ignore annotation. Also check that the rest of the test of this class are not flaky and these tests successfully pass in CI. | 8 |
| 469 | MULE-7972 | Redesign muleContext bootstrapping in OSGi | Current bootstrapping mechanism inspects all available jars searching for bootstrap properties files. That must be modified to work on an OSGi container. In OSGi, bootstrapping should follow white-board model so a bootstrapping service can be used (with no OSGi knowledge) which would enable test running with not container to be able to bootstrap the mule context. | 13 |
| 470 | MULE-7976 | Migrate HTTP Connector to use grizzly | This is just to replace Netty server with Grizzly server. There is going to be a different task for properly configure grizzly server and the execution model. | 5 |
| 471 | MULE-7977 | Add a system property to force a console appender | Add a system property named mule.forceConsoleLog which forces a console appender if one is not already defined on the current log4j configuration. The purpose of this is to enable other products such as Studio to always have a predictable way to capture all the logs of the application regardless (and without tampering with) its configuration. This is something additive to the configuration already present for the application (if any). It doesn't altere the standard configuration selection nor log separation performed in standard mode. the mule.SimpleLog property has precedence over this property. If it is specified, then all the logic described here will not be executed. | 1 |
| 472 | MULE-7982 | AMQP 3.6 for beta final tasks | Things TODO here are: - create updatesite.zip final version RC1 for amqp transport - create amqp-transport.zip final version RC1 for amqp transport - create new update site specifically for beta - http://repository.mulesoft.org/blalblablabla or some url - put amqp connector inside beta update site, and call it "AMQP-0-9 Transport" with version 3.6.xxxxxx - test to make sure new connector install overrides/updates existing connector install - call connector AMQP-0-9 - include the 'beta' tag in the AMQP connector gif/image - make sure Studio team is aware/okay with all of this - release mule-amqp-transport RC1 to Maven Acceptance Criteria: From the private beta portal. As a user I should be able to: - download the updatesite.zip for installing in Studio - download the mule-amqp-transport.zip for installing directly into a Mule ESB instance. For Studio. As a user I should be able to: - download Studio Oct 2014 release - go to Help > Install New Software > - add the beta update site - navigate to the beta update site and see the AMQP-0-9 transport - install the transport in Studio - if an old version of the transport is already installed, a dialog should be shown instructing users that their existing transport will be updated - after installing the transport in Studio, users should see AMQP-0-9 components in the palette, and be able to add those to their Studio flows For standalone. As a user I should be able to: - include the mule-amqp-transport reference in my pom.xml file, which for the beta period will include the RC1 version of the transport in my project | 8 |
| 473 | MULE-7983 | Change DevKit support module to use new http connector | When doing OAuth with Connectors created by DevKit it's possible to define a connector-ref attribute and reference the http:connector that will listen for the OAuth callbacks. This is the way in which current Devkit connectors allow support for https on the callback. This should integrate with the new connector in the following way: * If no connector is specified, we should use the new one with a default config * If no connector is specified, but the useOldHttpTransport configuration flag is turned on, then we default to the old transport * If a connector-ref is specified, then it should show the same behaviour with either the new connector or the old transport | 8 |
| 474 | MULE-7986 | Make sure the new HTTP connector handles 0.0.0.0 and IP endpoints on the same port. | MULE-7985 refers to the old transport, we need to make sure the new connector handles it too. | 8 |
| 475 | MULE-7987 | Upgrade Saxon to 9.6.0.1-HE | Upgrade Saxon in order to get fully compliant 2.0 and basic 3.0 support for XPath, XSLT and XQuery | 8 |
| 476 | MULE-7989 | Discussion on user-managed objectstore to define what is needed | there 3 categories of needs: 1) Using ObjectStore as a user database - with queries, transactions, etc. 2) Using ObjectStore as a user key value store - e.g. for lookup tables, caching, connector oauth tokens, etc 3) Using ObjectStore for application state - e.g. idempotent router, until successful, etc. #1 is NOT a goal and I don't think we should spend a single cycle on this. People can use databases for that. If, at some point, we have time to do this - we can look at it. If anyone feels differently about this, ping me on slack and I can explain in more depth. For #2 and #3, we identified a few areas that need to be addressed. I am summarizing the discussion between Pablo and I, so some of this address part of the solution and not the problem :). I think it's all open for debate FWIW. We need to clarify the semantics around persistence and clustering for ObjectStores. We identified 3 different modes that we need to support clustered + persistent, clustered + non-persistent. Right now, CloudHub implements clustered + persistent, while ESB implements clustered + non-persistent. Either we need to make this more explicit inside the ESB or remove one of the modes. Also, the two different modes have very different availability characteristics on cloudhub, so it's important to know what type of persistence a component is selecting. Partionable object store stuff is currently very messy. it's supposed to be an internal semantic, but it gets exposed to consumers (e.g. routers). ObjectStoreManager shoudl be handling naming/partitioning underneath the covers. If not, this ends up being a layer on top of ObjectStores, and it becomes harder to build a management interface around it. Key-value store use cases require an update method. We need to document the consistency model - e.g. write last wins We need an ObjectStore which can use the new database connector for on-prem customers. We need an easy way for users to specify new object stores via XML which get created via the ObjectStoreManager. Use case here is that I want to specify an objectstore specifically for my cache which has a specified TTL and maximum # of values. I don't believe this is possible right now. (rinse and repeat for any other mule component) Pablo Abad - we didn't talk about #6, but I thought of it while writing this up, so just capturing it. Please let me know your feedback on this. Acceptance criteria: * create jiras for tasks associated to creation of this feature | 8 |
| 477 | MULE-7990 | Create Serialization API | Create a serialization API which replaces direct uses of SerializationUtils. This API will allow applications to specify custom serialization mechanisms. | 5 |
| 478 | MULE-7991 | Migrate HTTP request element to use grizzly | Currently http request element is using jetty. We need to change it to use grizzly. | 8 |
| 479 | MULE-7992 | Change http listener response writing to do streaming | The listener response streaming behaviour is implemented but we still need to write the grizzly response using streaming. This requires some research in grizzly to figure out how to do it. | 3 |
| 480 | MULE-7994 | Add flag to avoid parsing incoming multipart in http listener | For proxy scenarios we need to avoid parsing multipart incoming request. This will also allow to the user to do streaming with multipart. | 3 |
| 481 | MULE-7997 | HTTP response builder is not parsed correctly within flow | response-builder as MP is not working because of the definition parsers. The old new http transport is replacing the old transport definition parser so it's failing. | 8 |
| 482 | MULE-8004 | Remove examples from the distribution | Because we now have examples in Studio and the Mulesoft library, it doesn't make sense to also keep maintaining the examples on the distribution. They should be removed from the distribution and our code base. Notice that before removing them we need to make sure that: * They don't ship with any tests worth keeping (the scripting example has a couple that I'd like to move to the scripting module) * Some system tests use them. We need to make sure they remain available for those testes Keep examples folder with a README file saying that we are not shipping examples anymore (check content with Steven) Fix examples version in QA builds. | 5 |
| 483 | MULE-8006 | Add test cases to validate Content-Type encoding and mule transformations | We need to add test cases that validate mule transformations when receiving a request in http listener and when sending a response. Same with http requester. When Mule receives a request in http:listener, then if the user wants to transform the message to an string we need to do the transformation taking into account the Content-Type header charset (if there's one). Same when sending a response through http:listener and when using the http:request element. | 5 |
| 484 | MULE-8007 | Fix spring-security tests. | There are many tests using static ports in this module. We need to change them for dynamic ones to avoid flakiness. | 3 |
| 485 | MULE-8011 | Module HTTP Listener Connector Request based on path not working fine | When you use a Wildcard to support a pattern in the PATH it's not working fine in these scenarios: For path="/in_wildcard/*" /> 1) It doesn't work consuming it with path="/in_wildcard/" 2) It doesn't work consuming it with path="/in_wildcard/foo1/foo2" (with /in_wildcard/foo1 works fine) If I have another flow in the same app with a path="/in_wildcard/*/subpath1" /> 1) It doesn't work consuming it with path="/in_wildcard/foo1/subpath1" Examples: <flow name="http_listener_test_wildcard"> <http:listener host="localhost" port="8083" path="/in_wildcard/*" /> <set-payload value="TestOK" /> </flow> <flow name="http_listener_test_wildcard_2"> <http:listener host="localhost" port="8083" path="/in_wildcard/*/subpath1" /> <set-payload value="TestOK123" /> </flow> 1) GET Method: http://localhost:8083/in_wildcard/ should return "TestOk" but it doesn't work in that path (STATUS 404 No listener for endpoint: /in_wildcard/) 2) GET Method: http://localhost:8083/in_wildcard/foo1/foo2 should return "TestOk" but it doesn't work in that path (STATUS 404 No listener for endpoint: /in_wildcard/foo1/foo2/) 3) GET Method: http://localhost:9001/in/in_wildcard/foo1/subpath1 should return "TestOk123" but it doesn't work in that path (STATUS 404 No listener for endpoint: /in_wildcard/foo1/subpath1) | 5 |
| 486 | MULE-8013 | Support keepAlive for persistent connections in HTTP Connector | We need to support persistent connections, both for listener and request in the new connector. | 8 |
| 487 | MULE-8015 | General Testing New HTTP-Module Listener-Requester | *HTTP-Listener* * Response-Builder inside and outside the Listener ** Headers ** Streaming ** disablePropertiesAsHeaders * Content type application/x-www-form-urlencoded * Transfer Encoding * Error Handler * Proxy * Security ** SSL-HTTPS ** Basic auth - Digest * Threading profile *HTTP-Requester* * Methods ** PUT ** POST * Error Handler * Security ** SSL-HTTPS ** Basic auth - Digest * Consuming API with definition ** RAML ** API def *Testing General Scenario for Both, listener and requester* * Deployment Scenario ** Standalone, Cluster, Webapp and CE Standalone * Shared connector CE and Shared connector EE * Reliability Pattern * Synchronous and Asynchronous * Request-Response ** One-Way ** Request-Reply * CXF WS and Jersey | 13 |
| 488 | MULE-8018 | Merge http connector code cleanup and merge | Cleanup code from the http connector module and merge it into 3.6 branch. | 13 |
| 489 | MULE-8019 | Replace builders with a fluent API | Replace the Builders with a fluent API at an ExtensionManager or Describer level. A mockup to take as reference (not commitment) of what we're shooting for is this: {code:java} public Construct test() { return new DeclarationConstruct("ws-consumer", "1.0").describedAs("Web Service Consumer") .withConfig("config").declaredIn(String.class) .with().requiredParameter("wsdl-location").describedAs("uri to find the wsdl").ofType(String.class).whichIsNotDynamic() .with().requiredParameter("service").describedAs("serviceName").ofType(String.class) .withConfig("newConnector") .with().requiredParameter("wsdl-location").describedAs("uri to find the wsdl").ofType(String.class).whichIsDynamic() .with().requiredParameter("service").describedAs("serviceName").ofType(String.class) .with().optionalParameter("connector").describedAs("The connector to use").ofType(Object.class).defaultingTo(null) .withOperation("consume").describedAs("Go get them tiger!") .with().requiredParameter("operation").describedAs("the operation to execute").ofType(String.class) .with().optionalParameter("mtomEnabled").describedAs("Whether to use mtom or not").ofType(boolean.class); } {code} This should improve usability and reduce the complexity of our own code since now the builder implementation is part of the API | 13 |
| 490 | MULE-8020 | Remove prefixes from ext-api core classes | Remove the "Extension" prefix from classes such as ExtensionConfiguration, ExtensionParameter, ExtensionOperation, etc | 1 |
| 491 | MULE-8021 | Remove minMuleVersion restricition from extensions API | In the future, we'll shoot for letting the runtime should decide this based on the extensions metadata | 1 |
| 492 | MULE-8022 | Remove the api subpackage in the extensions API | Extensions API will be beta during the whole 3.x series, so it shouldn't have the api keyword on its packages. When we move to Mule 4, extensions API will be an OSGi bundle so the whole api classification makes no sense anymore | 1 |
| 493 | MULE-8023 | Reduce the amount of DataTypeQualifiers | We need less DataTypeQualifiers than we're actually supporting. The following should be removed: * Stream * Void The following should be collapsed: * short / int * DATE / DATE_TIME | 2 |
| 494 | MULE-8024 | Enable registration of top level pojos | Enable registering pojos as top level elements. The logic to do this is already done, all that's missing is the namespacehandler for it and testing | 2 |
| 495 | MULE-8025 | Forbid one same class to define both configurations and operations | Configurations and operations have to be defined in separate classes. | 1 |
| 496 | MULE-8026 | Replace current extensions discoverer with OSGish activator class | In order to be aligned with Mule's OSGified future, replace the current discovery model with something of this sort: public class MyActivator implements ExtensionActivator { public void init(Manager mgr) { fluentApi.stuff(); } } } The activator is to be discovered through standard java SPI | 5 |
| 497 | MULE-8027 | Allow to configure a proxy for outbound HTTP connections | The current HTTP transport allows to configure a proxy for outbound connections. The same feature should be available in the new HTTP module. | 5 |
| 498 | MULE-8029 | ExceptionStrategyNotification returns null resourceId | When an ExceptionStrategyNotification inside a flow is executed mule sends the resourceIdentifier in null (It should send the name of the flow) Attached is and app example 1- Deploy agenttest.zip app in mule 2- Call the following url: http:<mule ip>:9900/ExceptionStrategy Verify that the notification sends by mule contains the resourceIdentifier in null | 3 |
| 499 | MULE-8030 | TransactionNotification should return the name of the application that triggered it | When the Agent receives a transaction Notification there is no way to know the name of the application | 3 |
| 500 | MULE-8033 | DataSense doesn't recognise named columns correctly with MySQL joined queries | As Is: I am using MySQL database connector to issue the following query: Select a.item_id as `parentItemId`, a.item_name as `parentItemName`, c.item_id as `ItemId`, c.item_name as `ItemName`, b.level as `levelId` from item a, item_hierarchy b, item c where a.item_id = b.parent_item_id and b.item_id = c.item_id; The join works as expected as does the MySQL connector by returning the correct data. But DataSense in Studio in Studio in the data preview shows the following structure: Payload > List<Map> : List >> item_id : Integer >> item_name : String >> level : String Also leaving out the "as `descriptor`" only shows 3 result columns instead of 5 the query returns. To Be: Studio should show in design mode Payload > List<Map> : List >> parentItemId : Integer >> parentItemName : String >> ItemId : Integer >> ItemName : String >> levelId : Integer Mule xml: <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:neo4j="http://www.mulesoft.org/schema/mule/neo4j" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.5.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/neo4j http://www.mulesoft.org/schema/mule/neo4j/current/mule-neo4j.xsd"> <db:mysql-config name="MySQL_Configuration" host="localhost" port="3306" user="const" password="const" database="construction_machines" doc:name="MySQL Configuration"/> <neo4j:config name="Neo4j" doc:name="Neo4j"> <neo4j:connection-pooling-profile initialisationPolicy="INITIALISE_ONE" exhaustedAction="WHEN_EXHAUSTED_GROW"/> </neo4j:config> <flow name="constructionFlow1" doc:name="constructionFlow1"> <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP"/> <db:select config-ref="MySQL_Configuration" doc:name="Database"> <db:parameterized-query><![CDATA[Select a.item_id as `parentItemId`, a.item_name as `parentItemName`, c.item_id as `ItemId`, c.item_name as `ItemName`, b.level as `levelId` from item a, item_hierarchy b, item c where a.item_id = b.parent_item_id and b.item_id = c.item_id;]]></db:parameterized-query> </db:select> <logger level="INFO" doc:name="Logger"/> <neo4j:create-node config-ref="Neo4j" doc:name="Neo4j"> <neo4j:properties ref="#[payload]"/> </neo4j:create-node> </flow> </mule> | 8 |
| 501 | MULE-8034 | Uri Parameters should appear decoded in the inboundProperties | When a Uri paramter is sent with an encoded character it doesn't appear decoded in the inboundProperties (http.uri.params) . Example: <http:listener-config name="listenerConfig_9000_uri_parameters" host="localhost" port="9000" /> <flow name="http_listener_test_listener_config"> <http:listener path="/resource/{resource_param}" config-ref="listenerConfig_9000_uri_parameters" /> <set-payload value="#[message.inboundProperties['http.uri.params']]" /> </flow> http://localhost:9000/resource/value 01/ (value" "01 = space between value and 01) it will be send encoded to http://localhost:9000/resource/value%2001/ or http://localhost:9000/resource/value+01/ But it has to appear in the http.uri.params as "value 01" not as "value+01" when i obtain the "resource_param". | 5 |
| 502 | MULE-8035 | Change Contributors guide to include accepting the Agreement | We need to change the contributors file to include the terms to accept the license agreement. | 1 |
| 503 | MULE-8038 | HTTP Module configured as proxy duplicate messages | Seems that new http connector configured for proxy scenario is sending more request to the client server than expected. See test case HttpProxyTemplateTestCase,proxyStreaming, | 8 |
| 504 | MULE-8039 | Add behaviour to send a flow message source response asynchronously | Currently we can process a message through MessageProcessingManager but the processing is done all synchronous. We need, for the new http module, to add support to send the http response asynchronously. The only change required so far is a new FlowProcessingPhase with support for asynchronous dispatching of the response message. | 8 |
| 505 | MULE-8040 | Remove the concept of input and output types from an extension operation | Remove the concept of input and output types from an extension operation | 1 |
| 506 | MULE-8041 | Fix HttpListenerAttachmentsTestCase | There is an ignored test in HttpListenerAttachmentsTestCase, from the new http module. The test class contains two test methods, if run independently they both work fine. If run together, then sometimes one of them fails (the whan that is ignored). Apparently there may be an issue with the content lenghts of the multipart requests that are being generated, but further investigation needs to be done on this. | 5 |
| 507 | MULE-8044 | Http Listener fail to send response after receiving a big payload with transfer-encoding chunk | When sending a big payload with transfer-encoding chunk to an http listener, then the listener fails to send the response. See org.mule.module.http.functional.listener.HttpListenerRequestStreamingTestCase . | 8 |
| 508 | MULE-8045 | Remove method from HttpRequestBuilder | Remove HttpRequestBuilder#getHeaders. Refactor the way an HttpRequest is created based on the MuleEvent so that there is no need to have this getter in the builder. | 5 |
| 509 | MULE-8046 | Allow to enable/disable cookies in the outbound part of the HTTP connector | Provide a way to enable/disable cookies in the requests that are sent by the http requester in the new module. | 8 |
| 510 | MULE-8047 | Support shared http listener and request config in domains | We need to be able to shared http:listener-config and http:request-config betweens applications using domains. | 5 |
| 511 | MULE-8051 | Scatter-Gather: Custom Aggregation Strategy - AggregationContext gives wrong events when exceptions occur | When implementing a custom aggregation strategy (as a Java class) as in the documentation: http://www.mulesoft.org/documentation/display/current/Scatter-Gather , section Complete Code Example there seems to be an issue with messages that throw exceptions. It seems that the method collectEventsWithExceptions() from AggregationContext gives the event(s) as they were before entering the Scatter-Gather. So it is basically impossible to get the message(s) that actually caused the exception. collectEventsWithoutExceptions() - works as expected | 8 |
| 512 | MULE-8052 | New HTTP Module Request not encode values in the path attribute | In the new HTTP Request Module when you use a path that have chars that need to be encoded it doesn't produce an URI with the values encoded. For example: <http:request-config name="configWithoutBasePath" host="localhost" port="${httpPort}" /> <flow name="requestWithoutBasePathEncodedValues"> <http:request config-ref="configWithoutBasePath" host="localhost" port="${httpPort}" path="/out 1" /> </flow> The PATH in this case has to be encoded and arrive to the listener server as "/out%201" | 5 |
| 513 | MULE-8053 | CheckExclusiveAttributes should ignore documentation namespace | Classes like org.mule.config.spring.factories.AggregationStrategyDefinitionParser register the pre processor: org.mule.config.spring.parsers.processors.CheckExclusiveAttribute Now this preprocessor validates that only one attribute is present in this element. While this implementation seems o be correct it also stops me from adding any other attribute even though it belongs to a different namespace. For instance: <custom-aggregation-strategy class="org.mule.munit.CustomAggregationStrategy" doc:name="lalala"/> This definition fails and I'm only adding an doc:name. Here is the exception : org.mule.module.launcher.DeploymentInitException: CheckExclusiveAttribute.CheckExclusiveAttributeException: The attribute 'class' cannot appear with the attribute 'name' in element custom-aggregation-strategy{class=org.mule.munit.CustomAggregationStrategy, name=lalala}. org.mule.module.launcher.application.DefaultMuleApplication.init(DefaultMuleApplication.java:181) org.mule.module.launcher.artifact.ArtifactWrapper$2.execute(ArtifactWrapper.java:62) org.mule.module.launcher.artifact.ArtifactWrapper.executeWithinArtifactClassLoader(ArtifactWrapper.java:129) org.mule.module.launcher.artifact.ArtifactWrapper.init(ArtifactWrapper.java:57) org.mule.module.launcher.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:25) org.mule.module.launcher.DefaultArchiveDeployer.guardedDeploy(DefaultArchiveDeployer.java:274) org.mule.module.launcher.DefaultArchiveDeployer.deployArtifact(DefaultArchiveDeployer.java:294) org.mule.module.launcher.DefaultArchiveDeployer.deployExplodedApp(DefaultArchiveDeployer.java:261) org.mule.module.launcher.DefaultArchiveDeployer.deployExplodedArtifact(DefaultArchiveDeployer.java:110) org.mule.module.launcher.DeploymentDirectoryWatcher.deployExplodedApps(DeploymentDirectoryWatcher.java:287) org.mule.module.launcher.DeploymentDirectoryWatcher.start(DeploymentDirectoryWatcher.java:148) org.mule.tooling.server.application.ApplicationDeployer.main(ApplicationDeployer.java:130) Please check attached the full xml to reproduce. Could you please modify the implementation of CheckExclusiveAttribute to support this? | 3 |
| 514 | MULE-8055 | Be able to use the new HTTP connector with the Jersey module | Test the Jersey module using the listener from the new HTTP module instead of an HTTP inbound endpoint. Make the required fixes to make it work. | 8 |
| 515 | MULE-8057 | XML Parser error when using Response Builder with the new HTTP Listener | When you want to use the response builder with the new http listener it throws an unexpected exception parsing the XML document (see Log Output). Maybe there is a problem when having the dependencies of the old HTTP and the new one at the same time. Because a similar test case executed directly in the MULE-MODULE-HTTP project works fine. Similar Issue MULE-8017. | 3 |
| 516 | MULE-8061 | Remove duplicate message creation from test cases. | After MULE-8028 there are several test cases duplicating code to for mule message creation. we should add a method in our test infrastructure and reuse that. | 8 |
| 517 | MULE-8064 | Variables created after a scatter and gather are null even when value was set. | Variables created after a scatter and gather are null even when value was set. Putting the scatter and gather inside a enricher solves the problem. Project attached. | 5 |
| 518 | MULE-8065 | Change DefaultHttpRequester to receive a Configuration object instead of separated attributes for each configuration value | In HTTP connector, there is a HttpRequesterBuilder#setOperationConfig(HttpRequestOptions) method which is used to configure a DefaultHttpRequester instance. That configuration is done invoking every property setter in DefaultHttpRequester. DefaultHttpRequester must accept a HttpRequestOptions instead of having properties for each configurable value to reduce code duplication and make the code more simple | 5 |
| 519 | MULE-8067 | Decouple the extension-api from the concept of declaring or acting classes | Currently, the Extension, Configuration and Operation interfaces have the concept of declaring or acting classes. This ties the API to the traditional implementation model of annotated classes, which might not always be the case. Decouple that by introducing two new interfaces: ConfigurationIntantiator and OperationImplementation | 13 |
| 520 | MULE-8068 | Add tests to verify that extension api parsers support place holders | In the tests that validate the parsing of configurations and operations through XML, validate that property placeholders are correclty resolved | 2 |
| 521 | MULE-8069 | Define a richer set of expression aware XSD types | Now that the extensions api is going to make the parsing of expressions easier and enabled by default on every component, we should define new XSD types which bette reflect the expected return types. For example: * expressionSubstitutableString * expressionSubstitutableInt * etc Things to discuss and define: * Do we always allow embedded expressions? * is "#[foo] " a valid expression? | 8 |
| 522 | MULE-8070 | Jersey fails to retrieve cookie when running with new http module. | Jersey fails to retrieve cookie when running with new http module. See org.mule.module.jersey.JerseyCookiePropagationTestCase | 3 |
| 523 | MULE-8072 | Http Requester returns 200 instead of the actual request status code. | On the proxy scenario, when the proxied service is unavailable a 500 response should be received, instead it is responding with "200 Internal Server Error" which doesn't respect the http protocol. Steps to reproduce: - Deploy application. - Make sure there is no service being proxy. - Hit the endpoint. - A response containing the status "200 Internal Server Error" will be shown. Expected behaviour: The requester and proxy escenario should reply with the same status code and message. | 3 |
| 524 | MULE-8073 | Merge appkit and Mule ESB Maven Plugin in a single repository and fix naming conventions | The two projects (part of the early access beta for 3.6) shown here should be merged. Users should have one consolidated Maven extension. http://www.mulesoft.org/documentation/display/EARLYACCESS/Maven+Tools+for+Mule+ESB http://www.mulesoft.org/documentation/display/EARLYACCESS/Mule+ESB+Plugin+For+Maven | 8 |
| 525 | MULE-8074 | Fix flaky test AuthorizationCodeMinimalConfigTestCase | Fix flaky test AuthorizationCodeMinimalConfigTestCase. Failure is: java.net.SocketTimeoutException: Read timed out java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(SocketInputStream.java:152) java.net.SocketInputStream.read(SocketInputStream.java:122) org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136) org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:152) org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:270) org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161) org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:153) org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254) org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) org.apache.http.client.fluent.Request.execute(Request.java:143) org.mule.module.oauth2.internal.authorizationcode.functional.AuthorizationCodeMinimalConfigTestCase.hitRedirectUrlAndGetToken(AuthorizationCodeMinimalConfigTestCase.java:29) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:606) org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) com.github.tomakehurst.wiremock.junit.WireMockRule$1.evaluate(WireMockRule.java:74) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48) org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74) | 8 |
| 526 | MULE-8075 | Be able to use CXF with the new HTTP connector | Make sure that the CXF module can be used with the new HTTP module (both inbound and outbound). Do the changes required for this. | 13 |
| 527 | MULE-8076 | Write proposal for new splitters and aggregators | New splitters and agregators have been discussed along past brown bags. We need to write down the findings, fill the gaps and create a proposal to discuss. | 5 |
| 528 | MULE-8078 | Backport MULE-7611 to mule 3.5.x | Mule MVEL had a bug related to caching null subexpressions, whih is fixed in MULE-7611. Backport the fix to the mule 3.5 branch so that the next bug fix release contains it. (the fix is actually upgrading mule-mvel dependency) | 1 |
| 529 | MULE-8079 | Cast exception on the proxy http scenario. | When running the Proxy scenario of the http module, a very small percentage of the requests fails with the shown exception. | 3 |
| 530 | MULE-8086 | File handlers are not closed after a Queue is disposed | Per the Queue contract, when a queue is disposed all its storage is to be freed and the resources released. However, it is only clearing the storage but the file handlers remain open. I have verified that the number of files in the queuestore directory in .mule/ grows constantly. Checked with lsof -p <pid> Code is in github at https://github.com/mulesoft-consulting/ucso-api-manager.git | 5 |
| 531 | MULE-8089 | Wrong attributes for TLS in OAuth config | Attributes requestConfig and listenerConfig were not removed from the OAuth authorization grant types. We need to use tlsContext-ref instead. | 8 |
| 532 | MULE-8092 | Email address dev@mule.codehaus.org bounces back in "WARN org.mule.DefaultMuleMessage: setProperty(key, value) called with null value" | Using a message enricher to extract a non-existent property from the current payload and assign it to a flow variable causes the following warning. It has been reported that an email to the given address dev@mule.codehaus.org just bounced back. Please correct the email address, or remove the stack trace (which makes it look much worse than a warning), or remove the message from being logged in this situation altogether. WARN 2014-11-14 16:07:37,292 [[<removing project name from JIRA>].httpc.receiver.04] org.mule.DefaultMuleMessage: setProperty(key, value) called with null value; removing key: <removing key name from JIRA>; please report the following stack trace to dev@mule.codehaus.org java.lang.Throwable at org.mule.DefaultMuleMessage.setProperty(DefaultMuleMessage.java:470) at org.mule.el.context.MessagePropertyMapContext.put(MessagePropertyMapContext.java:49) at org.mule.el.context.MessagePropertyMapContext.put(MessagePropertyMapContext.java:17) at org.mule.mvel2.optimizers.impl.refl.nodes.MapAccessor.setValue(MapAccessor.java:52) at org.mule.mvel2.optimizers.impl.refl.nodes.VariableAccessor.setValue(VariableAccessor.java:46) at org.mule.mvel2.compiler.CompiledAccExpression.setValue(CompiledAccExpression.java:59) at org.mule.mvel2.ast.DeepAssignmentNode.getReducedValueAccelerated(DeepAssignmentNode.java:92) at org.mule.mvel2.MVELRuntime.execute(MVELRuntime.java:86) at org.mule.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123) at org.mule.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119) at org.mule.mvel2.MVEL.executeExpression(MVEL.java:943) at org.mule.el.mvel.MVELExpressionExecutor.execute(MVELExpressionExecutor.java:72) at org.mule.el.mvel.MVELExpressionLanguage.evaluateInternal(MVELExpressionLanguage.java:198) at org.mule.el.mvel.MVELExpressionLanguage.evaluate(MVELExpressionLanguage.java:183) at org.mule.expression.DefaultExpressionManager.enrich(DefaultExpressionManager.java:244) at org.mule.enricher.MessageEnricher.enrich(MessageEnricher.java:112) at org.mule.enricher.MessageEnricher.process(MessageEnricher.java:78) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:94) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:50) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:22) at org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:66) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:61) at org.mule.routing.AbstractSelectiveRouter.processEventWithProcessor(AbstractSelectiveRouter.java:308) at org.mule.routing.AbstractSelectiveRouter.routeWithProcessors(AbstractSelectiveRouter.java:298) at org.mule.routing.AbstractSelectiveRouter.routeWithProcessor(AbstractSelectiveRouter.java:288) at org.mule.routing.AbstractSelectiveRouter.process(AbstractSelectiveRouter.java:203) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:94) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102) at org.mule.construct.DynamicPipelineMessageProcessor.process(DynamicPipelineMessageProcessor.java:54) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:94) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102) at org.mule.interceptor.AbstractEnvelopeInterceptor.process(AbstractEnvelopeInterceptor.java:51) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102) at org.mule.processor.AbstractFilteringMessageProcessor.process(AbstractFilteringMessageProcessor.java:40) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:102) at org.mule.construct.AbstractPipeline$1.process(AbstractPipeline.java:109) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:94) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:50) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:22) at org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:66) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:61) at org.mule.construct.AbstractPipeline$3.process(AbstractPipeline.java:207) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.SimpleMessageProcessorChain.doProcess(SimpleMessageProcessorChain.java:43) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:50) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:22) at org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:66) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:61) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.SimpleMessageProcessorChain.doProcess(SimpleMessageProcessorChain.java:43) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.doProcess(InterceptingChainLifecycleWrapper.java:50) at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:67) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.access$001(InterceptingChainLifecycleWrapper.java:22) at org.mule.processor.chain.InterceptingChainLifecycleWrapper$1.process(InterceptingChainLifecycleWrapper.java:66) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) at org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) at org.mule.processor.chain.InterceptingChainLifecycleWrapper.process(InterceptingChainLifecycleWrapper.java:61) at org.mule.transport.AbstractMessageReceiver.routeEvent(AbstractMessageReceiver.java:511) at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:226) at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:208) at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:200) at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:187) at org.mule.transport.http.HttpMessageReceiver$7$1.process(HttpMessageReceiver.java:483) at org.mule.transport.http.HttpMessageReceiver$7$1.process(HttpMessageReceiver.java:480) at org.mule.execution.ExecuteCallbackInterceptor.execute(ExecuteCallbackInterceptor.java:16) at org.mule.execution.HandleExceptionInterceptor.execute(HandleExceptionInterceptor.java:30) at org.mule.execution.HandleExceptionInterceptor.execute(HandleExceptionInterceptor.java:14) at org.mule.execution.BeginAndResolveTransactionInterceptor.execute(BeginAndResolveTransactionInterceptor.java:54) at org.mule.execution.ResolvePreviousTransactionInterceptor.execute(ResolvePreviousTransactionInterceptor.java:44) at org.mule.execution.SuspendXaTransactionInterceptor.execute(SuspendXaTransactionInterceptor.java:50) at org.mule.execution.ValidateTransactionalStateInterceptor.execute(ValidateTransactionalStateInterceptor.java:40) at org.mule.execution.IsolateCurrentTransactionInterceptor.execute(IsolateCurrentTransactionInterceptor.java:41) at org.mule.execution.ExternalTransactionInterceptor.execute(ExternalTransactionInterceptor.java:48) at org.mule.execution.RethrowExceptionInterceptor.execute(RethrowExceptionInterceptor.java:28) at org.mule.execution.RethrowExceptionInterceptor.execute(RethrowExceptionInterceptor.java:13) at org.mule.execution.TransactionalErrorHandlingExecutionTemplate.execute(TransactionalErrorHandlingExecutionTemplate.java:109) at org.mule.execution.TransactionalErrorHandlingExecutionTemplate.execute(TransactionalErrorHandlingExecutionTemplate.java:30) at org.mule.transport.http.HttpMessageReceiver$7.process(HttpMessageReceiver.java:479) at org.mule.transport.http.HttpMessageReceiver$7.process(HttpMessageReceiver.java:475) at org.mule.transport.http.ThrottlingExecutionTemplate.execute(ThrottlingExecutionTemplate.java:91) at org.mule.transport.http.HttpMessageReceiver.routeHttpRequest(HttpMessageReceiver.java:474) at org.mule.transport.http.HttpMessageReceiver.routeRequest(HttpMessageReceiver.java:415) at org.mule.transport.http.HttpMessageReceiverRouterWorker.run(HttpMessageReceiverRouterWorker.java:31) at org.mule.transport.TrackingWorkManager$TrackeableWork.run(TrackingWorkManager.java:267) at org.mule.work.WorkerContext.run(WorkerContext.java:286) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) | 1 |
| 533 | MULE-8094 | HTTP Listener with Basic Auth should return status code 401 when authentication fails | When using the Basic-Auth with the new Module Http Listener it returns a 500 status code but it would be better to return a 401 like the old http does. Example: <flow name="listenerBasicAuth"> <http:listener config-ref="listenerConfigBasicAuth" path="/basic/" /> <http:basic-security-filter realm="mule-realm"/> <!--<mule-ss:http-security-filter realm="mule-realm"/>--> <set-payload value="TestBasicAuthOk"/> </flow> <flow name="httpInboundBasicAuth"> <inbound-endpoint address="http://localhost:9016/http_basic"> <mule-ss:http-security-filter realm="mule-realm"/> </inbound-endpoint> <set-payload value="TestHttpBasicAuthOk"/> </flow> In the first flow (listenerBasicAuth) using the tag: - <http:basic-security-filter realm="mule-realm"/> or - <mule-ss:http-security-filter realm="mule-realm"/> after the listener it returns a 500 in an invalid authentication. But with the old HTTP, in the second flow ("httpInboundBasicAuth") it returns a 401. | 5 |
| 534 | MULE-8097 | Hot spot in ServerAddress of HTTP Connector | When ServerAddress executes: this.ip = InetAddress.getByName(host).getHostAddress(); It's take a while to return. We need to improve it since it's used with every request. | 3 |
| 535 | MULE-8100 | Add MULE_REMOTE_CLIENT_ADDRESS property in the new HTTP connector | The HTTP transport sets a variable with the address of the client in inbound connections, but is able to detect if the request comes from a proxy (if so, the value of the X-Forwarded-For header is used instead of the IP of the proxy). This is explained in MULE-7263. We need to provide this functionality in the new HTTP connector. | 5 |
| 536 | MULE-8101 | HTTP requester not sending query parameters when processing a redirect under HTTPS | Check the behavior of redirects in the http:request element of the new HTTP module when using HTTPS. If the Location header contains a URL with query parameters, the request to that URL doesn't contain the parameters. To reproduce, check AuthorizationCodeFullConfigTestCase#localAuthorizationUrlRedirectsToOAuthAuthorizationUrl. MuleClient is being used twice, to manually process redirects, replace that with only one call with enabled redirects. | 8 |
| 537 | MULE-8102 | Upgrade schema versions to 3.6 | Upgrade schema versions to 3.6 | 1 |
| 538 | MULE-8103 | The application logging configuration is not read or used. | When deploying an app with a logging congif (log4j2.xml), mule doesnt use its config and use the default every time. Steps to reproduce: Deploy the attached app on a mule instance. Wait for it to be deployed. The default app log will be created no matter which configuration was given. Expected behavior: Log into the configured file instead of the default one, if using Console, should log into mule_ee.log or mule.log (depending on the distribution). | 1 |
| 539 | MULE-8104 | HTTP Requester not removing previous inbound properties | The http:request sets inbound properties to the resulting Mule message but keeps any previous inbound property that were set before the request. To reproduce, test the proxy scenario using a flow with an http:listener and an http:request. When returning from the request, the Mule message still has inbound properties from the listener. | 3 |
| 540 | MULE-8106 | TCP Transport creating MULE_REMOTE_CLIENT_ADDRESS as outbound | While working on STUDIO-5148, the team found that TCP is creating the MULE_REMOTE_CLIENT_ADDRESS as outbound property rather than inbound as per our way to adapt messages and the way we set that property everywhere else. https://github.com/mulesoft/mule/blob/bfb3a17263d1e4b32ee10272cbf710a2bf41b16b/transports/tcp/src/main/java/org/mule/transport/tcp/TcpMessageReceiver.java#L421 | 3 |
| 541 | MULE-8107 | Default maxThreads is 128 when worker-threading-profile isn't present but 16 when it is. | As title.. | 3 |
| 542 | MULE-8110 | Http Listener Module Path Issue with path with wildcard and another hardcoded in the same port and with spaces in the path | When there are two listeners in the same port but one has a wildcard the other has a hardcoded path and there is a collision between them it has to enter in the listener that has the hardcoded path. For example: 1) Flow with path = "/in" and another flow with path = "/in/* " It enters in the /in/* listener but it should enter in the "/in" without wildcard 2) path="/in/*/subpath1" path=/in/* When you consume it with "/in/foo1/subpath1" it goes to the path /in/* 3) Similar to the previous case. path="/in/*/subpath1/*" and Path=/in/* When you consume it with "/in/foo1/subpath1/subpath2" it goes with the /in/* 4) path="/encodedValues/foo 1" and you consume it with /encodedValues/foo%201 it returns a 404. For all of these cases there are Functional Test Cases inside the System folder of the HTTP module tests: *HttpListenerPathTestCase | 3 |
| 543 | MULE-8112 | ArrayIndexOutOfBoundsException when logging exceptions | Sometimes, when logging an exception with a RollingFileAppender an ArrayIndexOutOfBoundsException is thrown. | 1 |
| 544 | MULE-8113 | Tests Infrastructure modules build warning | When running mvn validate on mule-tests-infrastructure module I get a warning because there is a duplicated declaration of maven-jar-plugin in mule pom.xml. {noformat} [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for org.mule.tests:mule-tests-infrastructure:jar:3.7.0-M1-SNAPSHOT [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.apache.maven.plugins:maven-jar-plugin @ org.mule:mule:3.7.0-M1-SNAPSHOT, /Users/alejandrosequeira/dev/mule/ce/pom.xml, line 1803, column 21 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Mule Tests Infrastructure 3.7.0-M1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-maven-version) @ mule-tests-infrastructure --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.269 s [INFO] Finished at: 2014-12-02T16:40:14-03:00 [INFO] Final Memory: 9M/246M [INFO] ------------------------------------------------------------------------ {noformat} | 1 |
| 545 | MULE-8114 | Change IO strategy in HTTP requester | Use SameThreadIOStrategy in the outbound part of he new http connector. As the exchange pattern is always request-response it makes no sense to use a different thread worker to process the request. | 3 |
| 546 | MULE-8115 | CXF proxy test seems to be slower with the new http module than with the http transport. | The ProxyTestCase with proxy-conf-flow.xml as config file runs for 1 minute and 25 seconds, but with proxy-newhttp-conf-flow.xml (using the new http module) it runs for 3 minutes and 15 seconds. | 8 |
| 547 | MULE-8116 | Error in the XML Parser of the HTTP Module when the Header tag is used with the Error Response Builder | This exception is throw when there is an Error Response Builder: "nested exception is java.lang.IllegalStateException: No parser defined for header in the context error-response-builder" | 3 |
| 548 | MULE-8117 | StringIndexOutOfBoundsException when requester receives GET with wrong body | When sending a GET with content-type application/x-www-form-urlencoded and an incorrect form body it returns an empty response due to a java.lang.StringIndexOutOfBoundsException. To reproduce run the following command using the configuration: {noformat} $curl -G --data 'hello' http://localhost:8080/1 curl: (52) Empty reply from server {noformat} | 3 |
| 549 | MULE-8118 | Max connections exceeded in the outbound part should block instead of failing | When running the proxy scenario under more than 10 concurrent threads, the requests starts to fail due max connections limit exceeded. This parameter is not set, so this should be the default "-1"... no limit. The tcp configuration has been removed from the requester to asure that this issue is probably from the listener. Also on the core log this exception has been found: dic 03, 2014 3:07:20 PM org.glassfish.grizzly.nio.transport.TCPNIOTransport configureChannel WARNING: GRIZZLY0004: Can not set TCP_NODELAY to true java.net.SocketException: Invalid argument sun.nio.ch.Net.setIntOption0(Native Method) sun.nio.ch.Net.setSocketOption(Net.java:373) sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:189) sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:295) sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:330) org.glassfish.grizzly.nio.transport.TCPNIOTransport.configureChannel(TCPNIOTransport.java:445) org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:214) org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:154) org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:258) org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:552) org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103) org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89) org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414) org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383) org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347) org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) java.lang.Thread.run(Thread.java:745) dic 03, 2014 3:07:20 PM org.glassfish.grizzly.nio.transport.TCPNIOTransport configureChannel WARNING: GRIZZLY0006: Can not set SO_REUSEADDR to true java.net.SocketException: Invalid argument sun.nio.ch.Net.setIntOption0(Native Method) sun.nio.ch.Net.setSocketOption(Net.java:373) sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:189) sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:295) sun.nio.ch.SocketAdaptor.setReuseAddress(SocketAdaptor.java:413) org.glassfish.grizzly.nio.transport.TCPNIOTransport.configureChannel(TCPNIOTransport.java:451) org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:214) org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:154) org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:258) org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:552) org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103) org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89) org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414) org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383) org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347) org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) java.lang.Thread.run(Thread.java:745) | 8 |
| 550 | MULE-8123 | Jetty http.context.path inbound property has a different value in 3.6 compared to 3.5 | The jetty transport in 3.6.0-M3 is setting the http.context.path inbound property to a different value than 3.5 given the following endpoint address and request: endpoint address: http://localhost:8080/api request: http://localhost:8080/api/console/index.html in 3.6 we get: http.context.path: /api/console/index.html and in 3.5 the value was: http.context.path: /api the 3.5 behavior is the expected one. | 5 |
| 551 | MULE-8124 | Resource Not Found in HTTP should return a body with a clear message | HTTP Module returns 404 when a valid port is hit but there's no listener in it. | 3 |
| 552 | MULE-8127 | HTTP Listener Module is not adding the WWW-Authenticate header field in the response | When you send bad basic credentials for authentication the response of the listener is not adding the WWW-Authenticate header field. But in the case you don't send the authentication header credential it includes the WWW-Authenticate header field. As I understand in the RFC (http://tools.ietf.org/html/rfc2616#section-10.4.2) the server has to add the WWW-Authenticate header field in both scenarios. | 5 |
| 553 | MULE-8129 | HTTP Listener config throws NPE when a request is received but no listener is referencing the config | When no listener is referencing a listener-config, and a request is received in the configured port, a NPE is thrown in the server. To reproduce, add this listener-config: <http:listener-config name="customConfig" host="localhost" port="1234"/> Run the app, and then hit with a browser http://localhost:1234 | 3 |
| 554 | MULE-8130 | Null pointer exception on the first request causes the listener to close the connection. | When loading the application, the first request fails to be processed due an exception and after that no connection can be created, probably the listener's socket is close on the exception. | 5 |
| 555 | MULE-8132 | HTTP listener not setting exception payload. | There's a scenario in CXF where an exception is thrown after calling an HTTP listener. An exception payload is expected but you get null. Test is testServerClientProxyDefaultException and can be found in ExceptionStrategyTestCase. | 2 |
| 556 | MULE-8133 | Log separation doesn't work after upgrading to log4j 2.1 | Because of a change in Log4j's lifecycle, after upgrading to 2.1 the application logs never load their configuration which in practice means that log separation is disabled even though applications do have a separate logging context. | 3 |
| 557 | MULE-8134 | JUL loggers are not bridged to log4j2 | Components like jersey and Grizzly are logging using JUL but that API is not bridged to log4j2. JUL loggers should have the same treatment as the others do | 3 |
| 558 | MULE-8139 | Thread names are i) lacking app prefix ii) duplicated between http inbound and outbound | I have checked this is not an issue for per-app logging, but I beleive it's an issue for MMC and possibly other things. It's also bad practice to repeat thread names. | 3 |
| 559 | MULE-8142 | HTTP Listener is storing only the first part of a MultiPart request as attachment | given the following request using RestAssured: {code} given() .multiPart("description", "Barcelona Badge") .multiPart("image", "bbva.jpg", this.getClass().getClassLoader().getResourceAsStream("org/mule/module/apikit/leagues/bbva.jpg")) .expect() .statusCode(200) .body("upload", is("OK")) .when() .put("/api/leagues/liga-bbva/badge"); {code} only the first part ("description") is being stored as an inboundAttachment. Using http:inbound instead of listener generates both attachments as expected. failing test using listener: https://github.com/mulesoft/apikit/blob/http-3.6/mule-module-apikit/src/test/java/org/mule/module/apikit/leagues/LeaguesHttpListenerTestCase.java passing test using endpoint: https://github.com/mulesoft/apikit/blob/http-3.6/mule-module-apikit/src/test/java/org/mule/module/apikit/leagues/LeaguesTestCase.java in both classes the test in question is putMultiPartFormData() | 8 |
| 560 | MULE-8144 | Cannot add ContextResolver in Jersey Module | When trying to add a context-resolver in 3.6.0 it seems that Mule don't do anything. To reproduce download the attached project and run mvn clean test using mule.version 3.6.0-M3-SNAPSHOT (the current value) and see that it doesn't fail. If you use 3.5.0 it fails. | 5 |
| 561 | MULE-8146 | Grizzly thread leaks | When running the CE test suite, you can see grizzly threads piling up to the point in which by the time the suite is almost over there's a gigantic amount of idle threads. This leads to flakiness and in some environments it even fails the build because the host can't allocate more threads. Additionally, it raises the concern about those threads being actually stopped when an application is undeployed on a live container. Please trace and fix the leak and verify that those threads do not survive an application undeployment. | 8 |
| 562 | MULE-8147 | Support doc/literal with multiple message parts in ws consumer | WS Consumer should support doc/literal web services that have multiple message parts inside them. Note: since WS consumer sets the payload to the body of the SOAP message, this means that it will have to have a wrapper element around the message parts. | 13 |
| 563 | MULE-8148 | WS Encryption support for WS Consumer | We should support WS Security encryption/decryption capabilities in WS consumer. | 8 |
| 564 | MULE-8149 | WS Security Signature support for WS consumer | We should support WS Security signature and verification capabilities in WS consumer. | 8 |
| 565 | MULE-8150 | HTTP Connector OAuth Implicit Credentials | Need to support OAuth implicit credentials for new HTTP connector. | 8 |
| 566 | MULE-8151 | Malformed responses when Jersey sends a chuncked response | When a Jersey endpoint responds with a chuncked response, then the chunks are not correctly formed and the last one is not correctly finialized. As a result, the response is garbled. | 5 |
| 567 | MULE-8156 | Create examples for HTTP module documentation | Create exmaples to include in documentation for new HTTP Module. | 13 |
| 568 | MULE-8157 | It isn't possible to set the module HTTP Listener Config and an Oauth Provider in the same Port | As the Mule Oauth Provider use the HTTP Transport you can't set the same port in the provider and the Http Module Configs of the flows that have the resources. Also there is a problem when you change the port of the Provider to not overlap them and deploy the app because it goes on with the error of "BindException: Address already in use". You have to stop the Mule Standalone and started again. | 13 |
| 569 | MULE-8159 | java.lang.IllegalStateException: Only owner thread can write to message still occures with http module | . | 5 |
| 570 | MULE-8160 | 100% errors with http listener under high concurrency | 100% Failures at 8000 concurrency. Http transport only has 0.32% failures, and jetty none. | 8 |
| 571 | MULE-8162 | HTTP listener fails with NPE when the message is filtered out | The following config is failing with NPE. It doesn't fail when the message is not filtered out. Error: java.lang.NullPointerException org.mule.module.http.internal.listener.HttpResponseBuilder.build(HttpResponseBuilder.java:77) ~[mule-module-http-3.6.0-M3-SNAPSHOT.jar:3.6.0-M3-SNAPSHOT] org.mule.module.http.internal.listener.HttpMessageProcessorTemplate.sendResponseToClient(HttpMessageProcessorTemplate.java:87) ~[mule-module-http-3.6.0-M3-SNAPSHOT.jar:3.6.0-M3-SNAPSHOT] org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:56) ~[mule-core-3.6.0-M3-SNAPSHOT.jar:3.6.0-M3-SNAPSHOT] org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:23) ~[mule-core-3.6.0-M3-SNAPSHOT.jar:3.6.0-M3-SNAPSHOT] | 5 |
| 572 | MULE-8163 | Requests randomly fail (1 in 1M) with NPE, even at low conconcurrencies e.g. 50 | Around 10 times in a million requests, the request fails due a null pointer exception caused by the future returning null instead of a valid response. Class and line: org.mule.module.http.internal.request.grizzly.GrizzlyHttpClient#send response = future.get(responseTimeout, TimeUnit.MILLISECONDS); | 8 |
| 573 | MULE-8165 | Spike on execution model of extensions api | Make it execute operations | 13 |
| 574 | MULE-8166 | Make a Spike on consolidating all mule registries into a Spring one | Make a Spike on consolidating all mule registries into a Spring one | 13 |
| 575 | MULE-8167 | Remove byte as a DataQualifier | Remove it | 1 |
| 576 | MULE-8169 | Refactor transport discovery for OSGi | Current transport discovery mechanism inspects all available jars searching for service properties files. That must be modified to work on an OSGi container. In OSGi, transport discovery should follow white-board model so a transport service can be used (with no OSGi knowledge) which would enable test running with not container to be able to properly create the mule context. | 8 |
| 577 | MULE-8170 | Redesign context builder discovery for OSGi | Current context builder discovery mechanism inspects all available jars searching for service properties files. That must be modified to work on an OSGi container. In OSGi, transport discovery should follow white-board model so a context builder service can be used (with no OSGi knowledge) which would enable test running with not container to be able to properly create the mule context. | 8 |
| 578 | MULE-8172 | Cannot log to application log for a failed deployment | Install latest snapshot (build c22fb549), create an application with the attached config and start using bin/mule -M-Dmule.agent.enabled=false. Deployment fails as expected but there is a problem when trying to log to application log. See attached log. | 8 |
| 579 | MULE-8173 | Add protocol attribute to listener-config and request-config to improve usability | Currently is difficult for an user to realice how to configure HTTPS for listening HTTP requests or sending HTTP requests. The way to do that currently is by defining a TLS Context element (which can be empty for sending request, in such case it will use jvm default certificatess) inside the listener-config or de request-config element. That it's not straightforward if the user is working with XML and for users that do not know that SSL / TLS is the protocol behing HTTPS isn't either despite they use Studio. The idea is to add a protocol attribute (with default value HTTP) in the listener-config and the request-config. - Listener config: - if user sets protocol="http" or provides no values then we validate that the user didn't put a TlsContext. - If user sets protocol="https" we validate that the user provided a TlsContext with at least a keystore configured on it. - Request config: - if user sets protocol="http" or provides no value then we validate that the user didn't put a TlsContext - if user sets protocol="https" and provides no TlsContext config then we create a TlsContext by default (implicitly) using the default jvm certificates - if http is selected, port 80 is used by default - if https is selected, port 443 is used by default The usability improvements is: From Studio the user has a much more easy way to find where to define the use of HTTPS since it's going to be in the main configuration section of both listener-config and request-config From XML the user will see a hint from the XML content assistant to pick the protocol right in the listener-config element or request-config element. With the new behaviour there's no reason to support an empty tls:context element in the config. When we rebuild the current TCP transport ideally we can reuse the same mechanism as in HTTP (no idea what the "protocol" attribute would be called in that case) or add support for an empty tls:context again. | 5 |
| 580 | MULE-8176 | Deprecate HTTP transport | Deprecate XML elements of the HTTP transport. | 5 |
| 581 | MULE-8177 | HttpListener ParameterMap should behave as a Map | ParameterMap is a Map<String, String> and holds the values of query parameters, uri parameters and POST params. The problem that currently have are: - The parameter map is mutable when it should't - It does not have an API in the interface that can be used by the user (there's an special method getAll used when a parameter returns a collection of values) - it does not comply with the Map interface for Map<String, String> as it declares. | 3 |
| 582 | MULE-8178 | Default HTTPS configuration in requester not working correctly | The protocol="HTTPS" configuration in the request-config is ignored if there is no default TLS context factory in the registry. | 3 |
| 583 | MULE-8199 | Remove Maven warnings | We recently had an [issue|MULE-8113] with our Maven build, it wasn't including a dependency. When doing a little research I found that it was because a duplicated declaration of maven-jar-plugin. This root problem didn't appear when building the module, but when building an ancestor (distance 2). To avoid this kind of issues we must ensure that we don't have Maven warning in our builds. | 8 |
| 584 | MULE-8180 | HTTP Listener fails during initialization inside batch | When adding an http:listener inside the input of a batch job then the app fails during startup. Seems that DefaultBatchEngine is asking for all the batch jobs during initialization, then the batch job manually executes initialize and injection over the input elements (http:listener) but at this point the HttpListenerConnectionManager has not bean registered (using registry bootstrap) so there's a null pointer during listener initialization. | 5 |
| 585 | MULE-8181 | Problem sending outbound attachments in HTTP requester | When sending a multipart request, the requester assumes that each part is a file, and adds the corresponding headers (filename attribute at the beginning of the part, transfer-encoding: binary, etc). This makes the request to be invalid in some cases. Use case to test: upload a file to Box. Example test (replace the dev token and the parent folder id): <http:request-config name="requestConfig" host="upload.box.com" port="443" protocol="HTTPS" responseTimeout="10000" /> <flow name="test"> <set-attachment attachmentName="attributes" value="{"name":"test.txt", "parent":{"id":"12345678"}}" contentType="application/json" /> <set-attachment attachmentName="test.txt" value="Test content" contentType="text/plain" /> <http:request config-ref="requestConfig" path="/api/2.0/files/content" method="POST" > <http:request-builder> <http:header headerName="Authorization" value="Bearer xxxxxxxxxxxxx"/> </http:request-builder> </http:request> </flow> The requester sends a multipart request with the following format. POST /api/2.0/files/content HTTP/1.1 Host: localhost:8082 Authorization: Bearer xxxxxxxxxx MULE_ENCODING: UTF-8 Connection: keep-alive Accept: */* User-Agent: NING/1.0 Content-Type: multipart/form-data; boundary=Tdv259AB4D2JOrezEkOphg5Ikreks3mIO2jC Content-Length: 463 --Tdv259AB4D2JOrezEkOphg5Ikreks3mIO2jC Content-Disposition: form-data; name="attributes"; filename="attributes" Content-Type: application/json Content-Transfer-Encoding: binary {"name":"test.txt", "parent":{"id":"12345678"}} --Tdv259AB4D2JOrezEkOphg5Ikreks3mIO2jC Content-Disposition: form-data; name="test.txt"; filename="test.txt" Content-Type: text/plain Content-Transfer-Encoding: binary Test content --Tdv259AB4D2JOrezEkOphg5Ikreks3mIO2jC-- The problem is the "attributes" part, which is sent as a file part. It shouldn't contain the filename attribute, and the transfer encoding shouldn't be binary. Postman just sends the following, and it works correctly: Content-Disposition: form-data; name="attributes" {"name":"test.txt", "parent":{"id":"12345678"}} | 8 |
| 586 | MULE-8184 | HTTP Listener Server should return Method not supported | When there's at least one HTTP listener for a uri but the listeners for that uri do not support a given method an status code 405 Method Not Allowed should be return. Currently it's returning 404. | 5 |
| 587 | MULE-8185 | Change the AsyncCompletionHandler in the HTTP requester to use a static logger | The AsyncCompletionHandler used by AHC in the HTTP requester uses a logger that is stored in an instance variable. Change it to use a class variable, to avoid loading the logger from the logger factory each time a request is sent (an AsyncCompletionHandler is created for each request). | 3 |
| 588 | MULE-8188 | Mule starts when a request element has host/port undefined, only failing when request is used. | This should fail at startup, not in runtime. | 3 |
| 589 | MULE-8189 | Improve HTTP listener logging for usability | Mule does not log to show what host/port/path Mule listening on. This is important for understanding what might be going on when things aren't working as expected, and existed with the existing http transport. Also, error/logs related to listeners not being available should take into account "allowedMethods" otherwise errors like this which make no sense occur: {code} WARN 2014-12-30 10:01:46,424 [[http-module-echo].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: / WARN 2014-12-30 10:01:46,424 [[http-module-echo].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: Available listeners are: [/] {code} | 3 |
| 590 | MULE-8197 | Listener response streaming only returns part of body. | If you edit this test case to use larger body sizes, then tests begin to fail: org.mule.module.http.functional.listener.HttpListenerResponseStreamingTestCase | 5 |
| 591 | MULE-8201 | Exception in HTTP listener when path="/" and basePath="/" | When using an http:listener with path="/", and referencing a listener-config where basePath="/", then an ArrayIndexOutOfBounds exception is thrown when receiving a request. | 3 |
| 592 | MULE-8202 | HTTP requester not adding the reason phrase in the response | The HTTP requester is adding an inbound property with the status code of the response, but no property with the reason phrase. Currently there is no way of getting the reason phrase of the response, analyze if it makes sense to add another inbound property with the reason phrase. The status code validator should also include the reason phrase when failing due to an invalid status code in the response. This is useful when consuming REST APIs that add information in the reason phrase of an error status code response. | 5 |
| 593 | MULE-8205 | Listener should respect keep-alive with HTTP 1.0 and disable chunking. | With HTTP 1.0 KeepAlive header, the http response from Mule returns "Connection: Close" when streamingMode is ALWAYS or the payload is an InputStream. I'm not 100% sure if HTTP 1.0 officially supports chunking, but I am sure that the keepAlive header should be respected an chunking shouldn't affect this. | 8 |
| 594 | MULE-8206 | Inconsistent implementation of streamingMode="NEVER" between listener and requestor. | There are a number of cases tested in HttpListenerResponseStreamingTestCase where even when responseStreamingMode="NEVER" chunking is still used. In my mind it should be the "AUTO" mode that decided if it should use chunking based on i) payload type ii) presence of headers. If there is a mode called "NEVER", it should never do chunking otherwise this is confusing/misleading. On the other hand, <request> currently throws an exception in this scenario. Update behaviuor so that in both cases: AUTO: - Chunking if payload is InputStream and no Content-Length header present. - Else delete transfer-encoding header if present and log. ALWAYS: - Delete content-length header and log. NEVER: - Delete transfer-encoding header and log. | 5 |
| 595 | MULE-8209 | Mule Integration QA build is failing because of wrong sxc dependency version | tests/integration module is failing because is trying to retrieve sxc version, which is not needed. | 3 |
| 596 | MULE-8210 | Support parameter grouping in Configurations and Operations | There are cases in which a group of parameters are frequently used together, for which it makes sense to treat them as a group. The extensions api already supports mapping pojos directly in the XML, but in same cases which group is preferred as parameters rather than a top level object. To enable that, the @Parameters operation will be created {code:java} @Extension public class MyExtension { @Parameters private Options options; } public class Options { @Parameter private String color; @Parameter @Optional private String mode; private String owner; } } {code} The outcome of the code above is a configuration with two parameters called 'color' and 'mode', one required and the other optional. The configuration has no attribute called options. If the Options class were to have another field also annotated with @Parameters, then such fields will be ignored. In the same way, the annotation can be applied to a class holding operations: {code:java} public class Operations { @Parameters private Options options; @Operation public void hello(String message) { ... } @Operation public void goodBye(String message) { } } {code} In this case, both operations will have three parameters: message, color and mode. The last use case for this annotation is to have nested parameter classes: {code:java} public class Options { @Parameter private String color; @Parameter @Optional private String mode; @Parameters private MoreOptions moreOptions; } } {code} In this last example, the configuration/operation that is augmented with this extra parameters will have the sum of Options and MoreOptions parameters. Those parameters will be flattened, meaning that the model will contain no reference to the fact that the MoreOptions parameters were nested inside Options. The field must be a Java bean property (ie it needs to have setters and getters matching the field name). | 8 |
| 597 | MULE-8212 | Cleanup the @Operation annotation parameters | The @Operation parameter takes a name argument. That should be remove since directly contradicts the consistency that the API tries to enforce The annotation also contains an "acceptedPayloadTypes" which is no longer used. That should be cleaned up | 1 |
| 598 | MULE-8213 | Move packages on annotations module from org.mule to org.mule.module.annotations | Each module/bundle must use different packages names for OSGi. Annotations module uses org.mule prefix which belongs to mule-core | 3 |
| 599 | MULE-8214 | Moving packages on spring-config module from org.mule to org.mule.module.springconfig | Each module/bundle must use different packages names for OSGi. Spring cnofig module uses org.mule prefix which belongs to mule-core | 3 |
| 600 | MULE-8215 | Write spec for validations extension | Write and validate a Spec for a new extension module for validation purposes. | 8 |
| 601 | MULE-8220 | Build number Maven plugin should be activated always | We are currently executing maven-build-number-plugin only in release profile, this should be ran for all profiles. | 3 |
| 602 | MULE-8224 | Remove Unused Scripts | We need to see which of these scripts in buildtools/scripts are still being used, and remove the ones that are not: CheckReintegratedWorkingCopy.groovy DeployArtifacts.groovy EclipseXmlCatalog.groovy ListExcludedTests.groovy ListIncludedTests.groovy ListSchema.groovy ListTestExclusions.groovy ScanLicenseHeaders.groovy SchemaStatistics.groovy SvnJiraParser.groovy SvnJiraParser.sh SvnPropertiesSetter.sh SwitchLicenseHeader.sh SwitchSchemaVersion.groovy SwitchVersion.groovy XmlCatalogFromMuleStandaloneDistro.groovy build.sh compare_exclusions.sh mkpom.sh mule_root.sh mule_undo.sh tabstospaces.sh update_poms.sh | 5 |
| 603 | MULE-8229 | Fail to expand properties when using property placeholder shared in a domain | Steps: # Deploy the below application and domain # Put domain.properties in domain root dir # bin/mule * Expected: Mule starts and flow listens on 127.0.0.1:8811/in1 and 127.0.0.1:8811/in2 * Actual: Mule fails to start because $[http.port] is an invalid value for port * Note: I put domain.properties file in domain root directory because in domain/classes it is not found | 5 |
| 604 | MULE-8232 | Core extension dependencies are not initialized in order | Core extensions are initialized using the discorevy order instead of the order determined after resolving the dependencies. | 1 |
| 605 | MULE-8233 | Move tests/functional tests to tests/integration | tests/functional should be only for test harness | 3 |
| 606 | MULE-8234 | Do not publish test-jar for any module that is not test harness | We publish test source code, we don't need to distribute test binaries except for the test harness. | 8 |
| 607 | MULE-8235 | Remove functional-tests jar from distributions | Validate with community/support/developers | 5 |
| 608 | MULE-8236 | Integrate Mule ESB Matchers | # Test matchers ## Pass and fail scenarios ## Test error description # Verify that we didn't created a similar one yet # Documentation | 13 |
| 609 | MULE-8239 | Supported and recommended JRE version should be at least 1.7.0_60 | In MULE-6866 we upgraded to Groovy 2.3.7-indy but according to [Groovy docs|http://groovy.codehaus.org/InvokeDynamic+support] there are known issues with Java versions lower than 7u60. We should increase supported and recommended versions to 1.7.0_60 | 1 |
| 610 | MULE-8240 | Allow extension components to extend existing functionality | There're cases in which an operation implemented through the ext-api should be part of an specific substitution group. Because substitution groups are an XSD specific concept and because the same concept might be necessary in other DSL types, we need a mechanism to denote extensibility that goes beyond Java's "extends" and "implements" keywords but is still type related. For that purpose, two new annotations are created: @Extensible: means that a given type is extensible by another extension. It doesn't mean type subclassing, but extension from a functionality point of view. This annotation has an optional String alias() attribute to allow a better experience when generating XSD @ImplementationOf(type=XX.class): This annotation can be used on a class or method implementing operations. It means that the affected operations are to be part of a substitution group defined by an extensible type. The type argument in this annotation is mandatory and has to be a type that is annotated with @Extensible | 3 |
| 611 | MULE-8241 | Allow restriction on which types of operations can be nested | Currently, the ext-api supports nested operations through the use of arguments of type NestedProcessor. However, the generated schema allows any type of message processor to be nested. There're cases in which it's necessary to limit that to specific groups. For those cases, a new annotation is created: @RestrictedTo(type=XX.class) The type used in that annotation has to be annotated with @Extensible. By doing that, the SchemaGEnerator will generate a specific named group for that extensible type and only items on that group will be allowed as nested for that operation | 5 |
| 612 | MULE-8242 | Rename extensions -> extension in java package name | Also ExtensionManager is better than ExtensionsManager in english IMO. | 1 |
| 613 | MULE-8248 | OAuth authentication code doesn't fail when access token is null | When consuming some APIs such as Facebook or Google Contacts a response code 400 is returned according to the log, but it does not match with the debugger HTTP response code, which is 401 NOTE: using success status code validator, does not avoid the exception. We tested with 400 and 401 See attached documents | 5 |
| 614 | MULE-8253 | Spring Spike part II: Take lifecycle away from Spring | Continue the Spring registry spike, this time try to take lifecycle control away from Spring | 8 |
| 615 | MULE-8254 | Spring Spike part III: Make a fast registry for tests | Continue the spring spile. This time, make a fast registry for tests | 8 |
| 616 | MULE-8257 | The changes in MULE-7742 impacted in performance, a better solution should be used. | Review that changes in MULE-7742 and the previous changes proposed by Victor Romero. | 13 |
| 617 | MULE-8260 | Deprecate org.mule.util.scan classes in Core in order to support Java 8 | Our current version of ASM (3.3.1) is not fully compliant with Java 8, so we need to deprecate it use for 3.7 M1 and look for a replacement in 3.7 M2. | 5 |
| 618 | MULE-8264 | Support TLS SNI Extension in Http OutboundEndpoint | Java does not send SNI because of the the socket is created. While Java 7 supports the SNI extension with TLS it only uses it if the hostname is specified when the Socket is created rather than a InetAddress (it doesn't get hostName from InetAddress). | 5 |
| 619 | MULE-8265 | Test support for TLS SNI Extension in Http Module Requester | Currently not supported. Also review listener support. | 8 |
| 620 | MULE-8267 | Mule 3.6 HTTPS Request Connector does not validate certificate presented by remote server | The server SSL certificate is not validated by requestor at all. | 8 |
| 621 | MULE-8270 | HttpRequester not configuring TLS cipher suites and protocols | The HTTP requester from the new module is not configuring restricted protocols and cipher suites for TLS. | 8 |
| 622 | MULE-8273 | Document new HTTP Connector | Add documentation for HTTP Connector | 5 |
| 623 | MULE-8274 | Discuss how to: Mule Test Harness should include Mule jars in test classpath | Now when a user creates a Maven Mule project when he runs the tests gets errors because not including in the classpath Mule jars. We should have a way to make tests include those jars. One possible solution is to make the archetypes include Mule ESB distribution dependency with runtime scope. This way all transitive dependencies would be included when running tests. | 5 |
| 624 | MULE-8277 | OAuth2 postAuthorize() with an expired token fails even if token was refreshed | The Box connector has a postAuthorize method that invokes one of the connector's processors. When one of the connector's processors is invoked and the postAuthorize is called with an expired access token, the BaseOAuth2Manager is able to refresh the access token but re-throws the token expired exception which makes processor invocation fail. I believe the issue can be found in the following method: org.mule.security.oauth.BaseOAuth2Manager.postAuth(OAuth2Adapter, String) | 1 |
| 625 | MULE-8278 | HTTP Listener does not handle "Expect: 100-Continue" (RFC 2616) header correctly | This can cause depending the scenario: 1) 1s latency overhead 2) Requests to hang | 8 |
| 626 | MULE-8282 | 401 response received, but no WWW-authenticate header was present | I've been searching and and tinkering since last week to figure out what is wrong with this, but no matter how I tried it still gives me this error in the console. I'm testing the http connector (3.6 EE) against twitter ReST API vs testing with Chrome's POSTMAN Rest client. With the POSTMAN client, it is working fine when POSTing status update. However with Mule it fails and gives me the error mentioned. I even added "WWW-Authenticate" (replaced "Authorization") before the call to http connector itself, and tried with adding it to header as well, still everything fails. Note: For the get timeline it is working both on Postman rest client and http connector, but when I tried on POSTing to status/update.json, Postman is successful, while Anypoint http connector fails. | 5 |
| 627 | MULE-8284 | Http Listener allows inexistent keystore | When I create an https listener Mule validates that the trustsore file exists but it doesn't validate that the keystore file exists. Try with the attached config. Create the truststore like this: keytool -genkey -alias mule -keyalg RSA -keystore keystore.jks -dname "CN=Mule, OU=Engineering, O=MuleSoft, L=BA, ST=BA, C=AR" | 5 |
| 628 | MULE-8287 | Allow cipher suite and protocol configuration per connector | TLS cipher suite configuration is done through conf/tls-default.conf for all the Mule Server. We need a way to allow per connector configuration. Use cases: - Connect to a legacy API uses a vulnerable cipher suite for which the vulnerability has been mitigated, but I don't want to allow that cipher suite for other consumed APIs. - Because of internal security policy I need to use a particular set of cipher suites to publish an API but I need to consume an external API wich uses a different cipher suites not allowed internally. | 5 |
| 629 | MULE-8486 | Allow to set certificate alias in keystore configuration | When multiple certificates are installed in the keystore file, we need to provide a mechanism to pick one in the tls context element. How this is done can be review but most likely is using the certificate alias. So an alias optional attribute must be used in the keystore element. When there are multiple certificates and alias is not defined we should define hich on we should pick. | 3 |
| 630 | MULE-8288 | Disable SSLv3 by default on FIPS 140-2 scenario | The file tls-fips140-2.conf doesn't restrict enabled protocols by default. When enabling FIPS 140-2 on wrapper.conf, SSLv3 gets enabled by default. | 1 |
| 631 | MULE-8290 | HTTP static resource component fails with HTTP listener | The HTTP static resource component fails with the new HTTP listener component because it doesn't extract correctly the listener path to define the resource to return. | 5 |
| 632 | MULE-8291 | Client credentials does not fail if it could not retrieve access token | When using client credentials, start up of the application does not fail if mule was not able to retrieve an access token. Additionally some logging information must be added for troubleshooting. | 5 |
| 633 | MULE-8292 | HTTP Listener doesn't validate clients | When using tls:trust-store in an HTTP listener it doesn't validate the client certificate. Reproduce running: curl -k https://localhost:4443 {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:tls="http://www.mulesoft.org/schema/mule/tls" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.6.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/tls http://www.mulesoft.org/schema/mule/tls/current/mule-tls.xsd"> <http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="0.0.0.0" port="4443" doc:name="HTTP Listener Configuration"> <tls:context> <tls:trust-store path="keystore.jks" password="storepass" /> <tls:key-store path="keystore.jks" password="storepass" keyPassword="keypass" /> </tls:context> </http:listener-config> <flow name="1"> <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP" /> <set-payload value="#['Message received at ' + new Date().toString()]" doc:name="Set Payload" /> </flow> </mule> {code} | 5 |
| 634 | MULE-8295 | Upgrade to grizzly 2.3.19 | See fixes includes multiple bug fixes plus two improvments I requested: 1) SNI Support out of the box with SSLFilter. https://java.net/jira/browse/GRIZZLY-1737 2) Mechanism to limit size of send queue and this direct memory use. https://java.net/jira/browse/GRIZZLY-1730 | 8 |
| 635 | MULE-8297 | Upgrade CXF to 2.7.15 version | Mule 3.7 needs to run using Java 8, but current CXF major version (2.5) does not support it, and we have to move to version 3. We need to define how to provide (if possible) backwards compatibility and how to use the new version. | 13 |
| 636 | MULE-8298 | Upgrade Spring to version 4.1 | In order to support Java 8 we need to move to a newer version of Spring. | 8 |
| 637 | MULE-8301 | Upload 3.6.0 javadocs | Upload javadocs to: https://www.mulesoft.org/docs/site/3.6.0/apidocs | 5 |
| 638 | MULE-8303 | ClassCastException when setting a MEL expression in the config-ref of a Connector's call | When a MEL expression is set in the config-ref of a Salesforce Connector call and the object-store has no OAuthState stored for a user, the operation fails for that user with a ClassCastException with the following message. ******************************************************************************** Message : Failed to invoke describeSObject. Message payload is of type: CaseInsensitiveHashMap Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. java.lang.String cannot be cast to org.mule.security.oauth.OnNoTokenPolicyAware (java.lang.ClassCastException) org.mule.devkit.processor.DevkitBasedMessageProcessor:97 (null) 2. Failed to invoke describeSObject. Message payload is of type: CaseInsensitiveHashMap (org.mule.api.MessagingException) org.mule.devkit.processor.DevkitBasedMessageProcessor:128 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.lang.ClassCastException: java.lang.String cannot be cast to org.mule.security.oauth.OnNoTokenPolicyAware at org.mule.devkit.processor.DevkitBasedMessageProcessor.process(DevkitBasedMessageProcessor.java:97) at org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) at org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:58) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** I believe the issue can be found in the following method: org.mule.devkit.processor.DevkitBasedMessageProcessor.process(MuleEvent) line 97. moduleObject is cast to OnNoTokenPolicyAware without verifying if it is a String. The method findOrCreate does verify that in line 174. | 5 |
| 639 | MULE-8304 | It is not possible to define more than one keystore/truststore | The TLS contexts introduced in 3.6 interfere with each other. Reproduce with the following scenario, where there are two flows that consume an HTTPS service, one with the server certificate in the truststore, and the other one without it. The first flow should work but the second one should fail. Currently, they both work correctly. <http:request-config name="validCertHttpConfig" protocol="HTTPS" host="localhost" port="${httpsPort}"> <tls:context> <tls:trust-store path="trustStore" password="mulepassword" /> </tls:context> </http:request-config> <flow name="validCertFlow"> <http:request config-ref="validCertHttpConfig" path="requestPath" method="POST" /> </flow> <http:request-config name="missingCertHttpConfig" protocol="HTTPS" host="localhost" port="${httpsPort}" > <!-- No certificate has been configured to test certificate verification --> </http:request-config> <flow name="missingCertFlow"> <http:request config-ref="missingCertHttpConfig" path="requestPath" method="POST" /> </flow> | 5 |
| 640 | MULE-8368 | Modify substitutableInt restriction to allow APIGateway extension language | API Gateway has an extension language composed by: ![ <language extension> ] This extension cannot be used in the port property of the listener-config and request-config, because of the substitutableInt restriction. The actual regex in the restriction is: <xsd:pattern value="(\#\[.+\]|\$\{[^\}]+\})"/> Including the Gateway language extension should be: <xsd:pattern value="(\#\[.+\]|\$\{[^\}]+\}|\!\[.+\])"/> | 1 |
| 641 | MULE-8307 | HTTP requester throws timeout errors with POST request | Appears to be related to the "Expect: 100 continue" header with Grizzly, that is found in HTTP/1.1 POST request. The bug reproduces in ESB 3.6 and 3.6.1, also GW 1.4. attached is the jmx file, using this proxy app for ESB (no Gateway tags). https://github.com/mulesoft/performanceworks/blob/master/APPS/PROXY-MCD/100B/http_module_proxy/proxy.xml If you change the method to GET instead of POST, you will not get the error. You should be able reproduce it easily. Wai ERROR 2015-02-11 00:29:48,112 [[PabloTestAPI_NewHTTP].proxyConfig.worker.09] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : Error sending HTTP request. Message payload is of type: BufferInputStream Code : MULE_ERROR-29999 -------------------------------------------------------------------------------- Exception stack is: 1. null (java.util.concurrent.TimeoutException) org.glassfish.grizzly.impl.SafeFutureImpl$Sync:357 (null) 2. Error sending HTTP request. Message payload is of type: BufferInputStream (org.mule.api.MessagingException) org.mule.module.http.internal.request.DefaultHttpRequester:190 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: java.util.concurrent.TimeoutException at org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerGet(SafeFutureImpl.java:357) at org.glassfish.grizzly.impl.SafeFutureImpl.get(SafeFutureImpl.java:264) at com.ning.http.client.providers.grizzly.GrizzlyResponseFuture.get(GrizzlyResponseFuture.java:173) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** | 13 |
| 642 | MULE-8312 | HTTP requester always add a / at the beginning of the request URI | An http requester with this config http:request path="something" should generate a request with uri something but it's generating /something instead. | 5 |
| 643 | MULE-8318 | WS consumer not evaluating flow vars in the serviceAddress when used with the new HTTP connector | WS consumer allows MEL expressions in the serviceAddress property. Since 3.6, when the new HTTP connector is used by default, flowVars are not recognized in MEL expressions in the serviceAddress. The only variables that work are properties related to the Mule message. With the HTTP transport it works OK. This is because the outbound call uses muleClient to use the HTTP requestor, and the MuleEvent that carries the flowVars is lost. To reproduce, modify DynamicAddressFunctionalTestCase to use a flow var instead of an inbound property. | 5 |
| 644 | MULE-8325 | Review and merge MULE-7588 | Review and merge MULE-7588 | 5 |
| 645 | MULE-8326 | write a spec on new lifecycle and registry consolidation | Write and circulate a spec on MULE-7588 | 8 |
| 646 | MULE-8328 | HTTP delete body is not allowed | I am not able to call HTTP delete verb from mule HTTP connector with body . | 5 |
| 647 | MULE-8330 | Improve Jenkins email notifications to add the info about who made the last commit | Mail Notifications of failure don’t have the message of the commit which launch the build. | 3 |
| 648 | MULE-8331 | Application Plugins (Cloud Connectors) support for external dependencies | As a user I will like to use a connector such as Siebel, packaged as a plugin deployed in the plugins folder and be able to use external dependencies that cannot be shipped inside the connector. | 8 |
| 649 | MULE-8332 | Fix Mule ESB Maven Tools testing for apps using domains. | 1.1-SNAPSHOT right now depends on changes for 3.7 that haven't been done yet. We need to modify it so that ExampleFunctionalTestCase extends from DomainFunctionalTestCase if the app belongs to a domain. | 3 |
| 650 | MULE-8338 | HTTP listener fails when receiving empty request with content type x-www-form-urlencoded | When a POST request with content type application/x-www-form-urlencoded and empty body is sent to an http:listener, a 500 response is received and the flow is not executed. This happens because of a ClassCastException inside the listener. The flow should be executed, with NullPayload in the Mule message. | 1 |
| 651 | MULE-8341 | Domain redeployment fails with zip file closed | When doing a redeploy of a domain it fails with zip file closed when trying to reload some classes. | 5 |
| 652 | MULE-8343 | Review and update classloading documentation | Documentation of mule classloading at http://www.mulesoft.org/documentation/display/current/Classloader+Control+in+Mule is not accurate and is out of date. There are missing things like application plugins, new domain classloading, etc | 5 |
| 653 | MULE-8346 | HTTP Request returns 401 when given correct authentication | A prospect has not been able to connect to a web service hosted in IIS using Digest auth in the HTTP listener. They could connect using a java class with same credentials. none of the following combination worked as username in the HTTP connector: {realm\username, realm\\username, username:realm. Here is the webservice I used to reproduce the error: http://httpbin.org/digest-auth/auth/user/passwd Credentials {username=user, password=passwd} If needed: port=80; realm=me@kennethreitz.com Returned is 401: unauthorized | 8 |
| 654 | MULE-8350 | After upgrade CXF to 2.7.15 some jaxws-client configurations fail when using a proxy. | When the service method receives a Holder OUT parameter and then a String, the string value is not received by the server. If the method returns void, then the value placed in the OUT parameter does not arrive the to client. See org.mule.module.cxf.HolderTestCase, method testClientProxyEcho3Holder. | 8 |
| 655 | MULE-8353 | README.txt in <MULE_HOME>/logs is outdated | The README.txt has not been updated to reflect the changes derived from the implementation of log4j 2. | 1 |
| 656 | MULE-8388 | Remove JRuby from distribution | There is a vulnerability issue on the jruby version used in old Mule version. Updating Jruby to a newer version requires to upgrade to joda time, which also requires to update other dependencies. So we have decided to remove JRuby from old Mule distributions | 8 |
| 657 | MULE-8356 | Source attribute in http requester not working when payload is null | When the "source" attribute is specified in an http:request element, it is ignored when the payload of the Mule message is NullPayload. Example: <http:request-config name="config" host="localhost" port="${httpPort}" /> <http:listener-config name="listenerConfig" host="localhost" port="1234" /> <flow name="formParam"> <http:listener config-ref="listenerConfig" path="/*" allowedMethods="GET,POST" /> <set-variable variableName="httpBody" value="#[{'testName1':'testValue1', 'testName2':'testValue2'}]" /> <!-- With this line uncommented, the map is sent. If not, the POST request has no body even if the source attribute contains a map. <set-payload value="test" /> --> <http:request config-ref="config" path="testPath" method="POST" source="#[flowVars.httpBody]" /> </flow> | 5 |
| 658 | MULE-8364 | Update commons-io in mule-commons to match the one used in mule | In mule-common the commons-io version is 1.4: {code} <!-- Same version as Mule! --> <dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>1.4</version> </dependency> {code} While mule is declaring the version to 2.4: {code} <commonsIoVersion>2.4</commonsIoVersion> {code} This happens both in 3.6.x and master branches. | 1 |
| 659 | MULE-8370 | ObjectAlreadyExistsException when using splitter and until-successful | When using a splitter and an until-successful message processor, the following exception is thrown: ERROR 2012-10-03 14:46:09,550 [[5955-until-successful].connector.http.mule.default.receiver.04] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : null Code : MULE_ERROR--1 -------------------------------------------------------------------------------- Exception stack is: 1. null (org.mule.api.store.ObjectAlreadyExistsException) org.mule.util.store.AbstractObjectStore:53 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/store/ObjectAlreadyExistsException.html) Root Exception stack trace: org.mule.api.store.ObjectAlreadyExistsException org.mule.util.store.AbstractObjectStore.store(AbstractObjectStore.java:53) org.mule.routing.UntilSuccessful.storeEvent(UntilSuccessful.java:300) org.mule.routing.UntilSuccessful.storeEvent(UntilSuccessful.java:291) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) Steps to reproduce: 1) deploy the attached application '5955-until-successful.zip' 2) invoke the app by hitting "http://localhost:8080/in" Expected: each message in the split list should be assigned a unique id in the UntilSuccessful class which will be used in the object store Actual: only the first message in the list is sent successfully as the second message throws an exception (the mule event id is used and since this is the same for each message, the exception above is shown) Workaround: as a workaround, one may create an extra flow and make use of a vm queue in between the splitter and until-successful. This creates a new event per message, hence the exception does not occur. | 3 |
| 660 | MULE-8373 | Upgrade ActiveMQ to version 5.11.0 | We need to evaluate the effort and migrate ActiveMQ dependencies to 5.11.0 to take advantage of the latest bugfixes. | 3 |
| 661 | MULE-8376 | Release Mule ESB Maven Tools (v 1.1) | We need to release version 1.1 (ideally for 3.7) since this version now includes a proper test case for apps that belong to a domain. The release will also mean reviewing the current solution and testing the tools. | 8 |
| 662 | MULE-8382 | Can't uncompress zip files containing no entries for folders | Mule requires ZIP files that contain entries for folders and files like this: x/lib x/lib/a.jar x/lib/b.jar When the zip file contains only entries for files lie this: x/lib/a.jar x/lib/b.jar The file cannot be processed correctly. | 2 |
| 663 | MULE-8383 | log4j2.xml not being loaded during functional test case | When doing a functional test case logs are not active by default. The idea should be that if I place a log4j2.xml in some place in the classpath then I should be able to enable logs. What happens is that this file is not getting picked up. Doesn't really matter in which part of the application folder structure is placed it doesn't get loaded. If you run a test the only thing you see is: WARN 2015-03-13 10:11:07,233 [main] org.mule.tck.junit4.AbstractMuleTestCase: -------------------------------------------------------------------------------- Hung threads count: 2. Test case: org.mule.munit.TheTest. Thread names: -> AsyncLoggerConfig-1 - 10 -> ReaderThread - 8 -------------------------------------------------------------------------------- Now you try to configure Log4j2 on your own the logs start working just fine but in order to do that you need to add this code to your test: try { URI configuration; configuration = Thread.currentThread().getContextClassLoader().getResource("log4j2.xml").toURI(); Configurator.initialize("config", null, configuration); } catch (URISyntaxException e) { e.printStackTrace(); } Please check the attached project for more data. Please notice that the application has just a logger MP with level Debug which by default shouldn't be printed unless you change the logs (which works just fine when running mule normally) | 5 |
| 664 | MULE-8407 | Backport MULE-8315 and MULE-7789 to all maintenenance branches | As part of the library updates related to security vulnerabilities, there is a couple of changes that must be backported to 3.5.x, 3.4.x, 3.3.x, 3.2.x and 3.1.x: MULE-7789: needed to remove the usage of tomcat-util artifact (this one is already included in 3.5.x branch) MULE-8315: needed to upgrade tomcat libraries to a newer version | 8 |
| 665 | MULE-8408 | Collection splitter is not setting the group size when payload is an Iterator | Salesforce queries return an iterator and when a collection splitter is used, it fails to aggregate the collection after because the group size is set to -1. Attached mule config This seems to be happening because this class https://github.com/mulesoft/mule/blob/bfb3a17263d1e4b32ee10272cbf710a2bf41b16b/core/src/main/java/org/mule/routing/outbound/IteratorMessageSequence.java is used from https://github.com/mulesoft/mule/blob/1dbf6e09a651184e9c54ec8988ecf1907cbdd58f/core/src/main/java/org/mule/util/collection/EventToMessageSequenceSplittingStrategy.java and it is setting UNKNOWN_SIZE as Group size for all Iterator payloads | 5 |
| 666 | MULE-8410 | Leverage MULE-7588 in extensions api | Leverage the work done in MULE-7588 to implement a corrected lifecycle and dependency injection in the extensions api | 8 |
| 667 | MULE-8411 | XmlToXMLStreamReader does not support OutputHandler as source type | XmlToXMLStreamReader declares OutputHandler as source type (in its superclass) but fails to convert that type. | 3 |
| 668 | MULE-8412 | Reuse OperationImplementation instances instead of creating and injecting new ones each time | Currently the ext-api is creating a new instance of the operation implementation for each event. That is very confortable for the user, but it has performance considerations associated to garbage collection and the new to perform dependency injection all the time. We need to move to a schema in which: * One instance is created per configuration and reused as long as that configuration lives * The Class holding the method annotated with @Operation needs to have a constructor which receives a single argument which is the configuration to use. Failure to provide such a constructor which result in the application not starting * Upon creation, Mule will inject dependencies on this class but will not add it to the registry * This also means that it will no longer be valid to obtain things like the MuleEvent through a @Inject annotation, you have to receive it a method argument, which means that the invoker needs a refresh too | 8 |
| 669 | MULE-8415 | Add a backwards compatiblity setting to support Devkit artifacts which violate JSR-330 | Per the work done on MULE-7588, Mule now supports the JSR-330 spec. However, as DEVKIT-1539 explains, Devkit is currently violating that spec. Devkit will fix this for the latest version but we need to add a compatibility setting to allow artifacts generated with older versions of devkit to function. This will work by customizing the injecting post processor to detectinstances which instances are devkit generated and skip dependency injection on them | 5 |
| 670 | MULE-8416 | Domains are not well disposed and get reused on redeploy. | Domains are cached on creation but they are not correctly removed on dispose so on redeployments they get reused. | 5 |
| 671 | MULE-8421 | Improve MuleMessage's data type consistency | DefaultMuleMessage's datatype is not being properly updated and maintained. For example: _DefaultMuleMessage#setEncoding does not update dataType's encoding _DefaultMuleMessage#setMimeType does not update dataType's mimeType _DefaultMuleMessage#setPayload does not update dataType's type _DefaultMuleMessage#setProperty is not update dataType when a encoding property is set on the message Improving data type consistency and propagation is required to better support auto transformations and mapping tools | 8 |
| 672 | MULE-8422 | Implement Validations XML components | Implement Validations XML components | 8 |
| 673 | MULE-8423 | Create MEL version for each validator in the validations module | Create MEL version for each validator in the validations module | 5 |
| 674 | MULE-8435 | Check if Ext-api jars are Maven Central compliant | Perform that verifyication on the mule-extensions-api and mule-extensions-api-annotations projects | 5 |
| 675 | MULE-8439 | Remove unused manifest files | These MANIFEST files are present in our code but are not used: ./modules/boot/src/main/resources/META-INF/MANIFEST.MF ./modules/builders/src/main/resources/META-INF/MANIFEST.MF ./modules/jaas/src/main/resources/META-INF/MANIFEST.MF ./modules/management/src/main/resources/META-INF/MANIFEST.MF ./modules/ognl/src/main/resources/META-INF/MANIFEST.MF ./modules/scripting/src/main/resources/META-INF/MANIFEST.MF ./modules/xml/src/main/resources/META-INF/MANIFEST.MF They are all replaced by the manifest configured in root pom.xml This manifest ./core/src/test/resources/META-INF/MANIFEST.MF is used to test the Java version checking, we shouldn't use a real manifest, we should use a fake one to check that version control is working. | 3 |
| 676 | MULE-8441 | Add a way to inject all available core extensions in a core extension | Mule core extensions can have dependencies against other core extensions, but these dependencies are fixed on compile time (dependencies are defined using MuleCoreExtensionDependency method annotation). In order to properly support some management scenarios, we need to provide a way to let a core extension to receive all the available core extensions. Given the constraints on lifecycle imposed by the MuleCoreExtensionDependency dependencies, a core extension that receives all the available core extensions cannot contain any methods annotated with it. | 5 |
| 677 | MULE-8442 | app.home property is no longer available | When an application is deployed, the Spring configuration builder is running before the SimpleConfigurationBuilder making some properties like app.home not available to the mule config | 1 |
| 678 | MULE-8447 | extension API should consistently always inject values through fields instead of setters | Right now, when the ext-api creates an object uses setters to inject values parsed from XML, while in some other scenarios like when resolving expressions it uses fields. That leads to some inconsistency plus the setter injection limits the ability to encapsulate the internal representation of some object's state. Always use fields to inject values. | 1 |
| 679 | MULE-8448 | ExtensionResourcesGeneratorAnnotationProcessor is not been fired | ExtensionResourcesGeneratorAnnotationProcessor is not been fired because the full classname of @Extension has changed and the refactor didn't modified this file. This is because of a java language limitation which doesn't allow a .class.getName() kind of reference there. As a result, xsd is not generated when building a extension | 1 |
| 680 | MULE-8450 | add the concept of parameter alias in the ext-api annotations | When using the ext-api through annotations, there're limitations on the possible names that parameters can take because of the java language reserved words. For example, an attribute cannot be named class. Another problem is when from a coding point of view, an attribute should have one name which isn't so representative when seen from an extension's parameter point of view. Because of that, we need the ability to add an alias attribute to the @Parameter annotation. | 1 |
| 681 | MULE-8451 | The application logging configuration is not read or used. | When deploying an app with a logging congif (log4j2.xml), mule doesnt use its config and use the default every time. Steps to reproduce: Deploy the attached app on a mule instance. Wait for it to be deployed. The default app log will be created no matter which configuration was given. Expected behavior: Log into the configured file instead of the default one, if using Console, should log into mule_ee.log or mule.log (depending on the distribution). | 1 |
| 682 | MULE-8452 | Introduce type level aliases for extensions API | When the XML support for the ext-api maps a java complex type as a top level element (usually the case when defining global pojos), there's the need to provide an alias so that the global element can have a name which is not directly tied to the Java type name. | 1 |
| 683 | MULE-8453 | Add data type to message properties | MuleMessage properties have no information about the type of the value they are holding. Providing a way to maintain this information will help to support more transformation scenarios and will improve usability in Studio | 5 |
| 684 | MULE-8457 | Replace SetPayloadTransformer with a plain message processor | SetPayloadTransfomer is the implementation behind set-payload element. As the name implies, is a Transformer and is executed invoking muleMessage transformation capabilities. Problem with this transformer is that it returns only a value and in order to properly propagated message's dataType, it must set the correct dataType (the one configured by the user). Besides that, transfomer's source/target dataType is not valid on this particular case, because the datatpye is dynamic (assigned value can be resolved from an expression). So dataType can't be statically defined. | 5 |
| 685 | MULE-8458 | Upgrade async-http-client to 1.9.19. | We need to upgrade to version 1.9.18 in order to support NTLM. Here's AHC's migration guide: https://github.com/AsyncHttpClient/async-http-client/blob/master/MIGRATION.md There could also be some issues with missing multipart classes. | 13 |
| 686 | MULE-8459 | Implement NTLM authentication for the HTTP Requester | Once AHC is upgraded to 1.9.18 we should be able to add support for NTLM. | 5 |
| 687 | MULE-8464 | Make json schema validator interoperable with the new Validator module | In mule 3.6.0 a json schema validator was introduced. It should be made interoperable with the new validation module introduced in MULE-8216 so that it can participate in <validation:all> operation | 1 |
| 688 | MULE-8465 | Improve set properties transformers to set property datatype | Mule message properties now contain a datatype. All the transformers that set properties in a message/session should provide a way to configure the datatype and update that datatype in the property accordingly. | 8 |
| 689 | MULE-8466 | Generated XSD defines restriction groups by extension | When an operation takes NestedProcessors as an argument, the @RestrictedTo annotation can be used to limit the acceptable message processors to a given substitution group. However, what the XSD generator is doing is to create a group which lists all of the operations in the given restriction type. Because that group is fixed, it doesn't allow to externally contribute more elements with the same substitution group. What the generator should do is to define a group which has a reference to the substitutionGroup and thus allowing variable elements which meet the restriction | 1 |
| 690 | MULE-8467 | ArgumentTypeMismatch when many nested operations are supported but only one is provided | The ext-api supports defining operations which can take one nested Operation or a list of them. When the operation supports many but only one is provided, the ResolverSetResult doesn't contain a list of one NestedOperation but a single one, which results on an ArgumentTypeMismatch. | 1 |
| 691 | MULE-8468 | Improve data type propagation for properties | Work done on MULE-8453 did not include updating some property setter methods to include datatype. | 2 |
| 692 | MULE-8469 | Message transformation must no update payloads data type when payload was not transformed | DefaulMuleMessage#transformMessage(MuleEvent, Transformer) always updates the message data type to the transformer output data type. That is wrong because some transformers update parts of the message other than the payload. (like message properties) Probably those transformers should be plain message processors, but a way to fix this problem is to check that payload has changed after the transformation. | 3 |
| 693 | MULE-8473 | Configs should be optional when using Ext-api operations in a flow | Right now, every MP which executes an extension operation is required to provide a config. This is not good from a usability standpoint so the desired behaviour is: * If a config is specified through the config-ref attribute, then use it * If no config is specified but there's one configured, then locate it and use it * If no config is specified nor defined, then depending on the extension an implicit one can be created. An implicit configuration is created by simply instantiating the default config. Configs should be marked as not supporting implicit creation through some annotation/annotation attribute | 8 |
| 694 | MULE-8474 | remove the "repackaged" package from extension-support module | Because ext-api development started when mule was using Spring 3.x, a Spring 4.x package was embedded into our code. Now that Spring was upgraded to the lastest version, that repackage should be remove in favor of the original classes in the spring jar | 1 |
| 695 | MULE-8475 | Implement a solution to automatically infer supported schema versions for XML compatible extensions | Right now, when an extension is to have XML support, the @Xml annotation includes a "schemaVersion" attribute. That is not a scalable solution because assuming that an extension is released in version 3.7, then its spring bundle should support schemas 3.7, 3.8, 3.9 and so forth, and it's very undesirable for a developer to traverse through all the extensions modifying that. We need a solution in which given an "inception version" version, the current schema version is inferred and the prior ones back to the inception version are also included in the spring bundle. | 5 |
| 696 | MULE-8476 | Spike on on inferring extension version from project version | Currently, the @Extension annotation includes a version attribute which is used to specify an extension version. However, it's undesirable to have the need to upgrade the version of every extension each time that a new version is released. A mechanism should be defined for the extension version to be automatically inferred from the underlying ${project.version}. There should still be a way to fix the extension version arbitrarily | 8 |
| 697 | MULE-8477 | Validate that Pojo attributes are not composites | When a pojo is used as a parameter in an Extension, XSD support is generated to allow users define the instance on the XML. However, this won't work if the object is a composite. The composite fields should be skipped when generating the XSD support. | 5 |
| 698 | MULE-8478 | It should not be mandatory for a class annotated with @Operation to depend on the config object | Right now, when a class contains methods annotated with @Operation, then it is demanded that a single constructor is available to create the instance and pass the configuration instance over. However, not in all cases the operations in a class require of the configuration. The behaviour should be that if such constructor exists then it's used. If it doesn't, then a default constructor is used to create a config-less operation instance. Only if no constructor is found which matches both criterias should an exception be thrown. | 5 |
| 699 | MULE-8479 | Operations of an Extensible extensions should not require to be annotated with @ImplementationOf | Extensions can be annotated with @Extensible to signal that external modules can extend them further. Right now, it's required for the classes in which such extensions are implemented to be annotated with @ImplementationOf. However, that's redundant since a given extension operations are by very definition extending it. Such annotation should only appear on third party extensions which are in fact extending it. | 5 |
| 700 | MULE-8480 | Consider renaming @ImplementationOf to @ExtensionOf | Consider renaming @ImplementationOf to @ExtensionOf since it's clearer for some persons | 1 |
| 701 | MULE-8481 | WSConsumerConfig should use the HttpRequesterConfig interface rather than the internal implementation | The *connectirConfig* field of the class org.mule.module.ws.consumer.WSConsumerConfig can be configured by passing an initialized instance of a *DefaultHttpRequesterConfig* when it should be using the interface of the the previous one: *HttpRequesterConfig*. This small chance will unblock the DevKit's story [DEVKIT-1527|https://www.mulesoft.org/jira/browse/DEVKIT-1527] providing an automated way of instantiating WSC manually when initializing a HttpRequesterConfig by hand. | 3 |
| 702 | MULE-8482 | Provide a builder for HttpRequesterConfig interface | Despite the normal use case for initializing a HttpRequesterConfig is from the definition parser, for a specific DevKit's story [DEVKIT-1527|https://www.mulesoft.org/jira/browse/DEVKIT-1527] we need to feed the WsConsumerConfig with an already initialized instance of *DefaultHttpRequersterConfig*. Before this jira, ideally, [MULE-8481|https://www.mulesoft.org/jira/browse/MULE-8481] should be tackled down to make WsConsumerConfig consume the HttpRequesterConfig interface, so that from a DevKit's POV initializing objects and passing through the WsConsumerConfig will work properly. | 8 |
| 703 | MULE-8483 | Update message data type when Content-Type property changes | When Content-Type property is set on a message, then payload's data type must be updated to reflect the new value. | 5 |
| 704 | MULE-8484 | Succesful undeployment is not show in console | # Download 3.7.0-M2-SNAPSHOT # Copy any Mule app to apps directory # Start server # Delete default-anchor.txt Undeployment request is logged and is done but concole never shows that now there is only one app deployed and that default app was undeployed successfully. | 1 |
| 705 | MULE-8485 | rename the artifact mule-extension-validations to mule-module-validation | We finally decided to not reflect the difference between a craft module and an ext-api based one on the artifact name since from a user's point of view there shouldn't be a difference | 1 |
| 706 | MULE-8490 | IP Validator should support IPv6 | IP validator should support IPv6, which is not an experimental protocol but a reality. | 3 |
| 707 | MULE-8492 | Email validator failures | Email validator fails for the following cases || email || is valid? || | a@a.com | no (leading space) | | a@a.com | no (trailing space) | | 1 |
| 708 | MULE-8493 | JSR-330 @Named and @Qualifier annotations are ignored | Because of Spring issue https://jira.spring.io/browse/SPR-12914, the @Named and @Qualifier annotations are not taken into account. The issue can be worked around by overriding the org.springframework.beans.factory.support.DefaultListableBeanFactory#findAutowireCandidates method. Apply a temporal fix for this and create another issue to remove that workaround until Spring fixes the issue. | 5 |
| 709 | MULE-8495 | URL validator fails | URL Validator fails for these URLs: Should be valid: http://✪df.ws/123 foo://username:password@example.com:8042/over/there/index.dtb?type=animal&name=narwhal#nose http://userid:password@example.com:8080/ Should be invalid: http://hola.com (trailing space) http://hola. com | 1 |
| 710 | MULE-8496 | Revisit the changes of MULE-8493 when SPR-12914 is fixed | Becaues of https://jira.spring.io/browse/SPR-12914, MULE-8493 had to be created to overcome a limitation on our JSR-330 support. When Spring fixes the issue, the changes applied on that commit should be revisited to see if they're still needed or should be deleted | 1 |
| 711 | MULE-8497 | Upgrade Spring to 4.1.6 | Upgrade Spring to 4.1.6 | 1 |
| 712 | MULE-8498 | Message transformation must maintain original mimeType and encoding when transformer does not provide them | When a transfomer is applyed on a DefaultMuleMessage and changes its payload, then the transformer's output datatype is assigned to the message datatype. However, transformer's output datatype not always defines mimeType and encoding. If a transformer does not change any of those fields, then the fields from original payload's datatype should be used. | 3 |
| 713 | MULE-8501 | ExtensionManagerConfigurationBuilder not invoked when Mule starts in standalone mode | When starting in standalone mode, the ExtensionManagerConfigurationBuilder is not been invoked and thus applications fail to deploy if they contain any extensions | 1 |
| 714 | MULE-8502 | Remove log4j2 error message when building | When running the Maven build from source, the following error message is thrown, even when the build finishes successfully. {quote} [INFO] --- maven-processor-plugin:2.2.4:process (process) @ mule-extension-validation --- ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. {quote} | 1 |
| 715 | MULE-8503 | Remove the "extension" prefix from the generated XSD file name | Since per MULE-8485 we decided that extensions should not have any naming differentiator, the %s-extension-%s pattern which is now used to name generated XSD needs to change to be source agnostic. | 1 |
| 716 | MULE-8505 | XSD Generator creates wrong attribute types for numeric parameters | h2. Size validator has int parameters for min and max values but the generated XSD creates attributes with Long data type. {code:xml} <xs:complexType name="ValidateSizeType"> <xs:complexContent> <xs:extension xmlns:mule="http://www.mulesoft.org/schema/mule/core" base="mule:abstractMessageProcessorType"> <xs:attribute type="mule:substitutableName" use="required" name="config-ref"> <xs:annotation> <xs:documentation>Specify which configuration to use for this invocation.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute type="mule:expressionObject" use="required" name="value"></xs:attribute> <xs:attribute type="mule:expressionLong" use="optional" name="min"></xs:attribute> <xs:attribute type="mule:expressionLong" use="optional" name="max"></xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="message"></xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="exceptionClass"></xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> {code} {code} /** * Validates that {@code value} has a size between certain inclusive boundaries. This * validator is capable of handling instances of {@link String}, {@link Collection}, * {@link Map} and arrays * * @param value the value to validate * @param min the minimum expected length (inclusive, defaults to zero) * @param max the maximum expected length (inclusive). Leave unspecified or {@code null} to allow any max length * @param options the {@link ValidationOptions} * @param event the current {@link MuleEvent */ @Operation public void validateSize(Object value, @Optional(defaultValue = "0") int min, @Optional Integer max, @ParameterGroup ValidationOptions options, MuleEvent event) throws Exception { ValidationContext context = createContext(options, event); validateWith(new SizeValidator(value, min, max, context), context, event); } {code} h2. expressionObject is generated for java.lang.Long parameters in isLong validator {code:xml} <xs:element xmlns="http://www.mulesoft.org/schema/mule/validation" type="IsLongType" substitutionGroup="validator-message-processor" name="is-long"></xs:element> <xs:complexType name="IsLongType"> <xs:complexContent> <xs:extension xmlns:mule="http://www.mulesoft.org/schema/mule/core" base="mule:abstractMessageProcessorType"> <xs:attribute type="mule:substitutableName" use="required" name="config-ref"> <xs:annotation> <xs:documentation>Specify which configuration to use for this invocation.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="pattern"></xs:attribute> <xs:attribute type="mule:expressionString" use="required" name="value"></xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="locale"></xs:attribute> <xs:attribute type="mule:expressionObject" use="optional" name="minValue"></xs:attribute> <xs:attribute type="mule:expressionObject" use="optional" name="maxValue"></xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="exceptionClass"></xs:attribute> <xs:attribute type="mule:expressionString" use="optional" name="message"></xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> {code} | 3 |
| 717 | MULE-8506 | XSD Generator fails to generate documentation for attributes | We should check with [this tool|https://github.com/mulesoft/mule-tool-schema-doc] that the documentation generated for Validators extension is correct. | 5 |
| 718 | MULE-8507 | Replace all string to number validators by a single one | There are several validators that allows to check whether a string has a number format: is-long, is-integer, is-double, is-float, is short. It would be a better user experience to have just one is-number and let user decide on the range using min and max attributes. | 1 |
| 719 | MULE-8509 | CXF Proxy-Client is throwing NullPointerException | Nowadays, if you want to create a proxy, you have to specify the port name and the soapVersion for each binding. This information is provided by the wsdl, so it shouldn't be required, the proxies should detect them automatically. As a consequence, if you have an API with multiple ports, one of them receiving a SOAP 1.1 envelope, and other one receiving a SOAP 1.2 envelope, and if you don't specify the port and the soapVersion in both proxies (service and client) you will not be able to send a SOAP 1.2 message. This means that a simple proxy cannot be used with both types of SOAP versions. | 8 |
| 720 | MULE-8510 | Setting a NullPayload in a property must behave as setting null | Mule uses NullPayload to represent a null value in a MuleMessage's payload. When a message has NullPayload and a property is set using an expression like #[payload], then the property will contain NullPayload. This situation requires that checking a property requires to consider NullPayload value as a separate case other than null and not null. | 2 |
| 721 | MULE-8512 | Allow default processing strategy to be configured per app | Currently if you want to use a sync processing strategy in every flow it is necessary to configure it on every single flow in your app. Add a attribute to the <configuration> element to define this once. Also, consider allowing a system property too. This would be useful for: - Alternative testing plans - Setting default per instance, e.g. in cloudhub maybe. {code:xml} <configuration defaultProcessingStrategy="non-blocking" /> {code} | 3 |
| 722 | MULE-8514 | Add support for non-blocking processing strategy to CXF/WS-Consumer | Add support so that CXF/WS-Consumer can be used in Flow and non-blocking processing supported. | 8 |
| 723 | MULE-8515 | NPE in is-long validator when setting a null locale | When setting programatically the locale to null validator fails with NPE {code:xml} <flow name="full-long"> <validation:is-long value="#[payload]" pattern="#[pattern]" message="#[message]" exceptionClass="#[exceptionClass]" locale="#[locale]" minValue="#[minValue]" maxValue="#[maxValue]" config-ref="validation"/> </flow> {code} {code} @Test public void otherIsLong() throws Exception { MuleEvent event; event = getTestEvent("400%"); event.setFlowVariable("pattern", "###%"); event.setFlowVariable("locale", null); event.setFlowVariable("minValue", null); event.setFlowVariable("maxValue", null); event.setFlowVariable("message", "Wrong pattern."); event.setFlowVariable("exceptionClass", java.lang.ArrayIndexOutOfBoundsException.class); runFlow("full-long", event); } {code} | 1 |
| 724 | MULE-8518 | Provide access to client certificate on 2-way TLS authenticated connections | When a 2-way TLS authenticated connection is created the client certificate should be exposed in the flow since it may be useful to use it to identify the client. We are going to expose the client certificate ONLY (not the CA certificates) in the flow using a new inbound property http.client.cert. The user can access the client principal by doing message.inboundProperties['http.client.cert'].getSubjectDN() We analyse if there is any risk by exposing the certificate as an inbound property but we got to the conclusion that there's no risk since the client certificate is publicly available in general and it's not used for the communication encrypt / decrypt. It's only used to identify the client. | 5 |
| 725 | MULE-8519 | Add a trace/debug log when a Validation was done successfully | It would be nice to have a trace/debug log that is shown after a validator is successfully executed. The log message should mention the info to identify the validator itself and the arguments used in the execution of the validator. | 1 |
| 726 | MULE-8520 | is-true validator throws ValidationException for String input | is-true and is-false validators throw IllegalArgumentException for non boolean values. But for String values throw ValidatorException | 3 |
| 727 | MULE-8521 | Validators fail when used with a MEL expression inside a component | When you use a MEL expression Validator inside another component, the following error is thrown: {quote} ******************************************************************************** Message : Execution of the expression "validator.validateUrl('http://www.mulesoft.com')" failed. (org.mule.api.expression.ExpressionRuntimeException). Message payload is of type: NullPayload Code : MULE_ERROR--2 -------------------------------------------------------------------------------- Exception stack is: 1. [Error: unresolvable property or identifier: _muleEvent] [Near : {... tension.validation.internal.el.ValidatorElContext(_muleEvent) ....}] ^ [Line: 1, Column: 66] (org.mule.mvel2.PropertyAccessException) org.mule.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer:693 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/mvel2/PropertyAccessException.html) 2. Execution of the expression "validator.validateUrl('http://www.mulesoft.com')" failed. (org.mule.api.expression.ExpressionRuntimeException) org.mule.el.mvel.MVELExpressionLanguage:202 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/expression/ExpressionRuntimeException.html) 3. Execution of the expression "validator.validateUrl('http://www.mulesoft.com')" failed. (org.mule.api.expression.ExpressionRuntimeException). Message payload is of type: NullPayload (org.mule.api.MessagingException) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor:32 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: [Error: unresolvable property or identifier: _muleEvent] [Near : {... tension.validation.internal.el.ValidatorElContext(_muleEvent) ....}] ^ [Line: 1, Column: 66] org.mule.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:693) org.mule.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:337) org.mule.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** {quote} | 5 |
| 728 | MULE-8523 | When all validator fails it should always throw an exception | Allowing all validator to avoid throwing an exception make us think about where should the validation result go. If we put it in the payload, we should overwrite the payload always, not only for the failing scenario. So, best solution for now is to always throw an exception. If needed in the future we can add the option to not throw an exception and put the result in a flow variable. | 1 |
| 729 | MULE-8527 | Remove AspectJ dependency in CE | AspectJ needs to be upgraded to version 1.8.5 to be consistent with the version number across all distributions and remove warnings when building. | 3 |
| 730 | MULE-8528 | When custom validator fails doesn't throw exception | When using this custom validator: {code} public static class FailingCustomValidator implements Validator { @Override public ValidationResult validate(MuleEvent event) { return ImmutableValidationResult.error(TEST_MESSAGE); } } {code} flow execution goes on and now exception is thrown. | 1 |
| 731 | MULE-8530 | Remove domain, ISBN, date, credit card validators | Remove | 1 |
| 732 | MULE-8531 | Fix validation module issues | Fix linked issues of the validations module | 13 |
| 733 | MULE-8533 | MBeans/JMX Memory Leak on vanilla Mule ESB Standalone | Jira created at request of Mariano Gonzalez - see http://forum.mulesoft.org/mulesoft/topics/mbeans-jmx-memory-leak-on-vanilla-mule-esb-standalone-no-custom-code-deployed?utm_source=notification&utm_medium=email&utm_campaign=new_reply&utm_content=reply_button&reply%5Bid%5D=15618818#reply_15618818 1) Deploy an out of the box Mule Standalone ESB, e.g. mule-standalone-3.6.1 2) Start - default app deploys, no custom code deployed 3) Start Oracle VisualVM, connect to Mule ESB 4) Watch the heap being consumed I performed this test with max memory changed to 256Mb in wrapper.conf (so I didn't have to wait so long for memory to be consumed), on openSuse 13.1, with Oracle Java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode) I have observed the same symptoms using Java jdk1.7.0_75 on openSuse, and Java jdk1.7.0_xx on Mac/OS, so it doesn't seem to be o/s or Java related. If I don't attempt to monitor Mule ESB, the memory leaks don't appear to happen, though it's difficult to be sure without being able to monitor, but I presume that this is MBean/JMX instrumentation related. Running Oracle JConsole does not appear to induce the same dramatic memory consumption, but does seem to cause some sort of slow incremental leak. | 8 |
| 734 | MULE-8534 | Reverse the semmantics of MULE-8415 | The flag introduced in MULE-8415 disables dependency injection for devkit components. We need it to be other way around. By default, Mule is not to inject into Devkit and the property is to be renamed to mule.devkit.participates.di and only when set to true devkit will be considered into DI. | 1 |
| 735 | MULE-8541 | Exposes information needed by DataMapper in order to run as a plugin | DataMapper is accessing some elements in our code that is defined as protected. Because now DataMapper is going to be a Mule plugin, this won't work anymore as it will ran in a different classloader. Need access to the following fields on MVELExpressionLanguage: globalFunctions, parserConfiguration and aliases Need access to MuleImmutableVariableResolver class | 2 |
| 736 | MULE-8535 | Ensure that transformers use a proper return datatype | Transformers define an output dataType which is set on the message after the transformation. In order to properly propagate message dataType, transformers must return the proper type, mimeType and encoding that corresponds to the executed transformation. | 8 |
| 737 | MULE-8536 | DI should never include Devkit components | Although MULE-8534 and MULE-8415 tried to keep some level of compatibility between mule's injector and devkit's components, some other integration issues keep popping up so we decided that for now Devkit will be excluded from it. Devkit will provide its own solution for DI | 1 |
| 738 | MULE-8538 | Dispose lifecycle phase is invoked even when initialise phase fails | dispose() should not be invoked if initialise() fails. At least thats how I believe it always worked. This change causes NPE's in dispose() in a lot of cases. Which results in much more verbose and confusing errores being logged. | 5 |
| 739 | MULE-8539 | Lifecycle not applied to Objects manually registered during initialisation | Suppose an Initialisable or Startable object which during any of those phases registers a new Lifecycle object (e.g.: like an endpoint which creates and registers a connector). Only the already completed phases are applied to the newly registered object while the one being currently executed isn't | 1 |
| 740 | MULE-8543 | CXF schemas for 3.5 and 3.6 are wrong | https://github.com/mulesoft/mule/blob/mule-3.x/modules/cxf/src/main/resources/META-INF/spring.schemas#L5-L6 | 1 |
| 741 | MULE-8544 | Core schema for 3.6 is not defined and rubbish at the end of line | https://github.com/mulesoft/mule/blob/mule-3.x/modules/spring-config/src/main/resources/META-INF/spring.schemas#L11 And remove rubbish bracket at end of line. | 1 |
| 742 | MULE-8548 | Upgrade Spring security to 4.0.1.RELEASE | Spring dependencies were updated to 4.1.6 and keeping Spring security in 3.1.0 is an important risk. | 5 |
| 743 | MULE-8549 | Update C3P0 to version 0.9.5 | There is a new version of C3P0. Would be great to update it to replace the old version that is shipped on Mule | 2 |
| 744 | MULE-8553 | Add max-send-buffer-size entry in wrapper.conf | We need to add that property now that it's available. | 3 |
| 745 | MULE-8555 | Promote to public api DefaultHttpListenerConfig.resolvePath or equivalent behavior | There's no way to resolve the full path of a listener using the public API. Mule 3.6 offered the following method that was changed in 3.7: {code} public String resolvePath(String listenerPath) {code} | 5 |
| 746 | MULE-8556 | SpringRegistry is not thread-safe | In versions prior to 3.7.0, the SpringRegistry was read only and all objects registered through the MuleRegistry API went to the transient registry. Per the work in MULE-7588, the TransientRegstry no longer exists and the SpringRegistry is writable. However, it's missing the ReadWriteLock that TransientRegistry had to allow register and lookup objects concurrently. This causes random failures, specially when dealing with dynamic endpoints | 3 |
| 747 | MULE-8564 | Fix jffi version | The JRuby pom doesn't specify a version for jffi, so Maven picks the last one available. As a result, each time a new version of jffi is released, the build breaks because the whitelist validation fails. Fix in 1.2.9 which is the latest available at this moment | 1 |
| 748 | MULE-8565 | Add support for preemptive basic authentication in the HTTP module | Allow to configure if basic authentication is preemptive or not in the new HTTP connector, by adding an attribute to the config: preemtive="true|false|expression" Also add this to the config builder in the public API of the connector. | 3 |
| 749 | MULE-8569 | Applications and corresponding domains should share the same OptionalObjectController | OptionalObjectsController is used to track objects registered through registry-bootstrap.properties which are optional. When an application belongs to a domain, that instance should be shared between the app and the domain. | 5 |
| 750 | MULE-8572 | Dependency injection fails when injection candidate is registered on domain | When the @Inject annotation is used to inject an instance which leaves on the parent domain context, injection fails | 3 |
| 751 | MULE-8573 | Add support for expressions in the authentication configuration of the HTTP connector | Add support for MEL expressions in the attributes of the authentication elements of the new HTTP connector. | 3 |
| 752 | MULE-8574 | DataType does not validates encoding | When setting the encoding in payload, transformers, properties and variables with an incorrect value it is not validated. In the other hand the mimeType throws an exception. I think that the encoding should have the same behaviour. When you set the property "ContentType" it let you use any value in both mimeType and encoding. But maybe in the content type situation is the desired behaviour. Steps to reproduce (see attached app): Set Payload: 1) Send HTTP request to http://localhost:8081/encoding_not_throw_exception : There the first set payload set the encoding with an invalid value but as then there is another set payload that set the encoding to a valid encoding there is not exception. 2) Send HTTP request to http://localhost:8081/encoding_throw_exception : Here the Set Payload set an invalid encoding value and it throws "java.io.UnsupportedEncodingException". Properties: 1) Send HTTP request to http://localhost:8081/encoding_not_throw_exception_in_properties : 2) Set property sets the encoding with a wrong value. In the check in the Outbound Property log: OUTBOUND scoped properties: pepe=2 pepe-DataType=SimpleDataType{type=java.lang.Integer, mimeType='text/plain', encoding='qwd'} | 5 |
| 753 | MULE-8576 | Inbound properties copied to outbound properties not maintain their datatypes | When the Inbound properties are copied to outbound properties they should maintain their datatypes. Right now they are setted to the default message type (Encoding = null, MimeType = \*/\*). 1) Send HTTP request to http://localhost:8081/copy_property . 2) In the first log you can check that the outbound property "inboundProp" has mimeType="text/xml" encoding="UTF-8" before the VM connector. 3) After the VM connector the inboundProperty "inboundProp" is copied from the inboundProperties to outboundProperties with "<copy-properties propertyName="inboundProp" doc:name="Copy Property"/>". Then you can check in the second logger that the Datatype of the "inboundProp" is set with encoding = null, mimeType = */* | 3 |
| 754 | MULE-8578 | The Json-to-Object transformer not change the mimeType correctly. It should set application/json | The json-to-object not change the mimeType correctly. It should set application/json as mimeType but keep text/javascript after an HTTP Request. Steps to reproduce (see attached app): 1) Send HTTP request to http://localhost:8081/json_object_wrong_mime_type . 2) Check in the log the datatype of the message after Json-to-Object transformer in the outbound property "json_object_datatype". | 3 |
| 755 | MULE-8579 | Datatype cannot be configured when adding properties using message-property-transformer | You can't set the datatype to the properties in the Message Properties transfomer | 3 |
| 756 | MULE-8580 | Fix JDK8 build | Tests run in a different order in the JDK8 build, so HttpsSharePortTestCase fails in that case because of some other test that runs before it. | 5 |
| 757 | MULE-8581 | Spike on Collection splitter is not setting the group size when payload is an Iterator | Salesforce queries return an iterator and when a collection splitter is used, it fails to aggregate the collection after because the group size is set to -1. Attached mule config This seems to be happening because this class https://github.com/mulesoft/mule/blob/bfb3a17263d1e4b32ee10272cbf710a2bf41b16b/core/src/main/java/org/mule/routing/outbound/IteratorMessageSequence.java is used from https://github.com/mulesoft/mule/blob/1dbf6e09a651184e9c54ec8988ecf1907cbdd58f/core/src/main/java/org/mule/util/collection/EventToMessageSequenceSplittingStrategy.java and it is setting UNKNOWN_SIZE as Group size for all Iterator payloads | 5 |
| 758 | MULE-8582 | Spike - Mule support XA transaction on XA resources used by a Spring object component ? | As you should know, a common use case is the bridge pattern : * read a message from an inbound endpoint (from a JMS queue or/and a database through JDBC). * writing the message to an outbound endpoint (to a JMS queue or/and a database through JDBC). {code:xml} <service name="myBridgeService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"/> </inbound> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox" /> <jdbc:outbound-endpoint queryKey="insertMessageStmt" /> </multicasting-router> </outbound> </service> {code} What happens then if something goes wrong when writing the result to the outbound endpoint (eg. jdbc endpoint)? If you don't use XA Transaction on inbound and outbound endpoints, the message will not be rollbacked to the inbound endpoint in case of an Exception. So you will have to solve this issue by configuring <xa-transaction> on each endpoint with the appropriate transaction strategy. {code:xml} <service name="myBridgeService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"> <xa-transaction action="ALWAYS_BEGIN" /> </jms:inbound-endpoint> </inbound> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox"> <xa-transaction action="ALWAYS_JOIN" /> </jms:outbound-endpoint> <jdbc:outbound-endpoint queryKey="insertMessageStmt"> <xa-transaction action="ALWAYS_JOIN" /> </jdbc:outbound-endpoint> </multicasting-router> </outbound> </service> {code} But what happens now if you have a component between inbound and outbound enpoints ? {code:xml} <service name="myDaoService"> <inbound> <jms:inbound-endpoint queue="/queue/inbox"> <xa-transaction action="ALWAYS_BEGIN" /> </jms:inbound-endpoint> </inbound> <component> <spring-object bean="messageDao" /> </component> <outbound> <multicasting-router> <jms:outbound-endpoint queue="/queue/outbox"> <xa-transaction action="ALWAYS_JOIN" /> </jms:outbound-endpoint> <jdbc:outbound-endpoint queryKey="insertMessageStmt"> <xa-transaction action="ALWAYS_JOIN" /> </jdbc:outbound-endpoint> </multicasting-router> </outbound> </service> {code} In most cases, the Spring object component (eg. messsageDao) will execute complicated business operations (from a currently existing business API) and also use a DataSource to execute several SQL select and update statements before returning a result to the outbound. These JDBC operations will be handled likely by Spring JdbcTemplate or even HibernateTemplate. As far as I understand, Mule is fully responsible to handle enlistment/delistment and close of XA resources (see _org.mule.transaction.XaTransaction_). So by default, XA resources used by a Spring object component will not be handled by Mule and will not participate in the XA transaction started from Mule. For completeness... I've also found a unit test for this usecase in Mule distribution under MULE_HOME/src/mule-3.1.2-src.zip/org/mule/test/integration/transaction/XATransactionsWithSpringDAO.java. When you execute this test, you will have a successful result but the XA resource used by the dao bean is not enlisted nor delisted in/from the transaction started from Mule. | 8 |
| 759 | MULE-8583 | Upgrade async-http-client to 1.9.21 | This version includes several fixes but depends on also upgrading Grizzly. | 3 |
| 760 | MULE-8584 | Upgrade grizzly to 2.3.20 | This is necessary to upgrade AHC. | 1 |
| 761 | MULE-8594 | Content-type is not set on HTTP responses | When using an ObjectToJson transformer (with return type String), "content-type" header is not being set in the response. This might happen with other transformers, in fact with any other thing that sets a String Payload. Attaching an example app that reproduces the issue. Running the same app with Mule 3.6 shows the right behavior. | 5 |
| 762 | MULE-8596 | JMX connection error when using JConsole | Deployed an simple app with an HTTP listener and HTTP request. Opened Oracle Java Mission Control and when I went to the threads view I got an exception on the console. I cannot see the threads when using JConsole, it seems that JMC recovers from that error and shows the threads anyway but at the cost of having a big delay in the response time. This is working in 3.5.x | 8 |
| 763 | MULE-8597 | set-payload with invalid MIME type returns an ugly error | When using an invalid MIME type in set-payload the error message is not very clear. Deploy this app: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/> <http:request-config name="HTTP_Request_Configuration3" host="localhost" port="8082" doc:name="HTTP Request Configuration"/> <flow name="nonblockingFlow" processingStrategy="non-blocking"> <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP" allowedMethods="GET"/> <set-payload value="Response OK" encoding="asdfsadf" returnClass="pepe" name="my-set-payload" mimeType="mimeTypeFake" ignoreBadInput="false"/> </flow> </mule> {code} Request: ~ curl http://localhost:8081/ javax.activation.MimeTypeParseException: Unable to find a sub type. (org.mule.api.MuleRuntimeException). Message payload is of type: BufferInputStream% App log: org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor:32 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) -------------------------------------------------------------------------------- Root Exception stack trace: javax.activation.MimeTypeParseException: Unable to find a sub type. javax.activation.MimeType.parse(MimeType.java:102) javax.activation.MimeType.<init>(MimeType.java:63) org.mule.transformer.types.SimpleDataType.<init>(SimpleDataType.java:40) + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything) ******************************************************************************** | 3 |
| 764 | MULE-8598 | Deployment should fail when using Invalid MIME type | When deploying the below config deployment should fail because MIME type does not exists. Now is failing in runtime when executing the flow {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/> <http:request-config name="HTTP_Request_Configuration3" host="localhost" port="8082" doc:name="HTTP Request Configuration"/> <flow name="nonblockingFlow" processingStrategy="non-blocking"> <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP" allowedMethods="GET"/> <set-payload value="Response OK" encoding="asdfsadf" returnClass="pepe" name="my-set-payload" mimeType="mimeTypeFake/fake" ignoreBadInput="false"/> </flow> </mule> {code} | 3 |
| 765 | MULE-8600 | Setting wrong encoding causes flow execution to hang | Deploy the below config and run this: curl -m 10 http://localhost:8081/ curl: (28) Operation timed out after 10004 milliseconds with 0 bytes received It logs an error as soon as I send the request but then I only receive the curl timeout without Mule doing anything. When I remove encoding="asdfsadf" ti returns 200 immediately. | 8 |
| 766 | MULE-8601 | Deployment should fail when using invalid encoding | When deploying the below config deployment should fail because encoding does not exists. Now is failing in runtime when executing the flow {code:xml} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:scripting="http://www.mulesoft.org/schema/mule/scripting" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd http://www.mulesoft.org/schema/mule/scripting http://www.mulesoft.org/schema/mule/scripting/current/mule-scripting.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/> <http:request-config name="HTTP_Request_Configuration3" host="localhost" port="8082" doc:name="HTTP Request Configuration"/> <flow name="nonblockingFlow" processingStrategy="non-blocking"> <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP" allowedMethods="GET"/> <set-payload value="Response OK" encoding="asdfsadf" name="my-set-payload" /> </flow> </mule> {code} | 3 |
| 767 | MULE-8603 | keepAlive is not working correctly in the HTTP requester | keepAlive is not working as expected. The http:request element always sends the header Connection: keep-alive in the request, regardless of the usePersistentConnections attribute in the config. If usePersistentConnections is set to false, keepAlive should be disabled, but the header is still sent. Also, in the proxy scenario (using a listener and a requester) connections are kept alive but not reused. See example config here: https://github.com/mulesoft/performanceworks/blob/master/APPS/PROXY-MCD/100B/http_module_proxy/proxy.xml This causes "Remotely closed" errors, thrown by the service that is being proxied in a highly concurrent scenario. | 8 |
| 768 | MULE-8604 | Incorrect error processing on Jetty transport | Jetty transport is not properly managing error conditions that occur when a MuleMessage fails to be created for the current request. For example, if a request contains an invalid mimeType, it won't be possible to create a DefaultMuleMessage from it, an exception will be thrown to signal the error, but the returned response will be a 200 instead of 500. (NOTE: the problem exists only when there is no MuleMessage, once it has been created, then it works as expected) | 2 |
| 769 | MULE-8605 | Using Preemptive basic authentication in the new HTTP Module uses two request where the User/Pass are invalid | Using the correct User/Pass in basic authentication with Preemptive enabled in the new HTTP Module works fine. You send a single request with the Authorization field and you receive a 200. But in the case when you use a wrong User/Pass, it send fine the Authorization field but when the server respond with a 401, the requester send a new requester trying to be authorize. See the attached files with the comparison of how works the http-client (only 1 request) and how it works the requester (2 requests) +To reproduce you can use these tests:+ * HttpRequestAuthTestCase - invalidBasicAuthentication (Mule-ee) (Requeter - 2 requests) * HttpListenerAuthTestCase - invalidBasicAuthenticationPreemptive (Mule-ee) (Http-client 1 request) | 5 |
| 770 | MULE-8606 | Can't use redelivery policy | If an idempotent-redelivery-policy is defined for an inbound-endpoint, the execution of the flow will halt after the following message: org.mule.processor.IdempotentRedeliveryPolicy: The message cannot be processed because the digest could not be generated. Either make the payload serializable or use an expression. | 1 |
| 771 | MULE-8609 | Should be able to fetch prototype by name without lifecycle applied | In most scenarios, when a prototype is lookup up by name, lifecycle should be applied to it before returning. There're some scenarios (e.g.: fetching a MessageProcessor that will go into a DynamicPipeline) which are not so and we need a way to specify that this case is different. The following method was applied to the LifecycleRegistry to support such case: {code:java} /** * Look up a single object by name. * <p/> * Because {@link #lookupObject(String)} will * return objects which had lifecycle phases * applied,this method exists for cases in which * you want to specify that lifecycle is not to be * applied. The actual semantics of that actually depends * on the implementation, since invoking this method * might return a new instance or an already existing one. * If an existing one is returned, then the lifecycle might * have been previously applied regardless. * * @param key the key of the object you're looking for * @param applyLifecycle if lifecycle should be applied to the returned object. * Passing {@code true} doesn't guarantee that the lifecycle is applied * @return object or {@code null} if not found */ <T> T lookupObject(String key, boolean applyLifecycle); {code} | 1 |
| 772 | MULE-8610 | Update MVEL version to 2.1.9-MULE-006 | Need to update MVEL to include the fix for MULE-8336 | 1 |
| 773 | MULE-8615 | Regression found on proxy scenario with the new http module. | proxy scenario have a regression between 3.7.0-SNAPSHOT 1 and 2, build on may 12. build tps latency 3.7.0-RC 6847.83 27.9199 3.6.2 18380.5 8.63 Diff % -62.74% 223.52% | 13 |
| 774 | MULE-8619 | Review event copying and access control in non-blocking support | Need to ensure there are no issues.. | 1 |
| 775 | MULE-8620 | Add dynamic configurations for DB connector | Current Db Connector configurations are static, that is, configured values are defined when Mule starts and never changed. In order to support multi-tenant scenarios, DB configurations must be dynamic. That is, configured values could be expressions that are resolved for each MuleEvent. With this feature, a single DB config can be resolved to multiple DB on runtime depending on how the expressions are resolved | 8 |
| 776 | MULE-8625 | Support disablePropertiesAsHeaders in http:request builder config | http:listener element supports disablePropertiesAsHeaders in the response builder configuration. We should add support for disablePropertiesAsHeaders in the http:request builder element. Also it must support mule expressions. | 5 |
| 777 | MULE-8626 | Connection and Keep-Alive message properties should not affect Listener/Requestor connection reuse behaviour. | Listener can be set up to use persistent connections and client attempt to reuse connections, but if for some reason a "connection" header gets returns to the listener this behaviour breaks. Connection reuse behaviour should be encapsulated in listener/requestor. | 5 |
| 778 | MULE-8627 | Review CXF documentation | Review CXF documentation | 8 |
| 779 | MULE-8628 | HTTP Connector should not send/respond http.* properties | HTTP Connector knows these properties are internal, so it makes sense that they are filtered and not sent. | 5 |
| 780 | MULE-8632 | HTTP Listener Connector reject a GET and DELETE that contains a body. | http://forum.mulesoft.org/mulesoft/topics/http-get-delete-how-to-get-the-body-of-request-using-http-listenner-connector | 5 |
| 781 | MULE-8635 | ConcurrentModificationException when hot deploying | To reproduce: # Deploy first application in Mule Standalone CE # Deploy second application to a different server (app1 depends on it) # Load application with some requests (Don't know if this is needed to reproduce) # Deploy third application by moving the exploded app to apps directory | 8 |
| 782 | MULE-8638 | [Regression] NPE when filter fails | When a filter evaluation fails message is discarded but a NPE is shown in app log. | 8 |
| 783 | MULE-8649 | Resolve data type from simple MEL expressions | Now that dataType is being propagated for payload and properties, it would be good if dataType can be propagated when MEL expressions are used. For example, when using set-payload with "flowVars['foo']" expression, it would be good if the property dataType is assigned to the payload's datatype. Simple expressions include: * payload/message.payload * direct access to invocation/session properties, like #[foo], where foo is an invocation/session variable * access to flowVars, like flowVars['foo'] * access to sessionVars, like sessionVars['foo'] | 8 |
| 784 | MULE-8650 | SecurityFilterMessageProcessor does not support non-blocking. | SecurityFilterMessageProcessor should implement NonBlockingSupported | 3 |
| 785 | MULE-8654 | Can't use redelivery policy with FTP | If an idempotent-redelivery-policy is defined for an inbound-endpoint, the execution of the flow will halt after the following message: org.mule.processor.IdempotentRedeliveryPolicy: The message cannot be processed because the digest could not be generated. Either make the payload serializable or use an expression. | 5 |
| 786 | MULE-8655 | Update jython to 2.7.0 | Update to the lastest jython release | 3 |
| 787 | MULE-8656 | Database Connector artifact located in registry no longer implements Testable and DataSense interfaces | All datasense related functionality for the Database connector is no longer working due to the connector/config element stored in the registry not implementing the required interfaces | 3 |
| 788 | MULE-8657 | XMLStreamException when using non blocking cxf:proxy-service and cxf:proxy-client | Steps to reproduce: - Deploy the attached apps (the leagues-ws will work as a server and the wsdl-proxy as a proxy), notice that the wsdl-proxy app is prepared to be non-blocking. - Make a the following request: URL http://localhost:8090/api Headers: SOAPAction: getTeamsAction Content-Type: text/xml;charset=UTF-8 Body: {code} <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:leag="http://leagues.examples.mule.org/" xmlns:soc="http://mulesoft.com/schemas/soccer"> <soapenv:Header/> <soapenv:Body> <leag:teams> </leag:teams> </soapenv:Body> </soapenv:Envelope> {code} This warning appears in the log of every request | 3 |
| 789 | MULE-8658 | XML header is not removed when proxying, using non blocking cxf:proxy-service and cxf:proxy-client | Steps to reproduce: - Deploy the attached apps (the leagues-ws will work as a server and the wsdl-proxy as a proxy), notice that the wsdl-proxy app is prepared to be non-blocking. - Make a the following request: URL http://localhost:8090/api Headers: SOAPAction: getTeamsAction Content-Type: text/xml;charset=UTF-8 Body: {code} <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:leag="http://leagues.examples.mule.org/" xmlns:soc="http://mulesoft.com/schemas/soccer"> <soapenv:Header/> <soapenv:Body> <leag:teams> </leag:teams> </soapenv:Body> </soapenv:Envelope> {code} Notice that the soap envelope does not contain the xml tag: <?xml version="1.0" encoding="UTF-8"?> but the response has it. This issue does not happen if the proxy is prepared to be blocking (ie. the response never contains the xml tag). Also, the previous versions of Mule didn't add the tag in the response. This issue appears on every request. | 8 |
| 790 | MULE-8664 | NullPointerException testing connection on DB connector from Studio | When testing connectivity on the attached app from Studio, a NPE exception is being thrown. Problem is that datasource's URL is wrong (using http instead of jdbc:mysql prefix). This causes mysql driver to return a null connection instead of throwing an exception. Then DB connector wraps that connection and the NPE is thrown during connection.close. | 5 |
| 791 | MULE-8666 | Set mime type correct for common files with FTP/File connectors | The FTP and File connectors should set mime types for common file types correct, including CSV, XML, and JSON. | 5 |
| 792 | MULE-8669 | non-blocking processing strategy should only allow direct-threading-profile | Currently we cannot force the configuration to use direct-threading-profile for all non-blocking flows, this is because thread pool belong to the listener and not to the flow. We need a bigger change that we cannot make now and we can only address it in Mule 4. Because we don't have a concrete use scenario for using non-blocking with a worker threading profile we want to validate that you can only use direct-threading-profile for HTTP listeners when flow's processing strategy is non-blocking. This validation will be on runtime. | 1 |
| 793 | MULE-8676 | HTTP listener should ignore 'Transfer-Encoding' property as it is a hop-by-hop header | Transfer-Encoding is a hop-by-hop header and therefore shouldn't really be used by HTTP listener if there is a "transfer-encoding" property present in the outbound property scope to determine response streaming behaviour. Generally current behaviour is fine, but there is one case that is currently incorrect IMO. * We shouldn't stream a String payload when the "transfer-encoding" outbound message property is present. * We shouldn't stream a String payload when the "transfer-encoding" and "content-length" outbound message properties are both present. * Aso, While I think it is probably correct that a String payload should be streamed when a "transfer-encoding" header is configured and streaming mode is 'AUTO'. This is not the way the user should be enabling streaming and I suggest we log an INFO message whenever a transfer-encoding header is set suggesting the user uses the responseStreamingMode attribute instead. Failing test that show this can be found in this branch: https://github.com/mulesoft/mule/compare/MULE-8676 *AUTO Behaviour appears to be inconsistent with HTTP requestor because the presence of both transfer-encoding/content-length headers results in no streaming with requestor, but streaming with listener* | 8 |
| 794 | MULE-8677 | HTTP requestor should ignore 'Transfer-Encoding' property as it is a hop-by-hop header | Transfer-Encoding is a hop-by-hop header and therefore shouldn't really be used by HTTP requestor if there is a "transfer-encoding" property present in the outbound property scope to determine request streaming behaviour. Generally current behaviour is fine, but there is one case that is currently incorrect IMO. * We shouldn't stream a String payload when the "transfer-encoding" outbound message property is present. Also: * Aso, While I think it is probably correct that a String payload should be streamed when a "transfer-encoding" header is configured and streaming mode is 'AUTO'. This is not the way the user should be enabling streaming and I suggest we log an INFO message whenever a transfer-encoding header is set suggesting the user uses the responseStreamingMode attribute instead. * There are currently no tests covering the case when these headers are configured using a <request-builder>, we should add these. *AUTO Behaviour appears to be inconsistent with HTTP listener because the presence of both transfer-encoding/content-length headers results in no streaming with requestor, but streaming with listener* Failing test that show this can be found in this branch: https://github.com/mulesoft/mule/compare/MULE-8676 | 8 |
| 795 | MULE-8678 | HTTP Requestor should not use Host property. | If I have configured requestor to hit google.com, i should then not be able to set a host message property or host header (on request builder) that conflicts with google.com. Currently if i hit google.com and i have <set-property propertyName="Host" value="pirulo"/> in my flow then google with receive "Host: pirulo". If the host configured is an ip address then thats different, need to decide if requestor should take "Host" value from message properties or only from response-builder (or neither) in that case. | 5 |
| 796 | MULE-8680 | Allow TLS context to be shared in a domain | It'd be good to be able to share a TLS context so that several shared listener configs can use the same one. Another benefit is that all that data (including passwords) will only need to be visible at the domain level, so app developers could use the certs without having access to the perhaps critical data. | 8 |
| 797 | MULE-8685 | CopyOnWriteCaseInsensitiveMap should be interoperable with a regular map | CopyOnWriteCaseInsensitiveMap provides improved performance in cases in which reads vastly outnumbers reads. However, it's not good when: * I want to create a CopyOnWriteCaseInsensitiveMap from an existing map * The initial assumption stops being true and I want to transform the CopyOnWriteCaseInsensitiveMap to a regular one This should be supported | 1 |
| 798 | MULE-8687 | Passing a JaxB annotated pojo to the HTTP listener response is throwing a transformer error | Using the Workday connector and sending a POJO with results to the HTTP listener is throwing the copied transformer error. There is a simple app attached to reproduce it. | 1 |
| 799 | MULE-8690 | Remove registry deprecation warnings from log. | In API Gateway we need to use a registry feature that generates several log entries like: {code} WARN 2015-06-05 16:41:53,968 [Thread-2] org.mule.registry.DefaultRegistryBroker: 3 registries have been registered, however adding registries has been deprecated as of Mule 3.7.0 {code} How to reproduce: - Configure GW to use any valid organization - Deploy an API with autodiscovery - Run GW Expected: - The information is not logged at all in no log file. Actual: - The information is logged in mule_ee with WARN level. | 1 |
| 800 | MULE-8693 | XA transaction must set tx timeout in XA resources | XA transaction must set tx timeout in XA resources | 3 |
| 801 | MULE-8696 | PROCESS_COMPLETE pipeline notification not sent when strategy is NB and the last component in the flow is not NB | Having a flow using non-blocking processing strategy where the last component is not non-blocking prevents PROCESS_COMPLETE Pipeline Notification to be fired. Steps: 1) Call the listener in the attached app 2) Check pipeline notifications Expected: - PROCESS_START, PROCESS_END and PROCESS_COMPLETE are fired Actual: - Only PROCESS_START and PROCESS_END are fired | 1 |
| 802 | MULE-8698 | NonBlockingNotSupportedFunctionalTestCase.aggregator caused InboundAggregationNoTimeoutTestCase to fail. | Messages created in NonBlockingNotSupportedFunctionalTestCase.aggregator are not related by their rootId which caused InboundAggregationNoTimeoutTestCase to fail. | 5 |
| 803 | MULE-8700 | Incorrect XSD generated for extension built using extension API | Reviewing the code or extensions API implementation, found that the XSD sceham generated for the test Heinsenberg extension's killOne operation is wrong. {code} <xs:element xmlns="http://www.mulesoft.org/schema/mule/heisenberg" type="KillOneType" substitutionGroup="heisenberg-empire" name="kill-one"></xs:element> <xs:complexType name="KillOneType"> <xs:complexContent> <xs:extension xmlns:mule="http://www.mulesoft.org/schema/mule/core" base="mule:abstractMessageProcessorType"> <xs:sequence> <xs:element minOccurs="1" name="kill-operation"> <xs:complexType> <xs:group xmlns="http://www.mulesoft.org/schema/mule/heisenberg" minOccurs="1" maxOccurs="1" ref="heisenberg-empire-group"></xs:group> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute type="mule:substitutableName" use="optional" name="config-ref"> <xs:annotation> <xs:documentation>Specify which configuration to use for this invocation.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute type="mule:expressionString" use="required" name="reason"></xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> {code} From that snipet, a XML like the following would be valid if checked against a schame validation tool: {code} <heisenberg:kill-one reason="I'm the one who knocks"> <heisenberg:kill-operation> <heisenberg:kill-with-custom-message victim="Gustavo Fring" goodbyeMessage="bye bye"/> </heisenberg:kill-operation> <heisenberg:kill-operation> <heisenberg:kill-with-custom-message victim="Gustavo Fring" goodbyeMessage="bye bye"/> </heisenberg:kill-operation> </heisenberg:kill-one> {code} | 3 |
| 804 | MULE-8708 | Validations doesn't support concurrency. | Hitting a validations app with more than one thread causes an exception saying that no config-ref was set and there are N configurations. | 3 |
| 805 | MULE-8713 | Merge mule 3.x on 4.x branch | Merge latest changes on mule 3 into mule 4 branch | 5 |
| 806 | MULE-8723 | Mime Type for .CSV files is not being auto detected and set | Steps to reproduce: 1.- Create the followed Mule Config *Mule Config*: {code:XML} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:metadata="http://www.mulesoft.org/schema/mule/metadata" xmlns:dw="http://www.mulesoft.org/schema/mule/ee/dw" xmlns:file="http://www.mulesoft.org/schema/mule/file" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/file http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd http://www.mulesoft.org/schema/mule/ee/dw http://www.mulesoft.org/schema/mule/ee/dw/current/dw.xsd http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd"> <flow name="csv-common"> <file:inbound-endpoint path="src/main/resources/csv/" moveToDirectory="src/main/resources/files/to/test" responseTimeout="10000" mimeType="application/csv" metadata:id="09ca0cda-dd6e-4590-838d-fc1482fcb982" doc:name="File"/> <dw:transform-message doc:name="Transform Message"> <dw:set-payload><![CDATA[%dw 1.0 %output application/json --- payload map { Account: $.'Account Name', Contac: { Email: $.'Email Address', Phone: $.Phone } }]]></dw:set-payload> </dw:transform-message> <object-to-string-transformer doc:name="Object to String"/> <logger message="#[payload]" level="INFO" doc:name="Logger"/> </flow> </mule> {code} 2.- Create a CSV folder in the src/main/resources with the followed file: *Registers.csv* {code} First Name,Last Name,Phone,Email Address,Street Address,City,Zip Code,State,Country,Birthday,Birth Year,Marital Status,Account Name,Department, Other State,Other Country,Other Street,Other Email,Other Phone,Other Zip,AssistantName,Other City,Title,AssistantPhone Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,MN,Switzerland,June 28th,1998,Common-Law,Lycos,Asset Management,St Louis,NY,1692 Quis Rd,ornare.sagittis.felis@Morbi.org,1-657-224-8346,T9Z 7K4,Solomon Lane,Switzerland,Mr,1-657-224-8346 Solomon,Lane,1-657-224-8346,ornare.sagittis.felis@Morbi.org,1692 Quis Rd.,Bay St. Louis,T9Z 7K4,... | 3 |
| 807 | MULE-8724 | Operation state handling in extensions api | We need to clearly define how to manage state within operations define with extensions api. Not only define how to implement each use case but also doing it in a way that fits the user mindset. We need: - Global state between operators - Global state per config - Global state per tenant config - State for a particular operation (one per xml element) disregarding the config I'm just trying to list all the cases, then we would have to try to come up with use cases for each use case. | 8 |
| 808 | MULE-8725 | Implememnt multitenant configuration eviction policy | When using configs multitenant with extenision API there should be a way to evict (dispose) config that are not longer used. This is critical to avoid OOM and wasting resources for use cases where there may be hundreds or thousands config created over time. | 8 |
| 809 | MULE-8735 | MuleMessage is going to registry for every transformation when extended transformations are used. | Now there is no longer a transient registry it is critical that we don't lookup objects in the registry in runtime per-message. Not doing so will cause an performance impact and also thread contention at higher concurrencies. org.mule.DefaultMuleMessage#applyAllTransformers org.mule.DefaultMuleContext#getDataTypeConverterResolver | 1 |
| 810 | MULE-8736 | Enricher does not propagates datatype | Message enricher is not propagating datatype when well-known expressions are used (like expressions returning message's payload/properties) | 8 |
| 811 | MULE-8738 | No data type resolution accessing flow/session properties using dot notation | Data type resolution works for session/flow variables on MEL expressions using map syntax (like flowVars['foo']) but does not work when using dot syntax (like flowVars.foo). | 1 |
| 812 | MULE-8741 | Extract logic for creating implicit configs to a separate class | The logic for creating implicit configurations is now part of the DefaultExtensionsManager. Would be good to have that extracted to a separate class | 5 |
| 813 | MULE-8742 | Cannot build Mule ESB Maven Tools with Java 8 | When trying to build mule-esb-maven-tools from source code using JDK 8, it fails with the attached error message. | 8 |
| 814 | MULE-8743 | Mule registry failing to lookup sub-flows | When trying to do the following ``` context.getRegistry().lookupObjects(SubflowMessageProcessorChainFactoryBean.class); ``` Over a context that has been created with the following xml: ``` <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd"> <sub-flow name="firstFlow"> <set-payload value="#['real_payload']"/> </sub-flow> </mule> ``` The method returns an empty collection. When you do something like ``` context.getRegistry.get("firstFlow") ``` The bean is returned. It seems as if the problem is with the type lookup | 8 |
| 815 | MULE-9035 | Add extensions parent pom to script for deploying to maven central repo | Currently buildtools/scripts/DeployArtifacts.groovy doesn't deploy org.mule.extensions:mule-extensions, we need it because is the parent for all modules created by extensions-api | 5 |
| 816 | MULE-8753 | Give the Extension model the concept of vendor | Currently Extension instances are matched by its getName() method. They should also include the concept of vendor and be used for matching purposes as well. | 5 |
| 817 | MULE-8769 | Loggers memory leak after fixing MULE-8635 | Changes from MULE-8635 introduced a memory leak where MuleApplicationClassLoaders are not being disposed. MULE-8635 added logic to clean up loggers, but seems that the logic is executed but the memory is not released. To reproduce the issue: _ Start a vainilla mule instance _ Once default app is deployed force a redeploy touching the app's config file Expected behaviour, according to the code, is that after 15 seconds the memory is released, but that does not happen. | 8 |
| 818 | MULE-8772 | Create the new object store | Create the new object store. | 13 |
| 819 | MULE-8779 | Hostname verification not working correctly with HTTPS proxy | When configuring the http requester with HTTPS and a proxy, hostname verification is done against the proxy instead of the real host. This makes the request fail, as the certificate doesn't contain the url of the proxy. The verification should be made against the host of the request. This is a bug in AHC, it is fixed in AHC 1.9.27, so a possible solution to this is updating at least to this version. | 5 |
| 820 | MULE-8784 | Revisit DefaultExtensionManager implicit config test cases considering MULE-8741 | Now that implicit configs are instantiated by DefaultImplicitConfigurationFactory related tests should be refactored and that class should have its own tests. | 5 |
| 821 | MULE-8786 | WSC with basic auth wraps "error"s HTTP status code by throwing exceptions with timeouts | When using WSC in conjunction with HTTP Basic Authentication (through HttpRequesterConfig) when bad credentials are used in the basic auth, the output I see is a timeout [1] rather than an exception caused by a 401 or 403 status code error. To reproduce so, I'm attaching a small SOAP server (demo-soap-server.zip) and a mule app to try it out [2]. The endpoint I'm hitting is http://localhost:9000/acme-crm/orders?wsdl where the valid credentials are user: admin pass: admin. In the mule app there are two flows to be executed * (a) http://localhost:8081/goodCredentials where once it's hit you will see something like the following in a browser {code:xml}<ns2:CreateResponse><return>0</return></ns2:CreateResponse>{code} * and (b) http://localhost:8081/badCredentials where once it's hit you will wait for the default timeout of the WSC to be consumed, seeing at the end the stack trace in the mule app [1]. The issue here is that, despite the app will fail because of bad credentials, the developer should be warn that the error was an unauthorized rather than timed-outed. [1] Mule app stack after hitting http://localhost:8081/badCredentials {code:java|title=log of the mule application} WARN 2015-07-16 17:54:43,634 [[wsc_wrong_cred].HTTP_Listener_Configuration.worker.01] org.apache.cxf.endpoint.ClientImpl: Timed out waiting for response to operation {http://support.cxf.module.mule.org/}invoke. ERROR 2015-07-16 17:54:43,647 [[wsc_wrong_cred].HTTP_Listener_Configuration.worker.01] org.mule.exception.DefaultMessagingExceptionStrategy: ******************************************************************************** Message : Timed out waiting for response to operation {http://support.cxf.module.mule.org/}invoke.. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of type: PushbackInputStream Type : org.mule.api.transport.DispatchException Code : MULE_ERROR--2 JavaDoc : http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/DispatchException.html Payload : java.io.PushbackInputStream@2ef70222 ******************************************************************************** Exception stack is: 1. Timed out waiting for response to operation {http://support.cxf.module.mule.org/}invoke. (java.io.IOException) org.apache.cxf.endpoint.ClientImpl:740 (null) 2. Timed out waiting for response to operation {http://support.cxf.module.mule.org/}invoke.. Failed to route event via endpoint: org.mule.module.cxf.CxfOutboundMessageProcessor. Message payload is of type: PushbackInputStream (org.mule.api.transport.DispatchException) org.mule.module.cxf.CxfOutboundMessageProcessor:163 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/DispatchException.html) ******************************************************************************** Root Exception stack trace: java.io.IOException: Timed out waiting for response to operation {http://support.cxf.module.mule.org/}invoke. org.apache.cxf.endpoint.ClientImpl.waitResponse(ClientImpl.java:740) org.apache.cxf.endpoint.ClientImpl.processResult(ClientImpl.java:661) org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:581) org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481) org.mule.module.cxf.CxfOutboundMessageProcessor.doSendWithClient(CxfOutboundMessageProcessor.java:281) org.mule.module.cxf.CxfOutboundMessageProcessor.process(CxfOutboundMessageProcessor.java:128) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:94) org.mule.processor.BlockingProcessorExecutor.execute(BlockingProcessorExecutor.java:56) org.mule.processor.AbstractRequestResponseMessageProcessor.processBlocking(AbstractRequestResponseMessageProcessor.java:56) org.mule.processor.AbstractRequestResponseMessageProcessor.process(AbstractRequestResponseMessageProcessor.java:47) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:94) org.mule.processor.BlockingProcessorExecutor.execute(BlockingProcessorExecutor.java:56) org.mule.module.ws.consumer.WSConsumer$1.processNext(WSConsumer.java:183) org.mule.processor.AbstractRequestResponseMessageProcessor.processBlocking(AbstractRequestResponseMessageProcessor.java:56) org.mule.processor.AbstractRequestResponseMessageProcessor.process(AbstractRequestResponseMessageProcessor.java:47) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:85) org.mule.processor.BlockingProcessorExecutor.execute(BlockingProcessorExecutor.java:56) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.module.ws.consumer.WSConsumer.process(WSConsumer.java:107) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:85) org.mule.processor.BlockingProcessorExecutor.execute(BlockingProcessorExecutor.java:56) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:94) org.mule.processor.BlockingProcessorExecutor.execute(BlockingProcessorExecutor.java:56) org.mule.processor.AsyncInterceptingMessageProcessor.process(AsyncInterceptingMessageProcessor.java:102) org.mule.execution.ExceptionToMessagingExceptionExecutionInterceptor.execute(ExceptionToMessagingExceptionExecutionInterceptor.java:24) org.mule.execution.MessageProcessorNotificationExecutionInterceptor.execute(MessageProcessorNotificationExecutionInterceptor.java:107) org.mule.execution.MessageProcessorExecutionTemplate.execute(MessageProcessorExecutionTemplate.java:44) org.mule.processor.BlockingProcessorExecutor.executeNext(BlockingProcessorExecutor.java:94) org.mule.processor.BlockingProcess... ******************************************************************************** {code} [2] Mule application to try it out {code:xml|title=mule app.xml}<?xml version="1.0" encoding="UTF-8"?> <mule xmlns:dw="http://www.mulesoft.org/schema/mule/ee/dw" xmlns:ws="http://www.mulesoft.org/schema/mule/ws" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/ws http://www.mulesoft.org/schema/mule/ws/current/mule-ws.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/ee/dw http://www.mulesoft.org/schema/mule/ee/dw/current/dw.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/> <http:request-config name="HTTP_Request_Configuration_GOOD_CREDS" doc:name="HTTP Request Configuration"> <http:basic-authentication username="admin" password="admin"/> </http:request-config> <http:request-config name="HTTP_Request_Configuration_BAD_CREDS" doc:name="HTTP Request Configuration"> <http:basic-authentication username="admin" password="admin___AAAAAAAAAAAAAAAAAAAAAAA"/> </http:request-config> <ws:consumer-config name="Web_Service_Consumer_BAD_CREDS" wsdlLocation="http://localhost:9000/acme-crm/orders?wsdl" service="OrderManagementService" port="OrderManagementPort" serviceAddress="http://localhost:9000/acme-crm/orders" connectorConfig="HTTP_Request_Configuration_BAD_CREDS" doc:name="Web Service Consumer"/> <ws:consumer-config name="Web_Service_Consumer_GOOD_CREDS" wsdlLocation="http://localhost:9000/acme-crm/orders?wsdl" service="OrderManagementService" port="OrderManagementPort" serviceAddress="http://localhost:9000/acme-crm/orders" connectorConfig="HTTP_Request_Configuration_GOOD_CREDS" doc:name="Web Service Consumer"/> <flow name="wsc_wrong_credFlow"> <http:listener config-ref="HTTP_Listener_Configuration" path="/badCredentials" doc:name="badCredentials"/> <dw:transform-message doc:name="Transform Message"> <dw:set-payload><![CDATA[%dw 1.0 %output application/xml %namespace ns0 http://server.connect.mulesoft.org/ --- { ns0#Create: { order: { client: "failureCreatingOrder", clientId: 1, description: "someDesc", id: 1, items: { sko: 1 }, shippingDate: |2003-10-01T23:57:59Z| } } }]]></dw:set-payload> </dw:transform-message> <ws:consumer config-ref="Web_Service_Consumer_BAD_CREDS" operation="Create" doc:name="Web Service Consumer"/> </flow> <flow name="wsc_wrong_credFlow1"> <http:listener config-ref="HTTP_Listener_Configuration" path="/goodCredentials" doc:name="/goodCredentials"/> <dw:transform-message doc:name="Transform Message"> <dw:set-payload><![CDATA[%dw 1.0 %output application/xml %namespace ns0 http://server.connect.mulesoft.org/ --- { ns0#Create: { order: { client: "successCreatingOrder", clientId: 1, description: "description", id: 1, items: { sko: 1 }, shippingDate: |2003-10-01T23:57:59Z| } } }]]></dw:set-payload> </dw:transform-message> <ws:consumer config-ref="Web_Service_Consumer_GOOD_CREDS" operation="Create" doc:name="Web Service Consumer"/> </flow> </mule> {code} | 8 |
| 822 | MULE-8798 | Message mime type/encoding must be reset when payload is set without a datatype | DefaultMuleMessage#setPayload(Object) is maintaining previous mimeType/encoding instead of cleaning it, this is causing issues as transformers read the payload value taking in account the mimeType, which won't match the payload that was set. | 1 |
| 823 | MULE-8804 | CXF does not set the correct mimeType | If payload was a stream and it was consumed and converted to String (for ex. after a logger) dw fails. | 8 |
| 824 | MULE-8806 | New HTTP Listener not working with some kind of attachments | Using SoapUI to call a CXF WS with an attachment I discover that HTTP module was crashing. See attachment. Workaround was to use deprecated http endpoint. | 1 |
| 825 | MULE-8817 | Upgrade to Spring 4.2.x | We are in 4.1.6, wouldn't require a big effort. Consider upgrading Spring security too. | 1 |
| 826 | MULE-8820 | Performance degradation on registry lookup | Because the mule registry was unified on Spring, lookup and get operations take longer to execute because spring checks for prototypes, etc. We should add a cache to speed up lookups of things that we know are not prototypes | 5 |
| 827 | MULE-8821 | Concurrent calls to the OAuth2 authorize MessageProcessor fail when passing different values for accessTokenUrl | When the authorize MessageProcessor is invoked by 2 different users at the same time and each of those invocations is done with a different value for the accessTokenUrl, the access token request for one of them is made to the wrong url. I am using the salesforce connector v6.2.1 and this is how my authorize call looks like: <sfdc:authorize display="#[flowVars['display']]" authorizationUrl="#[flowVars['salesForceUrl'] + '/authorize']" accessTokenUrl="#[flowVars['salesForceUrl'] + '/token']" config-ref="sfdcConnectorConfig" state="#[payload]" accessTokenId="#[flowVars['remoteUserId']]" /> The flowVar salesforceUrl can take 2 possible values, which are: https://login.salesforce.com (Salesforce Production) https://test.salesforce.com (Salesforce Sandbox) When a user does the OAuth dance to login.salesforce.com at the same time another user does the OAuth dance to test.salesforce.com, one of the dances fail. ------------------------------------------------------------------------------------------ I believe the problem can be found in the way the accessTokenUrl is retrieved and saved by these 2 processors (in mule-devkit-support): - org.mule.security.oauth.processor.BaseOAuth2AuthorizeMessageProcessor<T> - org.mule.security.oauth.processor.OAuth2FetchAccessTokenMessageProcessor The BaseOAuth2AuthorizeMessageProcessor<T> (line 81) saves the accessTokenUrl value in the defaultUnauthorizedConnector object of the OAuth2Manager. The OAuth2FetchAccessTokenMessageProcessor (line 57) obtains an OAuth2Adapter (used to fetch the access token) from the OAuth2Manager. The OAuth2Manager creates the adapter setting the accessTokenUrl (line 256 BaseOAuth2Manager<T>) with the value taken from the defaultUnauthorizedConnector object. https://github.com/mulesoft/mule/blob/mule-3.5.2/modules/devkit-support/src/main/java/org/mule/security/oauth/processor/BaseOAuth2AuthorizeMessageProcessor.java#L81 https://github.com/mulesoft/mule/blob/mule-3.5.2/modules/devkit-support/src/main/java/org/mule/security/oauth/processor/OAuth2FetchAccessTokenMessageProcessor.java#L57 https://github.com/mulesoft/mule/blob/mule-3.5.2/modules/devkit-support/src/main/java/org/mule/security/oauth/BaseOAuth2Manager.java#L256 The defaultUnauthorizedConnector of the OAuth2Manager is common to all events and threads. I believe that when 2 users are doing the oauth dance at the same time the accessTokenUrl value of the defaultUnauthorizedConnector is being overwritten by the second user before the first is able to fetch the access token. | 8 |
| 828 | MULE-8822 | OAuth2 Refresh token logic fails after restart for preexistent connection | This issue is related to the problem encountered in JIRA MULE-8277. After restarting an application that uses the Box Connector, the first time a box request is made with a preexisting Box connection, that has an expired access token in its OAuthState, a refresh token process is triggered that does not attempt to save the refresh and access token obtained from box in the connector's ObjectStore. The Box connector postAuthorize method invokes one of the connector's processors in order to retrieve the id of the user after the OAuth2 dance for identification purposes. That request within the postAuthorize triggers the first refresh token process for the connector on its first use after restart. The way to reproduce the issue would be: - Run a mule application on mule 3.6.2 with the Box Connector and a persistent Objectstore for it - Do the OAuth dance with a Box user using the authorize MessageProcessor. - Wait until the Box access token expires or modify it in the OAuthState saved in the Objectstore to make it invalid - Restart the mule application and attempt to run a Box MessageProcessor like <box:get-user /> twice. (The first attempt should refresh but not save and the second should fail to refresh) | 5 |
| 829 | MULE-8823 | Unable to deploy Application in Mule 3.7.0 | Nowadays, if you want to create a proxy, you have to specify the port name and the soapVersion for each binding. This information is provided by the wsdl, so it shouldn't be required, the proxies should detect them automatically. As a consequence, if you have an API with multiple ports, one of them receiving a SOAP 1.1 envelope, and other one receiving a SOAP 1.2 envelope, and if you don't specify the port and the soapVersion in both proxies (service and client) you will not be able to send a SOAP 1.2 message. This means that a simple proxy cannot be used with both types of SOAP versions. | 8 |
| 830 | MULE-8827 | Tests for HTTP connector in HttpSecurityFilterFunctionalTestCase depend on tests executed one the HTTP transport | org.mule.module.cxf.HttpSecurityFilterFunctionalTestCase is executed on flows using HTTP transport and HTTP connector. All test pass under the current configuration as the HTTP transport tests are executed before the HTTP connector's. Running the connector test only or switching the order breaks the following tests: * testAuthenticationAuthorisedGetHttps * testAuthenticationAuthorisedPostHttps * testAuthenticationFailureBadCredentialsGetHttps * testAuthenticationFailureBadCredentialsPostHttps | 5 |
| 831 | MULE-8833 | Require jdk8 | Make jdk8 required and set the compilation level to 1.8 | 1 |
| 832 | MULE-8834 | Fix ext-api version in 3.x | Further development of the ext-api will continue on the Mule 4 branch and thus the version of it should be fix for 3.x | 1 |
| 833 | MULE-8837 | Improve usability to manage cookies in the HTTP listener | Currently, the only way to handle cookies in the HTTP listener is through the Set-Cookie and Cookie headers (reading and setting them manually). Improve the usability so that the user doesn't have to manually parse a cookie sent by the client, or know how to create a Set-Cookie header. (Probably by adding come cookie object as the old http transport had, and adding some new syntax to the response-builder element in the config). | 13 |
| 834 | MULE-8854 | Exceptions are wrapped in extensions API | There's a problem when throwing certain exceptions. I was invoking a non existent method in the operation of an extension, expecting the NoSuchMethodException to be wrapped by a MessagingException. The result was a MessagingException wrapping a UndeclaredThrowableException that then contained my exception. I tracked it down to the rethrowRuntimeException method in class org.springframework.util.ReflectionUtils: public static void rethrowRuntimeException(Throwable ex) { if (ex instanceof RuntimeException) { throw (RuntimeException) ex; } if (ex instanceof Error) { throw (Error) ex; } throw new UndeclaredThrowableException(ex); } So it seems this involves all exceptions that are not RuntimeException or Error. | 1 |
| 835 | MULE-8897 | mule-maven-plugin CloudHub deployment fails when domain is already in use | When trying to deploy an application to CloudHub, deployment fails if the domain is already in use. Plugin should validate that the domain is free before trying to deploy the application. | 1 |
| 836 | MULE-8904 | mule-maven-plugin CloudHub redeployment configuration loss | When you use the Maven plugin to redeploy an application with the redeploy=true flag, the existing application gets deleted before the updated application is deployed. This behavior causes all CloudHub configured properties to be lost, and the plugin currently supports only a few of the configurations to be set on the POM file. CloudHub configurations such as Properties, Insight and Logging need to be reconfigured every time the application is deployed. Ideally, we should be able to specify all configurations so they can be updated through the POM file, or the Maven plugin should redeploy without deleting the existing application so we don't lose the configuration. | 3 |
| 837 | MULE-8905 | Write documentation for the validations module | Write documentation for the validations module | 5 |
| 838 | MULE-8908 | Add the concept of ExceptionEnricher in Ext-Api | Add the concept of an ExceptionEnricher in the ext-api which gets invoked whenever an operation throws an exception. This is useful to avoid repetitive try..catch blocks. It would be defined by an interface roughly looking like this {code:java} public interface ExceptionEnricher { Exception enrichException(Exception e); } {code} Then you can declare it at an Extension level: {code:java} @Extension @Operations(Operations.class); @OnException(handler = PetExceptionEnricher.class) public class PetStoreConnector { … } {code} Or at a configuration level: {code:java} @Configuration(name="pooled-config") @PooledConnector(PetClientConnectionHandler.class) @OnException(handler = PooledPetConnectionExceptionEnricher.class) public class PooledConnectionConfig { } {code} A simple implementation would look similar to this: {code:java} public class PetExceptionEnricher implements ExceptionEnricher { public Exception enrichException(Exception e) { if (irrelevantException(e)) { logger.error(e.getMessage()) } else if (e instanceof SocketException) { return new ConnectionException(e); // wants to reconnect } else { return e; } } } {code} | 8 |
| 839 | MULE-8909 | Implement Reconnection on the Ext-Api | Implement Reconnection on the Ext-Api | 8 |
| 840 | MULE-8910 | Implement connection validation policy on Ext-Api | Create a mechanism so that connections can be validated to still be functional. Notice that this is not design time connection testing but runtime validation of a connection being usable. If the validation fails, then the reconnection workflow should be triggered | 8 |
| 841 | MULE-8916 | Unclear message when more than one transformer is available | When Mule finds more than one transformer flow execution fails. In this case we should show more information about the problem to the user, like why those transformers where selected and what to do to solve the problem. | 2 |
| 842 | MULE-8919 | mule-maven-plugin CloudHub deployment does not check for file existence | When you try to deploy a Mule application through a ZIP file, the Maven plugin does not check if the file actually exists. If it is an unexistent file, the deployment process starts anyway and the application is created in CloudHub using the name of the given unexistent file. The build fails because it can't deploy the application but the changes in CloudHub are already done and they're not rolled back. The expected behavior is that the plugin checks if the file exists before making any change in CloudHub. If not, it should throw an exception and fail the build. | 1 |
| 843 | MULE-8938 | Connector and Endpoint message notifications not fired when an exception is thrown | When there is an exception during the execution of a flow there are no connectorMessageNotification (when the new HTTP Module is used) or no endpointMessageNotification (when the HTTP Transport is used) sent, even when there is a response (with a failed status code). Expected: Some connector/endpoint message notification (maybe an specific type, like MESSAGE_ERROR) fired for this case. Actual: no notification. Attaching app showing the behavior | 8 |
| 844 | MULE-8939 | Release MVEL 2.1.9-MULE-008 | Perform a release of MVEL that contains the fix for MULE-8831 # Update pom.xml to meet Maven Central repository requirements # Update build plan to deploy to Maven Central # Sign the jar using gpg # Add javadoc plugin for releases | 5 |
| 845 | MULE-8958 | Allow insecure HTTPS connections | It is now impossible to disable all certificate validations in HTTPS, which would be useful for QA and early development scenarios. Though -Dcom.ning.http.client.AsyncHttpClientConfig.acceptAnyCertificate=true is intended for this, we are always adding our own default TlsContext when the protocol is HTTPS and thus bypassing that AHC logic. | 8 |
| 846 | MULE-9011 | Expand Flowstack functionality | The list of processors that were executed as part of a message should contain all processors executed, for all flows, so that it can be queried even after the message processing finished. | 5 |
| 847 | MULE-9012 | Include the name of the xml file where an element is declared when logging the element path | Currently, only the mule path and the application name are being logged when logging the path of an element as part of an exception message. For large applications composed of many files, the name of the xml file will be helpful to better find the component where the exception happened. | 3 |
| 848 | MULE-9032 | Upgrade BouncyCastle libraries to version 1.53 or newer | We should consider upgrading BouncyCastle to version 1.53 to leverage the latest bugfixes. This is a security related library and we should always use the latest stable version. | 5 |
| 849 | MULE-9038 | Build Mule 3.7.3 final binaries | Build Mule 3.7.3 final binaries | 3 |
| 850 | MULE-9060 | Update commons-collections version | The Apache commons-collections library (4.0, 3.2.1 and older) has a vulnerability in the InvokerTransformer object where serializable collections are allowed to execute arbitrary Java code, whenever the library is in the classpath. If we have an endpoint that receives a serializable object, that object can invoke arbitrary Java code at the moment we try to deserialize it. We should upgrade to the fixed version (3.2.2) as soon as it's available or remove the class from our classpath. | 3 |
| 851 | MULE-9065 | IndexOutOfBoundsException when header key has empty value | When an empty header is sent to a Jetty endpoint, it fails with said exception. | 5 |
| 852 | MULE-9066 | set-property throws runtime exception if the propertyName is empty | When using set-property, if the propertyName is empty, the schema consider it as a valid value, but every attept to use it throws a java.lang.StringIndexOutOfBoundsException. As a side effect, this also makes the request fail if the set-property is in a flow which contains an http:listener element. The solution IMHO would be changing the mule.xsd schema and adding a minLength value to the set-property element. How to reproduce: - Use the following mule-config. The deployment of the app will be successful. {code} <?xml version="1.0" encoding="UTF-8"?> <mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8981" doc:name="HTTP Listener Configuration"/> <flow name="set-property-errorFlow"> <http:listener config-ref="HTTP_Listener_Configuration" path="/set-property" doc:name="HTTP"> </http:listener> <set-property doc:name="Property" propertyName="" value="test"/> <logger level="INFO" doc:name="Logger"/> </flow> </mule> {code} When making a request, the config produces the following exception, and the response *never comes back*. {code} ERROR 2015-11-16 14:42:01,527 [[set-property-error].HTTP_Listener_Configuration.worker.01] org.mule.exception.DefaultMessagingExceptionStrategy: Caught exception in Exception Strategy: String index out of range: 0 java.lang.StringIndexOutOfBoundsException: String index out of range: 0 java.lang.String.charAt(String.java:658) ~[?:1.7.0_71] org.glassfish.grizzly.http.HttpHeader$Builder.handleSpecialHeaderAdd(HttpHeader.java:1240) ~[grizzly-http-2.3.21.jar:2.3.21] org.glassfish.grizzly.http.HttpHeader$Builder.header(HttpHeader.java:1134) ~[grizzly-http-2.3.21.jar:2.3.21] org.mule.module.http.internal.listener.grizzly.BaseResponseCompletionHandler.buildHttpResponsePacket(BaseResponseCompletionHandler.java:34) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.grizzly.ResponseCompletionHandler.<init>(ResponseCompletionHandler.java:52) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.grizzly.GrizzlyRequestDispatcherFilter$1.responseReady(GrizzlyRequestDispatcherFilter.java:96) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.HttpMessageProcessorTemplate.sendResponseToClient(HttpMessageProcessorTemplate.java:99) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:83) ~[mule-core-3.7.0.jar:3.7.0] org.mule.execution.AsyncResponseFlowProcessingPhase.runPhase(AsyncResponseFlowProcessingPhase.java:38) ~[mule-core-3.7.0.jar:3.7.0] org.mule.execution.PhaseExecutionEngine$InternalPhaseExecutionEngine.phaseSuccessfully(PhaseExecutionEngine.java:65) ~[mule-core-3.7.0.jar:3.7.0] org.mule.execution.PhaseExecutionEngine$InternalPhaseExecutionEngine.phaseSuccessfully(PhaseExecutionEngine.java:69) ~[mule-core-3.7.0.jar:3.7.0] com.mulesoft.mule.throttling.ThrottlingPhase.runPhase(ThrottlingPhase.java:185) ~[mule-module-throttling-ee-3.7.0.jar:3.7.0] com.mulesoft.mule.throttling.ThrottlingPhase.runPhase(ThrottlingPhase.java:1) ~[mule-module-throttling-ee-3.7.0.jar:3.7.0] org.mule.execution.PhaseExecutionEngine$InternalPhaseExecutionEngine.process(PhaseExecutionEngine.java:114) ~[mule-core-3.7.0.jar:3.7.0] org.mule.execution.PhaseExecutionEngine.process(PhaseExecutionEngine.java:41) ~[mule-core-3.7.0.jar:3.7.0] org.mule.execution.MuleMessageProcessingManager.processMessage(MuleMessageProcessingManager.java:32) ~[mule-core-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.DefaultHttpListener$1.handleRequest(DefaultHttpListener.java:126) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.grizzly.GrizzlyRequestDispatcherFilter.handleRead(GrizzlyRequestDispatcherFilter.java:83) ~[mule-module-http-3.7.0.jar:3.7.0] org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536) ~[grizzly-framework-2.3.21.jar:2.3.21] org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) ~[grizzly-framework-2.3.21.jar:2.3.21] org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy.run0(ExecutorPerServerAddressIOStrategy.java:102) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy.access$100(ExecutorPerServerAddressIOStrategy.java:30) ~[mule-module-http-3.7.0.jar:3.7.0] org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy$WorkerThreadRunnable.run(ExecutorPerServerAddressIOStrategy.java:125) ~[mule-module-http-3.7.0.jar:3.7.0] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [?:1.7.0_71] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [?:1.7.0_71] java.lang.Thread.run(Thread.java:745) [?:1.7.0_71] {code} | 1 |
| 853 | MULE-9069 | ExecutionInterceptor causes a 50% regression in the proxy scenario. | We found on the PerfCI test that the three proxy scenarios: [Module|https://github.com/mulesoft/performanceworks/tree/master/APPS/PROXY-MCD/1KB/http_module_proxy], [Transport|https://github.com/mulesoft/performanceworks/tree/master/APPS/PROXY-MCD/1KB/http_transport_proxy] and [Jetty|https://github.com/mulesoft/performanceworks/tree/master/APPS/PROXY-MCD/1KB/jetty_transport_proxy] Testing back with different builds we found that the regression was introduced between the builds 73 and 76, which relates to the dates 10/02/2015 and 10/05/2015, this reduces the list of possible changes to three commits, reading them one of them was spotted: [commit|https://github.com/mulesoft/mule/commit/3426f8762ced0f18b3193ab5384d0ea27b8f6696] We rollbacked the change in the ce distribution and was found that this is the cause of the problem, we encourage the team to define how to fix the previous issue to not impact on performance. Also during profilling a big contention was found tha ill attache in the logs output that may be the result of this changes regression. | 5 |
| 854 | MULE-9074 | WebService Consumer: xsd:import for external resources through HTTP fails with java.io.FileNotFoundException | WS consumer can't handle imported or included wsdl/xsd files when they are located externally. | 5 |
| 855 | MULE-9075 | Remove RC4 cipher suites from tls-default.conf | As per https://tools.ietf.org/html/rfc7465 we should remove this cipher suites from our suggested ones. | 3 |
| 856 | MULE-9078 | Add missing model validators | The following ModelValidators are missing and should be added: * Validate that all configuration models can be used with all operation models. This comes to the fact that an operation can require a connection type for which the available connection providers might be incompatible with certain configs (Moved to MULE-9214) * Validate that no parameters, configs nor operations are named as any of the following reserved words: name, config, configRef, connection. * Validate clashes on @ParameterGroup fields * Move some validations currently in ImmutableParameterGroup to validators * Validate that all connection providers have different names. Hint the user into using the @Alias annotation to customize the provider's names. | 5 |
| 857 | MULE-9083 | Add the concept of Message Sources in the Ext-Api | Allow the Ext-Api and the Ext-Framework to define and implement message sources | 13 |
| 858 | MULE-9084 | Allow SDK to generate Studio support | Allow the new SDK to optionally generate Studio editors and update site. On a first pass we only require functionality similar to that provided by Devkit. We'll iterate more in the future | 13 |
| 859 | MULE-9109 | Remove VM transport | Remove VM transport - All test cases testing VM must be removed - All test cases that are using VM as a mean for testing something else should be migrated to use something else whenever possible. PK created some infrastructure to replace VM usage like FunctionalTestCase.runFlow and <test:queue> component. ( see DatasourcePoolingLimitTestCase) - When is not possible to replace VM a new task should be created to cover that scenario when we have the required connectors/features to be able to test it. Add the test cases class names so we can use them as input for re-creating the test cases). Use issue https://www.mulesoft.org/jira/browse/MULE-9307 | 21 |
| 860 | MULE-9112 | Remove SSL transport | 1.2.14 Remove SSL transport | 5 |
| 861 | MULE-9113 | Remove TCP transport | 1.2.13 Remove TCP transport | 5 |
| 862 | MULE-9115 | Remove JMS transport | 1.2.17 Remove JMS transport | 8 |
| 863 | MULE-9120 | Remove devkit-support module | Remove module from the Mule 4 project | 2 |
| 864 | MULE-9149 | Upgrade antlr to 3.5 | We need to upgrade this dependency to match the one in mule-common and avoid conflicts. The affected modules would be drools and jBPM. | 3 |
