Chasing Daydreams » java

Objective-C: Getting Down and Dirty

Jay — Sun, 06 Mar 2011 23:15:05 +0000

Delved deeper into Objective-C programming over the weekend. As a challenge, I ported a Java program that I cooked up in roughly 30 minutes. No, it’s not Hello World :P After several hours, I was still not done! Okay, so I got a little bit fancy with the Objective-C version but most of the time I was slowed down by syntax, API adjustments, and memory management. That’s just the way learning goes, I guess. I certainly look forward to the day when I can cook up an Objective-C program in 30 minutes.

Objective: Objective-C

Jay — Tue, 16 Nov 2010 13:05:32 +0000

Since I’ve recently decided to study iPhone programming and and since Starcraft II is still a few days away, I was able to spend some time learning Objective-C, the programming language of choice for iPhone development. Since, I’ve gone through quite a few programming languages (LOGO, BASIC, Pascal, C, some C++, Java, and more recently Flex), picking up the syntax and the basics was a relative breeze. I expect, as usual, things will get exciting once I start working with the iOS APIs. Haven’t felt this excited in a while!

Rolling My Own Java Security Framework

Jay — Thu, 25 Feb 2010 02:30:05 +0000

I needed to quickly roll out a small security framework for an app at work. Since it’s a security framework, it must have at the minimum:

User Management – add/edit/delete users for administrators and change password for users.
Authentication – establish identity of a user by getting user credentials typically via a login page.
Authorization – establish if an authenticated user is allowed access to a resource.

For user management, I cheated and decided to have ActiveDirectory handle it. System administrator can add/edit/delete users using Windows admin console and users can change their passwords via ctrl+alt+delete.

For authentication, I made login.jsp and loginhandler.jsp. loginhandler.jsp uses authenticates against ActiveDirectory and, when authenticated, forwards the user to the previously requested URI. This URI was saved by the authorization filter.

Ahmed Hammad provided the reference code for authenticating against an ActiveDirectory server.

For the authorization check. Every time a user accesses a certain resource, we check if he is allowed access to that resource’s URI. If he is authorized, he is allowed to continue on to the resource.

Michael Klaene provided the reference code for the authorization filter.

And that was all there is to it.

Next, I’m thinking of using j_security_check if it has no platform-dependency issues.

<%@ page language=”java” contentType=”text/html; charset=ISO-8859-1″
pageEncoding=”ISO-8859-1″%>

Login

Login

WebSphere 6 Error: Unsupported major.minor version 49.0

Jay — Fri, 18 Dec 2009 05:47:49 +0000

I was trying to test a web application in WebSphere 6 when I encountered this error:

Error 500: java.lang.LinkageError: LinkageError while defining class: aiu.webservices.bean.ConfigServiceProxy Could not be defined due to: aiu/webservices/bean/ConfigServiceProxy (Unsupported major.minor version 49.0) This is often caused by having a class defined at multiple locations within the classloader hierarchy. Other potential causes include compiling against an older or newer version of the class that has an incompatible method signature.

After a little bit of puzzling and googling, the problem turned out to be that I have been compiling using JDK 1.4. while the WebSphere VM only has Java 1.4. The solution was to Project->Properties->Java Compiler->Compiler Compliance Level to 1.4. And Project->Properties->Java Build Path->Libraries->JRE System Library->Alternate JRE to 1.4.

I exported to WAR, updated the application via WebSphere console, and it worked! couldn’t believe it was that simple :P

Web Services with Apache Axis2

Jay — Wed, 19 Aug 2009 10:27:00 +0000

Since my new project would require me to use web services, I decided to get my hands at it.

Bottom-Up Approach To Writing Web Services

The logical place to start would be take your plain old Java classes (POJOs, I love them) and expose their methods to to the web. Since you already have the implementation, this is called a bottom-up approach. And with Eclipse Ganymede and Apache Axis2 1.4.1, it was all a breeze. Just create a dynamic web project, create your POJO(s), create Web Service, choose bottom-up. The Axis2 plug-in then creates a web service complete with WSDL (web service definition language) file and all. Here are the details.

With some groping and googling, I was able to successfully connect my test Adobe Flex application to my web service with no problems.

Top-Down Approach To Writing Web Services

The next step was to do it the other way around, given a WSDL file which describes your web service in great detail, and implement your service. Since you start with just the web service description, it’s called a top-down approach. It was also a breeze. Create a dynamic web project, create a web service, choose top-down, give the location of the WSDL file (I used the WSDL generated earlier), and generate all the necessary classes along with TODO tags where you’re supposed to add your code. Put it in your implementation, compile, deploy, and you’re good to go. Here are the details.

With just a small adjustment in the WSDL URI, I was again able to successfully connect my test Adobe Flex application to my web service with no problems.

All this with no need to mess around with HTTP (it’s just the transport), SOAP (it’s just the protocol), or WSDL (it is generated). Java tooling sure makes web services easy.