Worklight 5.0.5
Liberty 8.5.0.1
We are experiencing some timeout problems, i see in the liberty infocenter it says that you can turn on access logging on liberty with
<httpAccessLogging/>
and with
<httpAccessLogging enabled="true" filePath="e:\\Temp\\http_access.log" />
I have inserted the tag in my server.xml, but it does not create an access log file.
The main thing im looking for the is the IP address of the device that is making the call.
That was i can find out if the call made it to the server at a certain time..
httpAccessLogging is enabled on a per-httpEndpoint basis. Try:
<httpEndpoint id="defaultHttpEndpoint">
<accessLogging/>
</httpEndpoint>
...or:
<httpEndpoint id="defaultHttpEndpoint" accessLoggingRef="hal"/>
<httpAccessLogging id="hal"/>
Related
I'm going to describe an odd situation.. We have a product with a properly working CAS and LDAP integration. The problem is that not all of our clients use LDAP, which is fine, EXCEPT that the integration is still in place and so CAS is actively attempting to connect to the ldap server (and failing of course). It attempts to connect every five minutes, which creates a very bloated Tomcat log. My goal is to prevent it from attempting to connect without gutting the integration. I'm hoping someone knows of a way to prevent or manage when/how CAS attempts to connect to the defined LDAP server.
I've attempted to remove key components of the CAS property file as well as the deployerConfigContext.xml but the integration has too many dependencies, and I haven't been successful.
Here are some of the properties that are used in the cas.properties file. Setting the ldap.auth.enabled to false allows our integration to not use LDAP when authenticating the user but doesn't prevent CAS from attempting to connect to the LDAP server:
ldap.auth.enabled=false
ldap.url=ldap://xyz.customurl.com
ldap.useStartTLS=false
ldap.rootDn=DC=xyz,DC=xyz,DC=com
ldap.baseDn=DC=xyz,DC=xyz,DC=com
ldap.connectTimeout=3000
ldap.managerDn=CN=xyz,CN=Users,DC=xyz,DC=xyz,DC=com
ldap.managerPassword=xyz
ldap.authn.searchFilter=(&(sAMAccountName={user})(objectClass=user))
ldap.domain=123.456.7.890
ldap.pool.minSize=1
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600
ldap.usePpolicy=false
ldap.allowMultipleDns=true
This is the relevant section from the deployerConfigContext.xml. I've tried commenting the entire ldap section but have received various other errors that caused TomCat to crash:
<bean id="ldapAuthenticationHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="sAMAccountName"
c:authenticator-ref="authenticator" lazy-init="true"/>
<ldaptive:ad-authenticator id="authenticator"
ldapUrl="${ldap.url}"
userFilter="${ldap.authn.searchFilter}"
bindDn="${ldap.managerDn}"
bindCredential="${ldap.managerPassword}"
allowMultipleDns="${ldap.allowMultipleDns:false}"
connectTimeout="${ldap.connectTimeout}"
validateOnCheckOut="${ldap.pool.validateOnCheckout}"
failFastInitialize="false"
blockWaitTime="${ldap.pool.blockWaitTime}"
idleTime="${ldap.pool.idleTime}"
baseDn="${ldap.baseDn}"
maxPoolSize="${ldap.pool.maxSize}"
minPoolSize="${ldap.pool.minSize}"
validatePeriodically="${ldap.pool.validatePeriodically}"
validatePeriod="${ldap.pool.validatePeriod}"
prunePeriod="${ldap.pool.prunePeriod}"
useSSL="${ldap.use.ssl:false}"
subtreeSearch="${ldap.subtree.search:true}"
useStartTLS="${ldap.useStartTLS}"/>
The stack trace for the CAS to LDAP server connection is huge. Here is a small snippet. I can attach the whole thing if that is useful.
org.ldaptive.provider.ConnectionException:
javax.naming.CommunicationException: ldap.url.com:389 [Root exception
is java.net.UnknownHostException: ldap.url.com
I toggle between JDBC and LDAP/AD Handlers. Ensure that you comment out your ldap handler under:
deployerConfigContext.xml
xpath:
/beans
/bean[class=org.jasig.cas.authentication.AuthenticationManagerImpl]
/property[name=authenticationHandlers]
/list/
We satisfactorily resolved this by disabling this log4j property in the log4j configuration file in CAS:
<Logger name="org.ldaptive.pool.BlockingConnectionPool" level="debug">
<AppenderRef ref="console" />
</Logger>
Another option may have been to create a log4j filter and target the particular message that was causing the tomcat file to become huge.
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.
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 have an application running on Worklight 6.1 and I am seeing this messages on the log.
CWWKS3005E: A configuration exception has occurred. No UserRegistry implementation service is available
I don't need to authenticate the users on my application, can I ignore this message?
I'm not sure, but you can try to cancel logging for this specific package using following log configuration in server.xml:
<logging traceSpecification="XXX.XXX.*=off=disabled"/>
where XXX.XXX.* is the package where the error was occurred.
Here is a list of all available log levels: http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.nd.doc/ae/utrb_loglevel.html
I understand that you are not asked how to remove these messages from the log file, but you asked should you worry about these messages.
Anyway this log is not of Worklight server, it generated by Liberty server. It means you have something wrong in server configuration.
I found that this messages is because my server.xml configuration file of WebSphere Liberty Profile contains this feature
appSecurity-1.0
And I am not defining any User Registry.
http://pic.dhe.ibm.com/infocenter/rsahelp/v8r5/topic/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_feat.html
I am not running the Application Center in this profile and I am securing the Worklight console using properties in the worklight.properties file.
So, the question is can I remove the appSecurity feature?
Add <basicRegistry></basicRegistry> to your server.xml.
IBM Worklight 6.0 is installed on a Liberty Profile 8.5.5 with a mySQL db. While deploying the application and trying to access the Worklight console the below error is encountered on console
Error 500: javax.servlet.ServletException: Filter[authenticationFilter]: Could not find required filter class - com.worklight.core.auth.impl.AuthenticationFilter.class
In your server.xml you need to make sure that your worklight-jee-library.jar is in the application classloader.
<application id="worklight" name="worklight" location="BMOMobileBanking.war" type="war" context-root="/worklight">
<classloader delegation="parentLast">
<commonLibrary>
<fileset dir="/my/worklight/lib" includes="worklight-jee-library.jar"/>
</commonLibrary>
</classloader>
</application>
Make sure the "/my/worklight/lib" points to the directory where this JAR is. I may suggest ${shared.resource.dir}/worklight/lib which usually translates to $WASLP_HOME/usr/shared/resources/worklight/lib
I just went through the same issue. For me the issue is related to the worklight database not existing on my server. So check if the database WRKLGHT and WLREPORT are created and they are properly configured in your server.xml.
Look at the Create and Configure the databases link on the help website here
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.deploy.doc%2Fdeploy%2Fc_deploy_wl_project.html
If you've ensured the worklight-jee-library.jar is in the application classloader, and you're still having the problem, then you may have an issue with the Liberty server cache.
Try: server start worklight --clean
NOTE: replace worklight with your server name