Aspect Oriented Programming

Aspect Oriented Programming (AOP) is relatively new practice and was born because programmers discovered that there are things that Object Oriented Programming (OOP) can’t do. While OOP encourages modularity, encapsulation, inheritance and polymorphism, AOP separates concerns into modules or aspects. This way, when we need to maintain large projects, it would be easier because we would only need to edit certain modules and not the whole thing.
Aspects are like blankets that cover many components of the application. Examples are logging, transaction management and security. AOP will make it possible for these services to reach the whole program without having to intrude in the program’s main functionality. They would be implemented when they need to be and the program will know when.
An example in Spring in Action by Manning is the Minstel and the Knight. The minstrel would have to sing for the knight before and after the knight goes to battle. AOP is implemented here because the action of the minstel is not declared in the class of the knight, rather in the embarkOnQuest method of the program.

I am not yet sure which part of Projectrix can we use this but it definitely helped clear Spring concepts.

What does not seem to have been enhanced.

I’ve been getting this error since I reformatted my laptop, reinstalled everything, installed and updated plugins, imported project from SVN, added required jars and deployed to Google.

Uncaught exception from servlet
javax.jdo.JDOUserException: Persistent class "Class com.projectrix.oauth.model.UserOAuthAccessToken does not seem to have been enhanced. You may want to rerun the enhancer and check for errors in the output." has no table in the database, but the operation requires it. Please check the specification of the MetaData for this class.

What is this? I can’t login anymore haha. *Still investigating.*

Third Game Draft/Prototype

For our third game, we chose the topic linear equations.

Everyone, the power of polymorphism.

I was able to implement a tutorial that exposes GWT RPC as a Spring Bean! Now I can make use of Dependency Injection to give the the GWT-RPC services its dependencies such as Data Access Objects and other service classes. Don’t I just love POJO based development? Most probably I can unit test this as well. Now that makes it sweeter!

The GWT community has come up with a solution to integrate GWT RPC into a Spring container. The key here is simply to find a way for RPCs to get into the Spring container and be forwarded to the server POJO. This was done by implementing the controller interface and then making use of GWT’s RemoteServletService and what have you to process the call.

This was done by

1. implementing Spring’s controller interface
2. inheriting GWT’s RemoteServletService

I understand a bit what’s going on in there and I have to say that was a really smart thing to do!

But I do have my comment

I think it’s too “heavy” for each service to be implemented as a controller. Maybe the GWTRPC controller can have a list of services which can be wired in Spring and the GWTRPC controller can figure out from the payload which class it will use.

Something like this

@Override
public String processCall(String payload) throws SerializationException {
RPCRequest rpcRequest = RPC.decodeRequest(payload,
            this.remoteServiceClass);

// delegate work to the spring injected service
return RPC.invokeAndEncodeResponse(this.remoteService, rpcRequest
        getMethod(), rpcRequest.getParameters());
}

instead of using this.remoteService, do something like getRemoteService(String payload) which returns the appropriate
service class.

Another job for another day I guess.

Learning GWT-RPC

1. Well first off, I got to a bumpy start.  I wanted to add a GWT module to my developer sandbox but at first I didn’t know how.

You need a module file to make GWT work and the html file where the javascript generated by GWT will be hosted. Those are  pretty complicated to setup–manually. The module file is an xml file that needs a namespace and the javascript is very — well I don’t how to start explaining where to get that from. GWT doesn’t show you the generated javascript script.

But as it turns out, the GWT plug-in takes care of this for you! (Why didn’t I think of that in the first place?) Simply hit ctrl+n and create a module, html file or entry point.

2. So I tried applying what I’ve learned and after hurdling a few mistakes (no I still can’t make GWT RPC work), I finally find myself needing to learn how to integrate GWT with Spring for Hardwire’s requirements (since it uses the Spring framework).

This is the culprit:

<servlet-mapping>
        <servlet-name>SandboxServlet</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>	

<servlet-mapping>
	<servlet-name>lookupService</servlet-name>
	<url-pattern>/Rex/lookup</url-pattern>
</servlet-mapping>

Instead of the RPC going to the lookupService, it goes to the DispatcherServlet a.k.a Sandbox. That’s why I get this error:

11 1, 09 5:20:59 PM org.springframework.web.servlet.DispatcherServlet noHandlerFound
WARNING: No mapping found for HTTP request with URI [/org.sandbox.Rex/lookup]
in DispatcherServlet with name 'sandbox'

I could do a workaround by making all the requests to the url /app/*, meaning dynamic pages to go to the Sandbox dispatcher servlet while on the other hand all rpc calls destined for the lookupService must address to the url services/*.

But this is ugly, would you want to type in http://hard-wire.appspot.com/app/ to go to hardwire? I didn’t think so.

Besides I’ve always wanted the the RPC service to be exposed as a spring bean so that I can make use of the other POJOs I’ve made.

Ergo, I am going back tomorrow and work on doing this tutorial instead. Pretty neat stuff if you ask me.