Hi!

Need your help.

We have 3 different Webspehere application server in the same node.

Basically, I want to install same application to each of them.

On installation, the 2 Application XX names are changed to "XX_dest2" and "XX_dest3" and the first remain as XX to avoid error "Application already exists in the configuration".

But on run time, the 2 other applications use properties files of "INSTALL_DIR/XX.ear/...." and not files in folder "INSTALL_DIR/XX_dest1.ear" or "INSTALL_DIR/XX_dest2.ear".

We don't wan't to change how the applications are coded.

Is there work around on installing without changing the 3 Application Names but installation directory is different?

or is it possible to install with different Application names but when installed in the server the destination for Application "XX_dest1" will be INSTALL_DIR/dest1/XX.ear?

Basically retaining the XX.ear and not created XX_dest1.ear on install

Thanks in advance.

Hi Camaya,

I didn't get your idea by installing same application on three different app servers on same node! do you want to make load balancing or what?

//Ahmed

Camaya - 

Are you using WebSphere Application Server Network Deployment, or another version of WAS?  If you are using ND, simply create a cluster and this may help you get around your issue.  

If you provide details about WAS version, release, OS, topology, etc. you'll likely get more responses.

Erik

Thank you for the reply.

We have 1 instance of WAS
IBM WebSphere Application Server - ND, 7.0.0.0

We developed an application(APP.ear) to interface data from source to a destination.

for each of the destination, we created 1 Application server for each
Server > Server Types > WebSphere Application Servers
     1) SOA_DEV
     2) SOA_1QA

We install APP.ear 2 times

Applications > New Applications > New Enterprise Application
    Step 1 : Select installation options 

       1) installed as APP for DEV
       2) installed as APP_1QA for 1QA

              to avoid error "Application Already Exist In the Repository"

     Step 2 : Map Modules to SOA_DEV or SOA_1QA servers

When the installation is completed the APP are installed in

     1) INSTALL_DIR/APP.ear
     2) INSTALL_DIR/APP_1QA.ear

On runtime, the APP access file 
    INSTALL_DIR/APP.ear/APP.war/WEB-INF/classes/APP.properties

The problem is when APP for 1QA is run. It is not coded to access
   INSTALL_DIR/APP_1QA.ear/APP.war/WEB-INF/classes/APP.properties

1QA is wrongly using
   INSTALL_DIR/APP.ear/App.war/WEB-INF/classes/APP.properties


We know this can easily be fixed by updating the code and including a new parameter.

we want not to revise the current code.


Is there any work around:
Like, we have 2 different INSTALL_DIR
        1) INSTALL_DIR/DEV
        2) INSTALL_DIR/1QA

We still have to rename the APP on installation "STEP 1", but can they install the files without appending "DEV" or "1QA"

        1) INSTALL_DIR/DEV/APP.ear/....
        2) INSTALL_DIR/1QA/APP.ear/...

And not

        1) INSTALL_DIR/DEV/APP_DEV.ear/....
        2) INSTALL_DIR/1QA/APP_1QA.ear/...


Thanks again in advance!

The obvious solution is to fix the code and NOT hard code the application name.  But understanding that this isn’t an option for you, consider the following:

I have not tested this, but have you tried mapping the installed application  to both clusters?  If you scoped your variables and resources at the cluster layer, you should be okay.

The only foreseeable issue may be the mapping of the web modules to the virtual hosts, if you use a unique vhost for each app.  If this is the case, 

1.  switch to a shared vhost definition,
2.  update it accordingly for the servers,
3.  generate the plugins,
4.  modify them by hand to route accordingly,
5.  and propagate.

Again , I've NOT tested the above as I've not had this scenario, but it may work.  You can test the application by direct access to the  JVM using the :/

Let us know if that works, and if you can have the development team fix their code, I highly recommend it.  You shouldn't need to compensate for poor development practices. 

Thank you very much for the suggestion Erik!  The Vhost are setup individually for each environment.

I will try to suggest this to our admins and will let you know if it works.

Best Regards,
Abdon

Abdon,

I still feel that the core issue is a short coming of the application architecture and would recommend that it be corrected, but was curious if your administrative staff had any success with the above recommendation to address your immediate need.

you cannot have application deployed with same name within same cell

is your issue resolved...

If you give it a different application name, it will install it under the Application Name subdirectory. Application name can be changed at install time.
I have done it many times and it works. But, you will run into a context_root problem, unless you use a virtual host approach.

I agree with Erik’s comment about not hard coding the application name and I would go even further and say to never hard coding any external connections or other items that you can setup in WebSphere configuration.

At some point down the road you will have to migrate to a new system and this may be several years down the road and the knowledge of the app development may be gone and you may need to make changes to the application.

Also at some point you may need to move an external resource like a database or mail server or MQ server to a new host and once again you will have to have the application modified.

If you have these type of things configured in WebSphere configuration you will be able to change them much quicker then changing the app and redeploying it.

12 years ago I took over a WebSphere system that had apps that everything was hardcoded and this created many pain full hours for the development team and us admins. During these painful events our developers started changing their apps to use WebSphere properties and are now have more time for other projects.

The other thing that was happening was as the developer moved their code from dev to test to prod they had to make changes to these hardcode items and we are all human and prone to making mistakes which caused constant problems.

We now have a system where the developers can move the same exact ear, war, or jar from dev to test to prod without having to make any changes to their code.

 

We usually deploy the same app on 4 diff JVM in our environment but we seperate the property files outside ther ear. We generally add the property file as an JVM environmental variable or to the classpath. 

  For ex:

 Move app.properties outside ear file  and add a variable like APP_Properties_$ENV  for each JVM 


APP_Properties_DEV = /opt/websphere/apps/SOA_DEV/app.properties
APP_Properties_1QA = /opt/websphere/apps/SOA_1QA/app.properties


We usually seperate the property files , so you can define your own variables for each application like logging if that is defined under your app.properties. If all applications use the same property, how will you distinguish which application has thrown an error?