Wednesday, December 23, 2009

Simple EJB Bean

Okay so let's create a simple EJB bean that just says "hello", after that we want to secure the bean using a JDBC Realm.

Let's start with your basic EJB.

package com.blogger.ramen;

import javax.ejb.Stateless;

public class HelloBean implements HelloRemote {

public String sayHello() {
return "Hello from EJB!";


and the interface,


package com.blogger.ramen;

import javax.ejb.Remote;

public interface HelloRemote {

String sayHello();


See that wasn't that hard. Now let's write up the sun-ejb-jar.xml file so that we can let Glassfish know what to do with the EJB once we deploy it. Think of the xml descriptors as instructions for Glassfish on how it should expose your EJB, use your EJB, what resources are needed, and so forth. Some tags from the xml descriptors have been converted into annotations for your Java code, like @Stateless and @Remote.

One of the things that I usually put into the xml descriptor is the JNDI name. I'm just so use to doing it that way, but you are free to use the @Stateless annotation to give the JNDI. So let's look at my sun-ejb-jar.xml file, also note the sun that is in front of ejb-jar.xml. The ejb-jar.xml file is the standard xml descriptor and would be a good place for the JNDI but we need the sun specific one because we will need to secure our EJB later. We'll forgo the standard ejb-jar for the sun specific one.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "">

As you can see I've given my EJB a global JNDI name of ejb/Helloness/HelloThere.
Now deploy to Glassfish.

Congrats you've written your first EJB, or maybe your second or so. However, the JAR is running all by itself on your Glassfish server. The crappy part about that is that you won't be able to use injection now. The reason is that for injection to work the JAR and the client must be running together. You can bundle them together in a Java Enterprise Application. Of course, if you deploy the JAR with a client in an EE Application, you now have two copies of your JAR on the server.

To avoid all of that, you can just use a context lookup for the JNDI name. However, the caveat of that is, your application client won't know anything about the JAR, ergo, it won't know the signature of the method, return type, etc... If you're in Netbeans, you'll get a real eye opener if you try to include the JAR file in your project. It seems like it knows nothing about the JAR you included. Mainly you'll get something like an ejb ref error or something of the sort.

The reason? The client application is running on it's own just like the JAR is. The two aren't talking to each other, except for the JNDI lookup. So basically you lookup a POJO but then you basically cast it to an unknown type. You need to let that type be known to your client, to do such a thing, simply copy and paste your interface file into your client project.

So let's write our client program, as you know we have our file copy and pasted into our project, so I'll just cover the main file.


package com.blogger.client;

import javax.naming.InitialContext;
import com.blogger.ramen.HelloRemote;

public class Main {

public static void main(String [] args) {

InitialContext ctx;
try {
ctx = new InitialContext();
HelloRemote hr = (HelloRemote) ctx.lookup("ejb/Helloness/HelloThere");
} catch (Exception ex) {
javax.swing.JOptionPane.showMessageDialog("Massive failure!");


And there you go. A full client to use our EJB bean. Deploy that to your Glassfish server and then use Java Web Start to start up your application. Presto! You have your client getting the implementation from your remote EJB.

I'll be back later, maybe tomorrow, maybe after the holidays, to show how to secure the EJB using a JDBC realm. Of course if you want to see how to implement the JDBC Realm in Glassfish take a look at this post.


Tuesday, December 22, 2009

Holidays are fun, but they sure do sap the time from you.

Promise to post some EJB code examples tomorrow.

Monday, December 07, 2009

Sorry about the Holidays

Well, I knew that the Holidays would keep me pretty busy.  I haven't gotten around to posting anything with all the running around that I've been doing.  I'll go ahead and post something here just so I can keep my mind fresh about having a blog.

Hope everyone is having a wonderful holiday season!  Cheers!

Wednesday, November 25, 2009

Inkscape 0.47 is HERE!!!

OMFGRTFBBQ!!! Inkscape 0.47 is here! This is hands down the best tool for SVG work, period! You can read the release notes here.

Biggest item on my list is the Spiro tool. This has to be the coolest tool ever. Instead of storing the object as a set of bezier curves, it is stored as a set of points with curves where needed. Trying to get perfect curves are no longer a pain in the BBQ. Just change the arrangement of control points and the curves form automagically. Perfect raindrops, vines, and more await you.

The Knot tool looks to hold a lot of promise. I hadn't seen the knot tool in the trunk code so it's appearance is new to me. The hatches tool looks very cool but I'm not sure where I'll be able to use it. The ruler effect is one that I have used often in the trunk code. It does what it says, offers the ability to draw a ruler on a path. It is very useful if you need to add scale to a project.

I can't wait to get my hands on the new release. I know what I'm doing this Thanksgiving weekend!

Um...Being with my family and thankful for the wonderful life I have (uh, yeah that sounds like it...) Just kidding I love you all family.

Friday, November 20, 2009

LoginContext of ACC or more?

Many of the questions I see on Google are about how to setup a LoginContext and then use that context to login to the Glassfish server. First off, the server already creates a LoginContext for you, you do not need to make another one unless you have some real serious demands. Second, when you do make a new LoginContext you are making it outside of the Glassfish server.

JAAS uses a set of local files to determine which Java Objects (modules) to execute in order to make a login. Those configuration files also specify which of those modules are required to send back a "GO" to equal a full login. This is called a stacked login. You could have an application that requires not only a username and password, but also a smart card inserted. If either or both of them return a "NO-GO" then you are denied access.

The thing about JAAS is servers are not the only ones that can use it. You could make your normal Java 2 SE program use JAAS to authenticate smart cards or even a flat file that holds encrypted passwords stored on the local machine. Because anyone could have any given set of configuration files setup on their machine, when you use Glassfish to secure EJBs understand that Glassfish considers the server's configuration files to be the final say in the matter of logging on to access the EJB.

When you create your own LoginContext in your client application, JAAS has to consult the local configuration files. Since a JVM outside of the Glassfish JVM is running your client application, these JAAS configuration files have no say in authenticating your client to Glassfish.

Enter the ClientPasswordLoginModule. This module is a pretty neat little module. It takes in a client username and password and stores it. If you try to go somewhere that requires you to login, this module will take the information that it collected and pass it on to the module asking for login information.

Here is where some people get confused. They assume that the local JAAS needs to use the same module as the Glassfish module. No. Becuase there is no way the Glassfish server can be sure that your local result would be the same result with the Glassfish configuration. If our Application Client used a jdbcModule in the local JAAS configuration, we could (in theory) use a local MySQL to say (Oh yeah, he's who he says he is.) Instead, we have to pass username/password information on to the Glassfish server and the Glassfish server runs it through its jdbcModule, not our local jdbcModule. ClientPasswordLoginModule simply passes that information on to whoever asks for it.

You may also have heard of a ClientCertificateLoginModule, this allows a client to send a X509 certificate to login to a system. Usually your appclient is setup to use both ClientPasswordLoginModule and ClientCertificateLoginModule. The ClientCertificateLoginModule doesn't really do much if you haven't signed the application. If you have, this module makes sure that only the application that was signed is being used to access the resources. This keeps rouge applications from accessing your data. If you want IIMOP over SSL that's a whole other thing.

Remember, when you create a LoginContext inside you Java Client Application it will read in the local JAAS configurations. Those configurations should be setup to pass information back to Glassfish. However, my advice is to not even create your own LoginContext. The ACC on Glassfish is good enough for most needs, you shouldn't have to create your own LoginContext. I'll cover a method of how to get a bit more control over user logins with EJBs on Glassfish with your plain ol' Java Application Client.

Thursday, November 19, 2009

What's wrong with me?

Okay now a little bit of Java code to get into the mindset of using Glassfish.

What is wrong with this code?


package com.blogspot.ramenboy.logintest;

import javax.ejb.Remote;

public interface SimpleMessageRemote {

String sayWorld();



package com.blogspot.ramenboy.logintest;

import javax.ejb.Stateless;

public class SimpleMessage implements SimpleMessageRemote {

public String sayWorld() {
return "World!!";


package logintest01;

import com.blogspot.ramenboy.logintest.SimpleMessageRemote;
import javax.swing.JOptionPane;
import javax.ejb.EJB;

public class Main {

private static SimpleMessageRemote s;

public static void main(String[] args) {
JOptionPane.showMessageDialog(null, "Hello... " + s.sayWorld());

The problem with this code is (we are assuming that all the XML descriptors are in order) that we are injecting an EJB that is protected. Now there is nothing wrong with injecting a protected EJB but we shouldn't do this in our Main method. Injecting secure EJBs should be done once we have established the user as belonging to the system.


If the user fails to login properly (mistyped something or what-have-you). The Injection fails and the end result is an unusable object. The object being the whole freaking program, since this is the main method.

Ergo, don't do this unless you are just writing a simple test. This isn't really production grade programming to inject secure beans all over the place. A failed injection will bring your application client to a grinding halt with a very confusing error.

Pretty Print Test

Okay so I chickened out and started using the Google CSS for syntax highlighting. Here is a test.

package foo;

public class Testing {

public static void main(String[] args) {
javax.swing.JOptionPane.showMessageDialog(null,"Hello, World!");


So I hope this works.

Tuesday, November 17, 2009

Chest Colds are the worst

I think the title says it all.  This would be the seventh time this year that I have gotten sick.  I can not seem to do anything in my personal time other than get sick and try to recover.  I swear, I'm going to post some python code soon.  I just keep getting sick.

Tuesday, November 10, 2009

Using the built in login versus ProgrammaticLogin

Yeah, I figure I'd cover a bit of Glassfish and JavaEE nuances. Today's gem is logging in.

When you think of logging into something you may have a sudden urge to think, "Yeah it's just a database with users and passwords stored in it."

To an extent you are correct. The broad 10,000 feet view of logging in is that you present something and that something proves you are who you say you are.  In some cases it is a password, some cases it may be a USB stick, and in some cases it may be something on you like your thumbprint.  However, the fun thing about being a programmer is that you not only get to deal with the details of where, what, and how idenities are matched with proof, you also deal with the way it is prosented to the user, interfaced with that presentation, handled during transport, how to transport, and so forth.  Basically you'll leave wondering how the API actually helped you.

But I'm getting ahead of myself, short end is that no matter what framework you use; be ready to do a bit of leg work when it comes to logging people in.

Now on to the topic at hand.  In JavaEE there is a set way of how to handle logging in to an AS.  This method is known as JAAS (say it with me: Jazz).  Without going into what that means (you can safely assume that the J stands for Java) JAAS is the standard built-in method for logging into an AS.  Now JAAS is great and all but it was mostly intended for web based applications, so if you are doing a lot of web based apps then just sticking with the default JAAS won't do you wrong.

Therein is the problem, if you are doing Client Application programming (thick clients) you may seek to have a bit more control over the login process.  JAAS is an okay solution, and you can work around some of it's limitations, but after a point you're just boiler plating and you need to stop.  One thing about JAAS is that it is specific to the Application Control Container (ACC), that's not to say the code isn't cross platform, it means that the ACC handles login, not you, you have to keep poking at the ACC for information about the current state of the login.  This simplifies things at an amazing rate.  You can have a databased back login module in less than five minutes.  In fact you'll spend most of your time with SQL.  The problem is things like making sure the person provides a valid login add complexity because the ACC will toss an Exception at you and your client will receive a very cryptic error message about RMI-IIOP.

This is all because when something bad happens you can't trap the ACC (that's a good thing security-wise) and therefore authentcation errors blow up your client.  You have to write EJBs that force the system to log you in and then before actually using that login check to make sure it is okay.  This can add a bit of overhead in Client Applications...

Enter ProgrammaticLogin.  The purpose is pretty stright forward, handle logins programmatically.  Two problems with this approach, this will lock your code (once you start coding for ProgrammaticLogin you are locked into Glassfish with you code sans a major rewrite); second, you must handle everything about logging in yourself.  ProgrammaticLogin is lock-in for every platform, yes that's right, everyone has a ProgrammaticLogin (JBoss, Oracle, IBM, etc...), every single one of them makes it look the same (takes two to four parameters, passes information on to EJBs, etc...) but they all do it very differently per AS platform.  Judging by history, this makes it a good candidate for inclusion in the next version of JavaEE (???).

I guess I'll cover a bit about logging into an AS next time, I'll cover JAAS first.

Monday, November 02, 2009

Things not to do on Blogger when at work.

I'll try to keep updating this list as I go.
  1. Click the Next Blog link.
  2. Go to a blog that I know is going to have background music.
Holy smokes! Did you know it was November already?! Crap I've got so many car related things to get done it's not even funny.
  • Fix my car.  It's got a stuck open thermostat that makes the computer send P0126.  That's a you fail emissions error.
  • Inflate my freaking tires!  I usually am on top of this but the blasted air machines taunt me by accepting only quarters when I have a ton of dimes!  This also, by-the-way, sends a you fail emissions error.  In fact, every error on my car is a fail emissions error except low oil and low freon.  WTF?!
  • I turn an age evenly divisible by five this year.  That means that I have to pay to continue to keep my drivers license.  I don't really understand the point of this.  They don't require that you come in and have your eyes checked, your ability to drive checked, or anything that would ensure that you are still able to drive.  In lieu of all of that safety stuff they just want you to mail in a check and a form that ASSERTS that you still feel able to drive.
  • My son will be turning, an age that is a single number in binary, years old very soon.  I've so got to get planning and sending out invites done like it was yesterday.
  • I am so carpet bombing my friend's place.  He has consistently held the pieces of wood that I am using to make shelves for ransom.  He has until this Friday to return them, or I am getting 2,4,6-trinitrotoluene on his rear end.
See, this is what happens as you get older.  As a kid you loose track of time on a smaller scale, say minutes or even hours.  As an adult the same thing happens just on a larger scale, say days, months, seasons...  I guess it all just comes down to simply forgetting what year, century, millennium your currently in once you're ready to retire.

"What?! OH?!  Why are you grabbing me by the arms and dragging me out?!  What do you mean I retired seven years ago?! Let go of me right... oh forget it, I need a nap."

MS Access and the Gettoness that it is.

Why on Earth would you have a cross-tab query with no "non-VBA" method of making a report?  Oh well is guilty of the same crime.  C'mon, if I'm doing this with GUI magic in the query editor, why can't I do this with the report editor.

Well off I go to write about 400 lines of VBA code that no one will notice.  Nah, just kidding, it's only like 40 lines.

Code and Pre Tags


Usually when I do some code, I just really place it between some <pre> tags. If it will have a lot of < and > symbols (like C++ code). I'll do the code really quickly in gedit and replace them with the entities that correspond to them.

However I was on Microsoft's web site and I really liked the idea of how they surround their code with a little blue box with a bigger top border.

Now using Firebug to look at the CSS for this, it is a really simply addition to what I was doing.

This is what I was doing...
<pre style="border:1px solid #8888FF">

However, as you can see in the above example, I'm using a similar usage of the MS CSS except I've made it green as such:

This is my new take.
<pre style="border-style: solid; corder-color: rgb(192,231,192); border-width: 10px 1px 1px;white-space: pre-wrap;word-wrap: break-word;">

Also I've been trying to understand how ScribeFire works with <br />. I am still working on it. Also, I will try to get my own CSS written and uploaded to Blogger when time permits.

Sunday, November 01, 2009

VirtualBox I still love you

Well it seems I'm running into a problem. 64-bit guest won't seem to go into long mode on a 64-bit host when AMD-V or Intel VT isn't available. That's okay because VBox still rocks.

Thursday, October 29, 2009

Getting LDAP Ready.

If you've never installed a LDAP server don't worry, its very easy. I like to install via source instead of grabbing packages from repos. You can find the directions for getting started here.

Just so you know, the rootdn (owner the root user for LDAP) can be named anything, in fact I suggest you use something other than cn=Manager, since a lot of people look for that in new LDAP installs.

Also please read up on the Access Control chapter before you go off leaving your LDAP server running for any length of time. Understanding the ACL of LDAP is a little tricky at first so go over it a couple of times just to make sure you have it. It should be understood that most users will need to connect to your server to get login information. Crazy enough, LDAP supports a type of permission called "auth". This allows an unknown client to query the LDAP server but only receive a connection or nothing from the server. This way a client can transmit a query with user name and password and hope that a connection is returned.

If the idea of having unknown people query your LDAP server bugs you, you can always setup a Kerberos server to handle the authentication of users, I'll get to that when I cover SASL. If fact, in some contract jobs with the government, you are legally required to have an external authentication service.

Well I'll fire up VirtualBox and begin doing some LDIF entries into LDAP and then some python code.

What is LDAP and Friends

LDAP stands for the Lightweight Directory Access Protocol, you can read more about it here.

Barring that, I'll give you a really quick run down of the history and uses of LDAP. LDAP is the Internet version of the X.500 Directory Access Protocol (DAP). In the beginning there was DAP, and no one used it (except maybe a couple of companies and the government, oh and Outlook as well.) DAP used the full OSI protocol stack which, in short, is seven layers thick. The Internet runs on a slightly lower calorie protocol, weighing in at four layers. Now one can transition between the two quite easily.

(NOTE: When people hear OSI they think OSI Model, there are also a ton of ITU-T papers that actually define a real set of protocols, you can check them out here.)

So at any rate, X.500 defined this whole suite of protocols that allowed globally unique messaging and directory services (basically the precursor to email and a global phone book for all those email accounts.) Needless to say this was a pretty lofty goal. Moving on, some companies actually implemented OSI and started using X.400 (mail) and X.500 (directory) for company mail. Then along came the Internet and suddenly DAP and all related technology found itself isolated. Enter LDAP, whereas DAP was made to use a seven layer protocol, LDAP was made to use TCP/IP. This includes IPv4 and IPv6 and TCP and UDP variations. It is important to note that LDAP runs only on TCP/IP, so if you are using an IPX/SPX network then you will be using something like NDS (Novell eDirectory) which is a X.500 implementation on IPX/SPX (NOTE: NDS doesn't do everything X.500 does, but neither does LDAP).

Since LDAP was made to use the protocol of the Internet, and the Internet has become so wildly popular, LDAP has become a very popular replacement for X.500 installations. The rest of the history of LDAP isn't all that fascinating so I'll leave at that.

So what is LDAP used for? Well it can be used as a limited gateway to X.500 directories (and for a lot of large companies that is exactly what it is used for) but also it can be it's own trimmed down X.500 directory. Trimmed down because LDAP doesn't implement the parts of X.500 that rely on the OSI protocol. So what is this directory? Well it is basically a database that houses user information. Usually the LDAP database is optimized for many reads and few writes and usually doesn't implement things in a relational manner like an RDBMS. Instead, LDAP is tree like and the database is optimized to think that way as well. LDAP is also good at storing user information that can be used on the application side. A RDBMS usually has data types that you store into it, an LDAP has a schema that is more role based as opposed to data based.

As an example, an RDBMS would have a user name and password field for user logins. LDAP would have a user schema that stores user name and password. Not much difference really but the schema is mostly role based, as you can imagine you can find a role that fits your needs from the IANA and add that to your LDAP server to fulfill that role. It makes a lot of sense when you get more complicated examples like a FedEx Account Contact role versus (FULLNAME, ADDRESS1, CITY, STATE, ZIP, ACCOUNT, ...) like you would find in a RDBMS.

Also, LDAP is tree like in nature. To implement the same ability in a RDBMS you need at least two tables, one to hold the normalized data and the other to add the structure you need. So you may have a list of contacts: in a LDAP directory each branch may separate that contacts role in your company; in a RDBMS you would need another table describing the roles and who belongs to them. I know it's not a big difference but it makes all the world of difference when you try to make optimizations and LDAP generally requires less administration and complex layouts.

So what role does LDAP play in the real world? Usually it stores user information, logins, contacts, and so on. Basically the same kind of information you might find in a phone book sans the whole computer aspect of it. This is really important in the real world as it allows people to centralize user information. Allowing only a few trusted sources to edit the data and allow the rest of the users to use it while conducting business. Think of it as a company wide Roladex. Because it stores contact information it can also store login information (basically a list of contacts that work for the company). The LDAP server can tell the difference between the role of "Standard-Contact" and "Employee-Contact". The standard contact might just have the regular information you'd expect, but the Employee contact may have everything a standard contact has and also have a password and username field within it.

I hope this gives you a better idea of how LDAP works in the real world. LDAP stores user information and anything that you might be interested in storing for that user (notes, bookmarks, appointments, etc...) It's not a replacement for a RDBMS, but it is a good solution for the purpose it was written for. If you find yourself building an application that doesn't need RDBMS but needs millions of reads and very few writes, LDAP would be a good solution for you.

Wednesday, October 28, 2009

LDAP and Python

I have no idea why I am so attracted to LDAP. At any rate, I'll be over the next couple of weeks posting some LDAP python work that I'm doing. Here is the python library that I'll be (and most people) using. I figure it was time that someone made Yet Another LDAP GUI Tool (YALGT).

Nah I take that back, that sounds way too much like YAST from Novell.


I love the web proxy at my company. Basically it is useless. At any rate, since I can not use the web interface on Blogger, I've started using ScribeFire at work to publish post. Right now my views about it are mixed. I just have a funny feeling about it because it has the little logo in the top right corner.

Why is that a big deal?! Well ever since we left the era of Netscape Navigator, I haven't seen the logo in the top right corner in some time, except for adware. Therein lays the point. The add-on reminds me of adware. So I'm a little cautious about it.

Also the <br /> in ScribeFire acts weird and sometimes it tries to add a <div> that adds a invisible tracking pixel to my blog. (Which reminds me I've got to go through and make sure I removed them all).

Anyone know this person?

Don't know anyone per se in Canada, but it is at least worthwhile to re-post this. Please help find this person's family

Pitfalls of AS400 and MS Access

Where I work we have an AS400 system that provides our DB.  However, our IT admins decided to use a rather uncommon naming scheme. Our Libraries "folders if your looking for a Windows equal" have a period in their name.

Well you may, or may not, know that the period is how the AS400 system tells the difference between a library and a member when using the *SQL naming scheme. So usually you have something like this:


Then you have the FNTUSR library and the ACCNUMB member of that library. But if you have something like this:


You basically have garbage, at least as far as ODBC goes. The problem actually lies within the ODBC driver that IBM includes. It doesn't follow the same resolution method as the actual AS400 system, maybe because it is local and ODBC is remote but details aren't really that important. The ODBC driver goes out and yanks the CHK member during the resolution and asks for the BILLNO member, skipping completely the ENTR part of the name.

Needless to say this may prevent you from using ODBC to connect to the AS400 system. If there was only a way to pass the name as one chuck so that the ODBC driver would stop parsing the second period and placing the resulting token in the garbage.

Oh wait, there is...

The wonderful world of Microsoft allows you to pass a chuck of information into the ODBC parser, bypassing the tokenizer, by surrounding it with quotes! Hooray! But wait! In addition to the wonderful-ness that is Microsoft. None of their GUI offerings allow you to give quotes (except Excel, go figure). So if you are wanting to connect to an AS400 system that is administer by half witted admins that place extra periods all over the place in an AS400 system (look *SYS != *SQL, you can not use *SYS when you are brainwashed into thinking that it is the same as *SQL). You will need to go the VBA route (hooray... please shoot me now).

For those of you not really familiar with the VBA way of doing things, it involves a lot of pain. Please observe (I've named the DSN as400_connect):

Public wspAS400 as Workspace
Public cntAS400 as Connection
Public dbAS400 as Database

Public Function IWroteThisFunctionBecauseOurAdminsAreDumb()

Dim qryDef as QueryDef
Dim rs as RecordSet
Dim SQLString as String

On Error GoTo ConnectionError
Set wspAS400 = DBEngine.CreateWorkspace("idiot", "", "", dbUseODBC)
Set dbAS400 = wspAS400.OpenDatabase("idiot_db", , , "ODBC;DSN=as400_connect;DATABASE=SM456J12")
Set cntAS400 = wspAS400.Connections(0)

On Error GoTo QueryError
Set qryDef = cntAS400.CreateQueryDef("", SQLString)
Set rs = qryDef.OpenRecordset

DoCmd.SetWarnings False

'Insert you records into you MS Access DB here

DoCmd.SetWarnings True

MsgBox "Something got F***ed up!"
GoTo CleanUp

MsgBox "Something got F***ed up!"
GoTo CleanUp


On Error Resume Next

Set rs = Nothing
Set qryDef = Nothing


Set cntAS400 = Nothing
Set dbAS400 = Nothing
Set wspAS400 = Nothing

End Function

That should get you started on getting crap out of the AS400 system and into your MS Access database. Notice that I am using the *SYS naming scheme. Try both the *SYS and *SQL naming scheme (library/member, library.member) to see which one your AS400 system is using (or at least will resolve). You can change that bit of information in the DSN entry on your system under ODBC Administration in Windows.

PS: Please make sure you have the damn ODBC driver from IBM before you even try setting up the DSN.
Testing from work!

Saturday, October 24, 2009

I have a problem

I think you can see what it is:

I'm more upset that they didn't show the peas being eaten as well.

<?xml version="1.0"?>

<m:RSVP xmlns:m="http://justy.yogabagaba.lan/partyparty">


<?xml version="1.0"?>

<m:GreenBeans xmlns:m="http://justy.yogabagaba.lan/partyparty">
<m:Message>I feel your pain</m:Message>


At least that's how I see a SOAP based conversation going.

USB Zebra doggy style

Do you have a Zebra printer that has firmware restrictions? I'm looking at you FedEx!

Well, most FedEx printers with custom firmware (99% of them) still understand raw ZPL II commands. If you have a dotNET or Java application that is sending ZPL II commands to the printer then you already know that the parallel port is the easiest way to do it.

But let's say that you code with the assumption that you'll always be on a parallel part and then suddenly you find yourself toe to toe with a locked up FedEx Zebra (Z4M is the one I seem to be running into lately).

These printers are USB and using the dotNET stack to send USB ZPL II to the printer is not only a headache, but you'll have a better chance to make PNGs and send them to the printer to be printed.

Instead, setup the printer to have a network share "we'll say Printer in this case", pull up a command line in windows and chant the following words:


Ta-Da! Now you can send ZPL II to a USB printer via the usual raw data port API Stuff. This also has the happy effect of by-passing evil FedEx firmware locking out stuff thingies.

JSF and beyond

As far as intros to the Java EE go, once you understand the idea of JSP you just start adding layers.

JavaServer Faces (JSF) uses JSP to dispaly pages, however, instead of messing with the URL or setting cookies to keep track of your session, JSF adds Java objects to keep track of that. The objects are Java Beans (not to be confused with EJB) that provide a layer between the JSF container and your Java objects.

That's right, JSF is a container that runs inside a web container. You might think that this would add a ton of overhead, but you'd be surprise at what they squish in there.

JSF was based on the ideas of Struts from Apache. Struts brought a MVC container to the web container. The ease of MVC made people go ga-ga. In the end the number of layers and MVC frameworks exploded. So it would be difficult to try and cover them all. I am going to focus on ICEFaces here on my page since that is what I use.

JSF is an awesome method to make web based applications and over the next couple of posts, I'll show some basic uses.
Maybe it is because I have a kid that this seems all the more funnier.

At any rate this is very wrong and do not play this in an area where others can hear it. I can assure you it will offend.

I think the best part is that the Nick Jr. is visible even in the lil' Jon parts.
Update: So Lazy Town Entrainment decided to enforce their copyright claims on the last video, so par for the course someone re-posted it. It's a shame that Google has no backbone.

Monday, October 19, 2009

JSP and Java EE

If you are looking for a good intro into the semantics of JSP then may I suggest here.

So what are Java Server Pages (JSP)? If you have done any work with PHP then you'll be right at home with JSP.

JSP is a method of creating Servlets with specially formatted HTML pages. You add in Java code scripts inside tags delimited by <% and %> (properly called: scriptlets I know, I find myself calling them Java Script sometimes too, but that's a whole different thing)

Expressions, one line shots of Java code that return a String, are encapsulated in <%= %>

Here is a quick sample of the two intermixed:

int j = 0;
while (j != 12 {
<div style="border:1px dotted #338833">
This is line #<%= j %>
</div><br />
<% } %>

If that brings up memories of PHP, you wouldn't be the first. JSP also adds Directives <%@ %> and Declarations <%! %>. The latter being important because this is how you add methods to the servlet that will be created from your JSP.

The servlet that is created for also has some special data members added to help you out. The tutorial covers how to use these quite well. It is important that you use these members because most of the time you're JSP is assumed to be thread safe (try not to break that assumption.)

The really cool thing is JSP tags! Unlike PHP (but like ColdFusion, if you've ever used it) you have access to a tag library. These tags quickly provide functions that you're most likely to use (like include another page.) You can also write your own library of JSP tags to encapsulate logic in your pages. This effectively allows you to separate logic from presentation (the ultimate goal in web application.)

But this brings us bark to the idea of MVC vs. Three Tier. JSP acts as our presentation in Java EE, however JSP brings us almost too close to Three-Tier design. Things that you want to go from page to page (shopping cart contents come to mind) have to either be pushed down to the database or passed through cookies/URL. This can make a lot of developers feel uneasy because it is a lot of work for such a small gain (easy presentation of Java objects.) If only there was a way to keep the ease of MVC design, have the ease of JSP presentation, and still have the flexibility of Three-Tier design.

Lucky for you, there is. There has been a lot of Java community members banging their heads over this, and over the years it has yielded about a dozen or so very mature frameworks. All coming together in the Java standard call Java Server Faces (JSF).

As you can see JSP offers a very powerful method of building presentations of Java objects. Many companies use JSP as the display end of their products. Later I'll cover JSF and show you how to bring the ease of MVC design into a Multi-Tier development platform.

Sunday, October 18, 2009

Going easy on the breaking return!

Wow I looked at my post on servlets and I see that I need to lay off the <br /> tag for awhile.
If you haven't guessed from the avatar, I'm a fan of family guy. I know I'm so original.

Servlets are the starting topic when covering the Java EE platform. So let's begin.

In a Java environment you have three key pieces to making your program run.

  1. The Java Virtual Machine (JVM)

  2. The Classpath

  3. The Class loader

The class loader is the important one here. It is the job of the class loader to get your Java class loaded into the JVM. This is much the same as a loader for an OS.

The Class Loader is "boot strapped" by the java command line utility. This is all fine and dandy, up till you get to a point where you need classes loaded by a remote client.

Enter the container. The container is a concept much like the class is. A container is a class that loads other classes, much like the class loader. It can other things as well like support LDAP security, email users, establish an SSL connection, manage database transactions, and so on. The container is limited by the scope of the system class loader, but the container can load classes based on whatever rules it provides.

Much like a class hides data members from the programmer, containers hide the method of invocation for classes loaded into it. A web container gets an HTTP request and loads Java objects in response, it doesn't really matter how it goes about doing it.

Servlets are the base of the Java EE model. They are invoked by an HTTP request, by means of a web container (see above). Servlets implement the Servlet interface which allows a container to invoke and maintain the life cycle of the object. More than likely you will be looking to extend the javax.servlet.http.HttpServlet class. This class comes with pre-built methods to handle the common HTTP request. Such as:

  • doDelete - to handle the HTTP DELETE request

  • doGet - to handle the HTTP GET request

  • doPost - to handle the HTTP POST request

and so on... Each servlet that you create translates into a web page. Each method implements logic to handle a type of request. You'll be spending the bulk of you code in the doGet and doPost methods.

Working with the base servlet model is not the idea tool for interactive web pages. Basically you are writing a web page in Java as opposed to HTML, which adds to the complexity. Using the base servlet model is good for operations that you really want fine grain control over the entire logic flow. Here is an example of a servlet. You can readily see that we're just writing a web page within Java.


import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloWorld extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

PrintWriter wout = response.getWriter();

wout.println("<html>\n<head><title>Hello, World!</title></head>
\n<body><h1>Hello, World!</h1></body>\n<html>");

As you can see this isn't exactly the greatest model. That's where JSP comes into play, but I'll cover that later. For now, you can see that a servlet allow fine control over what type of request will cause what action, but it is a lot to be asking you programmers to be Java/Web/Http experts all the time (ie, you could not manage [reasonably] a web site strictly made up of servlets.) Usually you will reserve servlets for testing EJBs and stuff that requires fine control over the process. You'll mostly use JSP/JSF for all other stuff.


Thursday, October 15, 2009

Hello from BloGTK

Hello everyone. I'm trying out BloGTK as a client to Blogger. Mental note, SVG rendering will crash the program. So this is my second go at this post.

Pre-formatted code:


int main(int argc, char * argv []) {

std::cout << "You entered " << argc << " CLI arguments. They are:" << std::endl;

for(int x=0; x<argc; x++)
std::cout << argv[x] << std::endl;

return 0;

Thank you and now a random image.

Java EE 5 Development using GlassFish Application Server cover
Understanding OOP pitfalls in Java EE:

Object Orientated Programming (OOP) is the foundation on which the Java language is built upon. When you build a Java program you are building a set of objects that will work together towards a goal. This brings me to the first point: in Java EE it is important to remember to think of the object and not the task.

A common pitfall is to start adding logic into a class that broadens its scope. Remember, objects should be single shot, single idea things. Let's say you have an object call BankAccount. You would put into this class the account number, the account name, address, details, balance and so forth. However, you may be tempted to place logic that converts the object into, say a SQL string or properly formats an address for display in a GUI. NO! Do not add logic to the class if it does not need to be added to keep the concept that the class represents, sane. A bank account does not need to know about SQL, a bank account does not need to know about GUIs.

The reasoning behind this is that the Java EE platform takes a lot of the bridge work out for you, you adding it back in prevents you from fully accessing all of the features (besides if you're adding them in who is Java to tell you wrong?)

Complex logic goes into classes that will handle other classes. In the example above you might include the BankController class. It will be this class' job to gather the needed objects to handle the object you pass in. The BankController
class may need to gather the objects that handle permissions, validation, database connectivity, and so forth. The Java EE platform has this covered for you. So you just worry about modeling classes after the real world thing they represent.
MVC, why is it so important and why n-tier matters:

If you've been programming for a while, you've undoubtedly have come across the Model-View-Controller (MVC) design pattern. When I started programming my code started out as just one long procedural call, the "everything in the main function" design pattern. As I got better with programming I started breaking logic into different functions and calling the functions. Eventually, I got to Object Oriented Programing (OOP) and began the path of looking at programming not as a bunch of steps that need to take place to reach a goal; but instead as distinct ideas and concepts that put together, made a program.

The MVC design pattern was developed to give developers a way of looking at a problem and separating common areas of a program. Basically, a program has to deal with the end-user and a database. We could easily design a monolithic program that did the task, but if something changes in the database, then we need to modify all of our code (or at the very least hunt down the section in our code that deals with the database) to adapt to the change. Logically speaking, it wasn't long until people started to understand that the user interface should be a separate body of code from the part that deals with the database. As user interfaces got more and more complex, the logic that handles validation and talking to the database module had to be separated too. Thus was born the MVC design pattern. In essence, gurus would preach the divide and conqueror technique of MVC to new developers in hopes that they would start their programs in the vein of MVC. This way as the program evolved, it evolved with ease.

However, there is one fall down to MVC. It assumes that all things are on the same machine. When we start connecting to a remote database to update our view, we start getting into handling SQL statements, exceptions, invalid return values, and many more issues (does NULL mean that the line should be blank or does it mean invalid?). The view is not the place to handle this type of code, or at least if you want to keep things simple. Thus, people holding to the MVC design pattern have created ways of wrapping database connections into convenient APIs that handle the mess, so that you can devote more time to making a good user interface.

It's a nice thought, but it only goes so far. Just pick up a book on MySQL and PHP and notice how many times they suggest that you just ignore exceptions. Eventually, way back in the day don't let me make you think that this is a new development, it was understood that one machine just couldn't run everything (contrary to IBM's claims), and thus we embarked on a mission to find a way to make a program run on multiple machines. Enter multi-tier design patterns.

At first, people used messaging systems to communicate between different machines. Think of it as Bob's copy of program A is running on Server A, Jane's copy of program A in running on Server B, and so on. Server A and Server B talk to each other to keep data in sync using a messaging protocol. This was an alright solution, but it really didn't get far from the MVC way of looking at things. It was also a waste of resources, the View didn't use as much resources as say the Controller; the Model used the most disk space; the View was limited to the interface capabilities of the machine holding the Model and the Controller. Basically, if your database had eaten all of your hard drive, you upgraded the drives; controller eating all your memory, you added more. It would have been better to place the Model on a machine with tons of hard disk space, the Controller on the fastest CPU, and the View on a system that supported familiar GUI elements.

Multi-tier design patterns were developed to allow each layer in the tier (Presentation, Logic, and Data) to run on different machines. Some used proprietary protocols to achieve this (SNA comes to mind). With the advent of the Internet, the standardization of TCP/IP as the protocol of choice, Microsoft bringing open network connectivity (I know, who would have thought), and the desire for things to be less single vendor and more heterogeneous, new methods would need to be put into place to actually implement multi-tier design patterns.

This is where multi-tier underwent its first redesign. Now instead of assuming that the protocol would be packed with the vendor, multi-tier patterns had to abstract protocols altogether; in essence the developer shouldn't have to worry about the protocol, as long as the program can see the server everything should work. While we haven't gotten away from the idea that a program is tied to a protocol (Web browsers still assume TCP/IP as the transport), we have made progress (Web browsers can used IPv4 or IPv6). So it's important to remember that multi-tier is still protocol dependent, just now you don't have to worry about directly working with the protocol (unless you really want to!?).

This redesign is what gives us the model that we all know and love. It breaks the way an application works into three parts. Presentation, Logic, and Data. At face value it looks a lot like MVC, and to an extent it is. However, in a multi-tier application the Presentation is assumed to never talk to the Data, all things must pass through the Logic layer. Where as in MVC, the Controller provides input to the Model, and the view gets the output of the Model. This is the fundamental difference between the two.

In MVC your View must deal with the data straight from the Model. In multi-tiered applications the Logic formats the Data into something that can be Presented.

In MVC, your web designers must know what kind of assumptions should be taken on data from the data source and how to issue the commands to get that data.
In Multi-tiered applications, the Logic handles all of this, your web developers simply access the properties of you logic (much better to write something like #{shoppingCart.orderNumber} versus SELECT ORDERNUMB FROM ORDERS WHERE SHOPPINGCART='cartnumber';).

All in all, multi-tiered design patterns have been developed to make use of multiple machines, abstract protocols from developers, and allow specialty developers to concentrate better on the task at hand. I know that some people still have the notion of what three and four tier development was like in the 60's, 70's, and 80's (which wasn't good and took long amounts of time to deploy) but the methods and tools have been refined to a point to make multi-tier more like Rapid Application Development (RAD) software. Simply put, MVC is an easier model to work within, but Multi-tier is continuing to keep the pressure on MVC as an easy model to develop within. Multi-tier isn't like it was back in the day, it has mature enough to be seriously considered before you begin your next enterprise application.

Wednesday, October 14, 2009

Logic, Database, Your customer:

That's the basic breakdown when it comes to providing central application services. You centralize the applications so you don't have to network share every single application you want your clients to use (it just doesn't look professional).

When you centralize your applications in your company, you add many different complex challenges to providing those applications and keeping things manageable and agile.
  • How do we secure our applications?
  • How do we make them available to the clients?
  • How can we remove redundant functionality?
  • How can we simplify the deployment process?
  • Database, logic, and client...Oh my!
If you come from a LAMP or RoR background this may all be very new to you. Basically the setup works as such:
  1. The client (web, thick, thin, or services) calls up an action like: *Create new shopping cart, *Add product #23, #46, #107, and #428-A to the cart
  2. Check out using the following information: (name, address, CC# etc...)
  3. Send back the result of the transaction.
In LAMP and Rails one would have web pages that implement the logic of connecting to the database, validating the information, managing the session, and so forth. Basically all the logic is in the web page.

In a multi-tier environment, you have separate processes that manage all of that. You have a web server that sends out the web page, you have an application server that handles the logic of your session and validating values, and you have a presistance layer that handles the logic of connecting to your database. Each layer can service any other application as well. You build the logic and use it in every application where it is needed.

This simplifies management because now you can take a project and break it into many smaller parts, instead of passing around one large PHP file with about a dozen includes.

It makes sense to break your large projects into smaller more manageable chunks. It's nice to know that you can write and execute common code once, instead of writing 30 or so include file and having who knows how many threads of execution going over the same include file. With a multi-tier platform one can manage the ever increasing demand of constantly growing flat file systems, add new features without major code surgery, and reduce the amount of covering the same ground (not only in code, but in CPU cycles as well).

Giving credit where credit is due, RoR is really starting to mature in the MVC realm of web frameworks, but it still has many short comings like reducing number of threads doing the exact same thing, or rich messaging between processes (however they do have a nice RESTful services API, but so does Java and dotNet).

In the end, modern web application frameworks provide robust one shot solutions to many problems, but as your demands grow managing those applications becomes harder and harder. Multi-tier applications make it easy to scale to large deployments with a little investment up front. Modern multi-tier has come a long way since the days of spending months on each single layer, frameworks have become more compact and interchangeable, providing quick application development, testing, and deployment.
Java EE 5:
I'm really big into Java. I know a ton of people boo Java because they think it is slow or some other reason. I'm here to tell you that Java is very prevalent and very useful. Many websites are powered by Java EE and with good reason.

Over the years Sun and the Java Community have added really exciting technologies to the Java Platform. Some have seen their day come and go, but many have really useful corner cases. However, the best platform I've seen in some time is the Java EE 5 platform.

Java EE is one of the few multi-tier application platforms still in town. The really hot craze right now is your good old LAMP stack or RoR. However, these approaches return to the days of monolithic hosting of network applications. This approach is nice for small to medium deployments, but without some serious modifications, do not scale well in large deployments. This is one of the reasons why LAMP has taken off so much, the stack is completely open source, so modifications can be done on the code easily to adjust to large deployments.

Multi-tiered software was made to scale. It has lost favor since it takes a lot of resources to get started at first (due mostly from configuring and creating the first bits of each layer.) Java and .NET have taken steps to address this large problem, how do we make multi-tiered APIs but still make it easy for small deployments?

Java EE 5 and the future EE 6 bring a lot to the table to make it easy to stop boiler plating things and start deploying services to meet your customers demands. I know it sound a lot like a big commercial.

Multi-tier software has gotten a bad rap from things like DCOM and CORBA. But if you sit down and try Java EE 5, I'm sure you'll see that multi-tier has come a long way from where it was.
Blog Restart ver. 3.0:

Yes, I'm restarting my blog. Let's see what happens.

Tuesday, June 09, 2009

Wednesday, May 20, 2009

A pointer to something that needs to be constant.

I've seen this code before...

type *getNodeList() const;

The problem with it is that it should not compile. The reason?
The "const" at the end of the method prototype says that you wont change *this. However, you are giving no guarantee that you'll keep this promise because you are returning type *.

For all the compiler knows, you're going to be an evil person and use the pointer to change *this. However, some compilers give you the benefit of the doubt and will happily compile this for you.

Thankfully, gcc is not one of them. For this to compile you have to ensure that you won't change *this. To guarantee this you need to make the pointer a constant type, type const * (I like this method of placing const to the right of the type but const type * means the same thing so it's no big deal.)

Therefore you get.

type const *getNodeList() const;

This should compile because you now have enough guaratees in place that the compiler will trust you. Of course you can override this type of behavor but I don't recommend it.