Michael Quattlebaum

It’s been a while since I’ve spent a significant time programming on the Blackberry, so it’s taken me a little while to get back into the swing of things.  But I in doing so, I came across quite a few challenges that I thought I might share solutions to in hopes of helping other developers out there.

First problem:
Trying to sign the code from my project and getting Status=”Not Registered” and SignerID=3 and Signer Name=RIMAPPSA2

Apparently this problem can be caused by a number of different things, including using third party libraries that need to be signed.  My problem, though, seems to be related some sort of bug in Eclipse when you are changing the properties of the Blackberry project.  To recreate, include a third party .jar file in your Build path and save it.  Then go into the properties for the project and change anything in the “Blackberry Project Properties” and “Apply”. You will note that the .jar file appears again in the root directory as well as the Referenced Libraries.  This apparently is the cause of the signer problem.  To correct, open the project properties, then go to Java Build Path.  Remove the .jar file.  Then click on “Add JARs” and select it again.  Click on OK and rebuild your Active Blackberry Configuration, and when you Request Signatures, the offending entry should be gone.

Second Problem:
Could not load images as a part of the project.

I was able to include an icon image in the project without any problem by adding the icon in the properties for the Blackberry project.  However, I was really struggling with getting images loaded using the Bitmap.getBitmapResource(“imagename.png”) method.  After a great deal of debugging and frustration, I discovered that the .jar file for the project was being built without my img directory (which I had put at the root of my project).  Instead, the img directory must be in the build path of the project.  For me, the easiest thing was to just move the img directory below the src directory.

Hopefully these solutions will help someone avoid similar headaches in the future.

OK, so I saw a lot of posts from people having this problem, and had a hard time finding the answer.  So, following my most recent process of blogging about it if it took me too long to figure out, here’s the answer.

We were getting a certificate error trying to connect Outlook 2007 over HTTPS connections back to our SBS 2003 Server.  Have done this lots of times with XP and Outlook 2003 and 2007.  Always works like a charm.

We added the certificate as usual, but still were receiving errors about the certificate not being trusted.  Looking carefully I realized it was a root certificate authority error (we generated our own internal certificate for access).

So, I had to copy the certificate that had been added and paste it into the trusted root area.

Here’s the specifics:

1.  Run certmgr.msc from the start menu

2.  I found my exchange server certificate added in the “Intermediate Certification Authorty/Certificates” directory.

3.  Select it and right-click on it, and copy.

4.  Then go to the “Trusted Root Certification Authority/Certificates” directory, and right-click on the folder and paste.

5.  Close the certificate manager, and open outlook and you should be prompted for credentials.

Hope this helps someone else!

We work with a client who sells a lot of the CS1504 FOB Scanners by Symbol (Motorola now).  Our default driver that goes out with the device hasn’t changed in forever.  But we discovered recently that customers using a 64-bit OS with the driver were having issues (the driver would not install).  We called our Motorola distributor, who told us that 64-bit drivers were not available.  Got the same story from Motorola.  Interestingly enough, when we went searching the software driver’s site, we found them.

Thought someone else might be having the same type of issues…so here’s the link to download the new driver.

http://www.prolific.com.tw/eng/downloads.asp?ID=31

Got a new MC75 to work with for development.  Was having trouble getting the WiFi connected to my network.  After some playing around with settings on one that worked vs. one that did not, found the following…

When you enable WiFi on the device the first time, go to the WiFi menu in the lower-right of the screen.  Choose “Options” there.  A combo box will appear with all the different options to change.  Select “Regulatory” and uncheck the “Enable 802.11d”

After that, I was able to easily pair with my internal access point with my WEP code entered.

For the life of me, I could not figure out the problem with connecting my new iPhone to my Exchange server.  Everywhere I looked, it was supposed to be a really easy process (using the iPhone 2.0 software which has a Microsoft Exchange account type to connect with).  I finally came across a post that explained the need for upgrading to Exchange SP2, and that SBS2003 doesn’t already load it automatically using windows update.  Crazy, huh?

Here’s a link to download the SP2 install.  I had no problem installing it on my SBS2003 server.

http://www.microsoft.com/downloads/details.aspx?familyid=535BEF85-3096-45F8-AA43-60F1F58B3C40&displaylang=en

Once I did this, the setup, sure enough, was quite simple.

My settings were as follows:

Email address:  myusername@mydomain.com
Domain:  MYDOMAIN
Username:  myusername
Password:  mypassword
UseSSL: ON

Once I entered this information on the first page, I got a certificate notification that mydomain.com was not a verified certificate.  I chose “Accept”.

Then, because I’m using 2003 and not 2007, I was then prompted for the server name.  This is the external, FQDN that points to my SBS2003 server, and the server name you would normally use to access Outlook Web Access (OWA).

Server:  mail.mydomain.com

Again, I was prompted that mail.mydomain.com did not have a verifiable certificate.  I chose Accept and was able to continue.

I then made sure that Mail, Contacts, and Calendars were all set up to sync, and moments later I was receiving data.

Just as an FYI, if you don’t have your internal DNS set up to resolve to the FQDN of the server (above mail.mydomain.com), then you probably want an internal DNS server to point there…otherwise you will have to turn off your WiFi while you are inside your network.

As with most things lately, if it takes me a while to find it, I’m gonna blog it.  So here are some key places to look when customizing the look and feel of the open source JasperServer.

The key location is the tomcat WEB-INF for the server.  In a default linux installation, that will be in

{Server Install Location}/apache-tomcat/webapps/jasperserver/

If you want to change the layout of the main page, or the top panel, look in WEB-INF/decorators/main.jsp

We started by just updating some of the header layout.

If you want to change the images to update them with your own, they are in images/  The stylesheets are in stylesheets/

The other key for us was managing the text that’s being displayed.  Luckily, a language file is used for this, and it can be found in WEB-INF/bundles/jasperserver_messages.properties

You might want to look at jsp.main.* and menu.*

For something that was harder to find:  the styles for the Javascript menus.

Look in WEB-INF/decorators/main.jsp  search for “linkobject.style.background”.  The color on the first occurrence is the background color when a submenu item has been selected.  The second is the default color for the top level menu items.  Just above this section of code is a line the begins with a TD tag where id=”href${status.count}”  this is the TD tag for the submenu items.  You can update bgcolor or other components there.

Hopefully that will help me find them quicker in the future, and maybe some other poor soul out there trying to do the same!

Have fun!

After spending quite a bit of time trying to resolve this JBOSS problem, I thought I would take a few minutes to blog the solution so that others coming across this problem would be able to save some time.

First, I have a JMS configuration using JBOSS that’s designed for access over the public internet.  Internally we were testing without having any problems at all.  When we tested remotely, we started getting the above error.  So my first thought (being new to JBoss) was that there are different security policies for local vs. remote connections.  After doing a bit of research, could not find anything that was wrong with my configuration.

I finally came across the settings for the UIL2 connection factory in JBoss (my default connection methodology).  I thought at first I had a firewall problem (port 8093), but I confirmed that 8093 was open on the FW and that the configuration pointed there (special note:  you also have to open port 1099).  Then I came across the “ClientAddress” property.  This turned out to be the problem.  Apparently there is a handshake that occurs on the connection, where the server passes the address that the client should connect on.  By default, the client is passed the binding address of the server.  Since I have a public access server, I had to set this property to the public IP address of my server.  Problem Solved!

Here are the specifics:

First, go to $JBOSS_HOME/server/default/deploy/jms     (or the location of your active configuration)
In this directory, you will find a  file called “uil2-service.xml”
Find the mbean entry that looks like this:
<mbean code=”org.jboss.mq.il.uil2.UILServerILService” name=”jboss.mq:service=InvocationLayer,type=UIL2″>
My default deployment did not have the ClientAddress attribute at all in the XML, so you will probably have to add it.
Here’s what it should look like:
<attribute name=”ClientAddress”>99.99.99.99</attribute>
where “99.99.99.99″ is the actual PUBLIC IP address of your server.
The attribute tag can go anywhere after the mbean begin line and the mbean end line for the UIL2 mbean.  I put mine right before the </mbean> end tag.