Archive for September, 2008

29
Sep
08

Remapping keyboard on recent distros that use evdev+hal

As you may have read on the previous post my Lenovo 3000 C200 needs a “patch” for its keyboard on X since slash/question/degree key is in an unusual place.

After a little research (grep -r saved my day) I found out that the configuration that used to reside on /etc/X11/xorg.conf is now on /etc/default/console-setup so the same rule for overriding keymaps is still valid. The corresponding configuration for recent distros is something like this:


XKBMODEL="abnt2"
XKBLAYOUT="br+lenovo(addslashes)"
XKBVARIANT=""
XKBOPTIONS=""

Recent update: If you want further explanation of the X keyboard configurations an excellent guide (and by the way the one I used to figure out this) is “An Unreliable Guide to XKB Configuration” by Doug Palmer (Also available here)

28
Sep
08

Remapping keyboard keys on X

I’ll share this tip since it took me some time to figure out this fix. I guess it is quite common in notebook keyboard to have such unusual layouts as mine (below):

The first impression I had when I bought this notebook was: “I guess slashes and question marks aren’t here on normal abnt2 keyboards…” but… Windows came bundled in my laptop and it was already remapped.

Then I installed Ubuntu (I guess it was 7.10 by the time) and for my surprise… the key seemed dead until I figured out that Right Control was missing… in fact my slash/question mark key was the right control. So I started a long research to find out how to fix this and after some research I discovered for both X and console. The solution is:

  • For X

Create a file under /usr/share/X11/xkb/symbols. I’ve named mine lenovo (guess why) and place this inside it:

partial modifier_keys
xkb_symbols "addslashes" {
key <RCTL> {  [ slash, question, degree ] };
};

Then modify your /etc/X11/xorg.conf and change XkbLayout section to this:


    Option        "XkbLayout"    "br+lenovo(addslashes)"

With this you override only this key from the original br keymap.

In order to find out the original key, in case you have a similar problem, run xev and have a look on the output. Mine looked like this (Control_R code confirms what I guessed, the key was in fact a Right control key):


KeyPress event, serial 34, synthetic NO, window 0x4a00001,
root 0x7a, subw 0x0, time 3139474, (430,712), root:(437,763),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

  • For Console keys

In order to change console keys you need to change the following file: /etc/console-tools/remap

and place the key changes there. It works like a file replace. So in order to make the same change I’d have this content inside it.


s/keycode  97 = Control/keycode  97 = slash/
/keycode  97 = slash/ashift keycode  97 = question
/keycode  97 = question/aaltgr keycode  97 = degree

For some weird reason, Ubuntu 7.10 and 8.04 wasn’t executing console remapping.

And at last, unfortunately this tip does not work anymore on upcoming Ubuntu 8.10 since it changed its key map control to use hal and evdev. So, I am back to where I was last year. If anyone by accident know how to do this in recent distros, please post a comment.

17
Sep
08

Connection request flow on outbound JCA connector

Continuing with the posts about outbound JCA connectors lets have a quick look at one of the main flows of an outbound JCA connector: the connection request flow.

By now you might be wondering: “What on earth is responsible for making my connectors poolable? Is there any dark magic involved?”.

First answer: “the ConnectionManager” and second answer: “Yes and it is container dependant!”. That’s the reason you should keep an instance of the ConnectionManager inside your ConnectionFactory when it is created, that’s how you delegate the connection creation to the pooling implementation of the container.

Enough explanation let’s have a look on a sequence diagram for a connection creation when we have no connections inside the pool.

First flow: connection request with no matching connections

First thing to take note, it is up to you to implement the matchManagedConnections, I’ve put a note on the next diagram that might help on this implementation: making the ManagedConnection be able to compare itself to a ConnectionRequestInfo makes the things easier. Also beaware that some Application Servers (eg.: WebSphere) skip the matchManagedConnections part if it detects by itself that the pool is empty or there isn’t any matching connection.

Sequence Diagram - No Matching Connection

Sequence Diagram - No Matching Connection

Another point about the specification is that it states that a single managed connection may be responsible for more than a single physical connection (FooConnectionImpl), this is required for scenarios where connection sharing is possible (refer to section 6.5.4.2 of the specification).

Previously I tried implementing using a single handle but I noticed that it does not take much effort to make it fully adherent, in fact, it is only necessary to use a delegate (FooConnectionHandle) that implements the FooConnection interface and delegates almost all the methods to the FooConnectionImpl instance that is inside the FooManagedConnection instance (refer to sections 6.5.4.1 and 6.8.1 of the specifications). The exception to the delegation is the close method that your connection must provide, this method in the delegate will be responsible for raising the Connection Closed Event, this is the way you signal the container that you are giving the connection back to the pool.
Second flow: connection request when there are matching connections inside the pool.

Sequence Diagram - Matching Connections

Sequence Diagram - Matching Connections

This flow is executed whenever the container guesses there are potential matching connections. The matchManagedConnection method is invoked with the minimal connection set that the container can identify. The connection set is a key point: specification states that the container is responbile for determining the minimal set that has a potential match to avoid degrading performance while looking for the connection. Also I noticed that some containers don’t check the connections inside this Set before sending them for matching.

Implementation Tips

Here are some decisions that might help on the implementation of the ManagedConnection and ManagedConnectionFactory.

  • Store the ConnectionRequestInfo that was passed to the ManagedConnectionFactory on the creation of the ManagedConnection as an attribute inside the ManagedConnection this leads to the next tip
  • Use the ConnectionRequestInfo stored in the ManagedConnection as argument to an overload of the equals method of the ManagedConnection class this helps in the implementation of the matchManagedConnection method
  • Never ever forget to include your ManagedConnection object on equals(Object) method implementation. The tip above may lead you to forget this details. Dont do this under any circumstance since specification requires this and some containers freak out after some use time if this method is not implemented (connection borrow time goes all way up if not implemented)

Next post I’ll focus on how to signal the container that something went wrong with the connection and how to validate the connection before it is returned to the requestor.

01
Sep
08

Outbound JCA connectors introduction

Continuing with the posts about JCA I’ll start with the project of an Outbound JCA Connector that I’ll call FooJCA. First of all and let make this clear, I am not stating that this design is an optimal JCA Connector design, what I can say is that I tried to make as compliant as possible from my understanding of the documentation.

Lets start with a overall view of the main classes and interfaces involved in a JCA Connector implementation.

Foo Connector Class Diagram

Foo Connector Class Diagram

First class to take note, the FooResourceAdapter, that’s one of the connector classes that is able to directly communicate with the container and use some priviledged services (eg.: scheduling Work instances or creating timers). This ability is provided by the BootstrapContext that is passed as a parameter of the start method by the container.

Another key class that also has the ability of interacting with the container is the FooManagedConnectionFactory. As you may have already noticed, this class isn’t always container dependant, or at least it may not be (that’s up to the developer the choice of providing functionality of the Connector outside the container). The difference (between working inside the container or outside it) is usually detected when the class method createConnectionFactory is called with or without the ConnectionManager. Talking about the ConnectionManager this is a Container implemented class that is responsible for pooling connections and related work. This Container work relies on the matchManagedConnections method that is provided by the ManagedConnectionFactory, so, pay much attention to this method implementation.

Moving on, the FooConnectionRequestInfo is a implementation of the ConnectionRequestInfo interface and is the class responsible for passing Connector dependant details about the request between the Container and the JCA Connector. One of the requisites of this class is that it implements equals and hashCode.

The FooManagedConnectionFactory as you may guess is the class responsible for creating the FooConnectionFactory instances and FooManagedConnection instances as well. It does not matter if the FooConnectionFactoryImpl instance will be Container dependent or not, it will be FooManagedConnectionFactory’s role of creating it.

At least but not last, the FooConnectionFactoryImpl will be the class responsible for creating FooConnectionImpl instances when requested (this will be treated in a separate post since it is a little long topic).

And, for finishing this post, FooManagedConnectionImpl is the class responsible for wrapping a FooConnectionImpl and returning delegates (FooConnectionHandle class) that implement FooConnection interface and notifies the container about the status of the ManagedConnection connection.

That’s enough for this post, keep on watching the blog for the rest of the implementation of the Outbound JCA Connector.




ClustrMaps

Blog Stats

  • 267,559 hits since aug'08

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: