Working on a neat project

Usually I have the most fun with design and coding. Rarely do I go back and play with the UI in the sense of having fun with it.

It's just mostly checking if the UI is okay and if there are any bugs/misspellings.

Well I've just got a project that I'm having fun with the UI as well because the interface is a Text based User Interface (TUI, if you are so inclined to use that).

It's cool using JCurses. JCurses is a very loose JNI for the Curses environment, nCurses on Linux. Since it does use JNI that means that you do loose the cross platform compatibility, but JCurses comes with sources and Win32 and Linux x86 binary libraries.

I've been able to compile JCurses for Linux amd64, Mac OSX, and PPA systems. So you should be covered for systems that you may want to run this on.(Note: I don't have access to an ARM chip so I don't know if you can use JCurses there).

The setup at work is to provide a SSH session via RF scanner to our warehouse users, noting new there we've been serving TN-5250 sessions via wireless for the past fifteen years (longer than I've been there).

However, this is the first time that I've actually been calling EJBs from a text based interface. The principal is basically the same, call the remote endpoint from the Java code, present results bark to user.

The fun part is with a text based interface, you really have to concentrate on features and how you present them. A screen full of text is impossible to use effectively, and the more options you present at once the more cluttered the screen appears.

I've found that the best way to break up things is not present all the needed input at once, but instead to take an ask on need approach. So when the next step is to get an EAN or UCC128 code that's what you ask and only that and the options that might effect that.

Also, keyboard functions are limited to basically, TAB, ENTER, F1 through F4, the numbers 0 through 9, and BACKSPACE. Obviously there are no mouse functions.

All of this, limited input, limited screen size, and limited ways of getting the user's attention (Curses can only ring the system bell) really forces you to really think out the UI in a manner that end users usually can't help with.

That's not to say that I never think of the UI for GUIs, but usually we have a company layout and guideline on how our GUIs are created. You simply follow that, get end user feedback, and modify as needed without breaking something.

I'll have to post some examples of JCurses and EJBs soon.

Heading on the road, again.

Well.  I'm heading on the road again.  Travel sucks and double much when it is business travel.  The hope is that this round is my last round for a good bit of time, until next year.

At any rate, I've really got to get back to blogging because I enjoyed it so much.

I've had time in the air to think of some little projects that I'd like to do personally on my system.  I'll have to share them when I'm not in the air.  Also, trains suck.  It never fails that I am delayed twenty minutes going to anywhere by a train crossing.  Just yesterday while going from one building to another I wasted forty-five minutes, the break down is as follows:

1. Rail construction, the construction train was at the crossing on Highway 11.  Wasted 23 minutes.
2. Slow moving train coming back via different route.  Wasted 17 minutes.
3. What the heck! A mostly unused train track is being used to move cargo into a rail-yard. Wasted 9 minutes.

That last one was just to spite me.  I think CSX personally has a vendetta out on me.

Well I'm off.  Cheers!

Where I work trains are a big problem. they can take up to fifteen minutes some times like this guy.
From my phone.

Yeah I know. I've been on the road for company related stuff.

So I've shown how to add security annotations to a pretty vanilla EJB. When you develop EJBs remember to keep them limited in scope. For example, if you have an EJB that handles Inbound orders (placeOrder, reviewOrder, cancelOrder, addToOrder, removeFromOrder, etc...) do not feature creep by having that same EJB handle Outbound orders or worst yet schedule orders in a calendar app.

I cannot tell you the number of times that I've run across an EJB where 30% of the code really belongs in its own EJB unit. For example the calendar app should view Inbound orders as a Collection not as a derived member called SchdOrd (PS use freaking descriptive names! The next guy will not understand that OrdTckChcExc is short for Order Ticket Cache Exchange; nor will that name mean anything to them.) A calendar *HAS A* Collection of Inbound orders makes more sense than A Scheduled Order *IS AN* Inbound Order.

The reason it makes more sense? Just because something is a something else does not mean that the logic for the unit is clarified by the statement. The statement only implies a date an doesn't do a very good job of telling anyone what that date means to anybody. A calendar (thus we get the date concept) has a (okay that tells us something about storage) collection (alrighty this tells us that we are going to be looking at a lot of similar things at once) of Inbound orders.

As you can see the HAS A statement tell more about the underlying logic than the IS A statement. So, more than likely by Justin's 23rd rule of programming, the logic will be easier to implement.

I'm getting off on a tangent here, sorry.

Next post I'll cover using a JAAS callback to implement acustom login dialog and how to handle a failed login, yes you do have to handle those Glassfish will not do it for you.

Cheers!

Had my first in and out burger. awesome.

teenage girl won't stop fighting

teenage girl won't stop fighting mom on aa flight1959. So we're landing in Phoenix. She was hand cuffed! Flight delay!

Posting from my phone!

So I can post during those long drives (If I was to type at say four letters a minute, I'd fill more than one text message).  Just to give you some scope of how long my drive to work is.  Cheers!

The switch to v2 over v3.

We had to downgrade to Glassfish v2.1.1 at work and I've been busy making sure everything is running smoothly. Our biggest issue (since I don't want to go on a rant about glassfish I'll just leave it at this issue) was the Java Web Start snafu. I know that the real problem lies with the JRE but we can keeping making workarounds on our Apache server and making custom JNPL's.

At any rate our requirement of JSF 2.0 was easily assuaged and I'd like to share that with you.

You can get all the information to install Mojarra v2.0.2 on Glassfish v2.1.1 form here.

Just follow those and you'll be able to deploy JSF 2.0 pages in no time!

UPDATE ON 7/21/2010:
Just so you know we're sticking with Glassfish v2.1.1 but the Glassfish 3.0.1 server has the issue pretty much fixed for most cases.

The upshoot with v2 is that we can actual take our three glassfish servers and have them talk to each other to keep everyone up to date!  Our v3 system had a cron, shell script, and NFS mount to do that but the v2 way is much better.

Apple will destroy you! Try not to be happy about how shiny your death will be.

Apple is the anti-Christ of computers. For years we all hated on Microsoft because they we're big bullies who try to take over everything. Now, don't get me wrong MS is evil, they will want you to use whatever they sell, but that have come to the conclusion that they can't control everything.

Enter Apple, they do believe that they can control everything, they will control how you get books on your iPad, they will control which book you have access to, they will control which apps you can buy, they will control how and when you can use said apps you just bought, they control what you can and can not do on the Internet, they control how you will use the Internet, they control how you have access to content, they control the content that you access...

I could go on forever, in short, it will be Apple's way or no way. It will be Apple's software or no software. In no way is Apple equal to a free market of any sorts and in every single way possible is Apple total vendor lock-in. Once you go Apple it is over, you no longer have *your* documents, you have access to *Apple's* documents.

This all come in the wake of Apple's latest move to destroy Google's platform, increase the operating cost of YouTube, lock out any Microsoft tools, destroy any sharing between KHTML devs and WebKit devs, and now their move to remove Adobe and Ogg from the Internet.

I know what most people would say, just don't buy Apple, good luck on getting that to work. I'm currently on the campaign (since I'm tired of Apple treating open source like a little redheaded bitch) to ensure that people I know don't buy Apple ever again. I ask anyone and everyone who believes in a open world of software to get the word out that Apple is the largest private company threat to everyone's freedom on the Internet. Apple, don't buy into it!

Where was I?

So sorry. Lost track of what I was doing here. I'll try to keep that to a minimum.

At any rate. If you are using Glassfish v3 to serve up application clients via Java Web Start, then check your client's (the people who will be running your crap) JVM. JRE 1.6 u 18 has a nasty bug that prevents Glassfish v3 JWS from working correctly.

I've got to get back on this horse. I'll see you all soon!

What's going on? I know it has been awhile since my last post. Been a bit busy, also workplace has banned blogger from the network. So I'm posting this from my Wii. Fun stuff! Gnome 2.30 is released if you are into that kind of thing. happy April fools day!

Adding Security to EJB

Alright let's take a quick look at the HelloBean.java file with security annotations:

package com.blogger.ramen;

import javax.ejb.Stateless;
import javax.annotation.security.RolesAllowed;
import javax.annotation.security.DeclareRoles;

@Stateless(name="HelloBean")
@DeclareRoles("SecureUser")
public class HelloBean implements HelloRemote {

        @RolesAllowed("SecureUser")
        public String sayHello() {
                return "Hello from EJB!";
        }

}

As you can see I've added the DeclareRoles and RolesAllowed annotations. The EJB container will read the meta-data in the class see the annotations and enforce the security described in them. This happens each time you call the method since it is Stateless.

So the next question is how does the container know you belong to the SecureUser role? Because the security mappings in your sun-ejb-jar.xml file. Here's what you need to add:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>HelloBean</ejb-name>
      <jndi-name>ejb/Helloness/HelloThere</jndi-name>
      <ior-security-config>
          <as-context>
             <auth-method>USERNAME_PASSWORD</auth-method>
             <realm>OurDBRealm</realm>
             <required>true</required>
          </as-context>
        </ior-security-config>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

As you can see the <ior-security-config> and all of it's friends to add a realm to our EJB. Our realm being OurDBRealm that we already setup using the JDBCRealm method that was given earlier. We need to add one more thing to that file, our security mapping, this will map something that will match an entry in the JDBCRealm with the annotation we've giving here. We add this snippit right after the <sun-ejb-jar> element.

<security-role-mapping>
    <role-name>SecureUser</role-name>
    <group-name>SUSER</group-name>
</security-role-mapping>

Deploy your EJB and rerun your client. You should get the default login prompt that's built into Glassfish. Login with the information you've stored in the database and you should see results. Viola! Secure EJB. Of course, if you give bad login information then you will get an exception. At any rate this is a pretty cut and dry use of secure EJBs. We'll look at how to provide your own login dialog and how to catch exceptions on login.

Cheers!

Just so we can get on with it. Go here to see how to add a realm to your Glassfish server. Once you've added the realm you'll need to create some groups. For the best method, give each group a specific task as it is easier to focus on a limit set of permissions than code for roles.

You may have a task like add a product, review a shopping cart, delete an account, or add a bank transaction. Roles are more like Super users, accountants, managers, etc.

Focus on task in your groups and then add triggers or EJB beans that focus on roles, which in turn aggregate your tasks.

Where have I been? Sorry I've just not had the time to post code samples here. Car had some issues, got them fixed, house had issues, cot those fixed, work has issues, not a damn thing I can do about those.

Okay, so here is a quick example of using the FedEx WSDL to build a simple tracking application. To get the FedEx WSDL you just go over to their developer website at http://www.fedex.com/us/developer. You will need to sign up to get a key and password to use their service. When you do sign up give it a couple of days for the key and password to be activated. If it takes longer than two days for the key and password to come online, just give the FedEx number a call.

So download the WSDL and add it to your web services on the services tab of NetBeans. Start a new Java Project and drag the track service from the services tab into the main method in your project.

You should now see some code that looks like this:

package javaapplication34;

/**
 *
 * @author Me
 */
public class Main {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {

        try {
            com.fedex.ws.track.v4.TrackRequest trackRequest = null;
            com.fedex.ws.track.v4.TrackService service = new com.fedex.ws.track.v4.TrackService();
            com.fedex.ws.track.v4.TrackPortType port = service.getTrackServicePort();
            // TODO process result here
            com.fedex.ws.track.v4.TrackReply result = port.track(trackRequest);
            System.out.println("Result = " + result);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

We are going to change that code to look like this:

package javaapplication34;

import com.fedex.ws.track.v4.ClientDetail;
import com.fedex.ws.track.v4.Notification;
import com.fedex.ws.track.v4.NotificationSeverityType;
import com.fedex.ws.track.v4.TrackDetail;
import com.fedex.ws.track.v4.TrackIdentifierType;
import com.fedex.ws.track.v4.TrackPackageIdentifier;
import com.fedex.ws.track.v4.TrackRequest;
import com.fedex.ws.track.v4.TransactionDetail;
import com.fedex.ws.track.v4.VersionId;
import com.fedex.ws.track.v4.WebAuthenticationCredential;
import com.fedex.ws.track.v4.WebAuthenticationDetail;
import com.fedex.ws.track.v4.TrackService;
import com.fedex.ws.track.v4.TrackPortType;
import com.fedex.ws.track.v4.TrackReply;

/**
 *
 * @author me
 */
public class Main {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {

        try {
            TrackRequest trackRequest = new TrackRequest();
            VersionId verId = new VersionId();
            verId.setServiceId("trck");
            verId.setMajor(4);
            verId.setIntermediate(0);
            verId.setMinor(0);
            //The WSDL does not say that this is required but it is.
            trackRequest.setVersion(verId);

            WebAuthenticationDetail auth = new WebAuthenticationDetail();
            WebAuthenticationCredential cred = new WebAuthenticationCredential();
            //This is the key.
            cred.setKey("XXXX");
            //This is the password
            cred.setPassword("XXXX");
            auth.setUserCredential(cred);

            ClientDetail detail = new ClientDetail();
            //This is the test account number
            detail.setAccountNumber("XXXX");
            //This is the test meter number
            detail.setMeterNumber("XXXX");

            TransactionDetail trans_detail = new TransactionDetail();
            trans_detail.setCustomerTransactionId("Tracking with Java");

            TrackPackageIdentifier packId = new TrackPackageIdentifier();
            packId.setType(TrackIdentifierType.TRACKING_NUMBER_OR_DOORTAG);
            //This is some tracking number that you already have.
            packId.setValue("XXXX");

            trackRequest.setWebAuthenticationDetail(auth);
            trackRequest.setClientDetail(detail);
            trackRequest.setTransactionDetail(trans_detail);
            trackRequest.setPackageIdentifier(packId);
            trackRequest.setIncludeDetailedScans(Boolean.TRUE);

            TrackService service = new TrackService();
            TrackPortType port = service.getTrackServicePort();

            TrackReply result = port.track(trackRequest);
            if (result.getHighestSeverity() != NotificationSeverityType.FAILURE && result.getHighestSeverity() != NotificationSeverityType.ERROR) {
                System.out.println("----RESULTS----");
                if (!result.getTrackDetails().isEmpty()) {
                    for (TrackDetail d : result.getTrackDetails()) {
                        System.out.println("Tracking Number " + d.getTrackingNumber());
                        System.out.println("Tracking Description " + d.getStatusDescription());
                    }
                }
            } else {
                for (Notification n : result.getNotifications()) {
                    System.err.println(n.getMessage());
                }
            }
        } catch (Exception ex) {
            ex.printStackTrace();
        }

    }
}

Ta-da! Simple example of the FedEx tracking Web-Service in action. If your account has not been enabled yet you will receive an "Authentication Failed" message. Otherwise you should start seeing some detail about the package. I suggest that you give the TrackDetail class a quick glance since that will be where most of the information you need to access will be. Remember to read those pesky annotations in the WSDL for more information and the PDF on the FedEx developer's website.

Best Description of today's computer reporting

With all the tech buzz that is going on these days, there is no end to the number of "reporters" that generate "news" stories about said tech buzz. However, while looking over one of the news stories on a site I found a comment that justly defines what is really going on here.

If next week Steve Jobs called a press conference and sliced his dick off with a silver scalpel in a room full of stunned reporters, I have no doubt that -- not to be outdone -- Sergey Brin would cut off his with a chainsaw on nation-wide TV seven days later.

And no one in the tech punditry -- all happy just to have jobs and something to write about besides the latest PC graphics card -- would question *WHY* these idiots are emasculating themselves, they'd just write tedious "thought" pieces contrasting the metaphors of Job's elegant, shiny castration versus Brin's use of loud horsepower.

--RobotRunAmok

Absolutely classic.

The world of apps. There's an app for that.

Warning, I am a Java fanboi (even if they sold out to Oracle)

A few years ago a platform was made called Java. It promised to allow people to write and compile their code once and run it everywhere. Of course real life set in an everyone realized that a VM just made software run slow. Basically you had two computers running in the space of one, the OS and the VM. However the idea was that a program could run anywhere and the idea was incredibly huge.

Microsoft tried their hand at Java and found out quickly that Sun meant business when it meant Java compliance. Microsoft would go on to make their own version of Java called .NET eventually. Most other players, IBM / Oracle / Apple / RedHat / Novell played fine with Sun and Java. However, without support from the MS desktop world, Java slowly migrated to business applications and middle-ware. Seeing who were the big players it's no surprise.

Then came along a thing called XML. Now the Internet was hot, but XML made it more flexible, more robust, and more friendlier. With XML, JavaScript, and Asynchronous HTTP you had AJAX. With XML, XSLT, and scripting you had blogs and walls. With XML and SOAP you had web APIs. For the first time the web was becoming a platform and not just a presentation layer. Add in the Open Source movement and MySOL / Linux / PHP / Apache and the web was becoming more and more about sites that provided services and tools for others.

Enter Google. Google has been the driver of the Web Platform, MS tried with ASP, then ASP.NET, and so forth, but all has not been about giving to people but instead just a platform of putting stuff on the web (I'm sorry I dropped my GeoCities account back in '97). MS has created an API to end making APIs. Google embraced the idea of taking an API an making an API out of it.

With the web becoming the cross platform application and presentation layers, Java slowly started grinding towards that goal, of making Java and web work together. Well, happily, no one was going to sit and wait for Sun Microsystems to get off their tush and start making stuff transpire. Struts was born, Spring was born, Tomcat was born, and so on... Sun was quickly loosing their driver's seat to Open Source projects that ran on Java. And to an extent Sun was begrudgingly accepting of the change.

Then the mobile generation started, and that brings me to my muse.

Apple pushed a web central platform with a native SDK as a last option for their phone platform.
Google is pushing a web central platform with a native SDK as a last option for their phone platform.
Microsoft is pushing their .NET platform, yadda yadda yadda, it does some web stuff too for their phonelaptopcomputerservertoasterXbox360sink platform.
Oh yeah and Palm is doing something web centric for their phone platform.

However, sans Palm, all have made big markets in their native application space. The HTML5 platform has been somewhat missing in all of their market software.

Wasn't the idea of Java to build apps that would run on the iPhone, Droid, Pre, and whatever monster MS puts out? Wasn't JavaFX to make apps so easy that people wouldn't think of native?

What went wrong? The what I call "70's mindset" has dominated the cell phone market. That hardware dictates software is the 70's mindset. Vendors do this because of two reason:

1. Control
2, Ease

Apple has a very tight grip over their API, in fact they take in very little input as to what the next SDK will have. Pretty much the same over at the Google camp. They have it open sourced, but very little is changed by outsiders as far as the standard API goes. Do I need to even mention the amount of control MS has over .NET?

Control makes Ease. Picture if you will how absolutely easy it would be to build a platform if you design the platform to run only your specs! That in is the problem with Java on the phone. There are (were, give it a couple of more years) many Java phones out in the world (unless you have Verizon). But Java has gotten away from Sun, quite literally now thanks to Oracle, and control is now anyone (and everyones) game.

HTML5 may prove to be the ultimate winner, but the road ahead is long. The W3C may have the final say but a lot of players, like Apple and Google, are in a big tug of war with the standard that HTML5 for mobile may be out of reach to be a real goal anytime soon.

Thus, we have hardware specific (er, platform) applications that could have used Java but chose not to. We must muse, why is HTML5 better than Java on mobile phones?

Cheers

Trying out Blokkal

Since I'm a big KDE user, yes that means KDE 4 as well. I decided that I would try an actual KDE client to write to my blog.

So this is a test of that.

Also I want to try out pre:

public class Hello {

	public static void main(String [] args) {
		System.out.println("Hello, World");
	}

}

Cheers!

Secure Simple EJB Bean making the DB tables.

Alright, it has been awhile but I swear I've been away for very good reasons.

So if you remember our basic EJB HelloBean, let's look at how to add security measures to provide a login for people to run our EJB code.

First we need to setup our JDBC realm. To do that we need an actual database. I'll be using MySQL as it is a wonderfully simple database to use and maintain, at the same time MySQL scales nicely and can be used for very big projects. So let's say you have your MySQL server up and running. Let's create a database called helloDB. To do that from the MySQL prompt (hereafter known as the sql prompt (since I hate having to hit the shift key for SQL)) type in:

CREATE DATABASE helloDB

Now let's create two tables, one to hold user names and passwords, the other to hold user names and groups. We'll call these tables USERTBL and GRPTBL.

CREATE TABLE USERTBL (
	USERNAME VARCHAR(13) NOT NULL,
	SHAPASSWD CHAR(64) NOT NULL,
	PRIMARY KEY (USERNAME)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE GRPTBL (
	ENTRYID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
	USERNAME VARCHAR(13) NOT NULL,
	GROUPING VARCHAR(20) NOT NULL,
	PRIMARY KEY (ENTRYID),
	UNIQUE KEY (USERNAME, GROUPING),
	CONSTRAINT FOREIGN KEY (USERNAME) REFERENCES USERTBL (USERNAME) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Here we've created the two tables we need to start a security realm using the JDBCRealm module. The SHAPASSWD field of the USERTBL is to store our passwords in SHA-256 encoded strings. You can use any kind of hash function that is known to Java, like MD-5 or SHA-1, I'm going with SHA-256 because I like it among other things.

Also note that I did not make a composite primary key for the GRPTBL but instead created a unique key for the user name / group name pair. I don't like composite primary keys, I don't know many DB admins that do, they have a purpose but just using them anywhere is not really a good idea.

Well there you have the DB side of it. I'll look at the Glassfish end of it in the next post. Cheers!

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.

//File:  HelloBean.java
package com.blogger.ramen;

import javax.ejb.Stateless;

@Stateless(name="HelloBean")
public class HelloBean implements HelloRemote {

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

}

and the interface,

//File:  HelloRemote.java

package com.blogger.ramen;

import javax.ejb.Remote;

@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" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>HelloBean</ejb-name>
      <jndi-name>ejb/Helloness/HelloThere</jndi-name>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

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 HelloRemote.java file copy and pasted into our project, so I'll just cover the main file.

//File:  Main.java

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");
			javax.swing.JOptionPane.showMessageDialog(hr.seyHello());
		} 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.

Cheers!