As per the link, Mule Anypoint Studio application launcher now supports launching multiple applications and it works. I could not find how to stop individual application if multiple are deployed?
http://blogs.mulesoft.org/release-studio-2015-01/
You can't. Studio's console refers to the JVM instance running the attached Mule distribution, not to each individual deployed app on that instance. However, if you modify any app config file, that app will be redeployed.
On the other hand, reviewing the log you can see that each app is deployed independently from <workspace>/.mule/apps/<app-name>.zip. After its deployment, a file named <workspace>/.mule/apps/<app-name>-anchor.txt will be created, if you remove that file the app will be undeployed.
HTH, Marcos.
I did stop an individual app while others are still running. Please see the image below for your reference.
you can see the app mule-smtp has been stopped while others are in still running state.
Hope this helped.
you can enable the mule run time in preferences tab of anypoint studio.
That is easiest way to stop specific applications on anypoint studio
Related
I'm trying to publish an ASP website with a Azure SQL database to Microsoft Azure using Visual studio 2015 community. Its getting stuck at a certain point and taking too much time. Screen is shown below.
Screenshot of Output window
From the deployment screenshot, it seems your application takes too long time to update file CustomerCarePortal.dll. If this file is too big, it is normal to take some time to upload. If this file is not big, please try to delete this file via ftp, then deploy again to see whether it will reduce your deployment time. You could also try to deploy the application to a new clean Web APP to check whether it related with Azure Web APP environment. If you have some deployment issue, please have a look at this article. The detailed log information may be help to find out the reason.
Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.
I am running on SP1 beta of 2010... it may or may not related to the beta. But, in general, can adding a project to the codeplex TFS server somehow make WCF break when also inside an Azure project?
Seems to be the pattern for me. Immediately upon launch I get a ServicePoint exception. If I remove the app from source control everything works fine.
My project consists of
Azure WCF hello world application
VS2010 SP1 beta
Adding codeplex TFS reference causes exception
Is it a CommunicationFaultedException? If it is, it is a bug when working with Azure 1.3 SDK projects that are checked into TFS. Make sure you have the Web.config file checked out (writeable).
If not, can you give any other information on on the ServicePoint execption?
I'm looking for suggestions on keeping a program that is running on a network updated. Installation consists of 15 users, each have the program on their local pc, but they all access same date from sql server.
I am looking for a clean method that would allow me to update one folder on the network and for each computer to get updated when they run the program and the programs sees a later ver on that folder on the network. (Obviously I can do this inside the program itself since it won't allow being overwritten while opened.)
You should have a look at
ClickOnce is a deployment technology
that enables self-updating
Windows-based applications that can be
installed and run with minimal user
interaction.
Using ClickOnce Deployment in
VB.NET
ClickOnce - A new VB.NET 2005 Deployment Tool
ClickOnce Deployment for Windows Forms Applications
ClickOnce Deployment in .NET Framework 2.0
Another option is to create a second program that will check the network for an updated version of your application. Let's call this program "updater.exe".
You can run updater.exe on system startup like Adobe Reader or Sun Java do.
Or, when your application is started it can load updater.exe. If updater.exe finds an update, it can close/unload your application, download the newer version, restart your application and close itself.
astander's answer above is correct, you can use ClickOnce for this. Another option is creating this application as a web application.
Web applications basically work the way you described, the application's files reside in a web server, all the users connect to it using a browser, and to update the application you only need to update the files in the server.
I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.