Can anyone please explain the significance of JNDI properties file in worklight app developement, Also is it mandatory to have one JNDI properties file for the mobile app developed using worklight to work.
thanks
djrecker
JNDI properties are not unique to Worklight. There is no requirement to use JNDI, rather it is simply a convenient method to lay out various properties that may be used in various environments (QA, UAT, PROD, ...) where you will find yourself deploying the Worklight Server.
As a Worklight Server has many properties that will be different per the environment (ports, hostnames, etc...), using JNDI properties you could better manage them in a single location (file). By not doing so, you may find yourself creating for example multiple .war files - a .war file per environment instead of 1 .war file for all environments, where the required properties for the environment are taken from a single file (the JNDI properties file).
You can read more about this, here: Configuring a Worklight project in production by using JNDI environment entries
Related
About Worklight 6.2 Analytics.
https://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_6.2.0/com.ibm.worklight.monitor.doc/monitor/t_setting_up_production_cluster.html
There are several JNDI properties to configure but It is not explained how to configure them in WAS ND and in which scope must be configured (if this has sense)
For example the worklight.properties are configured as application properties during the application installation.
How are configured the analytics JNDI properties on WAS?
And also in which scope should them be configured, this is also struggling me. For example it says that properties like "analytics/shards" or "analytics/replicas_per_shard" must be configured in the first node, but for me these properties should be properties configured at cluster level, not at node level.
Also WAS ND topology is something completely dynamic and flexible, what happens if I remove that "first" node?
Ok, now I understand that when in the Worklight Analytics documentation talk about cluster it is not talking about WAS Cluster but about Elasticsearch cluster.
Taking into account this, configuring a cluster for Analytics does not mean to install the analytics.war in a WAS cluster, it means that you will install analytics.war file in a number of WAS servers (not WAS clusters, not WAS nodes) and with the ElasticSearch properties you will configure the ElasticSearch cluster.
Is this correct?
The specific answer to my question is that the value of the properties are set during the detailed installation of the analytics.war file as it is done with the Application Project WAR file, worklightadmin.war or worklightconsole.war.
It is only needed to set those properties if you are configuring Analytics in more than one server.
I have my web application currently hosted on WebSphere Application Server 7.0.0.0.
Now i want to migrate my application to JBOSS EAP 6.2.0. GA.
Has anyone done it before? I need help on below issues.
I want to create following equivalent components in JBOSS.
1) Oracle data source
--> To create Oracle Data Source, we first definitely need to create Oracle JDBC Provider. So also need to know how to create equivalent to this in JBOSS.
2) Queue
3) Activation Specification
4) Shared library to contain configuration file and third party jars.
How to deploy applications on JBOSS knowldge would be an added advantage.
Yeah, have done some googling and found below links,
http://www.redhat.com/f/pdf/jboss/JBoss_WebSphereMigrationGuide.pdf
https://docs.jboss.org/author/display/AS72/How+do+I+migrate+my+application+from+WebSphere+to+AS+7
But the links doesnt have any practicle knowledge.
I have tried migrating from websphere to JBOSS\WildFly 10.
Not sure about the other versions of JBoss but wildfly 10 has a configuration xml which you can use to configure your server.
I configured the database, queues, queue factories, namespace bindings using this configuration xml which is available as part of the server installation itself.
The file is present in this location
YOUR_SERVER_INSTALLATION_HOME/opt/jboss/wildfly/standalone/configuration/standalone.xml
There are multiple configurations that are possible and you can customize them as per your need as well. You can refer the below documentation for customization.
https://docs.jboss.org/author/display/WFLY10/Subsystem+configuration
I want to know if there is any way a resource in weblogic can have multiple JNDI names?
My problem is that I have 2 versions of the app deployed on the same weblogic managed server (version A and B). Now, I want to repoint all the clients using version A (using jndi: java:comp/env/A) to version B (using jndi: java:comp/env/B) without the clients have to do anything. Clients use T3 connection to connect. Here the assumption is that the clients can point to version B without any code change (only point to the new apps jndi i.e. java:comp/env/B).
As of now all the clients update the JNDI names to the new version name and do a restart to repoint to my apps new version. I want to prevent this effort.
I think if I can make version A JNDI to also point to version B of app (so there are 2 jndi's java:comp/env/A and java:comp/env/B pointing to same EJB in version B), the clients will start pointing to version B.
So, if there is a way to add multiple JNDIs to a resource I should be good. If you have any other idea this can be acheieved, please let me know.
You would have to deploy the same EJB class with a different JNDI name - thus there will be 2 running deployments of the EJB with 2 different JNDI names.
I think this is a bad idea - I dont see why the JNDI name has to change from A to B in the first place?
Clients are using EJB A with JNDI A , you now have the different EJB version called B. Can't you just change the JNDI A to point to EJB B?
I want to create an application that is not aware of the environment it runs in.
The environment specific configuration I want to leave up to the configuration of glassfish.
So eg I have a persistence.xml which 'points' to a jta data source
<jta-data-source>jdbc/DB_PRODUCTSUPPLIER</jta-data-source>
In glassfish this datasource is configured to 'point' to a connection pool.
This connection pool is configured to connect to a database.
I would like to have a mechanism such that I can define these resources for a production and an accept environment without having to change the jndi name. Because this would mean that my application is environment aware.
Do I need to create two domains for this? Or do I need two completely separate glassfish installations?
One way to do this is to use clustering features (GF 2.1 default install is often developer mode, so you'll have to enable clustering, GF 3.1 clustering seems to be on by default).
As part of clustering, you can create stand alone instances that do not participate in a cluster. Each instance can have its own config. These instances share everything under the Resources section, and each instance can have separate values in the system properties, most importantly these are separate port numbers.
So a usage scenario would be that your accept/beta environment will run on it's own instance with different ports (defaults being 38080, 38181, etc., assuming you're doing an http app). When running this way, your new instance will be running in a separate JVM. With GF 2.1, you need to learn how to manage the node agent. With GF 3.1, you won't have to worry about that.
When you deploy an application, you must choose the destination, called a Target, so you can have an accept/beta version on one instance, and a production version on the other instance.
This is how I run beta deployments with our current GF 2.1 non-clustered setup and it works pretty well.
I have an EAR that I deploy as production, in context "/".
I'd like to deploy a test version of the application on the server, the same Glassfish instance.
Is it possible to deploy the application under a different context and port in the same instance?
If so, beside changing the context in application.xml, do I need to change anything else?
Usually you can deploy a test version of the application by altering the context root, and deploying it as a whole new application.
However, you must take the application's design into consideration. If the application utilizes a database, more often that not, you'll need a test database instance. All JNDI names (this includes datasources and EJBs, if any) that the test and production applications use, must not have any conflicts. It is an ill-advised move to run multiple instances of the same application, all of which reference the same JNDI names.
Finally, it is a standard accepted practice to separate your test and production environments, and even have separate machines for the same, in the case of mission critical apps and the like. This is done usually to prevent accidental overwriting of one environment (usually the production one) by another.