When you try to add a java application as favorite into the Gnome Shell‘s lateral dock and run it you’ll end up having duplicated icons, one for the launcher and one for the running app. This happens b/c the shell uses an application based system for grouping tasks, so the idea is, if you add an application as a favorite launcher and you start it you’ll end having that launcher icon highlighted. Internally the shell matches the running process with the Exec clause of the .desktop file .
This works well except for applications running inside a VM or being interpreted b/c those will share the same running process. On that situation the shell inspects the WM_CLASS X Window property ^[1] and matches it with the full name of the desktop file. E.g. if your applications has the WM_CLASS set as “mySwingApp”, for this to successfully matched in the dock with its launcher, that launcher must be called mySwingApp.desktop located according XDG.

Note: for inspecting that value on any window you just need to run xprop WM_CLASS and click into the target window

Why is this happening?

Even if you are creating a swing application from scratch there is no easy way to tweak that X Window property using plain and portable APIs. Taking a look into openjdk sources, this is how them manages it

String mainClassName = null;

StackTraceElement trace[] = (new Throwable()).getStackTrace();
int bottom = trace.length - 1;
if (bottom >= 0) {
    mainClassName = trace[bottom].getClassName();
}
if (mainClassName == null || mainClassName.equals("")) {
    mainClassName = "AWT";
}
awtAppClassName = getCorrectXIDString(mainClassName);

As you may note what is used for this value is the name of the class running the Swing main loop.

Da solution

Digging around the web I founded a java agent and a pretty similar explanation on what’s going on.
So what I did was to fork that agent and improve it a little bit. What I did was to move it into a maven structure and remove its packaging as a fat-jar (I’m radically against fat-jars as you can see in my comments here).

The forked project is located in my github here:
https://github.com/diega/window-matching-agent
and please take a look to the README there

A practical example

My first motivation on doing this was based on IntelliJ IDEA so I’ll paste here my environment.

• Download the agent-1.0.jar and put it wherever you want (I put it into IntelliJ’s bin/ folder)
• Edit the file bin/idea.vmoptions adding this line

  -javaagent:agent-1.0.jar=intellij-ultimate

• Create the file ~/.local/share/applications/intellij-ultimate.desktop with the following content

  [Desktop Entry]
  Version=10.5.1
  Name=IntelliJ IDEA Ultimate Edition
  Comment=The Most Intelligent Java IDE
  Categories=Applications;Development;
  Encoding=UTF-8
  Exec=env IDEA_CLASSPATH\=../lib/asm.jar /home/diego/bin/ideaIU-10.5/bin/idea.sh
  GenericName=IntelliJ
  Icon=/home/diego/bin/ideaIU-10.5/bin/idea128.png
  MimeType=text/x-java
  Terminal=false
  Type=Application
  URL=http://www.jetbrains.com/idea
  

Latest notes

If you download the agent-1.0.jar into another location (or with another name) you must adjust the -javaagent: parameter.
Of course, change the path in the Exec entry to point to your own executable.

Hope this helps somebody, it took me a while to figure out the-right-things-to-do™ :)

This post shows a reference implementation of drools persistence on top of a non transactional HashMap. This should serve as inspiration for more complex scenarios (like the Berkley DB one). This work was also developed under Intalio’s sponsorship.

As the new abstraction is heavily inspired on JPA there are some mechanisms which should be emulated in order to get the same behavior on both implementations.

Involved classes

Starting from the abstraction described in my previous post this is the new hierarchy for persisting drools runtime into a HashMap.

Drools abstract storage persistence diagram

I’ll try to explain the most relevant objects in the diagram relating them to JPA components.

MapBasedPersistenceContext

behaves like the EntityManager, it stores all objects which are not yet commited. Finding objects is also resolved through this interface, for support this behavior it has to have access to the KnowledgeSessionStorage.

KnowledgeSessionStorage

represents the real persistent storage. This is the extension point for support any other non-JPA implementation. It provides saveOrUpdate and find methods and is the responsible to assign id’s to the entities.

ManualTransactionManager

as we cannot rely on JTA to manage our session Drools hooks explicit calls whenever things should be serialized. This component must access the NonTransactionalPersistenceSession to get the entities waiting for being persisted into the KnowledgeSessionStorage.

JBPM5

The same concepts have been applied into JBPM5 codebase and we have there proper extensions for managing process semantics.

You’ll find there:

• MapBasedProcessPersistenceContext
• ProcessStorage
• ManualProcessTransactionManager
• etc

Usage

You must setup the environment you gonna pass to the JPAKnowledgeService (still keeping the name for backward compatibility) setting the TRANSACTION_MANAGER and PERSISTENCE_CONTEXT_MANAGER keys. For this I have just created simple factories but you can build them the way you want.

I suggest using KnowledgeSessionStorageEnvironmentBuilder or ProcessStorageEnvironmentBuilder. There doesn’t exist a default implementation of this storage, the one on top of HashMap is only used for testing porposes, so you have to pass to the builder your own implementation of the desired storage.

Testing further implementations

To test this two implementations (and any new one which wants to respect the drools persistence semantic) together, I have created a simple set of abstract tests(*).
For Drools Expert:
https://github.com/droolsjbpm/droolsjbpm/[...]/MapPersistenceTest.java
For JBPM5
https://github.com/krisv/jbpm/[...]/MapPersistenceTest.java
In a future will be great to abstract the current tests on JPA to be able to run abstract of the lower persistence layer.

What’s next

Clean up this interfaces a bit more and start working on a DB Berkley implementation

_{(*) tests names are not declarative enough, I’m holding a commit for this until coming repository split is done}

On the past two months, and under Intalio’s sponsorship, I’ve been working adding a new persistence layer into Drools. The main goal of this is to support Berlkey DB as persistent backend. Added abstractions are on that direction.
The approach for this task was to work on top of the current drools-persistence-jpa module. Is assumed this module is tested enough (through junit or merely day-to-day usage) and this is the one who defines the semantics which drools persistent applications should attach.

Little background on managing persistence

When you use the engine in a regular way, you obtain the ksession through the kbase and it doesn’t know anything about how to persist its state. To provide the ksession with persistence capabilities Drools makes use of the command pattern. That way, instead of creating it directly from the kbase you go through a factory which will return a decorator which will handle how and where the state is persisted. Being a decorator, at this point, will be totally transparent to the user whether or not the state is persisted.

Abstracting persistence

As the name dictates, drools-persistence-jpa module is heavily oriented to JPA usage. Then, what we have made here was to clean up the use of JPA interfaces and move them into this module.

The most used interface by JPA is the EntityManager, this one was abstracted by the PersistenceContext interface which now has specific methods for persisting SessionInfo’s and WorkItemInfo’s.
Internally Drools uses different scopes for dealing with persistenceContext’s, one for the whole application and one for each command. This behaviour has also been abstracted into PersistenceContextManager.

Persistence layer before refactor

Persistence layer after refactor

Backward compatibility

Other important aspect of this refactor is that maintains backward compatiblity. That means that, for the moment, you shouldn’t notice any difference if you already have your JPA application running. Current way to configure the ksession is still the same but we’ll add some new in the future, which, I wish, will end up being more polish and abstract.

JBPM5

This persistence refactor also applies for jbpm5 which now have a ProcessPersistenceContext and a ProcessPersistenceContextManager.

What’s next

In a comming post I’ll show a reference implementation on the top of a regular HashMap.

https://github.com/diega/rf-bpmn2-migrator

Enjoy.

_{Disclaimer: calling a 7-line class a tool isn’t fair enough, but you know…}

Git migration
Maven 3 compliance
Repository cleanup (no more .classpath and .project files)
Guvnor building coming less and less painful
Huge internal refactors and optimizations

The major of this tasks were leaded by ge0ffrey who has made our lives a lot better :)

As regular user of the framework when you finally decide to move from 5.1.1 to 5.2 you will find a big difference. Drools Flow is gone… but it has reborn as JBPM5!.
So the concepts remains the same but you’ll need to adjust your dependencies and make a reorganization of your imports. This is the first step on breaking backward compatibility preparing us for the big crash arriving on 6.0 :)
Basically u gonna need to add

<depdency>
  <groupId>org.jbpm</groupId>
  <artifactId>jbpm-[flow | persistence-jpa | bpm2 | ...]</artifactId>
  <version>${jbpm.version}</version>
</dependency>

Doing so you should change a lot of your org.drools packages into org.jbpm.

w00t

As you can see here,  the Template Editor is an extension of the famous Rule Editor which now has a Template Data tab. On this tab you’ll find a grid having the template placeholders (a.k.a. “template keys”) as columns. So in your knowledge base you’ll finally add the rules generated by the drools-template module, using the data into the grid and the parametrized rule that you’ve created in the editor.

Working on improve our knowledge about the Drools platform and to give something back to the community. This time we’ll discuss a language extension called Work Items. The official documentation says: “[Drools Flow] offers constructs that are closely related to the problem the user is trying to solve”. In other words, creating your own WorkItems lets you extend the business modeling language to a domain oriented way.
Creating a language for your process gives you an enormous flexibility in what you can express. The funny thing is that with this great power doesn’t come a great responsibility, meaning there is no more responsibility than needed to write any bored and unflexible process language.

Creating Work Items

As I’m talking to business analysts that have everything organized, I can ask you to look at your white boards closely and think which nodes have actions that involve the process itself. What needs to be achieved in every node, not how it will be made. Once you have your palette in mind you can refer to 8.2. Example: Notifications of the official documentation to learn how to integrate it with the Eclipse Flow Editor.
If you are a sharp vi-editor pal and want to get your hands dirty writing BPMN2 xmls on your own, you have to know that Work Items in Drools Flow are represented with Task nodes and they use its taskName atributte to relate it with the WorkItemHandler (a.k.a “where action happens”).
In this example you can see it

<definition>
  ...
  <process>
    ...
    <task id="_2" name="SafePoint" tns:taskName="SafePoint" />
    ...
  </process>
  ...
</definition>

To get more information about Task nodes you can refer to the BPMN2 draft specification here, chapter 10.2.3
It’s important to note that you only define what has to be done, not how. Keep reading if you are curious about that :)

Writing WorkItemsHandlers

Running your own solution for a given Work Item is as easy as telling the KnowledgeSession which handler will react when the process reaches one of this nodes. This is done through the WorkItemManager obtained from the ksession.
ksession.getWorkItemManager().registerWorkItemHandler(“MyVerySpecialWorkDomainAttached”, new MyVerySpecialWorkDomainAttachedHandler());
MyVerySpecialWorkDomainAttachedHandler implements org.drools.runtime.process.WorkItemHandler which has two methods: executeWorkItem and abortWorkItem, pretty autodescriptive names.
Now every time your session runs the process, it will execute your registered handler. Cool huh?
Only one caveat! Remember to reregister the handlers if you load the session from a persistent storage, because this information doesn’t belong to the runtime of the session thus is not persisted

Work Items behind the scenes

As the business analyst defines the semantics about Work Item, it is up to the developer to define how this will be implemented. Part of this decision involves dealing with the flow of the process, meaning if it should or should not be paused until the action finishes its execution. To inform the session that the Work Item has been completed, this has to be done through WorkItemManager, usually as follows:

• if you are inside WorkItemHandler, manager.completeWorkItem(workItem.getId());
• if you are at StatefulKnowledgeSession level, ksession.getWorkItemManager().completeWorkItem(workItemId)

As you notice here, you will need the id of the managed work item.
To get the list of uncompleted work item ids, it’ll depend on a contract between your application and the implementation of the handler. There have been some discussions recently in the mailing list about who should be responsible for getting the list. From the Drools point of view Salaboy makes a good point and Kris gives a summary of the idea.
The main idea is, if you have an specific node in your domain, you are the only one who knows what information is needed to achieve the task and who you should ask for this information. Furthermore, your long-running-remote-asynchronous task is going to need information collected along your process to complete it, all this information is part of the protocol between your application/process and the outside world to react when the process reaches its node. When these external part of your system completes, the execution will alert you about the completion and should be able to inject new information to the process. Again, it is up to you to push the results into the session and continue execution.
This is the general way used for implementing Human Tasks but it is the subject of some next post.

Work Items in action

As a teeny-weeny example of this concepts we have developed a web application that you can download from here and simple run it with ‘mvn jetty:run’.

Any feedback is absolutely welcome and rewarded with a glass of cold beer at a bar in my town (only applies for people with more than two degrees of separation from me :P)

Jetty configuration files

There are two main configuration files: jetty.xml and jetty-env.xml. The first one is for configuring the whole server and the last for your specifc context (the webapp). To load the first one you have to configure the maven plugin to set the location.

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>maven-jetty-plugin</artifactId>
  <configuration>
    <jettyConfig>src/main/webapp/WEB-INF/jetty.xml</jettyConfig>
  </configuration>
  [...]
</plugin>

The jetty-env.xml file will be auto loaded from your src/main/webapp/WEB-INF folder.

Datasources and jetty-env.xml file

Below, you can see how a WebAppContext is configured (pay attention to how readable this xml is). This is the way you expose objects in the JNDI directory: create a Resource into the jetty-env.xml file passing as first argument, the entry, in the directory and as second argument the object itself. In this example we are exposing a pooled datasource provided by H2, giving it a name that we’ll refer in persistence.xml as jta-data-source prefixed by java:comp/env/.

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
    <New id="DSTest" class="org.mortbay.jetty.plus.naming.Resource">
        <Arg>jdbc/testDS</Arg>
        <Arg>
            <New id="poolingDS" class="bitronix.tm.resource.jdbc.PoolingDataSource">
                <Set name="uniqueName">foobar</Set>
                <Set name="className">org.h2.jdbcx.JdbcDataSource</Set>
                <Set name="allowLocalTransactions">true</Set>
                <Get name="driverProperties">
                    <Put name="user">sa</Put>
                    <Put name="password">sasa</Put>
                    <Put name="URL">jdbc:h2:/tmp/droolsflow.db</Put>
                </Get>
                <Set name="maxPoolSize">3</Set>
                <Call name="init" />
            </New>
        </Arg>
    </New>
</Configure>

Finally you have to configure web.xml to expose the resource to your web application.

<web-app>
...
    <resource-ref>
        <description>My DataSource Reference</description>
        <res-ref-name>jdbc/testDS</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
    </resource-ref>
</web-app>

Transaction Manager & jetty.xml

Now it’s time to configure the Transaction Manager, so we will use Bitronix which provides a maven+jetty plugin. To start using it, you have to add it as a dependency of the maven-jetty-plugin in the corresponding section as follows:

            <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>maven-jetty-plugin</artifactId>
                <configuration>
                    <jettyConfig>src/main/webapp/WEB-INF/jetty.xml</jettyConfig>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.btm</groupId>
                        <artifactId>btm-jetty6-lifecycle</artifactId>
                        <version>1.3.3</version>
                    </dependency>
                    <dependency>
                        <groupId>org.slf4j</groupId>
                        <artifactId>slf4j-log4j12</artifactId>
                        <version>1.4.2</version>
                    </dependency>
                    <dependency>
                        <groupId>log4j</groupId>
                        <artifactId>log4j</artifactId>
                        <version>1.2.14</version>
                    </dependency>
                </dependencies>
            </plugin>

Next, you need to tell jetty to associate the Transaction Manager to start and shutdown the server life cycle. All this goes into jetty.xml:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure id="Server" class="org.mortbay.jetty.Server">
    <Call name="getConfiguration" class="bitronix.tm.TransactionManagerServices">
        <Set name="serverId">jetty-btm-node0</Set>
        <Set name="logPart1Filename">
            <SystemProperty name="jetty.home" default="." />
            btm1.tlog
        </Set>
        <Set name="logPart2Filename">
            <SystemProperty name="jetty.home" default="." />
            btm2.tlog
        </Set>
    </Call>
    <Call name="addLifeCycle">
        <Arg>
            <New class="bitronix.tm.integration.jetty6.BTMLifeCycle" />
        </Arg>
    </Call>

    <New class="org.mortbay.jetty.plus.naming.Transaction">
        <Arg>
            <Call name="getTransactionManager" class="bitronix.tm.TransactionManagerServices" />
        </Arg>
    </New>
</Configure>

Conclusion

After this xml battle, you are able to run any JPA+JTA application inside your jetty environment with minimum effort, just mvn jetty:run. All this was especially applied to run a Drools Flow application with persistent StatefullKnowledgeSession, which, btw, runs like a charm :)

Bonus stage

Remote debugging your mvn jetty:run with Eclipse

If you want to debug any maven application (in particular jetty running inside maven), try to execute mvnDebug jetty:run, which starts port 8000 and waits until Eclipse connects to it. To create a remote application debug configuration, go to Run > Debug Configurations > Remote Java Application and set port 8000; in the source tab you can attach the sources where you want to put your breakpoints, and finally click the Debug button.

Yendo al contexto Java, que es donde me siento cómodo seguro por el momento, me he encontrado con incontables casos donde a la pregunta de “cómo es su ciclo de deploy” la respuesta comienza con “exportamos el proyecto desde eclipse”…
Por qué esto está mal (sin orden particular)?
• Se depende de un humano para armar ‘entregables’ (no hay integración continua)
• Atenta contra la posibilidad de incluir a un nuevo integrante al equipo que haga uso de otra herramienta
• Tenemos que manejar las dependencias desde el eclipse
Otros efectos colaterales:
• Tendencia a ensuciar los controladores de versiones con cosas propias de las IDE
• Tendencia a nunca entender lo que una IDE hace tan mágicamente (aunque esto es algo inherente a la estupidez en cualquier contexto)
Soluciones a esto:
• Uso de Maven

Por qué Maven?
Maven no es nada de otro planeta ni hace magias oscuras. Hace muy pocas cosas y las hace bien. Mediante el uso de Maven se obtienen algunos puntos muy positivos: controlar dependencias, manejar ciclos de deploy (incluyendo el empaquetado) y unificar (de manera IDE agnóstica) convenciones a la hora de trabajar. Ésto último tiene un punto a destacar alucinante, que venga alguien totalmente ajeno a nuestro desarrollo y no se sienta [tan] perdido frente a cientos de archivos de código; va a saber dónde estan los fuentes, dónde buscar tests, dónde mirar a grandes rasgos qué bibliotecas se usan y va a poder generar un entregable corriendo un solo comando.

Qué es lo peor que podés hacer?
Intentar ajustar maven a tu proyecto y no al revés. Maven es una herramienta para organizar, que si bien deja que modifiques sus convenciones al hacerlo estarías perdiendo muchas de las cosas que destaqué en la pregunta anterior. Cuando te convenzas que estas son las cosas que querés que tu proyecto cumpla, pagá el precio por haber comenzado por la senda del mal y purga tu alma moviendo archivos y repensando los paquetes que tiene tu sistema.

Qué es algo feo feo de ver?
A alguien usando JBoss Developer Studio para mostrar las maravillas de Seam (básicamente hot deploy) cuando realmente conciliar estas maravillas con las ‘buenas prácticas’ antes mencionadas es imposible (y lo peor es que la mayoría de la gente valora más un entorno de desarrollo a-La PHP en lugar de un proyecto ordenado).

Quiénes son los más horrorizados con no comer/ver la tele/dormir con la IDE?
Los desarrolladores .Net . Ellos han comprado una serie de preceptos guiados por Visual Studio y sus wizards, que se les hace arcaico y elitista tratar de usar herramientas de línea de comando, el resto simplemente “la complican de gusto”.

Qué es lo que tendría que hacer un desarrollador nuevo cuando entra a un equipo?
• git clone [o el scm que quieran]
• mvn eclipse:eclipse [o la ide que quieran]
• [abrir la ide y buscar las cosas como tu intuición te indica]
• mvn package
• [deploy]
• [probar la aplicación]

Qué alternativas similares hay?
Para Java ninguna[**] y no me parece mal. Creo que se puede confiar bastante en los desarrolladores de maven como para que guien este camino.
Hablar de ciclos de desarrollo en otros lenguajes no puedo, solo comentar que en C se adolece del mismo problema que generó Ant en su momento, Autoconf/Autotools son infinitamente poderosos, infinitamente complejos y no existe una manera estándar de hacer las cosas, realmente una pena; apenas crece un poquito un proyecto C meterse es una tarea heroica.

[*]: término que nunca antes había escuchado :)
[**]: ant+ivy me parece una aberración mutante

Un poco de JAAS

Introducción:
JAAS es una especifación Java con el fin de autenticar y autorizar intenciones de acceso a recursos.
En en la práctica su uso más frecuente reside en la primera de estas dos intenciones. Esto, en mi opinión, se debe a que realmente la solución ofrecida para la autorización no es demasiado agradable para el desarrollador.

Filosofía:
JAAS está pensado para comportarse como una capa pluggeable que opera sobre dominios de autenticación. Su uso es totalmente transparente a través de la interfaz LoginContext que instancia todos los LoginModule del dominio especificado.
La idea de JAAS es proveer mucha generalidad sobre lo que significa la autenticación ya que no todo se hace a través de un par nombre de usuario/contraseña. Para esto, un LoginModule tiene que ser capaz de pedir la información necesaria para autenticar. Siendo la invocación de los módulos a través del LoginContext, es a este a quien se le pasa una instancia que implementa la interfaz CallbackHandler. El contrato establecido podría ser “cuando me llames al login, yo te voy a pedir estos datos”. Haciendo nuevamente incapié en que esta información puede ser el nombre de usuario y la contraseña, la respuesta de un lector biométrico, la clave secreta que tiene una llave usb, etc., etc.
Durante el proceso de login (formalmente en el método LoginContext#commit), luego de una validación exitosa, se deja a disposición del invocador una instancia de la clase Subject. Un subject es simplemente un grupo de identidades que refieren a quien quiere ser autenticado. Algo interesante de JAAS es que no define un concepto claro de cuándo alguien está o no autenticado ya que este estado booleano acotaría la generalidad que se está intentando obtener. Podría ocurrir el caso en que alguien falle al autenticar y en este caso se le asigne una identidad fantasma con ciertos permisos según la hora del día en el que intentó la acción. En este caso tener un rol por defecto para acceder a ciertas acciones no basta. Así es que se deja que el LoginModule inserte tantos Principal como crea necesario para lo que le parezca y el que hizo el llamado de autenticación tendrá que saber interpretar el resultado. Cada Principal va a ser una implementación concreta de la interfaz que va a quedar disponible a través del subject.
Inmediatamente después de creada la instancia de LoginContext ya se le puede pedir el subject, este subject, al no haber pasado nunca por ningun LoginModule, va a encontrarse vacío de todo principal, pero es válido pedir su referencia.
Las semánticas para esta lista de Principal son múltiples, una lista vacía puede indicar un usuario todavía no autenticado, alguien autenticado que no puede hacer nada, alguien sobre el que falló la autenticación, entre otras. Así como también la presencia de Principals puede referir a múltiple información sobre el sujeto en cuestión: roles, claves públicas, vcards, etc.

Implementación:
La solución de JAAS puede ser usada tanto para una aplicación web como para una aplicación standalone de manera similar. No existe un servicio de autenticación ni mucha magia detrás del hecho de entender que el LoginContext obtiene de una configuración la lista de LoginModule que tiene que instanciar para cada dominio de autenticación. Además también tiene que suministrar el callback a través de los cuales cada LoginModule requerirá datos de entrada.
Los puntos oscuros de esta generalidad se encuentran fundamentalmente en dos lugares. Primero al momento de implementar el CallbackHandler, ya que el LoginModule sabe qué va a requerir pero al tener una interfaz genérica solo puede pedir cualquier cosa que implemente la interfaz Callback y esperar a que en runtime lo que yo quiero en mis callbacks sean bien llenados por quien los implementó. Esto se va a ver más claro con algo de código:

• Al instanciar el LoginModule se le pasa un CallbackHandler.
• En el método login el LoginModule hace uso del CallbackHandler para obtener lo que espera para autenticar.
• Lo muestro en orden inverso ya que me parece más claro para entender el problema

[LoginModule#login]

RightFingerCallback fingerCallback = new RightFingerCallback();
USBKeyCallback() usbCallback = new USBKeyCallback()
callbackHandler.handle(new Callback(){fingerCallback, usbCallback});
metodoDeAutenticacionExtranho(fingerCallback.getFingerprintAsGifImage(), usbCallback.getKeyHardwired());

[Clase que intenta autenticar algo]

LoginContext loginContext = new LoginContext(“dominio-raro-y-seguro”, new CallbackHandler(){
public void handle(Callback[] callbacks) throws …{
for(Callback callback : callbacks){
if(callback instanceof RightFingerCallback){
((RightFingerCallback) callback).setFingerprintAsGifImage(obtainFprint());
} else if (callback instanceof USBKeyCallback){
…
}
}
}
}

• Sí, hay instanceof… se pueden hacer en algunos contextos juegos de polimorfismo pero en la mayoría de los casos hay que enfrentarse con esta situación y es importante saber que uno va a salir ligeramente herido en este camino.

El segundo lugar donde se busca generalidad es en la asignación de identidades ya que no todas las aplicaciones manejan roles, ni vcards, ni claves públicas, etc. Así se llega al punto donde así como se tienen Callbacks específicos para mis necesidades, se tienen Principal específicos para identificar la información que el autenticador me puede dar.
Otra vez algo de implementación:

• Los principal se agregan en el metodo commit ya que no hay que olvidar que nuestro LoginModule convive eventualmente en una cadena de módulos de autenticación y es posible que alguno de ellos no valide con lo que si completamos el subject antes de llamar a todos los login() del dominio vamos a darle identidades a nuestro sujeto que no queremos (o sí, pero estas cuestiones se manejan en cuanto a la configuración de cómo interactúan los módulos entre sí -demasiado avanzado para esta introducción conceptual-)

[LoginModule#commit]
…
getSubject().getPrincipals().add(new MyPrincipal());
…

Así que, una vez ejecutado el método login del LoginContext va a quedar un subject hidratado (dependiendo si autenticó) con los Principal que definirán su identidad dentro de nuestro dominio, pudiendo filtrarlos e inspeccionarlos para decidir si son autorizados o no.

Dentro de JBoss Application Server:
Siendo JAAS un modelo de seguridad tan independiente, el AS no puede proveer demasiado para su funcionalidad básica. Hablando de la rama 4.2.x, se cuenta con el mbean XMLLoginConfig que hace más amigable la escritura de dominios mediante xml que por defecto se encuentra en <name>/conf/login-config.xml, el archivo en sí es bastante autoexplicativo y por cualquier duda más allá de lo evidente, se puede consultar el dtd en docs/dtd/security_config.dtd

Resources (o “no dije mucho más de lo que aparece en los siguientes links”):

• http://www.j2ee.me/j2se/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html
• http://www.j2ee.me/j2se/1.4.2/docs/guide/security/jaas/tutorials/SampleLoginModule.java

]]> http://locademiaz.wordpress.com/2009/08/28/un-poco-de-jaas/feed/ 0 diega