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!

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

Promise to post some EJB code examples tomorrow.

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!

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.

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.

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?

File: SimpleMessageRemote.java

package com.blogspot.ramenboy.logintest;

import javax.ejb.Remote;

@Remote
public interface SimpleMessageRemote {

	String sayWorld();

}

File: SimpleMessage.java

package com.blogspot.ramenboy.logintest;

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

@DeclareRoles("AUser")
@Stateless
public class SimpleMessage implements SimpleMessageRemote {

@RolesAllowed("AUser")
public String sayWorld() {
	return "World!!";
}
}

File: Main.java

package logintest01;

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

public class Main {

@EJB
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.

Why?

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!");

		System.exit();
	}
}

So I hope this works.

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.

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.

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 OpenOffice.org 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

Hello.

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.