I'm trying to create a multiple mediators inside same java packages. e.g.
com.samples.wso2
However when 2 or more mediators are deployed using same package name, ESB will find just one mediator class. If unique package name is used for different mediators then all are found. Didn't find any information about this but seems like a bug to me. Can somebody confirm this ? Thanks,
Version used 4.8.0.
I have 2 custom mediators ("genuine" mediators, with xml conf, not class mediators) in the same package in WSO2 ESB 4.8.0 without problem
You should verify your META-INF/services/org.apache.synapse.config.xml.MediatorFactory and MediatorSerializer files : you need two lines in each file, to reference factories and serializers for each mediator
Related
I am performing XML to JSON transformations using Transform Message connector. I have created a mule-plugin for the transformations code and added it as a dependency to my application. When I deploy the application in anypoint studio(4.3.0) it is working as expected i.e. I am getting the full payload transformed to JSON. But, when I deploy the same application to ONPREM some fields of input(XML) are missing in the output(JSON). In case of the ONPREM application I am sending the message(XML-payload) via JMS(1.7.1)-Publish by publishing it to a JMS queue where my application is listening using JMS-On New Message and using the transformations mule-plugin(added as a dependency) to transform the XML to JSON and publishing via JMS-publish to a queue where another API is listening.
I observed that when I am dividing parts of dwl in modules and importing them in a main dwl and deploying at ONPREM the fields are missing. But, when I am using all the module's dwl code in same dwl file I am getting all the fields.
Please Help me with this.
Issue Resolved. There was a difference between Studio Runtime and ONPREM Runtime. When I patched the ONPREM with latest update. The Issue got Resolved.
So, i have three mule applications where one needs to be started before the other two. And I start mule as a windows service. I found this site and follow the example by putting
wrapper.app.parameter.1=-app
wrapper.app.parameter.2=%MULE_STARTUP_ORDER%
in wrapper.conf. where MULE_STARTUP_ORDER is an system variable containing App1:App2:App3
But when i look in my mule.log after staring the service app2 starts first followed by app3 and app1 is last.
And I use mule standalone 3.7.0.
Anyone have any idea what I am doing wrong/missing?
Try setting the list of applications directly in wrapper.conf in case the service has no access to the system environment variable from Windows. Also try using higher numbers for the parameters like the example in the KB article you referenced. Low numbers might be get overridden by other parameters.
Example:
wrapper.app.parameter.10=-app
wrapper.app.parameter.20=app1:app2:app3
I want to set time zone in server. Similar we have in mule 3
https://help.mulesoft.com/s/article/How-to-properly-set-the-TimeZone-in-Mule-Mule-Runtime-and-CloudHub
But in mule 4, i don't see a way to call class file outside flow. Any suggestion?
One way i found is setting the -Duser.timezone= in VM arguments. But still looking for way at program level
To call Java classes in Mule 4 you need to add the Java Module to your project and use it to call the method. If you want to use the Spring configuration instead of calling Java from a flow, then you need to add the Spring Module. Note that you have to put the Spring bean configuration in its own pure Spring XML file. Mule 4 XML files are not Spring XML files like in Mule 3. That means the Spring XML file must not have a <mule> tag. You need to reference the Spring XML in the Mule XML (example: <spring:config name="springConfig" files="beans.xml" />).
See the examples in the Spring Module documentation if you are not familiar with Spring.
I am using Mule 4 and I am looking to deploy a new application in Cloudhub but it is not allowing me to use the name "customer-api". There is no other application called that in any of the environments and I cannot see it used in API manager either. There was an API called customer-api which has been deleted so not sure if this name could still be cached/ registered somewhere and the entry needs to be cleared.
The only place I can see that name used is in the Anypoint Exchange but wouldn't think that would impact what we are deploying.
Does anybody know what could be preventing me from using that name?
Thanks for any help
Every MuleSoft customer uses the cloudhub, which means it has to be "globally" unique. Try customer-api-randomString and it should work.
I am trying to connect to GlassFish 3's JMS service from a standalone remote client. However I am getting a java.lang.ClassNotFoundException: com.sun.messaging.jms.ra.ResourceAdapter. Any ideas on how to fix this?
Here's my setup so far:
Glassfish 3 JMS Service in LOCAL mode (I am assuming that EMBEDED mode will not work in this case because it bypasses the network stack)
JNDI properties are specified as follows:
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
gf-client-module.jar (in GLASSFISH_HOME/modules) added to the standalone application's classpath. Also tried adding other jars present in the modules directory (such as jms-core.jar), but still getting the same ClassNotFoundException.
Any help would be much appreciated.
Instead of using all of the individual Glassfish jar files that you might need (such as gf-client-module.jar, imqjmsra.jar, and imqbroker.jar), the preferred method is to use the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib.
There is more information at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. That document pertains to using EJBs in standalone clients, but the solution is the same for using JMS.
Ok. I found a solution. See here for details, but the short answer is that I needed to add two jars to the classpath: imqjmsra.jar and imqbroker.jar. These were available inside a rar called imqjmsra.rar which can be found under glassfish's mq directory. I had to extract the two jars from this rar!
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
As mentioned in the Ivan A Krizsan's notes for the EJB certification, and depending on the Glassfish version, this should be enough:
GlassFish 3 (and GlassFish 4 too, I've just tested it): $GLASSFISH_HOME/lib/gf-client.jar
GlassFish 2: $GLASSFISH_HOME/lib/appserv-rt.jar and $APS_HOME/lib/javaee.jar