Have a job, join us in the JDeveloper WebServices/ Spring/ Weblogic SCA team

We are loosing a valued member of our team to Australia so we are looking to a talented developer to join us in the Reading, UK office. You can find out a little bit more by visiting the jobs page and searching for job 203089.

If you know me and are interested get in touch directly, so I can pass your information on. (Okay and claim the recruitment bonus if we take you :-) )

At UKOUG'09 today and tommorrow

REST using Jersey today, and WS-Secutiry tomorrow at lunch time. Camping out in the speakers lounge doing prep. Lovely day outside, just a bit cold to be working outside.

Debugging groovy in ADF

So I have completed my introduction to ADF course so will hopefully be able to start work on the side projects we have been given time for. It was interesting just how easy it was to do a lot of common things in ADF.

One this that did concern a lot of use was how to debug certain parts of ADF. Steve has a post on this topic but that doesn't say anything about the numerous cases where groovy is used as an expression language.

Since Groovy runs on the same VM as your application you can easily call out to external classes, so you simply need to create a handy debug class that returns the value it is passed in:

package project2;

public class Debug {
    public static <T> T debug(T object, Object... objects) {
        return object;
    }
}

You can then put this in your scripts, for example in this derived attribute on a view object:

You can then inspect both the value you have calculated along with any parameters you have passed in using the debugger:

It seems that by default the groovy scripts are not compiled to bytecode which is a shame as you can't step out into the groovy code; but this little hack can help in certain situations. Thank to my co worker Alan Davis for pointing out that there way a simpler method than generating a class with the client "breakpoint" bytecode in it :-).

Know which class you want but not which library?

This little feature in JDeveloper often goes unnoticed as people assume the search box filters on the library name. In fact it searches all library definitions for classes of the given name:

Don't need it very often; but when you do it is a god send.

Taking on the Spring Extension for JDeveloper

Had some interesting news that our team in the UK is taking over the Spring tooling in JDeveloper. There has been for a long while support for Spring tooling provided as an optional extension written by Duncan Mills. This will be the first time that a team has been able to work on it full time.

Of course don't expect to see anything that is the result of this change until a release after R11 PS1*. We would of course be interested to hear any views and opinions on what lovely** new features that related to Spring integration that users would be interested in.

_{* Standard disclaimer, this statement shouldn't be taken as a promise that we will ship this feature at any point in the future. Nor does it promise we will ever ship another version of JDeveloper.}

_{** The lovelyness of your new feature may down as well as up}

How to have more than one instance of AWT

I have been pondering a problem with the Costello, the test recording tool in Abbot. The one main draw back to this tool is that you can't access the recording window then the application you are testing has a modal dialog showing. This is a sever limitation that we can work around to some extent by modifying the window exclusion type for the Costello window after it is shown.

import abbot.editor.Costello;
import abbot.editor.ScriptEditorFrame;


{
  ...

  Costello.showCostello(ec);


  for (Frame next : Frame.getFrames() )
  {
    if (next instanceof ScriptEditorFrame)
    {
      next.setModalExclusionType(
        Dialog.ModalExclusionType.APPLICATION_EXCLUDE);
    }
  }

  ...
}

This is fine if you can accept that dialogs that used to be modal on Costello are no longer; but this is likely to cause bugs as the developer of Costello wasn't expecting this. (What does it mean to have two file open dialog up at the same time?)

(Anybody who believes in the sanctity of the Event Dispatch Thread please look away now, this means you Alex)

Underneath the covers swing makes use of the AppContext class to maintain the settings of a particular "instance" of AWT. For most cases you only have the one instance; but you need more in the case of applets in order to isolate them from each other. Each AppContext also has its own event thread so a deadlock in one applet cannot affect another. (Useful for helping a user when say JDeveloper deadlocks)

The actual AppContext is contained within a kinda inheritable-ThreadGroup-local variable. By default all thread groups will default to default "main" AppContext; but if you create a new ThreadGroup and an AppContext every thread and group under this will make use of the new context. Consider the following code that puts up a frame with a modal child window both on the "default" AppContext and a new AppContext created for just this occasion:

import sun.awt.AppContext;
import sun.awt.SunToolkit;

...

public static void main(String[] args) throws Exception {
    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    new Example("Main Event Thread");

    ThreadGroup group = new ThreadGroup("SomeOtherGroup");
    new Thread(group, "Start Another Frame") {
            public void run() {
                // Create a new appContext
                AppContext appContext = SunToolkit.createNewAppContext();
                // Create a second frame, independent from the first
                new Example("Other Event Thread");
            }
        }.start();
}

You end up with two windows each able to show a modal dialog at the same time. You can just about make out the different look and feels:

A quick look at the debugger shows that indeed we do have two independent event dispatch threads:

The only thing that is shared between the different AppContext is java.awt.Component.LOCK which is a bit of a pain. I am thinking about logged a bug saying that the tree lock should be on the AppContext to prevent one from blocking another. You can see this would be quite a trivial DOS applet attack. The most obvious work around is to re-load the classes in a separate class loader; but that presents some interaction issues so I will leave that as an exercise to the reader.

Suspend thread in JDeveloper debugger

Just found this little feature whilst working on a narly abbot issue. Basically it allows you to "stop" a thread from executing. This is really useful when debugging threading issues as you can use it to rule out a particular thread as to be the one causing the issue.

It would have been nice if there was a "suspend all other" threads action; but I have logged a bug for this so hopefully there will be one day.