Multiple JNDIs pointing to same resource on weblogic 10? - weblogic

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?

Related

JNDI properties file in Worklight

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

How do i migrate my application from WebSphere to JBOSS EAP 6.2.0.GA?

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

Deploy Java EE application without starting

I am using Apache Geronimo. I need a way to deploy an EAR application on an application server without starting the EAR module automatically.
When I deploy my EAR, it is automatically started. I need a way to specify, that it should only be deployed but not started.
Is there a way to do this?
In the past I've opened and closed gates to certain EJBs with the use of JMX.
The cool part:
100% Control your beans from outside using JConsole or your own JMX client.
The drawback:
Every bean instance has to be registered in the MBean Server which is not that cool as you are usually having multiple instances of the same bean.
The solution to this topic was having a #Singleton EJB working as a MBean/controller for all the instances of one EJB.

how to handle configuration for accept and production environment in glassfish

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.

Start/stop a deployment in Weblogic 9 using JMX (or WLST)

I want to start/stop a deployment in weblogic 9 server.
I prefer to use JMX to talk to a weblogic MBean. I already use this to start/stop a server, but I cannot find the MBean for starting/stopping deployments/applications.
In weblogic server 11g there is a AppDeploymentRuntimeMBean which can stop/start deployments. That is described here:
http://download.oracle.com/docs/cd/E14571_01/apirefs.1111/e13951/mbeans/AppDeploymentRuntimeMBean.html
But I cannot find a simular MBean in weblogic 9
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/wlsmbeanref/core/index.html
Is there a way to start/stop a weblogic 9 deployment using jmx or wlst?
BTW, when I record a WLST-script during start/stop of a deployment the pyton-script is empty.
Well actually AppDeploymentRuntimeMBean was first introduced in WLS 10.3 version. And this bean along with DeploymentManagerMBean were created to replace DeployerRuntimeMBean (it is considered deprecated since 9.0.0.0 version). As for me it seems that there is no way to start\stop applications with JMX on WLS 9 unless you decide to use deprecated API. And also consider the fact that you need Administration Server running in order to access Domain Runtime MBean Server that will provide an entry point to DeployerRuntimeMBean.