Deepak Pant

Do you have any metrics or suggestions on successfully delivering Agile projects in teams that are not co-located ? Self-motivating teams but spread across different geographies operating in different timezones.

ok thanks

I am also using Weblogic 10.3.6, which comes bundled with Jersey bundle jersey-bundle-1.9.war. I am also thinking using Jersey 2.13.

How is your overall experience? Is your upgrade working fine? Any issues that I should be aware of? Thanks for responding.

I think you should open open the WAR file and add it to the WEB-INF/lib folder, change web.xml and then add it again to the EAR file. Then reinstall the EAR file. Clean temp folders. Start App server.

stop your app server. delete the contents of wstemp and temp folders present under the profile folder. start the server.

1. You need WebSphere Network Deployment version. (WAS ND)
2. Create a Deployment Manager (Dmgr) profile.
3. Create two custom profiles on typically two different physical machines (also known as Nodes) and federate them to the Dmgr profile.
4. Log into the Dmgr WAS console and create a cluster.
5. Create cluster members in such a way that at least one application server runs on each of the nodes.
6. At the end of all the steps, following JVM processes will run across different machines.
Dmgr
NodeAgent01
NodeAgent02
AppServer01 (running in Node01 and part of NodeAgent01)
AppServer02 (running in Node02 and part of NodeAgent02)
7. You can start Dmgr, NodeAgent01, and NodeAgent02 in any order.
8. AppServer01 should always be started after NodeAgent01. Same applies for NodeAgent02/AppServer02
9. Once you have done this manually then you can create Jython script to automate some of the above steps.

I think it is a bad idea to stream 800MB of file using App/Web Server. You could instead generate the file and make it available via FTP server for printing etc.

You can change the ports either using WAS ISC console OR via Jython script. Either case works. If this is a one time exercise then you should change it via Console. But never attempt to change the XML files present under the config folder.

In cases Administrators do not allow editing via Console, you can create a Jython script to change it.

Application bounce: This is achieved by Stopping & Starting Application either from Console or via Jython scripts.

jvm bounce: This is achieved by Stopping & Starting Application Server either from Console (in ND versions) or via Jython scripts or Shell scripts.

In well ordered world, both the above bounces should handle Application startup/shutdown activities. But there is a good chance that some of your applications singleton classes or static objects are not cleaned up in Application bounce. As long as you handle those for application bounces you can use either of the above.

You are trying to hack into the deployment structure of WebSphere by copying the classes from behind the scenes.

If you want to continue this path then should stop the server and delete the contents of wstemp and temp folder under your profile folder. It will then pick your changes.

Yes "kill -3 <pid>" is a way to get the thread dump under UNIX systems. You should repeat the "kill -3" command after every 30 to 45 secs to get better understanding of the dump

Yes it is called one way SSL. Is your client a Java client ?

Typically the process is as follows:
1. Create a new self-signed certificate. In production replace this step with certificate request and CA issued certificate.
2. Export the Certificate from the WAS Console.
3. Create a new truststore (say clientTrustStore.jks). The store will have a password etc.
4. Import the certificate extracted in Step #2 into clientTrustStore.jks.
5. Now when you establish the HTTPS connection from client application you will set the name of the trust store, password etc.

Step 1 and 2 can be done using WAS console. Step 3 & 4 using command line keystore utility. Step 5 is in your java client code.

Hope this helps

If WAS is not picking up context root from WAR properly then you can always change it in the WAS console. See if that is working for you or not.

what version of websphere? version prior to 7.0 require .xmi instead of .xml

Generally migrating third party framework migrations are smooth. The challenge comes when the same framework is bundled with WebSphere as well. For example: Apache Axis2 comes bundled with WebSphere, Xerces, Xalan, Commons logging etc are all bundled.

The class loader issues come up and then you have to play with class loading setting at either library level (in Axis2) or WAR or EAR level.