I want to add a mule flow developed in one project to another project i.e wanted to use the flow created in one project in another project like flow reference.
If I am understood your requirement correctly, Your trying to access one mule flow that resides in one project from another project mule flow.
If yes, then you can't use mule flow reference component to achieve this instead you can VM component.
Mule introduced concept of Domains in mule run time version 3.5 and mule anypoint studio with run time version 3.6.
With Domains concept you can access flows across projects using VM component. Go through the below Mule documentation link that will clearly tell you on how to
https://docs.mulesoft.com/mule-user-guide/v/3.7/shared-resources
1) How to create Domain application.
2) How to create Shared components in Domain.
3) Creating application that uses shared components in Domains.
4) Deployment of Domains etc ..
You can manage your projects via Maven and package reusable flows. Mule can then use any of these flows imported on the classpath: https://docs.mulesoft.com/mule-user-guide/v/3.5/modularizing-your-configuration-files-for-team-development
Related
I am developing a project using grizzly-framework, which is a component integrated by glassfish. The project consists in building an agent, which is getting requests from lot of clients. This agent should then process the requests by communicating to a cloud-platform and getting information from there. The agent is based on grizzly. Since I do not have experience using glassfish, so I have mainly two questions:
1) I am asking, in which context I should use glassfish-embedded-web in my actual project.
2) Which benefits can I have when using this dependency?
I don't remember where I've red that, for gwt 2.7.0 sdk maven module must consist of 3 submodules: server, shared and client.
But on github I've seen different projects for 2.7
Can any one can answer me this question?
Code in server - runs in servlet container (for example access to DB)
Code in shared - can be used in client and in server codebase (for example DTOs - data transfer objects)
Code in client - will be compiled to JavaScript and runs in browser
So you must decide yourself how much modules you need. If you code is a simple widget that does not communicate with server, you need only client module
I am developing a Windows Service that uses TCP/IP to communicate with their clients.
So i create a project for the service using Maven. Now i need to create a client to comunicate with this service. Is it better to create another project or a module? Or create it inside the Windows Service project?
For development purposes it easier to create another module. First, its easy to view both client and server code in the IDE without having to close and open projects. Second, common code can be placed in another module, which makes easier to code and debug.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
Can any one tell me how to public the wsdl file ie., that web service is created in java using eclipse.I am self learner to java/eclipse and web service too,so can any one please make me clear with steps.
Thanks for your time!...
Apache Axis has some cool tools that I frequently use - to generate a wsdl, use java2wsdl. It has a command line version, but also a Maven plugin (which I highly recommend) that will re-generate the wsdl for you automatically each time you package your web service.
What's more, the axis stuff also provides auto-generation of client stubs by which you can use your web service in consumer apps or services. Alternatively, JAX-WS tools can be used for this as well. In either case I would recommend automating the process with Maven.
If you package your wsdl with your app in this way (rather than letting a server do this for you automatically), you can be certain that your contract will look the same on any platform.