JEE Application with external log4j properties

JEE Application with external log4j properties

Application characteristics

- An ear with EJBs, a War and some util files

- The log4j.properties not included in the ear

- log4j.properties located a out side the server.

- Solution tested on Weblogic 12c, but should be portable to any standard JEE container.

Issue

Though it is perfectly acceptable to include the log4j.properties inside the ear/war.It comes with drawback that logging levels cannot be changed on the fly, as the levels are stated in the log4j.properties bundled with the code.  

You can overcome this drawback by removing the log4j.properties from the EAR/WAR and placing it on the server machine in location accessible by the server process. 

Here is how to get that working.

Log4j background information

The most straightforward use of log4j in your application will be to

- Include the required log4j.jar in your ear/war

- Include the log4j.properties under your resources directory for Ex.

    mockapp\mockapp-war\src\main\resources

                           

    mockapp\mockapp-ejb\src\main\resources

- Have a statement similar to the one shown below to get the logger.

 Logger logger = Logger.getLogger(MockApp.class);

Once the logger instance is obtained, print out the log statements For Ex.

logger.info("My MDB got message today using Util: " + message);

When this application is deployed and the logger.info is executed the 

log  is output to the file mentioned in the log4j.properties file.

Steps to make Log4j logging work from an external file

- You will have to leverage the org.apache.log4j.PropertyConfigurator class.

- Get the logger in the following manner:

        Logger logger = Logger.getLogger(MyClass.class);
       
        PropertyConfigurator.configureAndWatch(<Location of your log4j.properties file>);

 For Ex.

       PropertyConfigurator.configureAndWatch("C:\\log4j\\config\\mockapp\\log4j.properties");

- Remove log4j.properties files from the ear/war

- Place the properties in the desired location.

- Build the ear or war and deploy. 

Now you will notice that though you don't have a log4j.properties file in your deployed artifact (ear or war). The logs are still being created.

Calling PropertyConfigurator.configureAndWatch ensures that any changes you make to this log4j.properties file will be picked up by the server in 60 seconds.

You can change this interval by using an overloaded configureAndWatch  method that takes in the 

reload delay.

Enjoy !!!! 

References:

https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configureAndWatch%28java.lang.String%29 

http://www.codejava.net/coding/how-to-configure-log4j-as-logging-mechanism-in-java?start=2 

Jboss5 trouble getting data from SOAP webservice, empty response

We have been on Jboss 4.2 eap for aeons and have finally decided to upgrade to Jboss 5.2.
One of the applications made a Webservice call to a thirdparty SOAP webservice.

Everything looked good in the logs until we made that webservice call and looked at the results.
No matter what we send in the request the response would come back null.

We used a standalone client to test the webservice call, and that worked fine ,we were getting the required response back, this test narrowed it down to Jboss5.2 jars.

There are a gazillion posts on resolving the issue with SOAP webservice calls wrt Jboss5.2.
Some talked about saaj-api.jar, some about including a jboss-classloading.xml to eliminate the usage of jboss5 jars.

The following solution looked most promising:
http://forum.spring.io/forum/spring-projects/web-services/86570-webservice-request-is-empty
But for some reason that would not work either.

Finally what worked was:
1. Deleting  jboss-as\server\<INSTANCE_NAME>\deployers\jbossws.deployer 
2. Making sure all the required jars are bundled in with our application. (Please see below for the entire list)

Now we did not have to delete the entire folder to get it working, just deleting 
the jbossws-native-core.jar  did the trick.
jbossws-native-core.jar has org.jboss.ws.core.soap.MessageFactoryImpl, which was being used by 
org.springframework.ws.soap.saaj.SaajSoapMessageFactory and that was causing all the trouble.



But just deleting the just the jar resulted in some scary looking deploy errors in the log on startup.
That did not affect the application, however we preferred to keep the log cleaner. Since, we did not care for  jbossws.deployer anyways we deleted the entire folder.

Jars that we bundled in with the application. Please note some of them are unique to our application ex. castor jars etc., but you get the general idea, right ???

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

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.

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