Shell scripting gotchas

• If strange behavior is encountered running an existing (working) script, your default shell may differ.  At the top of the script, you may need to explicitly set your shell, e.g. change #!/bin/sh to #!/bin/bash
• Whitespace is very important to the declaration of variables, that is:

numSections = 0;

attempts to execute a command named numSections whereas

numSections=0;

declares a variable of name numSections 

See this page for updates to this blog post.

Executing Oracle stored procedure with TOAD

In this example, the stored procedure returns a ref_cursor based on some input parameters.  In a TOAD Editor window, have something like this: 

select MySchema.MyPackage.MyStoredProcedure('param1', 'param2') from dual

and click on .

You will get results as a 1 by 1 grid, a concatenation of all the results, created by TOAD.

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.
   

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. 

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
   

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