What Happened to Gel?

Tuesday, June 24, 2008

A question that comes up from time to time is why I do not keep working on Gel or open source it. For those not familiar with Gel, it is a free Java IDE that I wrote a few years back. Unlike Eclipse or NetBeans, Gel was a native Windows application written in Delphi and thus had a low memory footprint and very good performance. You can find more information about Gel on the product pages.

Gel had a decent set of features for a Java IDE at the time including support for code completion and javadoc popups. As a result it gained a small but loyal following and it is from them that I usually get this question. Like most things in life the answer is somewhat complex and in fact there is not a single answer, here are some points addressing why I decided to stop work on Gel:

• The competition got better. Not only were Eclipse and NetBeans constantly adding new features, the performance of the Java based IDEs increased greatly due to better performing JVMs and increasing hardware capabilities. As a result Gel was ending up with less features and not much better performance then other available IDE environments.
• The Eclipse platform became the de-facto standard. When I started working on Gel the Java IDE market was highly fragmented and I felt that carving out a small niche in that market was quite feasible. Unfortunately as time progressed it became quite clear the Eclipse was dominating the market reducing the niche I was in and thus the merit of continuing to work on Gel. While Gel was free and I was not deriving an income from it, I had no interest in working on something that was only being used by a small group of people. As most readers probably know, I’m not the only one that was affected by the domination of Eclipse, witness the cratering of Borland’s JBuilder product.
• I took a job in 2003 with a company (BEA) that already had an IDE (Workshop) and my day to day job involved using that IDE. Prior to working for BEA my day to day development tasks used Gel, however with BEA I had to use the Workshop IDE in order to perform my job. Frankly I lost a lot of my motivation to devote my personal time to working on Gel because of this, one of the things that drove me to improve Gel was that it improved my own productivity when building Java products. Additionally I was also concerned about the optics of working on something that might be viewed as competitive to Workshop.
• Finally I had some personal reasons as well. I have a young son and I am finding as he gets older he puts more demand on my personal time. When he was three he would be in bed by 6:30 or 7 pm at the latest. Now that he is eight he doesn’t go to sleep until 9pm or so which really puts a damper on the time I have available for personal projects. In addition to the family issues, I have some health issues as well with diabetes and while I’m not keeling over or anything it does mean I don’t have the same energy level I used to have in terms of working late nights. It also means more of my personal time is being spent on working out and with other health related activities then doing development.

So those are the reasons for why Gel is not being actively developed anymore. The next question is why not open source it or publish the source code so someone else can carry on with it. Unfortunately Gel uses a number of commercial components that would need to be replaced before it could be open sourced. Additionally commercial icons, from Glyfx, are being used so I cannot even publish the source code without removing those first.

I have offered to work with interested individuals to make Gel open source and have sent the source code to about ten folks over the years since I stopped development. Unfortunately none of those individuals carried on with the project after that. With the fact that the usage of Delphi is dwindling I suspect the odds of finding someone with both Delphi and Java experience who wants to carry things forward is slim to none.

Gel was a fun project while it lasted but as the expression goes “All good things must end” and Gel is no exception. I will continue to leave the product pages up for those interested in checking out what was but there will be no further development on Gel.

Posted by Gerald Nunn at 10:17 AM | Categories: Java | Permalink |

Customizing the Portal Admin Tool (PAT)

Monday, June 23, 2008

The Portal Administration Tool, aka the PAT, is a great tool for allowing administrators to manage a portal deployment. However sometimes you want to extend the console to add extra features that are missing or specific to your application to enable administrators to control everything from one place. Fortunately in WLP 10 this is now supported and here is a little example I put together showing how easy this can be.

The documentation for extending the PAT is quite easy to follow and is located at http://edocs.bea.com/wlp/docs100/extendadmin/extend.html. This documentation lays out the steps to setup your customized PAT skeleton quite well and I am not going to repeat them here. Instead I will talk about moving beyond the skeleton to create something a little more concrete.

If you have been reading my blog for awhile you have probably noticed I have been covering WSRP quite a lot in the last year or so. This is because I have been heavily involved in a large federated portal project at a financial institution here in Canada. Thus continuing with the WSRP theme, the example extension I built addresses a specific pain point with with respect to the operational aspects of a federated portal, namely how do aoperational staff disable a producer when it is down for maintenance.

Starting in WLP 10, the com.bea.wsrp.consumer.management.producer.ProducerManager class allows for producers to be pro grammatically disabled or enabled as needed. Unfortunately this API has not yet been exposed in the PAT meaning that if someone wishes to use it a custom interface to the API needs to be built. Rather then writing a standard servlet or JSP I thought it would make much more sense to write a little console extension to do it and integrate the API right into the PAT.

The first thing that needed to be done was to create a page flow portlet to manage this new functionality. I am not going to go into the code in huge amounts of detail as you can download the code and have a look for yourself, however we do need to cover some of the highlights. This extension is built as a portlet but you can also build extensions as pages and books as well. The location of an extension in the PAT is controlled by the netuix-extension.xml file and is covered in the PAT extension documentation I linked to earlier. Here is the netuix-extension.xml file this example is using.

<?xml version="1.0" encoding="UTF-8" ?> 
<weblogic-portal-extension xmlns="http://www.bea.com/servers/portal/weblogic-portal/8.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/portal/weblogic-portal/8.0 netuix-extension-1_0_0.xsd">
<provider-info>
	<title>BEA PS - WSRP Production Operations Extension</title> 
	<description>UNSUPPORTED EXTENSION - An extension that adds support for WSRP production operations, this is unsupported do not contact BEA Support for assistance.</description> 
	<author>BEA PS Canada - Gerald Nunn</author> 
</provider-info>
<portal-file>/portal.portal</portal-file>
<page-extension>
	<page-location>
		<parent-label-location label="portalProducerSummaryPage"/>
		<page-insertion-point placeholder-position="99"/>
	</page-location>
	<portlet-content content-uri="/portlets/producerOperations/producerOperations.portlet" instance-label="ptlProducerOperations_1"  title="Producer Operations"/>
</page-extension>
</weblogic-portal-extension>

The extension above tells the PAT to place this portlet on the producer summary page by specifying the parent-label-location label as portalProducerSummaryPage. Next the placeholder-position="99" in the page-insertion-point element is sufficiently large to have the PAT place the portlet at the end of all other portlets on this page. The content-uri attribute tells the PAT where to look for the portlet in our extension WAR.

In terms of the code itself, this portlet needs to integrate with the tree selection on the left side of the PAT since we need to know what portlet is active. To do this we use the com.bea.jsptools.patterns.tree.TreeStateBean class. Important. A big word of warning though, this class is not documented and supported by BEA so it may change in the future, use this with care and do not open support cases if it changes. I do have a support case open about this as the example here (http://edocs.bea.com/wlp/docs100/extendadmin/portletreuse.html) dealing with the reuse of PAT portlets also uses undocumented code from the same package. When I learn more I will post an update.

To use this class to get the current producer handle, I use the following code:

TreeStateBean bean = TreeStateBean.getTreeStateBean(getRequest(), false);
String producerHandle = bean.getSelectedNodeLabel();

Once you get the handle it is straightforward to enable and disable the producer as required, feel free to browse the code to see the specifics. Here is a closeup image of the portlet, click on it to see a full screen view of the PAT with the portlet.

The example code to download is adminConsole.zip. To use the example, simply unzip it into a directory and then import it into an empty workspace using the Workshop option "Import existing projects". Once this is done you can create a Portal domain using the Configuration Wizard and then deploy these projects from Workshop into the new domain. One aspect I did not cover here that I will likely talk about in a future post is creating a customized admin console as a shared library to improve reusability and seperate the development of the extended console from the portal project.

One final word about the usefulness of this extension in a production environment. The ProducerManager APIs to enable and disable producers can be useful in certain situations however it does have a flaw in that it does not provide a message to the user that the portlet is not available. As a result users could be left scratching their heads wondering why certain portlets are not appearing in the Portal. To counter that you may want to integrate a message somewhere to notify them of what is happening. For example, the home page could have an alert portlet listing what producers are down or the message could be integrated into the portal's header or footer.

Posted by Gerald Nunn at 9:08 AM | Categories: WebLogic | Permalink |

Renaming the appmanager in Portal

Tuesday, June 17, 2008

When you create a streaming desktop in portal it creates a URL that is formatted as follows:

http://server:port/context-root/appmanager/portal-name/desktop-name

This URL is configurable in the sense that developers and administrators can rename any part of the URL. The context-root portion is controlled from weblogic.xml while the portal-name and desktop-name portions are chosen by an administrator when the streaming desktop is created. The remaining portion of the URL, appmanager, can also be changed but it is not completely inituitive how to do it, hence this blog entry.

Changing this portion of URL is actually quite easy once you understand where it is defined. The appmanager portion of the URL is defined as a servlet in the Portal shared library BEA_HOME/wlserver_10.0/portal/lib/modules/wlp-framework-full-web-lib.war. Since this is a servlet, we can simply add a new servlet mapping to in order to make it accessible at a different location. For example:

<servlet-mapping>
    <servlet-name>AppManagerServlet</servlet-name>
    <url-pattern>/test/*</url-pattern>
</servlet-mapping> 

Adding this mapping makes the portal available at the location http://server:port/context-root/test/portal-name/desktop-name. Of course this doesn't remove the appmanager mapping and that is still accessible, but adding a mapping does allow you to access the portal under a different name.

One caveat though is that while in theory adding a new mapping for a servlet in a shared library should work, I have found that occasionally I get errors when deploying a Portal application with this declaration. Specifically the deployment complains that no servlet with the name AppManagerServlet could be found. To work around this issue, I typically re-create both the servlet definition and mapping in my web.xml. Here is a complete example:

<servlet>
    <servlet-name>MyAppManagerServlet</servlet-name>
    <servlet-class>com.bea.netuix.servlets.manager.PortalServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>MyAppManagerServlet</servlet-name>
    <url-pattern>/test/*</url-pattern>
</servlet-mapping> 

Posted by Gerald Nunn at 9:28 AM | Categories: WebLogic | Permalink |

HTPC and Firewire Results

Sunday, June 15, 2008

In my last post I discussed how to setup the Rogers 3250HD box with MythTV using firewire in order to record channels right off the box including some HD channels, the holy grail of a Canadian HTPC and PVR setup. Unfortunately I ran out of time and did not get a chance to report on the results in terms of quality and what channels are available in HD to record so this post will correct that omission.

I went through each of the HD channels one by one to determine which ones were accessible and which were not. After that process I updated my channel lineup in Schedules Direct to just include the accessible channels and you can view my lineup of channels that worked at http://www.gexperts.com/blog/files/schedulesdirect/schedule.html. These are all of the channels that worked over firewire, trimming the non-working channels from the list makes navigating MythTV much easier and will make it a breeze for my wife to know what channels can and cannot be recorded.

With respect to the HD channels, most of the channels I am interested in are accessible through firewire. I found that I could get most of the HD Canadian channels (Global, CTV and CITY) with the notable exception of CBC but no worries there as I am not a fan of the mother corp. The standard American network channels (ABC, CBS, NBC and Fox) were all accessible on both the normal and west coast channels. Finally the only specialty channels I could get in HD were TSN, SportsNet and Discovery and this was a pleasant surprise as I did not expect any of these channels to be accessible.

The quality of the HD channels is for the most part excellent with some minor border artifacts on a few the channels. Here are some pictures of the results, you can click each picture to get a full screen image. Note that my HTPC is connected to my monitor at the moment hence why the full screen images are at 1680x1050 rather then a normal HD resolution. Here is the first shot from the west coast HD ABC channel that was showing Monsters, Inc last night.

As you can see this channel gives very nice HD output with no artifacting at all when accessed through firewire. The next image is from HD NBC which was showing Saturday Night Live last night.

If you look closely at the left side of the image you can see a thin orange bar. When you are watching it on the screen this bar grows and shrinks by a pixel or two in width every few seconds so it is more noticeable then in this static shot. Personally I do not find it a big deal though given the overall quality. Here is the next example, an image from the TSN HD channel.

Again no noticeable border artifacts here. Finally here is an image from Discovery HD.

I do not have a screenshot to show it, but some HD channels exhibit a bit of jitter when displaying an SD commercial but I've only noticed it on a few occasions. Also, some HD channels have a border artifact along the top when displaying an SD program. Neither is really a major concern for me as it does not detract from the quality of the actual programming.

In terms of useability, channel changes typically take 1-3 seconds to occur so somewhat slower then the 3250HD box itself. While not ideal it is not a showstopper for me because I plan on using the HTPC to record rather then watch LiveTV. There are no issues when flipping between channels that use different resolutions or between SD and HD channels, MythTV handles it all very gracefully. MythTV was also very good when hitting the inaccessible channels, the popup info box shows it trying to get a lock on the channel as the letters LAM slowly appear. If the channel is bad MythTV popups up a window saying the channel could not be tuned and allows you to channel change somewhere else.

Otherwise the useability of this setup is equivalent to a normal MythTV setup and all in all I'm still quite satisfied in terms of how this project turned out. I should be moving the computer downstairs to the living room in the next couple of weeks where it will get the real test with the Quality Assurance department, aka my wife.

Posted by Gerald Nunn at 4:44 PM | Categories: Home Theater | Permalink |

HTPC and firewire to cable box

Friday, June 13, 2008

Things are progressing nicely on my HTPC and it is time to move on to my next task, integrating the Rogers HD cable box with the HTPC over firewire. I stopped into one of the local stores and picked up a new Scientific Atlanta (SA) 4250HD, which is Rogers latest and greatest, for use in my office while I put the HTPC together. I could have temporarily moved the 3250HD that we already have in the living room but since this box may be in my office for awhile that wasn't an option, after all my family can only go so long without their TV fix.

Once I got the new box all hooked up and connected to the HTPC through firewire I ran plugreport which gives you some basic information about the firewire connection. I could see the 4250HD was connected so the next step was testing the connection. I compiled and ran the firewire_tester program and here is where I started having issues, no matter what I did I could not get a valid firewire connection to the 4250HD. After searching around for a bit it appeared that a few other people were having the same issue with the Rogers 4250HD box. It may be a driver or kernel issue because one person said his Mac didn't have any trouble interfacing with the 4250HD.

Unfortunately I'm using Linux so I needed an alternative. I knew the 3250HD would probably work as I had tried it under Windows previously and while the quality of the video was awful the connection was definitely there. So I disconnected both boxes and swapped them around and connected the 3250HD to the HTPC. When I fired up firewire_tester this time I still did not get a connection, however after moving the firewire cable to the second port on the 3250HD it made a connection right away. Next I configured the various sources in the MythTV backend setup and subscribed to schedule listings at SchedulesDirect. I was quite excited to see that it all worked the first time out of the gate with the exception of a couple of minor glitches.

The first issue is that MythTV would not change the channel on the SA3250HD box. After googling around I found that Mythbuntu includes a small program called SA3250HD that you can compile and setup with MythTV to handle the channel changing. Compiling it was quite trivial, I did it using the following commands:

sudo apt-get install libraw1394-dev libavc1394-dev
gunzip sa3250ch.c.gz
cc -o sa3250ch sa3250ch.c -lrom1394 -lavc1394 -lraw1394

I then copied the resulting binary to /usr/local/bin and configured MythTV to use it. After a quick test it was working like a charm. The second glitch was that whenever I went to the guide in MythTV with the live TV preview my CPU utilization would shoot up to 100% making the guide unuseable. Using the top command I was able to see that the xorg process was chewing up the CPU for some reason. I am using the NVidia drivers for the 8500GT card in the HTPC so using the default drivers was not the issue. After more googling I found the NVidia X configuration options here and saw there was an option called RenderAccel listed as experimental.

I modified my /etc/X11/xorg.conf to include this option and restarted X with the Ctrl-Alt-Backspace combo. Once X restarted I fired up MythTV and went into the guide again and sure enough CPU utilization dropped to a more sedate 20%.

Updated: I didn't have much time to play with the setup once I got it going so I will post some screen grabs and results of using the Rogers box this way during the weekend.

So now that MythTV is working with the cable box I need to setup the analog cable and ATSC tuners next. The ATSC tuner using OTA should be an interesting experience because my house is on the side of a hill towards the lower end of the hill, I suspect my line of site to Toronto and Buffalo is pretty impaired as I give up 20 to 30 feet of elevation with the hill. Anyways I'll have more on that next week.

Posted by Gerald Nunn at 12:39 PM | Categories: Home Theater | Permalink |

Filtering out unnecessary log messages

Monday, June 09, 2008

Sometimes you can have too much of a good thing and once in a while logging falls into that category. In a way logging is like beer, too little of it leaves you feeling unfulfilled whilst too much dulls the senses and makes accomplishing things difficult. Trying to find that middle ground can be difficult, but fortunately it is usually easy to tune the logging subsystem to display just the right level of information for the current situation.

Once in a while though you get into a situation where someone is unintentionally logging messages that are unnecessary and cannot be readily turned off by simply switching to a higher logging level. I recently ran into this situation at a client engagement where the WSRP subsystem in WebLogic Portal was logging a lot of unnecessary messages.

It turns out in this case that the extra logging is caused by a minor issue in Portal with page flows and WSRP. If you have a page flow action that takes a form bean as a parameter this form bean gets passed between the consumer and producer as part of an IPC event that encapsulates the action. The WSRP eventing system is designed to not attempt to deserialize event payloads unless explicitly requested, however due to an issue it does in this case. This leads to a ClassNotFoundException since the form bean class does not exist on the consumer and in turn causes the following message to be logged.

    
<[java.lang.ClassNotFoundException: portlets.main.TestBean
] Unable to deserialize event payload. See stack trace for details.
java.lang.ClassNotFoundException: portlets.main.TestBean
at java.lang.Class.forName(Ljava.lang.String;ZLjava.lang.ClassLoader;)Ljava.lang.Class;(Unknown Source)
at java.io.ObjectInputStream.resolveClass(Ljava.io.ObjectStreamClass;)Ljava.lang.Class;(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Z)Ljava.io.ObjectStreamClass;(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Z)Ljava.io.ObjectStreamClass;(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Z)Ljava.lang.Object;(Unknown Source)
Truncated. see log file for complete stacktrace

This message was appearing quite often and made examining the logs more difficult then it needed to be, no longer could the administrators just grep for 'Exception' to find potential issues. The client wanted to eliminate the log message but did not want to raise the log level of the server since they wanted to be able to capture other messages at the Warning level.

Fortunately a workaround to the issue was relatively easy. WebLogic Server has a feature called Log Filters that is accessed through the WLS console that allows an administrator to determine what is or is not logged by evaluating a simple expression. In addition to an administrator creating a filter it is also possible to do this in code. For simplicity we chose to simply add an expression to the WLS console, however creating a custom class to do the filtering might be somewhat more performant.

To remove the message above we simply created a log filter with the following expression:

MSGID != 'BEA-423498'

Once the filter is created you just need to apply it to the various loggers in the console. To do this simply click on each server in the console and go to Logging tab for the server. Open the Advanced section to apply the filter which was just created to the appropriate loggers. This process is a bit of a pain to do manually, fortunately it is easy to script this using WLST.

Posted by Gerald Nunn at 3:35 PM | Categories: WebLogic | Permalink |

Configuring the HTPC network card

Sunday, June 08, 2008

I was able to do a lot of work this weekend on my HTPC as my nephew Calvin came over for the whole weekend. My son Garet is an only child so usually daddy is his #1 playmate on weekends but I was happy to relinquish my duties to Calvin for the weekend and spend some quality gadget time on myself.

So here is a new entry on the trials and tribulations of getting a network adapter going in Linux. I have two motivations for blogging about this stuff, the first is to help others who may be attempting to do the same thing and running into the same issues. The second, and most selfish, is that I'll have a handy set of instructions for myself should I ever need to go through the process again.

I'm finding that Linux is to Windows as Visual Basic is to C++. Visual Basic is easier and more productive then C++ but there are things that are near impossible to accomplish in it. C++ is not very productive but there is nothing you cannot do with that language. In a similar vein, Linux is not particularly productive but I have found that I have far more options under Linux to get things going then I do under Windows.

So on to the topic at hand, the HP m9150f I am putting together for an HTPC comes with a Realtek 8168 network adapter. The first time I booted the computer after installing Mythbuntu the network adapter worked fine, however in all subsequent steps I found that the device would never bind for some reason. After doing some reading I realized the card was using the 8169 driver which for some reason did not work.

Fortunately Realtek has an 8168 driver on their website that can be used instead of the 8169 driver. Also fortunately is the fact that other folks have had issues with this card and the forums list a variety of solutions. I found the instructions from the user energymomentum in this post to be the best. However there were a couple of minor issues you should be aware of in addition to what is in that post to resolve this issue.

The first issue is that Realtek has published a new version of the driver, r8168-8.006.00 instead of r8168-8.005.00. I did find that the 005 patch file that is provided in this post worked fine with the 006 release though so no issues there. The second issue is if you untar the driver source to the /usr/src folder you might have trouble building the driver even when using sudo. I found I was getting Permissionm Denied errors even with sudo, dropping to root using sudo -s fixed the issue for me.

The last issue I found was that when I restarted the computer the changes no longer worked. After looking at this bug report here I was able to resolve it by blacklisting the 8169 driver and running an additional command as follows:

sudo sh -c 'echo "blacklist r8169" >> /etc/modprobe.d/blacklist-network'
sudo update-initramfs -c -k all

So I am a happy camper to have full network access going now. The one saving grace of the m9150f is it also has built-in wireless so I was able to use the wireless connection to debug the issue with the ethernet adapter.

Posted by Gerald Nunn at 4:00 PM | Categories: Home Theater | Permalink |

Upgrading lirc in Mythbuntu 8.0.4

The HP Media Center comes with a nice remote, pictured below, that I wanted to use with MythTV. While Mythbuntu has a control center application that allows you to configure the remote that you are using I could not get the remote working with it. The first time I installed Mythbuntu I selected the newer Microsoft media center remotes which corresponds to the mceusb2 device. When I went to try it it didn't work, no matter how much I stubbornly kept pressing buttons it would not kick-in so queue the troubleshooting.

I tried using irw to test the remote but it would just kick out right away and then subsequent irw attempts showed a connection refused message. After doing a bit more digging I ran the lsusb command and saw that my remote IR device was from a company called Formosa Industrial Computing, Inc. A friendly IRC person on the Mythbuntu IRC channel pointed out this device was not supported in the lirc 0.8.3-pre1 release that ships with Mythbuntu 8.0.4 so I would have to replace it with the newly released 0.8.3 release.

That same friendly user attempted to aid me with this process, unfortunately somewhere along the way things got toasted sufficiently that it was easier to just re-install Mythbuntu. I think the fault was mine, when I first tried compiling lirc I used some non-standard commands that probably screwed things up.

Anyways, I finally had some time this weekend for round 2. I reinstalled Mythbuntu from scratch and started the remote process again. I guess convential wisdon is wrong because for me the second time is the charm as I found the process to be relatively painless. Here are the steps I used to get this going.

• Download the lirc 0.8.3 release from the lirc website here. The file to download is lirc-0.8.3.tar.bz2 and is linked on the left side of the lirc page.
• Copy the file to /usr/src.
• Open a terminal and go to the /usr/src directory and execute the following commands.
• tar xjvf lirc-0.8.3.tar.bz2
• cd lirc-0.8.3
• ./setup.sh
• When you run the setup command you will get a dialog screen with options. Select option 1, Driver Configuration.
• Next pick the USB Devices option.
• Finally scroll through the list until you get to Windows Media Center Remotes (new version, Philips et al.) and select that.
• Back at the main screen, select Save configuration and run configure
• After this you can compile and install the driver. To do this, run the sudo make install command.

Now that the driver is installed, we need to fix a few more things before we can start using it. One problem we have is that Mythbuntu puts the lirc executables and module files in different locations then lirc does by default so we have to replace them everywhere. This is where I got hung up on previous attempt and went down the wrong path, this time I was able to locate a helpful forum posting that pointed me in the right direction. You can read that posting here

In addition to that posting, I also found I needed the lircd.conf from the 0.8.3 branch rather then the ones included with Mythbuntu. To copy the file I did the following:

sudo cp /usr/src/lirc-0.8.3/remotes/mceusb/lircd.conf.mceusb /etc/lirc/lircd.conf
sudo cp /usr/src/lirc-0.8.3/remotes/mceusb/lircd.conf.mceusb /etc/lircd.conf

I also copied the file to /etc/lircd.conf because lirc seems to look there for the file by default even though the /etc/init.d/lirc script looks for it in /etc/lirc/lircd.conf. Finally I adjusted /etc/lirc/hardware.conf so the line REMOTE_LIRCD_CONF would point at the correct location for lircd.conf. Here is my change:

REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"

After making these changes I ran the following set of commands to replace the 0.8.3pre1 lirc files that Mythbuntu installed with the newly built ones.

sudo cp /lib/modules/2.6.24-16-generic/misc/lirc_dev.ko /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_dev
sudo cp /lib/modules/2.6.24-16-generic/misc/lirc_mceusb2.ko /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_mceusb2
sudo cp /usr/local/sbin/lircd /usr/sbin/lircd
sudo cp /usr/local/sbin/lircmd /usr/sbin/lircmd
rmmod lirc_mceusb2
rmmod lirc_dev

Note the original instructions moved the driver files, I opted to copy them just in case something else looked for them here. After all these steps I could now run irw successfully and the remote works correctly with MythTV. Hopefully this positing will help others trying to get the same remote working with Mythubuntu 8.0.4

Posted by Gerald Nunn at 4:00 PM | Categories: Home Theater | Permalink |

Maven, WebLogic Portal and APPC

Tuesday, June 03, 2008

The WebLogic utility appc is an indispensable tool for pre-compiling JSPs and generating EJB classes. Unfortunately it turns out to be somewhat difficult to use appc with Maven and WebLogic Portal for a number of reasons.

The largest is that in WebLogic Server 10 the packaging of weblogic.jar changed significantly. Instead of being one uber-jar it is now a jar that is more focused on WebLogic implementation with many secondary features and interfaces moved to other jars in the modules directory. In order to make it easy to still compile applications by adding just weblogic.jar to a classpath, this jar now supports the JDK 1.5 extension mechanism whereby dependencies are linked in the manifest in a relative fashion.

The problem with this is that we cannot use Maven to pick up weblogic.jar from a repository since all the dependencies in the manifest are based on relative paths. One potential solution is to unwind the dependency tree and create equivalent dependencies in a repository by explicitly declaring dependencies in the libraries pom.xml. As you can imagine though this would be a fairly arduous task that would be somewhat brittle, every time a new release of WLS became available someone would have to once again unwind all the dependencies and create the necessary POMs.

I suspect that at some point Maven would support registering a file and the dependencies declared in a JAR automatically but that time has not yet arrived. Given I'm not a big fan of manual labor I opted to create a quick and dirty appc plugin that you can download from the products section here. This plugin is simply a wrapper around the appc utility that simply invokes it directly from a specified WebLogic home location. The plugin also comes with some convenience tools added to make using appc with Maven and Portal easier. For example, the plugin works around another appc limitation that allows only one shared library directory by allowing you to declare multiple shared library directories and concatenating them together before invoking appc.

Anyways more information is available on the products page so go check it out if you are interested. I also added a product page for my weblogic-library-plugin that was included in my original Maven and WebLogic Portal article. This version has been updated with some bug fixes since the article was written. Additionally it includes a new feature added by Kristel Nieuwenhuys that enables you to publish shared libraries to a remote repository.

Posted by Gerald Nunn at 8:58 PM | Categories: WebLogic | Permalink |

Setting up an HTPC with MythTV

Monday, June 02, 2008

One of the reasons I wanted to move my blog to my personal site was so that I could blog about things I'm interested in other then BEA products. Make no mistake, BEA (now Oracle) products rock but when I go home at night I'm not thinking "Gee, I really feel like doing more work on WebLogic Portal". Thus you can expect to see some entries about things not related to WebLogic or Java but still of a technical nature.

One of my more technical hobbies is home theater. I got into home theater when my wife and I had our son, as any parent knows it becomes more difficult to enjoy an evening out at the movie theater and as a result we ended up spending some money putting a basic home theater system in place. Over the years equipment has come and gone but the basic structure of the system has stayed the same. Like most folks, I don't have one of those expensive dedicated home theaters in the basement that was custom built for $50K. In fact, I live in a century home and the only thing the basement is good for is storage. Thus the structure of my system is the same as most folks, a television, a 5.1 surround system and various peripherals like a Blu-ray player, XBox 360, Wii and, what most of posts in this area will cover, a home theater computer (HTPC).

I've used an HTPC for almost five years now. The primary uses for the HTPC are to watch downloaded TV shows (shhh, don't tell anyone) and to act as a PVR by recording television shows. My first system was a P4 system that I built using an Antec Aria case. The Antec Aria case was great but working on it was a pain since everything is so tight in a case that small. I was happy with that system until it got fried a couple of years ago, I never figured out what happened as it just stopped working. With that computer gone, I replaced it with a computer I originally bought for my mother-in-law but reclaimed when she found she was never using it.

So that brings me to the here and now where it is time to get a new HTPC. After looking around for awhile I decided to get an HP media center computer as I didn't really feel like building one from scratch again. The HP machines are nice in that they typically have everything you need such as a TV tuner card and a remote control. Here in Canada these machines typically come up for sale as refurbs or discontinued models.

After keeping my eye out for one I decided to pick up a HP m9150f elite media center machine as bestbuy.ca had a refurb for $699. It got to my house within a few days and I immediately unpacked and set it up. Here is a picture of it sitting on my desk in my office.

I left my current HTPC in the living room for now so I could work on this one unfettered by the demands of my wife and seven year old to use the TV. For some reason, it is really hard to make progress setting up an HTPC when you never get to use the system because of other family members. If you look closely at the picture you can see a Rogers 4250HD terminal sitting next to it, one of my goals is to get the firewire going off that box to the HTPC. This goal is what is driving the project I will likely be blogging about for the next while, setting up MythTV on my HTPC.

I always wanted to give MythTV a try but I found Windows to be good enough for my needs that I didn't want to go through the trials and tribulations of setting up Linux and MythTV. However the firewire port on the Rogers HD terminals changed my mind because apparently the firewire port works best on Linux. Looking at this thread it was apparent that both Mac and Windows users were running into issues with firewire, albeit different issues. On the Mac people could record HD fine but were unable to change the channel. On Windows people could change the channel but HD recordings were littered with artifacts. Linux users reported positive results though and that spurred me on to bite the bullet and give MythTV a try.

So keep following this blog for the trials and tribulations of working with Linux and MythTV. I'm hoping for a hassle free ride but expect a few bumps in the road, we'll see how it goes.

Posted by Gerald Nunn at 8:51 PM | Categories: Home Theater | Permalink |

Good introductory WLP and WSRP article

The developer.com site has a nice introductory article on WebLogic Portal and WSRP by Scott Nelson. If you are new to WebLogic Portal and WSRP it provides a great overview of the topic and is well worth reading. One nibble though is the author states the following on page 2:

Remote portlets are consumed in the producer with a proxy portlet, and WLP provides two ways to create a proxy portlet. One method is through the WebLogic Workshop IDE at design time. Defining a proxy portlet at design time requires providing an address to the producer in a .portlet file; this cannot be changed at runtime. Due to this drawback, this approach is not recommended in this article. If you want to see how it works in detail, you can follow the tutorial included in the WLP documentation.

This is not actually correct, the .portlet file saves a handle to the producer and not the producer WSDL URL containing the producer IP address. The IP address is stored in the producer WSDL in the WEB-INF/wsrp-producer-registry.xml file and this can be modified at runtime in the Portal Administration Tool (PAT). To do this, go to Portal Management in the PAT and open the 'Remote Producers' node under the 'Library' node. Click on the producer you want to modify and then scoll down to where the WSDL is shown in 'Producer Properties'. Click the edit button and modify the WSDL as needed.

Posted by Gerald Nunn at 2:44 PM | Categories: WebLogic | Permalink |