I'm working on a Mobile First 7.1 application.
I have a JNDI entry in my server.xml like say,
<jndiEntry jndiName="MyPath/MyName" value="MyValue"/>
I need to access this JNDI property in my worklight.properties file. Went through the MF documentation, but nothing helped.
How do I retrieve this property in my worklight.properties so that I could use this in my adapters.
Found the solution myself.
Suppose, if there is a JNDI entry in server.xml like say,
<jndiEntry jndiName="MyName" value="MyValue"/>
Since, the values in the worklight.properties will be exposed as JNDI values finally, just declaring a variable without a value is the solution.
So, in your worklight.properties, just declare a name, without any values
MyName
Related
Recently, I switched to the websphere liberty 8.5.5.9. The adminCenter replaced the admin console. I used to configure many things in the admin console of lower Websphere version. but in the new admincenter, I couldn't find them any more, e.g. configure a datasource. any suggestions?
The Admin Console is the UI for WebSphere Traditional whereas Admin Center is the UI for WebSphere Liberty. Just like there are differences between the functionality of WebSphere Traditional and Liberty, same can be said for Admin Console and Admin Center.
Although Admin Center does not provide a 'wizard' type of experience that Admin Console does, you can use the Server Config tool to create a datasource and it can help guide you through the process by showing all the fields that can be set (including any defaults). If you stay in the Design view for the configuration file (likely server.xml) of the server that you want to alter, you can select 'Add Child' and select 'Datasource.' If will then populate all the fields with descriptions and defaults:
Data Source in Design View of Server Config in Admin Center
You can get similar assistance in the 'Source' view by activating content assist via ctrl+space. This functionality is not unique to datasource, but is provided for all elements.
In WebSphere Liberty you can configure your DataSource directly in the server.xml (similar to most server-level configurations in Liberty).
Here is an example from the Liberty documentation:
<dataSource id="DefaultDataSource" jndiName="jdbc/derbyEmbedded">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded databaseName="C:/databases/SAMPLEDB" createDatabase="create"/>
</dataSource>
<library id="DerbyLib">
<fileset dir="C:/db-derby-10.8.1.2-bin/lib"/>
</library>
To use a datasource, be sure to enable a JDBC feature in your server.xml, such as this:
<featureManager>
<feature>jdbc-4.1</feature>
</featureManager>
If you're not sure where to find your server.xml, by default it is in this location:
${wlp.install.dir}/servers/${your.server.name}/server.xml
For full doc on configuring data sources in Liberty, see: Configuring relational database connectivity in Liberty
In addition to editing the server.xml as described by aguibert, you can create and edit data sources using the Liberty AdminCenter as described in this IBM KnowledgeCenter topic.
We have an issue where the Worklight server is disclosing an Internal IP in its header.
In the Host : A.B.C.D is showing our internal IP server.
How can we resolve this issue, or is there any configuration in the server that needs to be applied ?
eI see a paramter called $WSRH: where does it come from ? since this one contains the IP. was it defined somewhere in the worklight.properties (or as JNDI property (some people use it later as adapter parameter)?
However, I believe you original question is about "Host" cookie value.
maybe this will help:
examine your worklight.properties (also packed into the project WAR file)
you can define there: publicWorkLightHostname
When configuring WL HTTP Adapters, the domain and port are part of the adapter configuration .xml file build and uploaded on the WL server.
For our use case (especially beta testing and demos) the endpoint server url needs to be configurable for the end user. Example, same builds are tested by QA on test envs, while BA connects to demo.
We have only one WL Server up and setting environment specific servers is not an option.
Is it possible to change domain/hostname dynamically at application launch or runtime ? Ideally it would be to get and use the domain/hostname value from a drop down or free input from the client and use it.
<connectivity>
<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
<protocol>http</protocol>
<domain>{hostname}</domain>
<port>80</port>
</connectionPolicy>
<loadConstraints maxConcurrentConnectionsPerNode="2" />
</connectivity>
Update: This answer is useful, so I leave it here for reference, but accept that it doesn't correctly answer this question!
There is a specific Worklight feature designed to address your scenario (for the Infocenter detail, see here).
You can do this by using a combination of worklight.properties and JNDI properties.
For example, let's say you had this setup in your adapter XML:
<connectivity>
<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
<protocol>${my.adapter.protocol}</protocol>
<domain>${my.adapter.domain}</domain>
<port>${my.adapter.port}</port>
</connectionPolicy>
<loadConstraints maxConcurrentConnectionsPerNode="2" />
</connectivity>
You then define default values for these in your worklight.properties file (in the server/conf directory of your Worklight project, and "burnt in" to the .WAR file when you build it):
my.adapter.protocol=http
my.adapter.domain=some.host.com
my.adapter.port=80
You can then override these values in individual environments, by setting JNDI properties. For example, if you are using WebSphere Liberty, you might put this in your server.xml:
<jndiEntry jndiName="my.adapter.protocol" value="https"/>
<jndiEntry jndiName="my.adapter.domain" value="some.other.host.com"/>
<jndiEntry jndiName="my.adapter.port" value="8080"/>
You could create 3 adapters: 2 adapters connect to each backend servers, and one "proxy" adapter.
Your application would call the proxy adapter, passing some variable (the dropdown). Then the proxy would call one of the 2 real adapters.
You can´t. An option is to use MashUps.
See:
IBM Worklight 6.1 - Can a HTTP adapter call another HTTP adapter on server-side?
http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v620/04_11_Advanced_adapter_usage_and_mashup.pdf
The idea is to have an Adapter responding to app mobile than this adapter call other deployed adapter (QA, Test Env, Prod Env, etc) considering any logic.
I think if you override WL.Server.invokeHttp so you can specify the domain name in each request instead of using the one set in the XML file, would a good alternative . You can get the domain name as parameter in the invocation request.
There is question that may interest you regarding that, you should check it because I'm not sure if it's possible or not. Worklight Adapter Override Origin of request
I need to change the value of the project stage dynamically ( at runtime ), based on the environment, using JNDI. From what I understand, the JNDI will override what is defined in web.xml. Is there a document / link that will help me with how I should code it? I am using websphere 8.5
In some examples I have seen that it is defined as resource-ref, but I am not sure I understand how is that used with JNDI to make it work and change the value at runtime.
Can someone help me with this?
As JSF 2.0 spec states, you can override context parameter javax.faces.PROJECT_STAGE via JNDI entry, which is looked via reference java:comp/env/jsf/ProjectStage.
To override the context parameter, you need to define following resource environment reference in your web.xml file:
<resource-env-ref>
<description />
<resource-env-ref-name>jsf/ProjectStage</resource-env-ref-name>
<resource-env-ref-type>java.lang.String</resource-env-ref-type>
</resource-env-ref>
in the application server configuration, you can define your ProjectStage value via Namespace binding ( in the web admin console select Environment > Name Space Bindings, define new String variable with jndi name jsf/ProjectStage and value Development or Production, depending on the environment).
Finally you need to bind your reference in the project with variable in JNDI. You can do it it 2 ways, via ibm-web-bnd.xml file, defining:
<resource-ref name="jsf/ProjectStage" binding-name="jsf/ProjectStage" />
Or during application installation, in the step were you provide mappings for Resource environment references.
For detailed discussion on this topic check Dynamically change project stage value at runtime using JNDI
I have a web service. Its domain and port can be changed. So I want to read port and domain from file or db. When this information change, I update them in db or file.
Adapter XML:
<domain>${adp.hostname}</domain>
<port>${adp.port}</port>
worklight.properties:
adp.hostname=localhost
adp.port=10080
This is working fine. But I'd like to take adp.hostname and adp.port from file or db.
Something to remember about adapters is that you cannot change in real-time any of the properties set in the adapter XML once it is deployed.
Once the adapter is deployed, it is transformed into an object and is stored in memory. At this time, then, you can no longer interact with its "setup".
The only thing you can do, is to decide what will be the value of these properties before your deploy the adapter. For example, a different set of properties for QA/TEST/UAT/PROD environments...
To setup external properties, starting Worklight 6.0 and above, you can read this documentation topic: Configuring an IBM Worklight project in production by using JNDI environment entries
Specifically for Tomcat in its server.xml:
<Context docBase="app_context_path" path="/app_context_path">
<Environment name="publicWorkLightPort" override="false"
type="java.lang.String" value="9080"/>
</Context>
You change app_context_path to your project's context (project name)
You add environment child elements for each property you need
Important to remember: these properties must also exist in worklight.properties; those will be the default properties, and if using the above example they will be over-written and the environment properties will be used instead.
In the example above you can see that it will replace the default property publicWorkLightPort.