In IBM Worklight 6.1, does the serverSessionTimeout property from the worklight.properties overrides the regular timeout configured in the App server ? In my case, I am running on Worklight on top of IBM Liberty, so the session timeout definition is set at <httpsession invalidationTimeout>.
In summary, what is the precedence? Worklight Session Timeout or App Server session timeout?
By using the serverSessionTimeout property in server\conf\worklight.properties (which will later sit in the project's .war file which you deploy to the WAS Liberty profile application server), you will override the default timeout value provided.
See this related question: What is the behavior of the session properties in the initOptions.js and worklight.properties file?
Related
I am trying to deploy an application from the central mobileFirst console (IBM MobileFirst 7 with Websphere Liberty) of a server farm consisting of 2 clusters. I have modified server.xml in each server in order to change the port from 9080 to 80.
I have changed the following lines:
!-- Declare the JNDI properties for the Worklight Administration Console. --
<jndiEntry jndiName="worklightconsole/ibm.worklight.admin.endpoint" value='"*://*:*/wladmin"'/>
to this:
<jndiEntry jndiName="worklightconsole/ibm.worklight.admin.endpoint" value='"http://MyServerEndpoint:80/wladmin"'/>
Though, everytime I try to depoly an application from the central worklight console (the console of the load balancer) no application is installed without an error in the worklight console while in the server that tries the deployment I see the following error:
Received status 500 for GET http://MyServerEndpoint:9080/worklig
htadmin/management-apis/1.0/runtimes?fullInfo=true
Why does it go for 9080 again since I have changed it? Do I have to change something else that I haven't changed?
NOTE: When I deploy an adapter everything works fine and both servers can see the new adapter.
When you changed the value of the jndiName from a the original string, you made it into a URL, according to this IBM KnowledgeCenter topic, if you want to bind an instance of java.net.URL into the JNDI namespace, use the jndiURLEntry configuration. For example:
<jndiURLEntry jndiName="urls/IBMKnowledgeCenter" value="http://www-01.ibm.com/support/knowledgecenter/" />
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 implemented a Push Notification adpater and would like backend system to call the procedure in order to submit notification.
With reference to this post, http://server:port/dev/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used but it works in development environment only.
At the end of the post it is mentioned that http://server:port/context/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used to invoke the adapter.
(1) May I know whether it is supported in production environment only? Because it returned HTTP method GET is not supported by this URL in development environment.
(2) Noted that we might need to define securityTest="wl_unprotected" for the adapter and thus the adapter is not protected. What will be the best way to achieve the goal for backend sytem to call the adapter with security control?
In Worklight 5, Worklight Studio uses Jetty within and the usage of a context root is not required. Only once moving your project to an application server such as Tomcat, WebSphere, Liberty, you have to specify it (in worklight.properties and application-descriptor.xml).
So,
in development - no.
in production - yes.
In Worklight 6 where Jetty has been replaced with Liberty, context root is now part of your project whether you are in development or production.
You will have to add the "wl_unprotected" securityTest to your procedure in the adapter XML.
As for protecting the requests, my guess is that your IT department can isolate and protect specific URLs and not allow using them in certain scenarios. You already have the URL structure for them to use.
I have seen some questions about dynamic adapter configuration at run-time
how to pass domain,port number,username and password from user input to worklight http adapter
With a Worklight Adapter can I change the domain and port for a procedure at runtime?
but my question is about adapter configuration after deploy on WL server 5.0.6 from external - not at runtime from code.
Our scenario is that in our enterprise development and testing process requires the QA and Testing team to change the destination host and port for the adapters from mockup-backend to testing-backend to production-backend regularly during testing.
of course, this should happen through configuration and not re-compile and re-deploy.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6?
Can this be changed in the WL database tables?
Can this be changed in the WL server filesystem somewhere?
since we did not find any solution to that yet, the developer team is already thinking about using the Adapter only as dumb facade and implement all connection to the backend-services in Adapter-side Java using the Java URL and Connection classes.
Then it would be easy to read a configuration file from the file system in Java to change the backend destination URL and ports in this file.
It would even be easy to read the URL and port from a property in the worklight.properties file in JavaScript and pass it to Java to connect.
I would like to avoid having developing all backend connection code in Java. I would rather see the project use the actual Adapter connectivity features, but I am also not sure how to convince the team since it is quite easy with just 4 lines of code in Java. The advantage of using the Adapter connectivity that can not be configured is hard to see over a own Java implementation in Adapter-Java code.
Thank you.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6? Can this be changed in the WL database tables? Can this be changed in the WL server filesystem somewhere?
In Worklight 5.0.6, as written in the questions you've linked to in the question, an adapter's connectivity settings cannot be altered. They are stored in the packaged adapter and cannot be read from anywhere else during runtime nor after deployment.
Which URL, port and weblogic server side settings do I need to use?
It depends if you want to connect to a WebLogic MBean server (Domain, Runtime, Edit) or platform (JDK) MBean server (See MBean Servers).
Connecting with JConsole to a WebLogic MBean server is usually a real pain:
Enable Anonymous Admin Lookup if version is lower than 10.3 (See WebLogic anonymous user permissioning)
Enable IIOP Protocol for Admin Server and Application Servers (See Enable and configure IIOP)
Launch jconsole with a custom commandline (See Managing WebLogic servers with JConsole)
Connecting to platform MBean server is like any other JVM (See How to activate JMX on my JVM for access with jconsole), but you would not see any WebLogic MBeans unless you configure WebLogic to use it (See Registering MBeans in the JVM Platform MBean Server).
Try adding this to your server start-up parameters. Change the port (7011) to whatever you prefer. You should be able to use JConsole then by specifying the remote server "{host}:{port}"
Note: the {host} does not include a "http://" prefix.
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=7011
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Also, you probably don't want to disable authentication like this in a production environment, but the parameters above should help you with testing. When using this, you won't need to specify a username/password in JConsole.
You'll have to enable the remote server to listen on a specific port for JMX -http://download.oracle.com/javase/1.5.0/docs/guide/management/agent.html#remote
URL would be your server's listen address. You also have the option to require authentication to limit the usage of the debug port.