Labels

.net (1) *nix (1) administration (1) Android (2) Axis2 (2) best practice (5) big-data (1) business-analysis (1) code re-use (1) continuous-integration (1) Cordova-PhoneGap (1) database (2) defect (1) design (3) Eclipse (7) education (1) groovy (2) https (2) Hudson (4) Java (1) JAX-RS (2) Jersey (3) Jetty (1) localization (1) m2eclipse (2) MapForce (1) Maven (12) MySQL (1) Nexus (4) notes (4) OO (1) Oracle (4) performance (1) Perl (1) PL/SQL (1) podcast (1) PostgreSQL (1) requirement (1) scripting (1) serialization (1) shell (1) SoapUI (1) SQL (1) SSH (2) stored procedure (1) STS (2) Subclipse (1) Subversion (3) TOAD (3) Tomcat (4) UML (2) unit-testing (2) WAMP (1) WAS (3) Windows (3) WP8 (2) WTP (2) XML (4) XSLT (1)

Friday, December 31, 2010

Debugging Tomcat-hosted applications running outside of Eclipse/WTP

  1. Execute Tomcat like so:  <Tomcat home>/bin/catalina.sh jpda start
  2. By default (see catalina.sh contents), the JPDA address is 8000
  3. In Eclipse, set up the following under Run > Debug Configurations > Remote Java Application:

  4. Of course, browse to the web application project you want to debug.  
  5. When you run this debug configuration, you will be able to step-through the code just as if you were running the web application inside Eclipse/WTP.  If necessary, add more projects under the Source tab.

Thursday, December 23, 2010

Testing REST-based web service over SSL using Jersey Client

To test a REST-based web service, I created a JUnit test that employs the Jersey client classes.  Once I changed the resource location to the https URL, I received the error "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".  At first, following the ideas on this Stack Overflow thread, I added some code to set up a ClientConfig with a SSLContext for the Jersey Client.  Then I created a new trust store with the server certificate (rather than importing into the default Java trust store) and pointed command-line arguments to this new trust store (and providing its password).  

However I continued to get the same error.  But when I imported the server certificate into the default Java trust store, the error went away.  And when I commented out all the ClientConfig code, and just used this.restWSClient = Client.create(); things continued to work!  It's possible I may not have referenced the new trust store properly but at this moment, it doesn't matter.  

One thing to note, SoapUI, which I previously used to test another web service over https on the same server, did not seem to require any client-side configuration (i.e. set up server certificate in trust store).  Not sure if it simply trusts whatever certificate that it sees. 

Friday, December 17, 2010

Configuring Axis2 to expose web services over https

  1. First configure Tomcat to handle https.  This link is useful for this but note for development purposes,when the keytool prompts for “Common Name (CN)”, enter “localhost”
  2. Without further configuration, if you attempt to access your web service over https, you will likely get an error about "https is forbidden" thrown from the AxisServlet class
  3. Next, configure Axis2 to accept https calls.  Edit the axis2.xml configuration file.  There should already be a section that looks like:
        <transportReceiver name="http"
                           class="org.apache.axis2.transport.http.SimpleHTTPServer">
        <parameter name="port">8080</parameter>
    
    Add another section like this:
        <transportReceiver name="https"
                           class="org.apache.axis2.transport.http.SimpleHTTPServer">
            <parameter name="port">8443</parameter>
        </transportReceiver>
    
    (Port may vary depending on your Tomcat configuration)
  4. Without further configuration, if you try again, you will probably get an error about java.lang.NoClassDefFoundError: org/apache/http/HttpResponseFactory.  This interface can be found in the httpcore library.  If using Maven, include the following in your POM file:
            <dependency>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpcore</artifactId>
                <version>4.0</version>
                <scope>runtime</scope>
            </dependency>
    
  5. Now it should be working as it did over regular http

Wednesday, December 15, 2010

Axis2 web service generation in Eclipse

Still exploring this but haven't figured out the purpose of two options in the Web Service wizard:


Not checking "Publish the Web service" still brings up a dialog about publishing to UDDI.  Not checking "Monitor the Web service" still creates a axis2-web folder and all the JSPs, etc. as checking the option; axis2-web seems to be a web application for monitoring the web service.

What effect do these options have? 

Strategies to creating a new web application project

A seemingly trivial task, starting a new web app project in Eclipse, requires specific steps when working with an assortment of technologies like Maven and Subversion.

  1. File > New > Other > Dynamic Web Project 
  2. To conform with Maven's WAR project structure, in the following dialog, specify /src/main/webapp for the Content Directory:
  3. Once the project is created, right-click on project > Maven > Enable Dependency Management. 
  4. The project can be associated with a pre-existing Subversion folder by Team > Share Project and on this dialog, enter the path of the Subversion folder at "Use specified folder name":
  5. I might have been on crack when I performed the steps below ... they are not necessary and are retained only for reference purposes:
  6. If you generally set-up a project in Subversion with the typical folders of branches, tags, trunk, create these first and then with Subclipse check-out the trunk as your working copy (change the project name from trunk to something appropriate).  If you start your project in Eclipse and then attempt to Team > Share Project, Eclipse dialogs seem to force you to create a new Subversion location under trunk rather than committing to trunk directly
  7. Create Maven web app project, commit, re-check-out using Eclipse New Project Wizard 
    1. Use a Maven archetype to create the skeleton of your web app project in the SVN working copy.  You can do this from the command-line (refresh workspace once done) or using m2eclipse via File > New > Other > Maven project.  However this step does not create an Eclipse project that is recognized by WTP's Tomcat
    2. Commit Maven project
    3. Then delete project from workspace including contents on disk (this is OK since everything is already committed to Subversion)
    4. Re-check-out using Eclipse's New Project Wizard, choosing Dynamic Web Project for the wizard type.  Along the way, there is a dialog box that asks for "Content directory":  From here you cannot specify the webapp directory in Maven's specific structure so just ignore for now
    5. Once the project is checked-out, edit the file .settings/org.eclipse.wst.common.component.xml  There is a line that will probably read <wb-resource deploy-path="/" source-path="/WebContent"/>.  Change that to <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
    6. Your project should now be Add-able to WTP's Tomcat and content in /src/main/webapp should be viewable in the web browser

Monday, December 13, 2010

Subversion over SSH on Windows: Folder '' does not exist remotely

Setting up SpringSource Tool Suite on Windows 7, when attempting to connect using Subclipse to SVN server with a URL of the form svn+ssh://, get the error "Folder '' does not exist remotely". 

Some people have had luck with HowTo: Configure SVN+SSH with Subclipse on Windows but I kept being prompted for username/password with each folder navigation in the SVN repository (unworkable!).  One of the comments in the blog referred me to Subversion Access from Eclipse Using Subclipse which worked for me although I continue to use username/password (saved) rather than public/private key as the latter method didn't work.  I probably have the key saved improperly on the client and/or server side. 

Other problems that I had as I accessed our SVN server over a VPN:
  • hostname wasn't resolving so I had to find out the IP address of the SVN server and use that in the URL
  • Attempted to use TortoiseSVN as it supposedly handles svn+ssh:// out of the box but after installation and rebooting Windows, still couldn't find the TortoiseSVN menu in the context menu in Windows Explorer

Thursday, December 2, 2010

Re-using your code with Perl modules

Re-use of code, when not copying-and-pasting, is a good thing.  I consider myself beyond a novice Perl programmer.  But since it was never a primary tool at work, I never learned how to develop re-usable Perl modules properly.  Following is a bare-bones implementation of a Perl module.  Note that a module containing a Perl class implementation would not have to use Exporter (nor should it!)

#!/usr/bin/perl
use strict;
use warnings;

package MyPkg;

require Exporter;

our @ISA = qw(Exporter);
our @EXPORT_OK = qw(myfunc);


sub myfunc{ 
 print "bar";
}


1;

In this case, the file containing this code should be named MyPkg.pm, to match the name of the package.  A bare-bones caller of this code could be as simple as:

 
#!/usr/bin/perl
use strict;
use warnings;

use MyPkg qw{myfunc};

myfunc();

Some additional notes:
  • In the module, require Exporter; is not always necessary (not yet clear the situation for its necessity)
  • If your package is something like MyGroup::MySubGroup, two things to observe:  (1) the name of your .pm file should be MySubGroup.pm and (2) the file should be placed in a subdirectory relative to @INC paths named MyGroup.  For example, if you want to locate your re-usable module togehter with your Perl script, you would put it in a subdirectory of the directory with the Perl script named MyGroup