In Summary
I was very happy to see that BEA finally released a long overdue .NET 2.0 Framework version of the portal. The UI refresh will definitely help speed up some of the design tasks that many people have labored to accomplish in the past. As for .NET 2.0, let's just say that I'll be happy to have my 64-bit web server not running under 32-bit compatability mode anymore (though I wouldn't have minded seeing the service applications as native .NET vs Java... hint, hint).
The only thing so far that I wasn't too happy with is sheer number of build warnings (~1180) that were not dealt with before shipping this code. Now I realize that part of the issue could be labeled as part of the Java to C# conversion, but if that were true then the Java code wouldn't have the same problems (unfortunately it appears to when I looked). I wouldn't be surprised if the recent acquisition of BEA even had anything to do with rushing this out the door a bit. Either way, all of the warnings pretty much fall into one of these categories:
- Member overrides that hide the original member in an inherited class (e.g. STR_MVC_CLASS_NAME found everywhere)
- Invalid major.minor.build.revision format in the AssemblyInfo.cs (even if this does match the Java build reference)
- "The variable 'e' is declared but never used." The exception handle from try catch blocks.
- Empty switch blocks
- Private fields that never have a value assigned.
- Unreachable code detected (!!!!!)
Now some of the items like the STR_MVC_CLASS_NAME issue are based on carry over code design going back to the earlier Plumtree 5.x builds. I understand why it's there, but couldn't this have been handled with a virtual/overrides option for the base & inherited classes?
If you are going to use a try/catch block that logs out with a generic message that doesn't include the error, how about following up the error message with a debug message that logging that does show the error exception?
Empty switch blocks and unused field values? Really now, just comment it out or delete it, don't leave it in there as is.
Lastly, regarding the unreachable code blocks, this one is beyond me. There were almost 350 instances of this when I built the project. 350!!! Now I haven't taken the time to go back over & find out what exactly happens in all of these, but most of them appear to have an intended purpose that follows the unreachable area. For now I can only assume that it will work as intended, but at some point in time I might just touch back on this to see what can be done.
