I have deployed my application running on my local server # http://localhost:8048/myservice?day=xx&month=yy&year=zzzz , it works succesfully on my local machine, in that it downloads a file from the http site. However when I deploy to Mule Management console . I understand that the default port is 8585. When I change the URL to MMC & give the default port with the same path, it does not download the file . Am I missingsomething
The MMC is a utility for managing and monitoring Mule Standalone Runtimes.
One of its functions is to deploy apps to a Runtime. You are not actually deploying to the MMC.
Does this help clarify the situation or do you want any further help on want The MMC is used for and how to do it?
Please check the logs inside MMC.It stores the logfiles date wise.See if your application has been deployed in MMC successfully and if yes then do the following things:
1)If you are using any path to download the file then cross check the path details.You can put a logger to crosscheck that.
2)Put a logger before the business logic and after the business logic and follow what it is logging in the log file.
3)In case your server is Linux then check the path separator pattern
MMC is a Mule Management Console which is used (provides provision) to deploy, undeploy, manage, monitor application and server both. From the statement you mentioned in your query it seems you are trying to deploy the app in the MMC - MMC is not a server its a console where you can register your ESB Runtimes -or- API Gateways (on-Prem) servers so that you can deploy the applications to the server/runtimes (which will go to the runtimes location $MULE_HOME/apps).
Please check if you have registered the server under MMC's Server tab - if not then you have to do this first and then it will allow you to perform application deployment using the MMC's APplication tab where you can upload your deployment archive/artifacts/build to the mmc repo and then you can deploy through the deployment options by selecting your server (which you have registered).
If I am missing something from your statement then please clarify more and will try to help you out here.
Related
I've created multiple managed servers in Weblogic. Each managed server has same IP(IP of weblogic server) and unique port.
I've installed ear and war files in these managed servers and all of them has their own context-root.
For example I have ear file A with context-root A on server A and a war file B with context-root B on server B.
Whenever I browse IP:PORT(A) which has set on server A, this application needs some files on war file B which has deployed in server B. So A can not find its resources and I get error.
I should mention that I put them in a cluster too but nothing changed.
How can handle this matter?
The cluster won't help you in this way because each web app is isolated from others in its own web container. If you need to share data or resources between web apps you can use a shared file system or a database for instance.
For this purpose I've used Oracle Http Server (OHS) plugin. after hours of searching in internet I've found that Weblogic application server does not implement anything to handle this issue.
https://docs.oracle.com/middleware/1213/webtier/
I am inside a corporate firewall that does not allow me to access the free deployed instance at https://console.gridgain.com/. I downloaded the source and tried to build but again the firewall does not allow me to go outside the network to retrieve the dependencies specified in the pom.xml file.
What are my options
You can download binary build of Ignite Web Console from Apache Ignite, deploy it on premise.
You can also deploy paid version of GridGain, deploy it on premise.
You can download WebConsole from the GridGain website by the following link: https://www.gridgain.com/resources/download
You can install it in your environment and use without needing to access external resources.
I have installed Worklight 6.2 on Linux, using Liberty 8.5.5 and DB2 10.5. Created the DB2 databases for WRKLGHT and WLREPORT. Have executed the Server Configuration Tool and successfully created a Worklight Server configuration (did not have any errors in the Console view when running the Ant tasks, tables were created successfully in the database, and configuration shows deployed status in the SCT). Created a runtime environment in the SCT, also seemed to succeed (no errors in Console view, tables created/updated, runtime environment shows deployed in the SCT). Stopped and restarted the Liberty server.
Can hit Worklight admin at (/worklightconsole) and log in successfully using my demo user, however it then indicates there are no runtime environments. When trying to access runtime environment at /worklight/console (which should be the correct URL given how I created the runtime config in SCT using my Worklight project WAR), I get various errors: first "Service unavailable since initialization is not yet complete." then after retrying for about a minute or two I get "javax.servlet.ServletException: java.lang.RuntimeException: Timeout while waiting for the management service to start up at com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForInitialization(AuthenticationFilter.java:561)".
Seems the management service is not starting up successfully. Upon reviewing the messages.log I see the following error precede it: "FWLSE0242E: Failed to synchronize application runtime information. The servlet initialization failed and the servlet will deny serve. The most common reason is a failure in JMX communication with the ''worklightadmin'' service. You need to restart the web application after fixing the problem. [project worklight]" and this creates an FFDC log.
I know this is a lot of information but trying to be complete. Anything I should check to fix the JMX communication issue and get the management service starting?
Thank you for the replies back. Turns out there is an issue with Liberty (I was on 8.5.5.0) and the IBM JDK I was using (1.7_64). Swapped out to the Oracle JRE (1.7.0_60-b19), pointed Liberty to use it, and the problem was solved. I am pursuing a fix with the Liberty team through IBM Support for this issue.
I cannot give a unique solution, but I can explain the situation and this may lead to a solution.
The runtime servlet initialization tries to contact the Worklight Admin service. The Worklight Admin service is a web application that must be running when the runtime starts. The runtime was not able to find the Worklight Admin service. It waited a while, in case that the Worklight Admin service is just starting up, but then gave up due to a timeout because within a given time, it could not find the Worklight Admin service.
Possible reasons:
the web server is not at all configured to run the Worklight Admin service. In your case, this seems not the problem, since you can access the Worklight Console. You should also see in the log file whether the Worklight Admin service did start.
the worklightadmin service might never start up ... this could be a configuration problem, e.g. with the WLADMIN data base. This could also be detected from the server logs.
when the runtimes and the Worklight Admin service start up together, it might be that the Worklight Admin service simply takes too long to start. Let's say you have 100 webapps, and the runtime starts first and the Worklight Admin service starts last, it could be that the 98 other webapps take too much time to start. In that case, make your web server lighter ... run only Worklight on that webserver, nothing else.
the Worklight Admin service starts, but the runtime cannot communicate with it. This indicates that the JMX communication is misconfigured. Follow the documentation of the webserver how to configure JMX. For liberty, see http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_admin_restconnector.html?cp=SSD28V_8.5.5%2F1-5-2-10-1&lang=en
I have created a server in liberty and installed IBM Worklight in it.
Everything was working fine till I protect the console.
After protecting the IBM Worklight console the authentication is asked
twice.
First Login Screen with URL localhost:9080
After Login Successful.Again the login is being asked with the hostmachines URL 192.168.10.16:9080
My questions are
Why login appears twice?
Why my hostmachine ip is being revealed?
You are accessing the console with address localhost, whereas in your code you are either using publicWorklightHosname=192.168.10.16 or while building you are using build for remote machine and then putting in IP of the server.
Here is what you need to do:
Make sure a DNS entry of the hostname is present in the server and client machine
Change the publicWorklightHostname property in worklight.properties file to a proper address eg
mymachine.mydomain.com
while building for Remote Server, use the same address as above i.e. mymachine.mydomain.com
redeploy the new war file
Worked perfectly for me.
P.S> I believe you are using local machine, in this case also you can use the machine name in worklight.properties file and make sure that the address you are using is same as the one you used to build. Nonetheless, it doesn;t matter in production or application deployment.
I installed worklight 6.1.0.1 on eclipse kepler from marketplace. I am getting the following error when I tried to build the application.
" Failed to deploy the application to Worklight server: please verify that the Worklight server is started and reachable.Connection to - 192.168.112.1:10080 failed. (Permission denied: connect)."
We send SOAP requests from the adapter. The backend services are only accessible if connected to VPN. I have connected to VPN and deployed the application. few JS files like dojo.js are pointing to local IP. For building the project to VPN IP , I right clicked the project and Run As>Build Settings and deploy targets. In the window that is popped up, I gave the VPN IP and cliked Ok. Again I right clicked project Run As>build all and deploy all. But still its being pointing to local IP 192.168.112.1:10080 and getting the error mentioned above when I try to deploy the application.
Even if I open project on worklight project console, its redirecting to local IP.
I think some ideas are mixed here.
Your application will be running in a local Worklight test server, that as part of Worklight Studio is placed in your development environment (localhost). If your adapters must use the VPN to reach the backend services, then you must only make sure the your-adapter.xml referes to the correct HTTP host (i.e. an IP address available through the VPN).
You should not need to change your local server address, i.e. if you double-click the Worklight Development Server in Servers view, the Host name field should be "localhost" (without quotes, that's the default value), or preferrable a local IP, may be 192.168.112.1 (or whatever local IP you have). If after trying all this, that still don't work, I'd change that to your VPN IP, but I believe that's not necessary.
One thing you may not be aware of is that when doing a build and deploy to Worklight Development Server, and you have the host name set to "localhost" the Worklight Studio will "guess" your IP, so that's probably the problem you are facing.
In a nutshell, what I'd do is:
1. Make sure your server host name is still localhost (or a fixed local IP address)
2. Make sure your adapter.xml file(s) refer to a correct IP or fully qualified host name in the VPN, so you can reach them.
3. Run As -> Build All and Deploy
4. Test
What I'm saying here is if you want your app built using the VPN IP, then you don't need to do it through Build Settings and Deploy Target, but just going to Servers View, double-click on Worklight Development Server and then set the Host name to the IP you want. The Build All and Deploy will do the rest for you.