Pages

Monday, April 28, 2014

How to change struts tooltip icon

Man, this morning came my Duh !!!! moment.

The requirement was to change the tooltip image to something that would make our clients happy.
For reasons best known to them, they were very unhappy with the default tooltip,gif provided by struts.

I was like no problemo, that should be simple, we were on struts2.3.16.1, just had to figure out how to specify the tooltip path and put the new image in path.

Google search landed me on this page :
http://struts.apache.org/release/2.3.x/struts2-core/apidocs/org/apache/struts2/components/UIBean.html

Perfect !!! I thought, they specify use tooltipIcon and all will be well.

Tried and tried it did not work.
After about 15 to 20 mins of this decided to read the entire page.

Found that the instructions were not accurate, but the example in the page was accurate.
It was not tooltipIcon but tooltipIconPath that was the correct parameter.

So, finally what I ended up doing was providing the tooltipIconPath in the s:form tag, problem solved.


Action mapping broke when we moved from Struts 2.1.8 to 2.3.16

We are in the habit of coding the Continue, Cancel and back buttons as shown below:
 


As you can see we were totally reliant on action:  ie the  action mapping mechanism provided by the DefaultActionMapper, we had 1000s of jsps that were similar.

It all worked beautifully as long as we were on 2.1.8, then came the news that 2.1.8 has a security hole. We had to upgrade to 2.3.16.1 ASAP.

To my horror none of the action mappings worked, clicking on any button submitted the form.
Imagine filling incorrect details and clicking cancel, and getting the following message : 'Your request has been Submitted'. This was a surefire way to get a drubbing from management.

Luckily I came across the following article, pls do read for details:
https://struts.apache.org/release/2.3.x/docs/s2-018.html

Oh, what joy!!!
All I had to do was to include the following properties in the struts.properties file and we were good to go.

Properties to be included in struts.properties:

struts.mapper.action.prefix.enabled=true
struts.mapper.action.prefix.crossNamespaces=false


Thursday, March 13, 2014

SCJEA OCMJEA Part 2 and Part 3 experience

Some tips and tricks from my experience and a few blogs that helped me through this journey.



I used StarUML 5.2, this version was not completely UML2. However, my assigment mentioned that my solution should be UML complaint. It did not specifically ask for UML 2, so I went ahead with StarUML 5.2 and since I passed, I don't think it harmed.

Some Tips:


Class Diagram:

I had crammed in a lot of information in the assigment. Towards the end, my class diagram looked more like an information overload. I did not want to split it as I did not want to risk failure, so
I created 2 images . 


In image 1 , I hid all the attributes and operations, left the dependencies and class level annotations intact. I removed most of teh comments too. I called it the overview diagram.
This diagram had a prominent note requesting the examiner to look at the Main Class diagram for operations and other details. That way I thought, the examiner can easily see classes and their relationships without getting bogged down by attribute and operation details.
In the main class diagram I crammed as much information as possible.


Deployment diagram:
I had two deployment diagrams.
The first one gave a high level view with firewalls, all clusters, datacenters etc.I showed all servers, and all nodes. This diagram did not give details of the ears/wars and jars.


The second one was called Type level deployment, it detailed how the jars, wars and ears were deployed. I only showed one AS node in the type level diagram, and put a note stating that. I showed external systems on both.

Assumptions:

I had made a lot of assumptions.
I did not want to aggravate the examiner by making her go through paragraphs of assumptions.
So I highlighted the important part of the assumption in bold, and then explained it in detail
in regular font. That way the examiner can get an idea by merely skimming through and then delve
into detail if she feels the need.

Risks:
I had in total 7 risks, I ordered them by degree of importance, thus the 3 major ones were first.



Going through Java ranch and reading experiences of others helped me refine my diagrams.

I started preparing for Part III while still working on my assignment. Trying to answer the list
of possible Part III questions helped me catch and correct some flaws or shortcomings in my design.

Blogs that helped me.

http://reddymails.blogspot.com/2011/07/well-assignment-i-got-was-designing-big.html

http://scea5-passingpart2and3.blogspot.com/

http://java.dzone.com/articles/my-path-scea-5

http://www.selikoff.net/2010/11/17/jeanne%E2%80%99s-sceaocmjca-5-part-23-experiences/

 Hope this helps, have fun.

Monday, March 3, 2014

Subversion Perl bindings for Git-Svn..getting rid of Can't locate SVN/Core.pm in @INC.Getting Git-SVN working on RHEL6

Getting the actual svn to git migration was simple, but getting my RHEL 6 system to a state where I could run git-svn...phew that was a long hard trek. 

The quickest way to get your system to a state where you can run svn to git migration would be to rely on https://www.atlassian.com/git/migration. Atlassian has a jar svn-migration-scripts.jar.

Download that and run :

java -jar ~/svn-migration-scripts.jar verify

This will give you the delta between where your system is and where it should be in order to get the migration done.
Get the required version of Git and Subversion installed.
In my case I got the got the following installed.
  • Git 1.8.4
  • Subversion 1.7.16 or higher
Then typed git-svn and got the following error:

 Can't locate SVN/Core.pm.


Basically the subversion perl bindings are missing.
There are tons of blogs an resources on how to get that working.
None of it work perfectly for me. Finally what worked was:
PS: I had root permissions on this VM
  •  Install Perl 5.18.2 (My RHEL6 only had perl5 )
    • Get the tar
    • Untar and go through the README, and Chown -R root:root perl-5.18.2
    •  Run the configure command:
      • ./Configure -des -prefix=/usr/local   This will create a ./config.sh file in the same folder
      • Run the ./config.sh file. this will generate the make file
      • Run the following
        • Make
        • Make test
        • Make install
      • Perl 5.18.2 is now installed to /usr/local
    • Set PERL5LIB to /usr/local/lib and export variable PERL5LIB 
      • export PERL5LIB=/usr/local/lib
         
    •  The type
      • cpan SVN::Core    and wait for it to finish
    • The find the location of git-svn
      • find / -name git-svn
      • vi git-svn and change the perl path to point to  5.18.2. perl and then save the change 
      •  That was it, git-svn worked like a charm.


If these steps do not get you where you want to be, here are some of the resources that have various solutions to the same issue.

http://www.linuxquestions.org/questions/slackware-14/could-not-launch-git-svn-647625/

http://slackbuilds.org/repository/12.2/development/subversion-bindings/

http://git.661346.n2.nabble.com/subversion-perl-missing-td6831600.html









Friday, January 17, 2014

Creating an archetype for a multi project JEE Maven project.


Goal
To create an archetype that can be used to create multi module maven projects.
Multi project, maven projects give us the convenience of running a maven command in the base project.
So if we type mvn clean install in the  base project, the command will be executed for all the enclosed projects.


To accomplish this we first need to create  a multi module project. Then create an archetype from that project.

This blog details the following steps:
- How I created the base project
- How I generated the archetype from the base project
- How I used the archetype to create my first mult project maven project

Base multi module project








The Archetype

Here is the directory structure of the final archetype. As you can see the actual archetype will be found under target/generated-resources folder.






The idea was to install this archetype in the company repository and all new projects will use this archetype to create its project structure.

Example of a project that was created using the above shown archetype.
As you can see the __rootArtifactId__ token is replaced with the actual project name.
Which in this case is acctauthreq

Sample Project using the archetype






Okay, time to go over the steps that  I went through to get the archetype going.

Creating the Base Project

Base project is the enclosing project. Here is the command  I used to generate it. I have decided to call the base project for the archetype adi-identity-archetype.

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=edu.vanderbilt.adi -DartifactId=adi-identity-archetype -Dversion=1.0


As you can see the maven-archetype-quickstart was used to create the base project.

 Running the above command will create a folder
adi-identity-archetype and a pom.xml with packaging type jar.


Cd to adi-identity-archetype and change the pom.xml packaging type to pom.

 













Also add dependencies to java ee, commons logging etc.
<dependency> 
      <groupId>javaee</groupId> 
      <artifactId>javaee-api</artifactId> 
      <version>5</version> 
      <scope>provided</scope> 
</dependency>

<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.1.1</version>
</dependency>



All the other maven projects will created inside this enclosing Base Project.

Creating the internal projects

Step 1: CD to adi-identity-archetype

Step 2: Create util project

Run the following command.



mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=edu.vanderbilt.adi.util -DartifactId=__rootArtifactId__-util  -Dversion=1.0


As you can see the artifactId is __rootArtifactId__-util.


Step 3: Create EJB project



mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=edu.vanderbilt.adi.ejb -DartifactId=__rootArtifactId__-ejb  -Dversion=1.0

CD to __rootArtifactId__-ejb 

 Then enter the relative path to the parent pom. The pom.xml of the enclosing Base Project will be the parent pom.







Set Packaging to
<packaging>ejb</packaging>



Add the following plugins



Add the following dependencies

 



Step 4: Create Web project.
We use a struts based web project and thus used the struts2-archetype-blank to create the web project.

If you do not care for struts you could use the maven-archetype-webapp to create the web project.


Here is the command I used to create a struts based web app.

mvn archetype:generate -DgroupId=edu.vanderbilt.adi.web  -DartifactId=__rootArtifactId__-war  -Dversion=1.0 -DarchetypeGroupId=org.apache.struts   -DarchetypeArtifactId=struts2-archetype-blank -DarchetypeVersion=2.1.8.1 -DarchetypeCatalog=http://people.apache.org/builds/struts/2.1.8.1/m2-staging-repository/


Add the relative path to the parent pom and change the packaging to war.
 Since we want to filter the web.xml we would need to configure the maven war plugin.





Since we do not use spring and jetty remove explicit dependencies to these jars.



Step 5: Create EAR project
Most of our applications are eventually packaged in an ear. Thus creating a packaging ear project.



mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=edu.vanderbilt.adi.ear -DartifactId=__rootArtifactId__-ear  -Dversion=1.0

Cd to __rootArtifactId__-ear
 Then enter the relative path to the parent pom. The pom.xml of the enclosing Base Project will be the parent pom.

 

  Change the packaging from jar to ear.



saa

 Add the following dependencies. The other internal projects are being added here as dependencies.



  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>

    <dependency>
     <groupId>${groupId}.util</groupId>
          <artifactId>__rootArtifactId__-util</artifactId>
           <version>1.0</version>
           <type>jar</type>
    </dependency>
    <dependency>
      <!-- 3.3. Dependency on EJB Module. -->
            <groupId>${groupId}.ejb</groupId>
            <artifactId>__rootArtifactId__-ejb</artifactId>
           <type>ejb</type>
           <version>1.0</version>
    </dependency>
    <dependency>
      <!-- 3.4. Dependency on Web Application Module. -->
            <groupId>${groupId}.web</groupId>
            <artifactId>__rootArtifactId__-war</artifactId>
           <type>war</type>
     <version>1.0</version>
    </dependency>
  </dependencies>


Configure the maven ear plugin as follows:

 

<plugins>
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
          <!-- 4.5. Specify modules to include. -->
         <modules>
            <!-- 4.5.1. Include Java Module. -->
            <javaModule>
            <groupId>${groupId}.util</groupId>
          <artifactId>__rootArtifactId__-util</artifactId>
           </javaModule>
            <!-- 4.5.2. Include EJB Module. -->
            <ejbModule>
          <groupId>${groupId}.ejb</groupId>
            <artifactId>__rootArtifactId__-ejb</artifactId>
            </ejbModule>
            <!-- 4.5.3. Include Web Application Module. -->
            <webModule>
            <groupId>${groupId}.web</groupId>
            <artifactId>__rootArtifactId__-war</artifactId>
           <contextRoot>${webContext}</contextRoot>          
            </webModule>
          </modules>
        </configuration>
      </plugin>
</plugins>



*Note specifying the webcontext as shown here will allow the user to specify the webcontext on demand during build. See Ex. below.



If the <contextRoot>${webContext}</contextRoot> is added in the maven ear plugin on mvn install you can pass in the required web context as a parameter






sds



And the resuting application.xml will have this value as the web context.






 Step 6: Create Model
We use EJB3 and JPA entities (implemented as Hibernate entities) and hence creating  a model project.


mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DgroupId=edu.vanderbilt.adi.model -DartifactId=__rootArtifactId__-model -Dversion=1.0

  CD to __rootArtifactId__-model
 Then enter the relative path to the parent pom. The pom.xml of the enclosing Base Project will be the parent pom.
sad

Add the following dependencies to hibernate.


<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
<version>1.0.1.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>4.0.1.Final</version>
</dependency>


Under folder __rootArtifactId__-model\src\main create folder resources


 







Under the resources folder create persistence.xml





Under __rootArtifactId__-model\src\main\java\edu\vanderbilt\adi\model create SampleEntity.java





Generating the archetype from the project

We are finally ready to create an archetype from this project.

This can be done as follows:

Step 1 :  cd to adi-identity-archetype

Step 2: Execute the following in the adi-identity-archetype dierctory.

mvn archetype:create-from-project

This will create the target/generated-resources folder.

Step 3:

cd to

adi-identity-archetype\target\generated-sources\archetype\src\main\resources\archetype-resources

Step 4:
Now visit each pom.xml and replace references to __rootArtifactId__ to ${rootArtifactId}

Change the  artifactId of each module to follow the pattern

${rootArtifactId}-<moduleId>

Ex.

   <groupId>${groupId}.ejb</groupId>
  <artifactId>${rootArtifactId}-ejb</artifactId>
  <version>${version}</version>
  <name>${rootArtifactId}-ejb</name>


Step 5: cd to 


 adi-identity-archetype\target\generated-sources\archetype\src\test\resources\projects\basic


Step 6: Modify the archetype.properties file as shown below.

#Tue Dec 31 12:37:25 CST 2013
package=it.pkg
version=0.1-SNAPSHOT
groupId=archetype.it
artifactId=basic
webContext=basic

Step7

CD to folder

adi-identity-archetype\target\generated-sources\archetype

Execute mvn install

That's it your archetype is now installed in the your repo.







References:

Some blogs and tutorials I relied on to get my archetype going. Thanks to the authors of these resources.



http://scriptlandia.blogspot.com/2006/05/how-to-make-javaee-project-with-maven2.html

http://struts.apache.org/release/2.2.x/docs/struts-2-blank-archetype.html

http://stackoverflow.com/questions/20325814/multi-module-dependencies-in-maven-ear

http://www.mkyong.com/maven/how-to-create-a-jar-file-with-maven/

http://maven.apache.org/shared/maven-archiver/index.html

http://docs.oracle.com/javase/tutorial/deployment/jar/downman.html

http://maven.apache.org/plugins/maven-deploy-plugin/usage.html