Can I deploy Mule on any of the application server. If so how do we deploy the Mule examples.
I have configured my eclipse to run JBoss and Mule Flows dont get deployed in the JBOss server. The syncronisation gives error(null pointer).
But when I run as Mule Application it runs fine but starts Mule Server.
How does Mule deployed in the production? Do we need Mule server in production working along with the application Server?
Can we package all the application in one(ESB + application) and deploy it in the application server.
You have the choice regarding production deployments of Mule:
Use Mule standalone as your first choice, as it comes packed with all modules/transport, is production grade (control scripts...) and supports hot application reloads.
If your deployment environment forces you to deploy on application servers (like JBoss), package your Mule application as a web application (WAR).
If you decide to package your Mule application as a WAR, I strongly suggest you use Maven to do so, as they each Mule module/transport require numerous dependencies. Dealing with this by hand would be insane.
Also be sure to use Servlet inbound endpoints instead of HTTP inbound endpoints otherwise Mule will open another HTTP server inside the web container. You want Mule to use the servlet container for its inbound HTTP requests.
Yes you can. You might want to take a look to the Embedding Mule in a Java Application or Webapp manual page, and the Deploying Mule as a Service to Tomcat.
Related
I have a basic spring batch app that runs on embedded Apache Tomcat in spring boot. I need to add spring admin capabilities to it. As per latest spring docs, I need to use spring cloud data flow to do this (https://docs.spring.io/spring-batch-admin/). So now I need to use spring cloud dataflow and integrate my spring batch app on local server. I just want it to run on my local machine under tomcat without deploying it to any cloud environments like cloud foundry or openshift. Is it possible? I am sure its possible. I would like to get some references/Examples on this type of integration and starter guide integrating spring batch app. Do I need to create tasks in spring cloud data flow to run my spring batch app? If there are any sample examples/pseudo code to guide me then it would be easy.
As described in the migration-guide, you can use the "local" variant of Spring Cloud Data Flow (SCDF) as a replacement to Spring Batch Admin (SBA).
SCDF is a simple Spring Boot application that you can run it as a standalone Java process similar to how you're running the application today.
Also, as described in the migration-steps, you'd have to port your existing batch workload to Spring Cloud Task model, and that should be a straightforward process - use this Spring Batch sample. To the most part, you'd copy/paste the business logic into a Spring Cloud Task application and all the infrastructure including schemas, repository, and other batch goodies will continue to work. There are few complex implementations in task-app-starers, which can be used as a reference, too.
Lastly, you can use SCDF's dashboard for monitoring and management.
I have used Spring Integration FTP to copy files from an FTP server to local and processing it. It is working fine with local using Spring Boot and Spring Integration, but I have deployed the application in OpenShift, but it is not looking for the FTP files.
For example:
In local FileReadingMessageSource is getting invoked
[task-scheduler-5] o.s.i.file.FileReadingMessageSource : Created message: [GenericMessage [payload=file-temp\abcd.xml, headers={id=30e5289a-aba6-19db-1d81-3036fca251b0, timestamp=1464675579294}]]
But it is not invoked in OpenShift. Is there any special configuration required for it to work?
As per the Linux team, OpenShift is not supporting FTP Client and it is not possible to run FTP using Spring Integration in OpenShift.
I need to create a http post request that will put a message in a message queue.So far I am able to do it successfull within the test framework i.e: using the integration node.
My question is how I will be able to test this from a external browser?
Do I need to deploy it in an external server?
Any links or suggestion will be really helpful.
I often use curl for testing webservices deployed to IIB. You can use the "-d" parameter to specify a file containing the POST data and this works well for both HTTP and SOAP.
I don't think browsers are meant to call web services directly, try SOAPUI for testing.
Message Broker Applications need to be deployed on a Broker and Execution Group or Integration Node and Integration Server (after V9).
I have a dropwizard application with a single resource. The resource is hosted on the server in form of JSON. I want to test the JSON created by dropwizard application by hosting a test server using TestServer Class of Dropwizard testing. So, I need to know how to stop/start a server using TestServer class in a dropwizard application. And I need to do it during test phase only no other alternative way.
There are many ways of deploying Mule ESB into a production environment. According to the documentation, it appears that running Mule as a standalone service is the recommended way of doing so.
Are there any reasons for NOT running Mule standalone in production? I'm sure its stable, but how does it compare to Tomcat as far as performance, reliability, and resource utilization go?
Should I still consider running it within Tomcat for any reason?
Using Tomcat, or any other web container, allows you to use the web tier of that container for HTTP inbound endpoint (via the Servlet transport) instead of either Mule's HTTP or Jetty transports.
Other differences are found in class loading, handling of hot redeployment and logging.
Now the main reason why people do not use Mule standalone is corporate policy, ie "thou shalt deploy on _". When production teams have gained experience babysitting a particular Java app/web server, they want you to deploy your Mule project in that context so they can administer/monitor it in a well-known and consistent manner.
But if you're happy with the inbound HTTP layer you get in Mule standalone and you are allowed to deploy it in production, then go for it. It's production ready.
Mule actually recommends deploying standalone. Inside a container like e.g. tomcat it has to share the threadpool, heap etc... This can obviously prevent it from performing at it's best.
The main reason you'd want to inside a container like tomcat is to get automatic deployment. I.e. you can just update your Mule application .war and the container will restart mule with the new application. This helps in testing.
Also some transports are specific to running inside a container, like the servlet transport. OTOH when designing solution so Mule transports between your container and your servlets your'e doing it wrong.