Version: Worklight 6.0
I'm following the instructions in infocenter for deploying the war file to a standalone websphere application server 8.5 and there is one step that I do not understand.
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_ant_tasks_sample_config_files.html
Step 5.
In the configureapplicationserver and unconfigureapplicationserver invocations (in target install and uninstall), define Worklight properties. For a list of properties that can be set, see Configuration of IBM Worklight applications on the server. In production, you must often define the following specific properties:
publicWorkLightHostname
publicWorkLightProtocol
publicWorkLightPort
In configureapplicationserver/unconfigureapplicationserver those properties do not exist, how do I define them and where and how do I use them in the ant file?
Or does this mean that before using this ant script I have to change the values of those properties in the worklight.properties file and (automatically) generate the WAR file? If this is the case I think it is not clear.
Thank you.
Define the three properties in install/uninstall target like this:
<property name="publicWorkLightHostname" value="myhost.com"/>
<property name="publicWorkLightProtocol" value="http"/>
<property name="publicWorkLightPort" value="9080"/>
Or you can set the three properties in worklight.properties file before running Ant. To set the properties, open the war file with tools like 7zip and modify the worklight.properties.
Related
I have gone through Mule Logging documentation but not clear on how to dynamically load different logging configuration files for each environments. Basically I want to control log verbosity and sync/async feature across environments so looking for similar feature of dynamically selecting property file based on server environment property variable.
2 ways you can load the log4j2 file dynamically in your application either from an external path or from your application classpath:-
setting the log4j2 file path in your application's mule-deploy.properties like :-
log.configFile=E:\common-log4j2.xml
Loading the log4j2.xml in your application programmatically by reconfiguring the log manager via Spring and load our own log4j2.xml file from your defined path:-
ref:- https://dzone.com/articles/getting-own-log4j2-file-for-mule-via-spring
I haven't tried it, but you should be able to set the log4j config file at the command line when launching Mule, using the log4j.configuration system property.
For example (in Windows) by adding -Dlog4j.configuration=c:\some-path\log4j-%MULE-ENV%.xml if your env variable is called MULE-ENV.
Note that there are several places this can be set - directly on the command line if using Mule standalone (in which case I believe you need -M-Dlog4j.configuration=...), in the wrapper.conf file if using standalone, or in the VM params section of the Arguments tab in Run Configurations when running in Studio.
You can have a bean in your application which can call the method to set the configuration. You can pass the environment name as an argument to this bean, it'll pick the configuration file associated with that environment. You can call the method using the invoke component and have this flow executed at the startup.
Till the flow is executed, default logging configuration can be used.
Today I have the same properties configurated on mule-app.properties file for each Apps. Like this:
All Apps (+ that 5) are running on the same Mule ESB runtime (CE).
For example, when It is necessary to change a host or password, I need to change the properties file of the all apps.
I would like to have just one properties file on Mule ESB runtime shared by all apps.
Is there a form to make this?
Thanks!
You can create a new Mule project and call it "shared". Now, in this project, you can create a file src/main/resources/config.properties and there put all the settings you need.
To have these settings in your current project, just add the project "shared" in the "Projects" tab of the "Java Build Path". Then in the main file of your current project, write
< context: property-placeholder location="config.properties" />
Use a Spring Property Placeholder and read a single file from the filesystem:
<context:property-placeholder location="file:/path/to/myConfigFile.properties" />
https://docs.mulesoft.com/mule-user-guide/v/3.6/configuring-properties#properties-files
I am building a bat file which automatically adds android environment to my worklight project and produce me with the apk file and worklight .war and .wlapp files to my destined location.
I have completed and everything works fine. i am using mfp bulid -d command to build the project and i have modifided the ant file in the MobileFirstServer Generator so that the above command give me .war file of the project.
Now my requirement is i want to build my project to a remote server so that my project.properties file in the android also gets updated with the serverip which i provide and i want to do this with the mobilefirst cli command since i am using a bat file and executing the commands.
I have seen this in the CLI build.xml file so this means if i have a build.properties file in my project anywhere i dont know exactly where it will take the ip,root,etc from that file.
XML
<!-- specify properties in this file or loaded from build.properties
<property name="worklight.server.install.dir" value=""/>
<property name="worklight.hostname" value="localhost"/>
<property name="worklight.port" value="10080"/>
<property name="worklight.username" value=""/>
<property name="worklight.password" value=""/>
<property name="worklight.app.dir" value=""/>
<property name="worklight.app.environments" value="common,iphone,android,blackberry10,windowsPhone8,windows8,ipad,mobileWebApp"/>
-->
In current releases of Worklight/MFP (6.x - 7.0), the CLI tool does not provide the ability to alter the IP address to a remote server prior to the build.
The workaround is to manually edit the wlclient.properties (Android, WP8) or worklight.plist (iOS) files in order for the application to connect to the remote server.
I have Done what i wanted via build.properties file.
Placed it in the Project folder of Worklight Project.
build.properties file has the following things in it
worklight.hostname=111.111.11.11
worklight.port=9090
Note: The above works only when internet connectivity is not present (i.e your ip-address should not be present for your system) This is an issue which i have noted. if your internet connectivity is there it will take your current ip address.
We are trying to use a org.JSON.JSONObject library for some intense json processing in the adapter side. We have Java classes which processes the data received from http adapters.
mobilefirst 6.3.0 and using cli 20150701 build
(the recent one).
This JSON referencing has no issues when building from eclipse mobilefirst studio environment.
We are building this environment in ubuntu linux 14.04. There is an error in referencing org.JSON.JSONObject..x.jar file when we execute
mfp start or mfp build or mfp deploy
Is there a way to reference this jar file during mfp start or mfp build or mfp deploy as a classpath.
We need to have something like
mfp -classpath "path/to/json.jar" build
please help.
As it turns out, the CLI does not yet recognize jars placed into the server/lib folder of your project. In oder to make this work, you can make a simple edit to the following file:
[cli install folder]/mobilefirst-cli/node_modules/generator-worklight-server/lib/build.xml
At or about line 123, add the third fileset element shown below:
<!-- Classpath for server runtime libraries used when building the WAR -->
<path id="server-classpath">
<fileset dir="${worklight.jars.dir}" includes="worklight-jee-library.jar" />
<fileset dir="${worklight.server.install.dir}/wlp/dev" includes="**/*.jar" />
<!-- add server/lib folder to classpath -->
<fileset dir="${worklight.app.dir}/../server/lib" includes="**/*.jar" />
</path>
After that, running 'mfp start' (or 'mfp restart' if your server is already running) will compile your custom Java code with any jars that you add to the server/lib folder included in the classpath.
JARs for use by your adapters should be added to you Project's server directory in the folder lib. They will be included in your Projects WAR file when the project is built (in Studio or by the ant tasks) and when you deploy that WAR it will be visible to your adapters.
I agree with #bjustin_ibm. Thanks for that. While the above approach works, there's also another way of doing this.
Alternative hack
Just add your required .jars to the following location, it gets added to the classpath during mfp start
/home/instanceubuntu/.ibm/mobilefirst/6.3.0/server/wlp/dev/spi/third-party
This solution is more simple and doesn't really have to maintain the build.xml file.
Hope this helps.
I want to use jrebel with intellij IDEA and JBOSS AS7.
(have a web application(so have WAR)).
By apache-ANT , build my-WAR and deploy it under JBOSS AS.
I know how introduce any changes of classes or resources to jrebel in the my-WAR (If I'm not mistaken!) , as follows:
(In rebel.xml)
<classpath>
<dir name="D:/project/myProject/out/production/myProject">
</dir>
</classpath>
<web>
<link target="/">
<dir name="D:/project/myProject/resources">
</dir>
<dir name="D:/project/myProject/view">
</dir>
</link>
</web>
But, really, "jerebel jar-file" Where is the my-WAR?
in => "warFile >WEB-INF > lib"?I did not see it.
please help me.
jrebel.jar is packaged inside the JRebel plugin for IntelliJ IDEA. It doesn't have to be deployed with the WAR itself. JRebel plugin will set the correct JVM parameters to the command line when you start via "Run with JRebel" or "Debug with JRebel":
-javaagent:/path/to/jrebel.jar
UPDATE: the newer versions of JRebel are configured using -agentpath JVM option instead:
-agentpath:${JREBEL_HOME}/lib/<platform-specific-binary>
See the documentation reference of the correct settings.
You don't have to do it yourself if you start the server from the IDE. If you start the server from the command line then you would have to add the JVM argument yourself with the correct path to jrebel.jar as described here: http://manuals.zeroturnaround.com/jrebel/standalone/launch-from-command-line.html#jboss-7-x
Java agents intercept class loading and thus have to be loaded before other classes. As you might have guessed, jrebel.jar is a Java agent and therefor nothing requires it to be packaged inside a WAR.
Instead, rebel.xml, the configuration file, has to be packaged in the WAR, in WEB-INF/classes directory. JRebel uses rebel.xml to detect, where the compiled classes and resources are. So when the application is deployed, JRebel finds rebel.xml configuration file and won't load the application classes from WAR itself, but instead it will use the path that is specified in that rebel.xml file. This is why rebel.xml has to be inside the war, as you may also start the server from command line instead of the IDE.