Cool Solutions

Launching Browser from External Application

2008-09-05T22:32:00.000-07:00

I have a standalone java/swing application, from which I want to launch a browser. There are various methods by which you can do so, but every time this java app calls Runtime.exec to launch, it creates a new browser window (unless the user has set browser such that for new urls, it opens in same window/tab).

My objective is to launch the browser such that, if I want to target a specific browser window, it does that, or if I want to open a new window, it does that too.

And, it should work with both IE and Firefox. Let's not talk about the Google's baby yet.

Now, to target a specific browser window, javascript's window.open is the best choice. However, I can't execute javascript from my java app, I need to have it executed in the browser. What I can do is -

1. Launch the browser from java app, to go to a intermediate URL (servlet/jsp), passing in the window name and the real target URL. This servlet/jsp will inject some javascript code in it to execute on load.
2. This javascript will call window.open function, passing in the target URL and the window name.
3. The target URL will be opened in the new window, or if a window with that name already exists, it will load that target URL page in that window.
4. Use the same javascript code to close this particular window which was originally launched by the java app.

This way, we have the target URL loaded into a named window.

The javascript code snippet is:

var winA=window.open(targetUrl, winName);
window.opener='x'; // this is for IE only
if(winA != window) window.close();

And this works perfectly in IE. However, I have various problems with firefox 2/3.

Allow Javascript to Close Windows in Firefox

Starting from firefox 2, it is not allowed to close a browser window, if that window was not opened by a script. In our case, since the original window was opened by java application, window.close() gives us the error - scripts can not close window not opened by script. The easy workaround for this is to change the firefox config, however, it depends on your specific solution, if you can ask your users to make this config change. I haven't explored the possibility of programatically checking/changing/prompting the users for this change.

Anyway, the change is this - type about:config in firefox address bar. This will give you a bunch of config options. Filter on dom.allow. You should see a config:
dom.allow_scripts_to_close_windows
The default is false, toggle it to true.

Now, you can close browser windows/tabs in firefox using javascript, even if the window/tab was not opened by javascript.

The Same Origin Policy

So far so good. The next problem I have is - getting handle of an already opened window.

You would think that when you use window.open("http://www.google.com", "googleWin"); it will open a window with the name googleWin. This is only partially true. It will open a window, with the URL www.google.com loaded, however, it will not set the name of the window to "googleWin", unless you executed the javascript to load window somewhere from http://www.google.com/....../.

This is a little known security feature of firefox, which I guess is dated back to Netscape days, called Same Origin Policy. According to Mozilla documentation,

The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin. Mozilla considers two pages to have the same origin if the protocol, port (if given), and host are the same for both pages.

There's one exception to this rule, where you can allow domain changes upto some extent, for example from http://store.company.com/... to http://company.com/...

Mozilla documentation is here:

http://www.mozilla.org/projects/security/components/same-origin.html

So, if you host the servlet/jsp which opens named window in the same server/protocol/port as the to be opened pages, you will be able to get handle to windows by name.

Square Architecture - Square Any Number Easy Way

2008-09-01T20:16:00.000-07:00

While nothing interesting going on in the software world, I got to play with some Math tricks, and got interested in ancient Indian math called Vedic Mathematics. While learning some of it, I thought of writing about this particular method-

Finding Square of Any Number using Vedic Math

The formula is called Dwandwa-yoga (Duplex combination process). Let's see how it works.
Duplex (D) of a number is found as follows, examples later will make it more clear.
For Duplex, in the number sequence we have to find square of, we take twice the product of the outermost pair, and then add twice the product of the next outermost pair, and so on until no pair is left.
When there are odd number of digits in the original sequence there is one digit left by itself in the middle, then this enters as its square.

So, if the number is:


                    a  then D -> a²
                    ab then D -> 2(axb)
                   abc then D -> 2(axc) +b²
                  abcd then D -> 2(axd) + 2(bxc)
                 abcde then D -> 2(axe) + 2(bxd)+c²
                ...and so on.

So, finding duplex is so easy, and after that, it is just addition, so very simple.
Before that, note that if we are given an n digit number to square, we will prepend that number with n-1 zeros.

So, let's try this. Find square of 52. It is a two digit number, so, add 2-1=1 zero in the front.


                                        052
Now, let's find the Duplex:

                         For 2,  D= 2² = 4
                         For 52, D=2(5x2) = 20
                         For 052,D=2(0x2)+5² = 25

So, simple, now, just add the numbers we got:

                                           04
                                          20
                                         25
                                       _______
                                         2704

Let's try one more example: 109²
A three digit number, so we have to add 3-1=2 zeros before it.


                 00109
Duplex:
            For 9,            D=9² = 81
            For 09,           D= 2(0x9) = 0
            For 109,          D=2(1x9)+0² = 18
            For 0109,         D=2(0x9)+2(1x0) = 0
            For 00109,        D=2(0x9)+2(0x0)+1² = 1

Here we go:
                                      81
                                     00
                                    18
                                   00
                                  01
                                __________
                                  011881 
                          
Indeed, that's the answer.

Let's do an easy one: 15²
                               015
                            For 5,    D = 5² = 25
                            For 15,   D= 2(1x5) = 10
                            For 015,  D=2(0x5)+1² = 1
And,
                                          25
                                         10
                                        01
                                     ________
                                        0225 is the answer.

Now, that brings me to a special case, for even easier calculation.
The special case is - the numbers which are ending with 5. Say, the number is of the form a5. The square of that number will be = a(a+1)|5².


So, for 15², the result will be 1(1+1) | 5²
                                i.e. 2 | 25 or 225.

Similarly, 95² will be 9(9+1) | 25
                                        i.e. 9025.

Now, that is superfast, I am sure in some cases it is even faster than doing it on calculator.

Installing Roller 3.1 on WebSphere 5.1 - Part 2

2007-09-25T21:37:00.000-07:00

Before going into the null pointer issue we saw at the end of Part 1, I came across couple of more issues, which need to be addressed first.

Roller.tld

This, needs to be defined in the web.xml, with right uri, otherwise, we get this error:
/index.jsp(36,0) File "http://www.rollerweblogger.org/tags" not found

<taglib id="tagLibRef_1">
<taglib-uri>http://www.rollerweblogger.org/tags</taglib-uri>
<taglib-location>/WEB-INF/tlds/roller.tld</taglib-location>
</taglib>

I moved the tld file from classes/META-INF/tlds/ to WEB-INF/tlds/.

LocalTransactionContainment

Whenever I access any roller page, I get the following error:
[9/20/07 15:15:45:536 MDT] 23d768b9 WebAppTransac E WTRN0043I: LocalTransaction rolled-back due to setRollbackOnly.[9/20/07 15:15:45:538 MDT] 23d768b9 WebGroup E SRVE0026E: [Servlet Error]-[LocalTransaction rolled-back due to setRollbackOnly]: com.ibm.ws.LocalTransaction.RolledbackException at com.ibm.ws.LocalTransaction.LocalTranCoordImpl.cleanup(LocalTranCoordImpl.java:1091)

According to the Servlet 2.3 specifications, all transactions should be committed or rolled back within the transaction boundries, in this case, servlet method execution. Now, these could just be select statements also.

One of the solutions to this issue, as described in WebSphere documentation is to edit the ibm-web-ext.xmi file, to include config for each servlet to have either commit or rollback the local transaction. I added this for all the servlets......but, no luck. Keep getting this error.

I then realized that even though, it is printing whole stacktrace, it may not really be the root of errors. So, looking further down, I found this NullPointerException-

RollerRuntimeConfig

So, the null pointers coming all the time is not allowing me to get to the registration page.

javax.servlet.ServletException: ServletException in '/WEB-INF/jsps/tiles/tiles-simplepage.jsp': null

The null pointer indicates that it is getting null for site.name etc. These are given default values in rollerRuntimeConfig.xml file. So, why null? Is that file not read?

There is no error in the logs that this XML file could not be found or failed to load. I had to now look at the roller source code to figure out what's happening. Infact, I put more debug statements in the code to see the values for each of these config parameters.

Well, everything is loaded fine. But, still null pointer when the jsp is looking for these parameters.

Going further deep, it is found that the code, at initialization, reads this xml file, and then stores these properties in the roller_properties table. And when JSP or any other code is getting the values for these, they come from the database.

Ok, lets check the database - roller_properties table. There is only one record, about database.version. No other properties read from XML are in there. That means the database insert is failing? How did it make just one entry though?

No idea, but that was the root cause of all these null pointer exceptions. In order to move forward, I decided to manually enter the default properties in roller_properties table. After adding all the required default properties in the table, I was able to proceed.

Like:
insert into roller_properties values ('site.name', 'roller');

Register First User

Ok, now, I can get beyond the first page. Infact, I can get to the registration page, and register the user. The first user registered will have all admin rights, so, this was really good.
Registration is simple, got it fine. Then, I try to login.....grrr.

Acegi Security

When I login with the registered userid and password, I get this:

Error occurred while invoking error reporter com.ibm.ws.webcontainer.servlet.LoadTargetServletFailure: Failed to load target servlet [FormLoginServlet]

FormLoginServlet, I guess this comes into picture only when Security is enabled in WAS. This is WebSphere specific servlet, and comes into play when login action is sent to j_security.

Looking into login.jsp, it is sending it to j_security_check. Ok, but there is no security enabled in websphere, so, may be that's why it is not finding this servlet. But, I don't want to use WebSphere security. I want to, for now, use simple jdbc authentication so that I can get into roller as admin.

This forced me to look at Acegi security documentation and code. It seemed simple that posting to non j_security_check should call the Acegi filters, rather than calling the app server's FormLoginServlet.

Let's get into security.xml, and make sure jdbcAuthenticationDao bean has right property value set for jndiName.
Next, look at authenticationProcessingFilter bean in same security.xml and update the property value from j_security_check to something else, I chose a_j_s for testing.
Now, go to login.jsp, and change the action to go to a_j_s instead of j_security_check.

Recycle the server. And wow...... I can login now!

Couple of more things:
rollerProperties.jsp - it uses JSTL 1.1 URI, so change it to use JSTL 1.0 URI, as we did in taglibs.jsp.
Also, roller.properties file has upload and search index directories defned, make sure they have trailing slash, otherwise it will give - can't access directory error.

Great.... now I am able to create the first blog.

I am still getting transaction rolledback exception, but only initially, it must be coming out of Acegi code, as it uses Spring, and since that code is executed very minimal after you are authenticated and authorized, the error doesn't show up every time you do something. But still, the error/warning is present in the logs, without causing any known harm.

Installing Roller 3.1 on WebSphere 5.1 - Part1

2007-09-24T14:45:00.000-07:00

Roller weblogger, what I thought would be a simple installation, turned out to be a painful one. I am trying to put together some of the major issues I came across and how I fixed them. Partly to blame roller community here, no good documentation, hopefully this will help some of the users getting Roller working on WebSphere, specially, version 5.1.x, AIX 5.3.

The Database

So, I started with database. I am using DB2 version 8.2. The OS is AIX 5.3.
When I tried Roller more than a year ago, it did not have db2 scripts, but thankfully, they have it now. It was easy. But, I was installing in an existing database, so added a separate tablespace for roller tables, and updated the scripts to create tables in the new tablespace.
Everything worked fine on DB side.

Datasource

Since I will be using Type 4 driver, created a datasource in the WebSphere with jndi name jdbc/rollerdb. Verified the connection, all good.

The WAR file

As documented in the installation guide the war file needs to be updated with hibernate and related jar files. Got all that, and put them in WAR's lib directory. I did not add db2 driver libraries, because WebSphere has them all, and I will be using type4 driver configured in websphere.

Updated the following config files:
hibernate.xml - use DB2Dialect
log4j.properties - specify the location of the log file on the server.
roller.properties - updated the upload and cache directory paths. I chose /tmp to start with.
Remove the <dispatcher> tags from filter section in web.xml, as documented there. This is because WAS 5.1 is servlet 2.3.

Yes, roller documentation says not to update roller.properties file directly, but define a new one, and specify it in JVM settings. Well, test installation, and doesn't matter anyway.

Just to be clear, WAS 5.1 is:
Servlet 2.3,
JSP 1.2 and
JSTL 1.0
(J2EE 1.3)

I thought it is all set now, and will be so easy to install on WebSphere, as it was on Tomcat.

Installation

I am deploying the roller in an existing app server in my dev system. Nothing special in that app server, just some other ear files are installed and working great.
Install the roller.war file, providing the context root as roller. Most of the installation takes default settings. And, fnally, see the message - roller_war.ear installed successfully. So far so good.

Recycle the app server. And there is goes:
Module, roller.war, of application, roller_war.ear/deployments/roller_war, fa
iled to start

That's it. No more information. No logs, nothing. Looking around on the web... not much information either. Somewhere I saw the problem could be with listeners denined in roller.tld file. The location of tld is also beyond my understanding. It is in ....WEB-INF/classes/META-INF/tlds/
Open it and I see:

<listener>
<listener-class>org.apache.roller.ui.core.RollerSession></listener-class>
</listener>
<listener>
<listener-class>org.apache.roller.ui.core.RollerContext</listener-class>
</listener>

Removed both of these from the tld. I don't know why they are defined here, they exist in web.xml also, where they should be.

Ok, start it again and see what happens now. Well, the application appear to do something more this time. Little better, got to see some errors in the logs now.

HibernateRoll F org.apache.roller.business.hibernate.HibernateRollerImpl TRAS0014I: The following excep
tion was logged java.lang.VerifyError: (class: org/apache/roller/business/hibernate/HibernatePersistenceStrategy, method: signature:
(Ljava/lang/String;Ljava/lang/String;)V) Incompatible argument to method

Ok, this means that the method being called has different arguments than what's being passed to it. Appeared to me that there might be two different versions of a class file in two different jars, and one, the old one is getting loaded first. Checked some obvious jars, found nothing suspicious. Let's fix the logging first.

Logging

I really wanted the log4j for roller working, so that I get the clue on what it is doing. So far, it was not creating the log file. Based on past experience with log4j, Apache commons-logging and WebSphere, I did this:
Add to web.xml:

<context-param id="ContextParam_id1">
<param-name>/log4jConfigLocation</param-name>
<param-value>/WEB-INF/classes/log4j.properties></param-value>
</context-param>

Got to see my roller.log now :-)

Classloader issue?

Well, having worked with WebSphere and dealt with its nasty classloaders since version 3.x, I thought, lets try to change the classloader policy.
So, the webapp's classloader policy is now set to PARENT_LAST. I did not want to do this, but nothing else was working.
Ok, start it again, somewhat better.

The VerifyError on Hibernate has gone now. Strange, I am not sure what it was conflicting with in parent.

And, now, it comes with new problems, of course, classloader mode has changed, so you will have new problems.

java.lang.LinkageError: Class org/xml/sax/EntityResolver violates loader constraints: definition mismatch between parent and child loaders
at org.jdom.input.SAXBuilder.configureParser(SAXBuilder.java:608)

The xmlrpc-1.2-b1.jar

There is org/xml/sax class files in this jar, which come with Java 1.4.2 also. easily tells you what the problem is. I removed all org/xml/sax class files from this jar keeping rest of them there.

Recycle... let's see what happens now!

New error:
Could not find datasource: jdbc/rollerdb
java.lang.ClassCastException: com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource

The jdbc2.0_ext.jar

This problem I have seen many times, Easy, just delete this jar from WEB-INF/lib/. This is because websphere already has javax.sql.*.

Ok, another recycle. See what it has got now:

Could not obtain connection metadata
java.sql.SQLException: null userid not supportedDSRA0010E: SQL State = null, Error Code = -99,999DSRA0010E: SQL State = null, Error Code = -
99,999
at com.ibm.db2.jcc.c.b.E(b.java:1975)
at com.ibm.db2.jcc.c.b.a(b.java:1981)

Ok, seen this before. That's my datasource. Need to use right authentication settings for container managed authentication. Fixed it, recycled it.

Cool...... it started successfully. Very good. Lots of initializing messages. no errors. Let's see if we can access it now?

JSTL 1.0

Nope, JSTL errors. Can't find the JSTL tags. I had dealt with this issue also in one of my other apps. Basically, the JSPs are using JSTL 1.1, but WebSphere 5.1 will support 1.0 version only.

Ok, locate the file giving error, /taglibs.jsp. Replace the taglib uris-
http://java.sun.com/jsp/jstl/core
with
http://java.sun.com/jstl/core

and

http://java.sun.com/jsp/jstl/fmt
with
http://java.sun.com/jstl/fmt

And, replace the two jar files, standard.jar and jstl.jar with their 1.0 versions.

Recycle, lets see if it is any better.......

Nope..... ugly null pointer.

RollerRuntimeConfig:getProperty - Trouble accessing property: site.shortName
java.lang.NullPointerException
at org.apache.roller.config.RollerRuntimeConfig.getProperty(RollerRuntimeConfig.java:67)
at org.apache.jsp._tiles_2D_simplepage._jspService(_tiles_2D_simplepage.java:277)
at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service(HttpJspBase.java:89)

Rest, we deal in part 2.