Benefits of omeda-3 - Flaxseed

 I have discussed at length in previous articles the benefits of omega-3 fish oils. I have not, however, given you much information about flaxseed, another popular and very beneficial omega-3 fatty acid. Let's explore why we need it, and compare it to the omega-3 fatty acids in fish oil.

"Wherever flaxseed becomes a regular food item among the people, there will be better health," said Mahatma Gandhi.

He was right. The true nature of flax as a health food has been known for centuries. In the eighth century, Charlemagne considered flax so essential for health that he actually passed laws requiring its use. Flax was one of the original medicines, used by Hippocrates himself.

Flaxseed oil can help protect against cardiovascular disease, cancer, arthritis and many other degenerative diseases. And though it's primarily a source of omega-3, the oil has the virtue of containing some other fatty acids as well, notably some omega-6's and some heart healthy omega-9's, providing a nice fatty acid balance.

There's been a long-standing controversy among health professionals over the relative virtues of flaxseed oil and fish oil. Fish oil contains two omega-3 fatty acids — EPA and DHA — which are absolutely critical to human health. Many people believe that those are the true superstars of the omega-3 community. And there lies the heart of the controversy.

Flaxseeds and flaxseed oil are one of the best sources on the planet for the important omega-3 fatty acid called alpha-linoleic acid. Alpha-linoleic acid is considered an essential fatty acid because the body can't make it — it has to be obtained from the diet. The body can then take that ALA and theoretically convert it to EPA and DHA. The problem is that it doesn't do a very efficient job of conversion.

Best estimates are that the body will convert between 8-20 percent of ALA to EPA, and only .5 to 9 percent into DHA. But this ceases to be a problem at all if you simply take a tablespoon of flaxseed oil every day. And it's a non-issue if you're taking both flaxseed and fish oil.

Here's why: one tablespoon of quality flax oil is 14 grams (14,000 mg) of which 55 percent (7,700 mg) is compromised of omegs-3's. If you convert 7 percent of that to EPA you get 539 mg EPA and if you convert even 5 percent to DHA you'd get 385 mg of DHA. So even if you were a vegetarian and using flaxseed oil as your only source of omega-3's you'd be OK, though I'd recommend a couple of tablespoons a day instead of one.

And conversion to EPA and DHA isn't the only reason to take flaxseeds or flaxseed oils. A recent article in Nutrition Reviews (June 2008) pointed out that ALA may have "independent, therapeutic properties similar to those of other omega-3 fatty acids" and "may also be of particular importance for neural development."

But the benefits of flax are not limited to the omega-3 content. Both the oil and the seeds (especially the seeds) are a great source of something called lignans which have a whole host of health benefits of their own, for both men and women.

Lignans have a protective effect against cancer, especially those that are hormone-sensitive like breast, uterine and prostate cancer.

Yes, if you put a gun to my head and told me I could only take fish oil or flaxseed oil, I'd probably choose fish oil. But truth be told I take them both, every single day. And if you won't or can't eat fish or take fish oil, then simply up your intake of flaxseed oil.

A recent study of male firefighters found that only 2.4 to 3.6 grams of flaxseed oil alone raised the firefighters EPA levels. That's about 1/4 to 1/3 of a tablespoon. If you upped that dose a bit to just the one or two tablespoons a day I recommend, I'm willing to bet both EPA and DHA levels would rise.

It is my sincere hope that each of you take some step, however small, to improve your health and lifestyle over this next year.

God bless and have a perfect New Year.

Creating a JAR File

The basic format of the command for creating a JAR file is:

jar cf jar-file input-file(s)

The options and arguments used in this command are:

• The c option indicates that you want to create a JAR file.
• The f option indicates that you want the output to go to a file rather than to stdout.
• jar-file is the name that you want the resulting JAR file to have. You can use any filename for a JAR file. By convention, JAR filenames are given a .jar extension, though this is not required.
• The input-file(s) argument is a space-separated list of one or more files that you want to include in your JAR file. The input-file(s) argument can contain the wildcard * symbol. If any of the "input-files" are directories, the contents of those directories are added to the JAR archive recursively.

The c and f options can appear in either order, but there must not be any space between them.
This command will generate a compressed JAR file and place it in the current directory. The command will also generate a default manifest file for the JAR archive.

---

Note: The metadata in the JAR file, such as the entry names, comments, and contents of the manifest, must be encoded in UTF8.

---

You can add any of these additional options to the cf options of the basic command:

jar command options

Option	Description
v	Produces verbose output on stdout while the JAR file is being built. The verbose output tells you the name of each file as it's added to the JAR file.
0(zero)	Indicates that you don't want the JAR file to be compressed.
M	Indicates that the default manifest file should not be produced.
m	Used to include manifest information from an existing manifest file. The format for using this option is: jar cmf existing-manifest jar-file input-file(s) See Modifying a Manifest File for more information about this option. Warning: The manifest must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.
-C	To change directories during execution of the command. See below for an example.

---

Note: When you create a JAR file, the time of creation is stored in the JAR file. Therefore, even if the contents of the JAR file do not change, when you create a JAR file multiple times, the resulting files are not exactly identical. You should be aware of this when you are using JAR files in a build environment. It is recommended that you use versioning information in the manifest file, rather than creation time, to control versions of a JAR file. See the Setting Package Version Information section.

---

An Example

Let us look at an example. A simple TicTacToe applet. You can see the source code of this applet by downloading the JDK Demos and Samples bundle from Java SE Downloads. This demo contains class files, audio files, and images having this structure:

TicTacToe folder HierarchyThe audio and images subdirectories contain sound files and GIF images used by the applet.
You can obtain all these files from jar/examples directory when you download the entire Tutorial online. To package this demo into a single JAR file named TicTacToe.jar, you would run this command from inside the TicTacToe directory:

jar cvf TicTacToe.jar TicTacToe.class audio images

The audio and images arguments represent directories, so the Jar tool will recursively place them and their contents in the JAR file. The generated JAR file TicTacToe.jarwill be placed in the current directory. Because the command used the v option for verbose output, you would see something similar to this output when you run the command:

adding: TicTacToe.class (in=3825) (out=2222) (deflated 41%)
adding: audio/ (in=0) (out=0) (stored 0%)
adding: audio/beep.au (in=4032) (out=3572) (deflated 11%)
adding: audio/ding.au (in=2566) (out=2055) (deflated 19%)
adding: audio/return.au (in=6558) (out=4401) (deflated 32%)
adding: audio/yahoo1.au (in=7834) (out=6985) (deflated 10%)
adding: audio/yahoo2.au (in=7463) (out=4607) (deflated 38%)
adding: images/ (in=0) (out=0) (stored 0%)
adding: images/cross.gif (in=157) (out=160) (deflated -1%)
adding: images/not.gif (in=158) (out=161) (deflated -1%)

You can see from this output that the JAR file TicTacToe.jar is compressed. The Jar tool compresses files by default. You can turn off the compression feature by using the 0(zero) option, so that the command would look like:

jar cvf0 TicTacToe.jar TicTacToe.class audio images

You might want to avoid compression, for example, to increase the speed with which a JAR file could be loaded by a browser. Uncompressed JAR files can generally be loaded more quickly than compressed files because the need to decompress the files during loading is eliminated. However, there is a tradeoff in that download time over a network may be longer for larger, uncompressed files.
The Jar tool will accept arguments that use the wildcard * symbol. As long as there weren't any unwanted files in the TicTacToe directory, you could have used this alternative command to construct the JAR file:

jar cvf TicTacToe.jar *

Though the verbose output doesn't indicate it, the Jar tool automatically adds a manifest file to the JAR archive with path name META-INF/MANIFEST.MF. See the Working with Manifest Files: The Basics section for information about manifest files.
In the above example, the files in the archive retained their relative path names and directory structure. The Jar tool provides the -C option that you can use to create a JAR file in which the relative paths of the archived files are not preserved. It's modeled after TAR's -C option.
As an example, suppose you wanted to put audio files and gif images used by the TicTacToe demo into a JAR file, and that you wanted all the files to be on the top level, with no directory hierarchy. You could accomplish that by issuing this command from the parent directory of the images and audio directories:

jar cf ImageAudio.jar -C images . -C audio .

The -C images part of this command directs the Jar tool to go to the images directory, and the . following -C images directs the Jar tool to archive all the contents of that directory. The -C audio . part of the command then does the same with the audio directory. The resulting JAR file would have this table of contents:

META-INF/MANIFEST.MF
cross.gif
not.gif
beep.au
ding.au
return.au
yahoo1.au
yahoo2.au

By contrast, suppose that you used a command that did not employ the -C option:

jar cf ImageAudio.jar images audio

The resulting JAR file would have this table of contents:

META-INF/MANIFEST.MF
images/cross.gif
images/not.gif
audio/beep.au
audio/ding.au
audio/return.au
audio/yahoo1.au
audio/yahoo2.au

Maven Repositories

Search Public Maven Artifacts:
http://search.maven.org/
http://download.java.net/maven/2
http://download.java.net/maven/1
http://repo.maven.apache.org/maven2

---

Spring Framework:
Releases:
<repository>  
  <id>com.springsource.repository.bundles.release</id>  
  <name>SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases</name>  
  <url>http://repository.springsource.com/maven/bundles/release</url> 
</repository>
...
<dependency>  
  <groupId>org.springframework</groupId>  
  <artifactId>org.springframework.core</artifactId>  
  <version>3.0.2.RELEASE</version> 
</dependency>
Milestone:
<repositories>
 <repository>
  <id>springsource maven repo</id>
  <url>http://maven.springframework.org/milestone</url>
 </repository>
</repositories>
...
<dependencies>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>3.0.0.RC1</version>
  </dependency>
</dependencies>

---

Hibernate Framework:
<repositories>
    <repository>
        <id>jboss-public-repository-group</id>
        <name>JBoss Public Maven Repository Group</name>
        <url>https://repository.jboss.org/nexus/content/groups/public/</url>
        <layout>default</layout>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </releases>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </snapshots>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>jboss-public-repository-group</id>
        <name>JBoss Public Maven Repository Group</name>
        <url>https://repository.jboss.org/nexus/content/groups/public/</url>
        <layout>default</layout>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </releases>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </snapshots>
    </pluginRepository>
</pluginRepositories>

Here is the dependency you need:
    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-core</artifactId>
        <version>3.5.4-Final</version>
    </dependency>
Following dependencies is required for slf4j error if you are using hibernate:
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-log4j12</artifactId>
 <version>1.5.6</version>
</dependency>

Avoiding the "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed" error

Please note: this post focuses on the standard Java https implementation.

The SSLHandshakeException is thrown by java when the host you are trying to contact doesn't have a valid SSL certificate for that hostname. Most of the time this is very useful, since it means something on that host is wrong (the certificate has expired, the machine you're contacting is not who it is pretending to be etc...). However, in development mode you often don't want to pay for a "real" certificate, signed by a CA (certificate authority) like Verisign. You will then use a self-signed certificate, which gets rejected by java. It's for these cases that we're going to build a workaround. Please note that you should probably not use this code in a production environment. If you do, there's no reason to use https, since you're bypassing its functionality and you might just as well stick to http.

The first thing we need to do is create a custom TrustManager for SSL. SSL uses a protocol called X.509.  We will build a TrustManager that trusts all servers:

X509TrustManager tm = new X509TrustManager() { 
  @Override
  public X509Certificate[] getAcceptedIssuers() { 
    return null; 
  }   
  @Override
  public void checkServerTrusted(X509Certificate[] paramArrayOfX509Certificate, String paramString) throws CertificateException {   }   
  @Override
  public void checkClientTrusted(X509Certificate[] paramArrayOfX509Certificate, String paramString) throws CertificateException { } 
};

As you can see, the checkXXXTrusted() methods throw Exceptions when something is wrong. We never throw an exception, effectively trusting all hosts.

The next thing we'll need to do is use this TrustManager on an SSLContext. An SSLContext is a factory class that is used to create socket factories, which in their turn create the actual ssl sockets used to communicate with the server. Here's how we do this:

SSLContext ctx = SSLContext.getInstance("TLS"); 
ctx.init(null, new TrustManager[] { tm }, null); 
SSLContext.setDefault(ctx);

There now remains one more thing to be done: set a custom HostnameVerifier. A HostnameVerifier is a class that makes sure the host you are contacting doesn't use a spoofed URL. We will again build a HostnameVerifier that trusts all hosts:

HttpsURLConnection conn = (HttpsURLConnection) new URL("https://serverAddress").openConnection(); 
conn.setHostnameVerifier(new HostnameVerifier() {   
 @Override
 public boolean verify(String paramString, SSLSession paramSSLSession) { 
  return true; 
 } 
});

Again, this HostnameVerifier will trust all hosts.
Putting all our code together, the final class will look like this:

public static void main(String[] args) throws NoSuchAlgorithmException, KeyManagementException, MalformedURLException, IOException { 
 X509TrustManager tm = new X509TrustManager() { 
  @Override
  public X509Certificate[] getAcceptedIssuers() { 
   return null; 
  }   
  @Override
  public void checkServerTrusted(X509Certificate[] paramArrayOfX509Certificate, String paramString) throws CertificateException {   }   
  @Override
  public void checkClientTrusted(X509Certificate[] paramArrayOfX509Certificate, String paramString) throws CertificateException { } 
 }; 
 SSLContext ctx = SSLContext.getInstance("TLS"); 
 ctx.init(null, new TrustManager[] { tm }, null); 
 SSLContext.setDefault(ctx);   
 HttpsURLConnection conn = (HttpsURLConnection) new URL("https://serverAddress").openConnection(); 
 conn.setHostnameVerifier(new HostnameVerifier() {   
  @Override
  public boolean verify(String paramString, SSLSession paramSSLSession) { 
   return true; 
  } 
 }); 
 conn.connect();   
}

One final note: I prefer the way the Apache HttpClient library handles this. In the HttpClient library you can make a clean separation between the ssl verification logic and the code that does the actual work. This allows you to easily remove the code in the production environment or to use a switch between the development and production environment. This is much harder in the plain java version, since the code is more entangled. See this post for how to do this with the Apache HttpClient.
 

Avoiding the "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated" with HttpClient

Please note: This article focuses on the Apache HttpClient library.

When developing a https application, your test server often doesn't have a (valid) SSL certificate. This will cause the following exception to be thrown when connecting your client to the test server: "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated".
I will be discussing a way to fix this issue with the apache HttpClient, version 4.0.1

Bits and pieces
--------------------
You usually create your HttpClient like this:
client = new DefaultHttpClient();

We will need to tell the client to use a different TrustManager. A TrustManager is a class that checks if given credentials (or certificates) are valid. The scheme used by SSL is called X.509, and Java has a specific TrustManager for this scheme, called X509 TrustManager. First thing we will need to do is create such a TrustManager:
X509TrustManager tm = new X509TrustManager() {  
 public void checkClientTrusted(X509Certificate[] xcs, String string) throws CertificateException { }  
 public void checkServerTrusted(X509Certificate[] xcs, String string) throws CertificateException { }  
 public X509Certificate[] getAcceptedIssuers() {
 return null;
 }
};

As you can see, this code doesn't do much: if a certificate is invalid the TrustManager is supposed to throw a CertificateException in the checkXXX methods. Since we always want to accept all certificates, we never throw an exception.

Next we need to find a way to set this TrustManager in our HttpClient. The TrustManager is used by the SSL sockets. Sockets are created using a SocketFactory. For SSL sockets this is an SSLSocketFactory.

When creating a new SSLSocketFactory, you need to pass an SSLContext to the constructor. It is this SSLContext that will contain our newly created TrustManager.

First thing we need to do is get an SSLContext:SSLContext ctx = SSLContext.getInstance("TLS");

TLS is the successor to SSL, but they use the same SSLContext.
Then we initialize this context with our new TrustManager that we created above:ctx.init(null, new TrustManager[]{tm}, null);

We can then finally create our SSLSocketFactory:SSLSocketFactory ssf = new SSLSocketFactory(ctx);

Now we still need to register this SSLSocketFactory with our HttpClient. This is done in the SchemeRegistry of the ConnectionManager of the HttpClient:ClientConnectionManager ccm = base.getConnectionManager();
SchemeRegistry sr = ccm.getSchemeRegistry();
sr.register(new Scheme("https", ssf, 443));

We register a new Scheme, with the protocol https, our newly created SSLSocketFactory which contains our TrustManager and we tell the HttpClient that the default port for https is port 443.

Putting it all together:
===================
The following class takes a HttpClient and returns a new HttpClient that accepts any SSL certificate:
/* This code is public domain: you are free to use, link and/or modify it in any way you want, for all purposes including commercial applications.  */
public class WebClientDevWrapper { 
 public static HttpClient wrapClient(HttpClient base) {
 try { 
  SSLContext ctx = SSLContext.getInstance("TLS");
  X509TrustManager tm = new X509TrustManager() {  
   public void checkClientTrusted(X509Certificate[] xcs, String string) throws CertificateException { }  
   public void checkServerTrusted(X509Certificate[] xcs, String string) throws CertificateException { }  
   public X509Certificate[] getAcceptedIssuers() {
    return null;
   }
  }; 

  ctx.init(null, new TrustManager[]{tm}, null);
  SSLSocketFactory ssf = new SSLSocketFactory(ctx);
  ssf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
  ClientConnectionManager ccm = base.getConnectionManager();
  SchemeRegistry sr = ccm.getSchemeRegistry();
  sr.register(new Scheme("https", ssf, 443));
  return new DefaultHttpClient(ccm, base.getParams());
 } catch (Exception ex) {
  ex.printStackTrace();
  return null;
 }
      }
}

You can then do something like this in the code that creates the HttpClient:
this.client = new DefaultHttpClient();
if(dev) {
 this.client = WebClientDevWrapper.wrapClient(client);
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Update:
In some exceptional cases, the method described above doesn't work. This is due to the Apache AllowAllHostnameVerifier still being to strict. In this case, you will need your own X509HostnameVerifier. Create it as follows:
X509HostnameVerifier verifier = new X509HostnameVerifier() {                  
 @Override               
 public void verify(String string, SSLSocket ssls) throws IOException {}                  
 @Override               
 public void verify(String string, X509Certificate xc) throws SSLException {}
 @Override               
 public void verify(String string, String[] strings, String[] strings1) throws SSLException {}
 @Override               
 public boolean verify(String string, SSLSession ssls) {
  return true;                
 }            
};

Then set it on your socket factory:
ssf.setHostnameVerifier(verifier);

If we put everything together, the new code looks like this:
/* This code is public domain: you are free to use, link and/or modify it in any way you want, for all purposes including commercial applications.  */

public class WebClientDevWrapper {      
 public static HttpClient wrapClient(HttpClient base) {        
  try {             
   SSLContext ctx = SSLContext.getInstance("TLS");
   X509TrustManager tm = new X509TrustManager() {                  
    public void checkClientTrusted(X509Certificate[] xcs, String string) throws CertificateException {}
    public void checkServerTrusted(X509Certificate[] xcs, String string) throws CertificateException {}
    public X509Certificate[] getAcceptedIssuers() {                    
     return null;                
    }            
   };
            
   X509HostnameVerifier verifier = new X509HostnameVerifier() {                   
   @Override               
   public void verify(String string, SSLSocket ssls) throws IOException {}
   @Override               
   public void verify(String string, X509Certificate xc) throws SSLException {}
   @Override               
   public void verify(String string, String[] strings, String[] strings1) throws SSLException {}
   @Override               
   public boolean verify(String string, SSLSession ssls) {
    return true; 
   }            
  };             
  ctx.init(null, new TrustManager[]{tm}, null);            
  SSLSocketFactory ssf = new SSLSocketFactory(ctx);            
  ssf.setHostnameVerifier(verifier);            
  ClientConnectionManager ccm = base.getConnectionManager();    
  SchemeRegistry sr = ccm.getSchemeRegistry();            
  sr.register(new Scheme("https", ssf, 443));            
  return new DefaultHttpClient(ccm, base.getParams());         
 } catch (Exception ex) {            
  ex.printStackTrace();            
  return null;        
 }    
    }
}
You can then do something like this in the code that creates the HttpClient:
this.client = new DefaultHttpClient();
if(dev) {
 this.client = WebClientDevWrapper.wrapClient(client);
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Working Example implemented in one of my project:

package com.company.test;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.conn.scheme.Scheme;
import org.apache.http.conn.scheme.SchemeRegistry;
import org.apache.http.entity.StringEntity;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.conn.ssl.SSLSocketFactory;
import org.apache.http.conn.ssl.TrustStrategy;
import java.security.KeyManagementException;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.UnrecoverableKeyException;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

public class HttpsTestClient {
 public static void main(String[] args) throws KeyManagementException, UnrecoverableKeyException, NoSuchAlgorithmException, KeyStoreException {
  SchemeRegistry registry = new SchemeRegistry();
  SSLSocketFactory socketFactory = new SSLSocketFactory(new TrustStrategy() {
   public boolean isTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
    return true;
   }
  }, org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
 
  registry.register(new Scheme("https", 443, socketFactory));
  ThreadSafeClientConnManager mgr = new ThreadSafeClientConnManager(registry);
 
  DefaultHttpClient client = new DefaultHttpClient(mgr, new DefaultHttpClient().getParams());
       
     HttpPost post = new HttpPost("https://host:7032/Xyz/service");
     try {
      String send = "< ?xml version=\"1.0\" encoding=\"UTF-8\"?> <msg> <head><Client>ComXCalFL</Client> <Region>QAYA</Region> <Source>E26XCALIBUR</Source><Destination>CCS01</Destination> <Origin>L0OG1-X-CAL ORDER DETAIL UPDATED</Origin> <Version>2.25</Version> <RoundTrip>MDU6MDAwMDAwMDM6MjAxMjA4MzE6MTE0OTE0MDA6ODIxMDAwMDA6TDBPRzowMg==</RoundTrip> <UserId>LRM 0B72</UserId> <ServerId>sbappre02-z04</ServerId> <TriggerDate>2012-08-31</TriggerDate><TriggerTime>11:49:14</TriggerTime> </head><body><OrderDetailUpdated> XML_PAYLOAD</OrderDetailUpdated></body></msg>";
     
      StringEntity strEnt = new StringEntity(send);
      post.setEntity(strEnt);
       HttpResponse response = client.execute( post);
       BufferedReader rd = new BufferedReader(new InputStreamReader(response.getEntity().getContent()));
       String line = "";
       while ((line = rd.readLine()) != null) {
         System.out.println(line);
       }
     } catch (IOException e) {
       e.printStackTrace();
     }
   }
}

Some Important Links

• Subversion:
• Web Site: http://subclipse.tigris.org/
• Eclipse Update: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
• Maven:
• M2E: http://m2eclipse.sonatype.org/sites/
• VideoLan:
• http://www.videolan.org/vlc/features.html
• 7 Zip:
• http://www.7-zip.org/download.html

Apache JMeter

Apache J Meter

# - Remember to set JAVA_HOME to JDK 5+
Example:
Server 1:
JAVA_HOME=/app/weblogic/jdk1.6.0_33/bin

WEBLOGIC_HOME=/app/home/mradmin/Oracle/Middleware
APACHE_HOME=/app/cemp/apache-jmeter-2.7
PATH=/app/weblogic/jdk1.6.0_33/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/app/home/mradmin/bin:/app/cemp/apache-jmeter-2.7/bin/ApacheJMeter.jar:
export PATH
Server 2: [Same on Server 2]

# - [cemp@cempda01 bin]$ jmeter -n -r -t Usage\ Cache\ Users.jmx -LDEBUG -l results.jtl
Example #:

[cemp@cempda01 bin]$ jmeter -n -r -t UsageCacheUsers.jmx -LDEBUG -l results.jtl
Created the tree successfully using UsageCacheUsers.jmx

Configuring remote engine for cmpcol-dt-4d.ula.com.net
Using remote object: UnicastRef [liveRef: [endpoint:[10.255.156.129:49889](remote),objID:[71770134:138a12bc3d9:-7fff, 5263036063349195177]]]
Configuring remote engine for cempda01.cab.com.com
Using remote object: UnicastRef [liveRef: [endpoint:[147.191.113.124:34820](remote),objID:[584b8767:138a1409048:-7fff, -1613329581385448862]]]
Starting remote engines
Starting the test @ Fri Jul 20 05:29:06 UTC 2012 (1342762146778)
Remote engines have been started
Waiting for possible shutdown message on port 4445
Generate Summary Results + 916 in 31.3s = 29.3/s Avg: 34 Min: 21 Max: 176 Err: 0 (0.00%)
Generate Summary Results + 2631 in 89.0s = 29.6/s Avg: 35 Min: 20 Max: 134 Err: 0 (0.00%)
Generate Summary Results = 3547 in 120.3s = 29.5/s Avg: 35 Min: 20 Max: 176 Err: 0 (0.00%)
Tidying up remote @ Fri Jul 20 05:31:29 UTC 2012 (1342762289011)
... end of run
[cemp@cempda01 bin]$
# - Important Commands:
1. [cemp@cempda01 bin]$ netstat -tulpn // Check port - process id.
2. Microsoft Windows:  start rmiregistry 30031 // remember to JAVA_HOME before.
3. Solaris OS or Linux:  rmiregistry 30031 & // remember to set JAVA_HOME before.
By default, the registry runs on port 1099. To start the registry on a different port, specify the port number on the command line. Do not forget to unset your CLASSPATH environment variable.
To check that the RMI registry has started correctly, you can check that it is listening on its standard port (1099 unless you've specified otherwise) with a tool such as TCP View.