Saturday, November 20, 2010

Unmanaged Entity Converter Part II

As you all know, seam's entity converter works only for persisted objects. If you have transient objects, then you will need to write a custom converter like here.

The thing about the above converter is that you need an abstract entity class, which will need to be extended by the entities that you are managing for. The solution used a Hash Map that takes in a key-value pair. The value is the object and the key of the object is implemented by the abstract entity manager.

One of my coworkers used slightly different approach, which I think is neater and did not require each entity to extend the abstract entity class. What he did was instead of creating the key, he used the hashCode value of the object. Each object is unique and so are their hash values. Therefore, we can safely use the hash values as our key. The detailed code is shown here.


Now, after we upgraded to JBoss 5 and Seam 2.2.1, the way we called the converter from the code is not working anymore. We originally used <f:converter converterId="nameOfConverterId">. But we keep getting "Value Not Valid" error as thrown by JSF. After two weeks of trying to figure out what is the cause, a slight change in the way we call converter solved the problem. Instead of using JSF tag, you can use the converter attribute of the component. For example, if you are using <h:selectManyCheckBox>, you can write like this :<h:selectManyCheckBox value="#{myValue}" converter="#{converterName}">. Make sure you reference the converter name using EL expression, otherwise it won't work.

Hopefully this post will save you a lot of time if you are having similar issues.



Wednesday, November 17, 2010

If you are an undergraduate or graduate Computer Science student, it's very possible that you will have to take an Operating System class as part of your curriculum. Most of the time, the class will have labs or coding projects. I'm not so sure of this, but I can say with a 99.9% confidence that almost all OS classes in the State uses Tanenbaum's book. I am not sure why it is so. I haven't read many Operating System books, so I can't make comparisons. But his book is one of the highly favored one. And also I notice that most professors who teach OS have experiences dated back to 1970s. From my experience with two different OS professors, both of them have experience dated back to those days with punch cards.

From my experience, most students hate OS class. But I think it is one of the important classes that every person in computer science or engineering discipline should learn about. The fact is that most of us enjoy coding and learning all sorts of programming languages. But we do not like to learn OS.

The thing that makes it hard us to enjoy OS is that there's no direct practicability, and it is very theoretical. And it's a lot of materials to digest. Professors will assign you to write a program that mimics those scheduling algorithms. But say, if you really want to see how it is done in your Windows XP or Unix, you need lower level programming. It is not as straight forward as C or Java.

If you are trying too hard to fit what you learned into the programming aspect, I'd suggest that you take a step back and try to understand as it is without complicating it. Of course, you will need some background knowledge in order to understand it. And if you have trouble understanding it, try to read through materials again and again. I find that Tenanbeum's textbook is pretty good at explaining. I'd compare that reading his textbook is pretty similar to reading an anatomy book. It's pretty self-explanatory, but a lot of materials to be memorized.

So, don't worry if you can't seem to get it through. Most CS students have to go through that once in their life and you are not alone.