Objective-C: Getting Down and Dirty

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

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

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.

Continue reading “Rolling My Own Java Security Framework”

WebSphere 6 Error: Unsupported major.minor version 49.0

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

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.