The first question, really, is what are you trying to do? Do you want to create a custom authentication component, or do you simply want to use a JDBCRealm.
In either case, the most straightforward tact to take is to simply head over to FishEye and pull up the JDBCRealm implementation, as it's been bundled within Glassfish for sometime.
It's worthwhile to look at simply because it does most of what folks want to do, it's implementation is straight forward, and it also exposes some interesting internal app server bits.
You can tweak or create your own realm using JDBCRealm as a template/prototype. And when you're done, plop the class in the $domain/ext/lib directory, restart it, and reference your realm directly from the Realm page in the appserver (just like you reference JDBCRealm or LDAPRealm).
If you simply want to use JDBCRealm, then it works pretty much like any other realm, but, again, the source to the implementation is a viable reference to how to use it.
If you want to use something LIKE JDBCRealm, but your table structure doesn't necessarily work as is, you can typically make SQL Views that mimic the structure that JDBCRealm uses, and work with JDBCRealm out of the box.
If you are wanting to create a completely custom authentication mode, you basically can either implement a Realm (which is a GF specific artifact), or you can go the JAAS path using a login module. As you noted, in GF, the login module is also GF specific (as it subclasses an internal class).
In truth the work is pretty much the same. I would simply go with a Realm, solely because you can easily take the source code from the Realms provided in GF already and pound on them readily to get a working example, without having to go through the JAAS configuration process. It's simply easier to use a custom Realm than a custom LoginModule. It's not portable, but it's easier.
If you truly need portability, go with a LoginModule, and pull your code out in to a separate class, and then use the GF specific LoginModule class as a wrapper to your real code. Then when you port to a different container that uses a "regular" LoginModule, your porting effort will be simpler.
Luck.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=215910