fidzu : JBoss

30 Jul 2010 3:37pm GMT

Guys,

If you haven't checked out our Vimeo channel yet (http://vimeo.com/channels/118841) now is a great time to do so. Alongside videos of how to build and deploy the project we have just uploaded our latest exposé on you can administer the BlackTie domain using our RHQ plugin.

Enjoy!

BlackTie Graphical Administration from Tom Jenkinson on Vimeo .

30 Jul 2010 10:53am GMT

So since the last tab sweep I have accumulated quite some links.First and foremost there is the Release of RHQ 3.0 (final). As we are phasing out the word "Jopr", the Jopr bits are now always included in RHQ.This release has been reflected in other publications likeTranslated announce on Opennet.ruDZone summary of RHQ 3 articlestfw.ruNews article at Jaxenter.deRHQ 3 has a new bundle provisioning

30 Jul 2010 8:47am GMT

So since the last tab sweep I have accumulated quite some links.First and foremost there is the Release of RHQ 3.0 (final). As we are phasing out the word "Jopr", the Jopr bits are now always included in RHQ.This release has been reflected in other publications likeTranslated announce on Opennet.ruDZone summary of RHQ 3 articlestfw.ruNews article at Jaxenter.deRHQ 3 has a new bundle provisioning

30 Jul 2010 8:47am GMT

Joseph from the RHQ team has written a good article on how the different compiler options (num workers, Xmx, Xms) affect the overall compilation time: http://josephmarques.wordpress.com/2010/07/30/gwt-compilation-performance/

30 Jul 2010 7:44am GMT

A few weeks ago I noticed that the coregui module of RHQ, which is the next generation web interface written in GWT (SmartGWT to be precise), started to have its compilation slow down…noticeably. Not only did the overall time to compile the module increase, but during the build my box seemed to more or less locked up. Even mouse gestures were choppy. So…I decided to investigate.

I started by writing a script that would compile the coregui module for me. It was important to gauge how the different arguments to the maven gwt:compile goal (http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html) would affect the system during the build. After reading through the documentation, I decided that 'localWorkers' and 'extraJvmArgs' were the two most important parameters to test different permutations for. Here is the script I came up with:

#!/bin/sh

# INTERVAL - the minimum amount of memory to use for gwt:compile
# STEPS    - the number of increments of interval
#            e.g. 4 steps of 256 interval = tests of 256, 512, 768, 1024
#            e.g. 5 steps of 200 interval = tests of 200, 400, 600, 800, 1000
# RUNS     - number of iterations at each (INTERVAL,STEP)

INTERVAL=256
STEPS=4
RUNS=10

declare -a AVERAGES
declare -a VARIANCES

function build
{
    workers=$1
    memory=$2

    dirName="workers-${workers}-memory-${memory}"
    vmArgs="-Xms${memory}M -Xmx${memory}M"

    mvnArgs="-Pdev -DskipTests -o"
    gwtWorkers="-Dgwt-plugin.localWorkers=\"$workers\""
    gwtJvmArgs="-Dgwt-plugin.extraJvmArgs=\"$vmArgs\""
    gwtArgs="$gwtWorkers $gwtJvmArgs"

    cmd="mvn $mvnArgs $gwtArgs gwt:clean install"
    echo "Executing $cmd"

    total_seconds=0
    rm -rf "target/runs/$dirName"
    mkdir -p "target/runs/$dirName"
    declare -a raws
    for run in `seq $RUNS`
    do
        outputFile="target/runs/$dirName/output.${run}.log"

        before=$(date +%s)
        eval "$cmd" > $outputFile
        after=$(date +%s)

        elapsed_seconds=$(($after - $before))
        raw[$run]=$elapsed_seconds
        total_seconds=$(($total_seconds + $elapsed_seconds))

        echo "Run $run Took $elapsed_seconds seconds"
        echo "Execution details written to $outputFile"
    done 

    average_seconds=$(expr $total_seconds / $RUNS)

    let "index = (($workers - 1) * 4) + ($memory / $INTERVAL) - 1"
    AVERAGES[$index]=$average_seconds

    sum_of_square_deltas=0
    for run in `seq $RUNS`
    do
       let "sum_of_square_deltas += (${raw[$run]} - $average_seconds)**2"
    done
    let "variance = $sum_of_square_deltas / ($RUNS - 1)"
    VARIANCES[$index]=$variance

    echo "Run Total: $total_seconds seconds"
    echo "Run Average: $average_seconds seconds"
    echo "Run Variance: $variance"
}

function run
{
    for workers in `seq 4`
    do
        for offset in `seq $STEPS`
        do
            memory=$(($INTERVAL * $offset))
            build $workers $memory
        done
    done
}

function print
{
    echo "Results"
    printf "          "
    for headerIndex in `seq 4`
    do
        printf "% 12d" $headerIndex
    done
    echo ""

    for workers in `seq 4`
    do
        let "memory = $workers * $INTERVAL"
        printf "% 10d" $memory
        for offset in `seq $STEPS`
        do
            let "index = ($workers - 1) * 4 + ($offset - 1)"
            printf "% 6d" ${AVERAGES[index]}
            printf "% s" "("
            printf "% 4d" ${VARIANCES[index]}
            printf "% s" ")"
        done
        echo ""
    done
}

if [[ $# -ne 1 ]]
then
    echo "Usage: $0 "
    exit 127
fi

rhq_repository_path=$1
cd $rhq_repository_path/modules/enterprise/gui/coregui

echo "Performing timings..."
run
print
echo "Performance capture complete"

In short, this will build the coregui module over and over again, passing different parameters to it for memory (JVM arguments Xms/Xmx) and threads (GWT compiler argument 'localWorkers'). And here are the results:

The columns refer to the number of 'localWorkers', effectively the number of concurrent compilation jobs (one for each browser/locale). The rows refer to the amount of Xms and Xmx given to each job. Each row represents statistics for the build being executed ten times using the corresponding number of localWorkers and memory parameters. The primary number represents the average time in seconds it took to compile the entire maven module. The parenthetical element represents the variance (the square of the standard deviation).

So what does this grid tell us? Actually, a lot:

• End-to-end compilation time suffers when using a single localWorker (i.e., only one permutation of browser/locale is compiled at a time). Not only does it suffer, but it has a high variance, meaning that sometimes the build is fast, and sometimes it isn't. This makes sense because the compilation processes are relatively independent and generally don't contend for shared resources. This implies the compilation is a natural candidate for a concurrent/threaded solution, and thus forcing serialized semantics can only slow it down.
• The variance for 2 or more localWorkers is generally low, except for the lower right-hand portion of the grid which starts to increase again. This also makes sense because, for the case of 4 threads and 1GB memory each, these concurrent jobs are exhausting the available system memory. This box only had 4GB ram, and so all of the physical memory was used, which starts to spill over to swap, which in turn makes the disk thrash (this was verified using 'free' and 'iostat'). Regardless of what other activities were occurring on the box at the time as well as how the 4 threads are interleaved, it has an effect on the build because approximately ½ GB was being swapped to my 7200rpm disk during the compilation. (Granted, I could mitigate this variance by replacing my spindles with an SSD drive (which i may end up doing) but it is nonetheless important to be mindful of the amount of memory you're giving to the entire compilation process (all workers threads) relative to the amount of available physical RAM.)
• The 512MB row has values which are relative minimums with respect to the other timings for the same number of localWorkers given different memory parameters. This indicates that 512 is the sweet spot in terms of how much memory is needed to compile the modules. I would surmise that the cost of allocating more memory (256MB or 512MB for each of 2, 3, or 4 worker threads) and/or the cost of GC largely accounts for the slightly decreased performance with other memory settings. And then, as mentioned above, with lots of threads and very high memory, swapping to disk starts to dominate the performance bottleneck.
• Aside from end-to-end running time, it's also important on a developer system to be able to continue working while things are building in the background. It should be noted that each worker thread was pegging the core it ran on. For that reason, I'm going to avoid using 3 or 4 workers on my quad-core box because my entire system crawls due to all cores being pegged simultaneously…which is exacerbated in the case of high total memory with 3 or 4 workers causing swapping and disk thrashing alongside all my cores being pegged.

Conclusions:

On my quad-core box with 4 gigs of RAM, the ideal combination is 2 localWorkers with 512MB. The end-to-end build will consistently (recall the low variance) complete just as quickly as any other combination (recall the low average running time), and it won't peg my box because only half of my cores will be used for the GWT compilation, leaving the other half for other processes i have running…eclipse, thunderbird, chrome, etc.

So what happens now if I take and move this script over to a larger box? This new box is also a quad core, but has a faster processor, and more than twice the amount of RAM (9 gigs). From everything deduced thus far, can you make an intelligent guess as to what might happen?

….

I anticipated that with more than twice the amount of RAM, that the worse-case permutation (4 localWorkers with 1GB of Xms/Xmx each) would cause little to no swapping. And with a more powerful processor, that the average running times would come down. And that is exactly what happened:

With nearly non-existent variance, it's easy to see the net effect of having plenty of physical resources. When the processes never have to go to swap, they can execute everything within physical RAM, and they have much more consistent performance profiles.

As you can see, adding more cores does not necessarily yield large decreases for the end-to-end compilation time. This can be explained because (at the time of this writing) RHQ is only compiling 6 different browser/locale permutations. As more localizations are added in the future, the number of permutations will naturally increase, which will make the effect of using more cores that much more dramatic (in terms of decreasing end-to-end compilation times).

Unfortunately, the faster processor on the larger box still got pegged when compiling coregui. So since 3 or 4 localWorkers doesn't result in dramatically improved end-to-end compilation times, it's still best to use 2 localWorkers on this larger box. I could, however, get away with dropping the memory requirements to 256MB for each worker, since the faster hardware seems to even out the the performance profile of workers given different memory parameters holding the localWorkers constant.

Lessons learned:

• In any moderately sized GWT-based web application, the compilation may take a considerable portion of each core it executes on, perhaps even pegging them at 100% for a portion of the compile. Thus, if you want your development box to remain interactive and responsive during the compilation, make sure to set the localWorkers parameter to something less than the number of cores in your system.
• Don't throw oodles of memory at the GWT compilation process and expect to get a speedup. Too much Xms/Xmx will cause the worker threads to spill out of main memory and into swap, which can have a detrimental affect on the compilation process itself as well as other tasks on the box since I/O requests explode during that time. Modify the script presented here to work with your build, and obtain reasonable timings for your GWT-based web application at different memory levels. Then, only use as much RAM as is required to make the end-to-end time reasonable while avoiding swap.
• Provide reasonably conservative default values for localWorkers and Xms/Xmx so as not to give a negative impression to your project's contributors. Err on the side of a slow build rather than a build that crushes the machine it runs on.
• Parameterize your builds so that each developer can easily override (in a local configuration file) his or her preferred values for localWorkers and Xms/Xmx. Provide a modified version of the script outlined here, to allow developers to determine the ideal parameter values on each of their development boxes.

Other tips / tricks to keep in mind:

• Only compile your GWT application for the browser/locale permutation you're currently developing and testing on. There's no need to compile to other languages/locales if you're only going to be testing one of them at a time. And there's no need to compile the applications for all browser flavors if the majority of early testing is only going to be performed against one of them.

Recall at the start of this article I was investigating why my box seemed to be non-responsive during the compilation of coregui. Well it turns out that one developer inadvertently committed very high memory settings, which as you've now seen can cause large amounts of swapping when localWorkers is also high. The fix was to lower the default localWorkers to 2, and reduce the memory defaults to 512MB. As suggested above, both values are parameterized in the current RHQ build, and so developers can easily override either or both to their liking.

Tagged: gwt , java

30 Jul 2010 5:42am GMT

In looking back at my JavaFX… does it have a future? posting, my views have been changed by some of the comments made (here and here), in particular about JavaFX vs. Flash/Flex and Java Web Start.

JavaFX and applets

I agree that comparing JavaFX applets vs Flash/Flex is not something we should be doing. Flash applications (deployed inside the browser in a Flash virtual machine) are years ahead of Java applets. It will take years, if at all, for applets to match Flash-like deployment. According to Adobe, Flash is already installed on 99% of Internet-enabled desktops. In case it's not available, installing Flash is a breeze (plus Google Chrome now ships with Flash player). Flash applications are installed very quickly, work, run smoothly inside the browser, and users are comfortable using such applications.

JavaFX and Java Web Start

On the other hand, deploying JavaFX applications via Java Web Start is an area where JavaFX could be successful and find a niche market.

A JavaFX application started via Java Web Starts runs in its own "Java window" outside the browser. This way the application is still running inside the powerful Java virtual machine, so you get a rich and responsive user interface that is also now browser-independent.

Launching via Java Web Start can be easily done by placing a link to a .jnlp file inside a Web page or even creating an icon on a desktop. Now we get the power of Java but outside the browser. However, the application still acts like a "Web application" since Java Web Start will check for any updates in the application and download them if necessary (like Adobe AIR). This way the user is always be running the latest version of the application.

For example, click here to launch JavaFX Seam Booking application via Java Web Start (note: the .jnlp file is generated in this case). Or click on this nice button:

It launched pretty fast, has its own window, no browser freezing, pretty nice.

Although I don't see many consumers-facing applications deployed using Java Web Start (even thought it's possible and some might), the target market is enterprise applications (or Internet business applications) such as customer support applications, rich interactive dashboards, scientific applications, educational applications, and other Intranet-based applications. For example, just replacing all Swing deployments in the enterprise would give JavaFX a huge potential market opportunity.

JavaFX and enterprise

Connecting JavaFX Web Start applications to a server is easily done with the Exadel Flamingo framework. This framework was designed from the ground up to make it simpler to attach rich UIs like JavaFX to back ends like Seam.

Furthermore, a growing requirement is to make Web applications available offline or when there is no Internet connection available. As the platform for JavaFX is the Java virtual machine, the offline feature can be more easily implemented than if the browser were the platform. And, if using the Flamingo framework, it already includes offline features that enable the application to run without an Internet connection and synchronize with the server once the connection is reestablished.

Future?

I always believed before that running JavaFX applications inside the browser was the way to go. While it's still possible (and easily done), I don't believe that's the way to go anymore. The browser is a platform; the Java virtual machine is another platform. There is no need to combine the two.

29 Jul 2010 9:21pm GMT

I'm happy to announce the first beta release of IronJacamar 1.0 which implements the Java EE Connector Architecture 1.6 specification.

Full release notes are here.

IronJacamar

We have rebranded the project to IronJacamar, since JBoss JCA was simply too boring a name.

This means of course that we have changed our web site and documentation URLs.

Certified

We have certified the Beta1 release against the Java EE Connector Architecture 1.6 TCK, which means that the release implements Chapter 3.5 of the specification.

This basically means that full outbound communication is supported, so we want to hear about your success with the release.

The distribution also features all of our extensions and tools

• Embedded environment with ShrinkWrap support
• Arquillian support for the embedded environment
• Validator chain for resource adapter archives
• Code generator which can generate a full development environment including a test suite

So check out our documentation on how to get started !

The Road Ahead

We are now working on integrating the container into the upcoming JBoss Application Server 7.0 release series and of course we will keep enhancing the distribution and our tools.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

29 Jul 2010 2:02pm GMT

29 Jul 2010 10:01am GMT

Earlier this morning Adobe announced their intention to acquire Switzerland-based Day Software, makers of the Web Content Management (WCM) products. Day Software contributes a lot to open source, including major contributions to the Jackrabbit, Sling, Chemistry, and other Apache open source projects that serve as a foundation for their products.

Adobe, on the other hand, is known for their proprietary products, including CS5, Illustrator, Dreamweaver, and the Flash platform and development tools, but not really well-known as an open-source company. The FAQ on the acquisition doesn't really mention open source (or Apache), so it was interesting to read Jukka Zitting's take. Jukka is a committer on multiple Apache projects and is an Apache mentor and PMC chair for Jackrabbit.

People outside of Adobe and Day are also raising questions about what this means, especially when the news comes with no mention of Day's open source contributions. Boris Kraft, CTO at Magnolia International (another CMS/WCM vendor), gave his impressions of the deal. Magnolia a nice product (which we use at JBoss.org) that runs on top of a JCR repository. As Boris mentions, Magnolia currently uses Jackrabbit but is really independent of any single JCR - and can in fact run on ModeShape.

Do your projects or products use Jackrabbit, and if so does this news give you concern? There's no better time to look at ModeShape, the open source JCR 2.0 repository that bundles in federation, sequencing, and whole host of other slick features.

29 Jul 2010 4:38am GMT

One of the unique features in RichFaces is its power and flexibility. If you don't want or need to deal with JavaScript then you use controls such a4j:support, a4j:commandButton, a4j:commandLink, a4j:poll, and a4j:jsFunction to fire and Ajax request and perform partial page updates. On the other hand, if you need more flexibility or looking for more fine-grained control over what happens before and after an Ajax request, RichFaces offers such feature. The feature is usually referred to as JavaScript interactions and allows you to tap into the Ajax request before and after the request.

There are three places where you can add or inject any custom JavaScript function:

For following example has all three events defined (onsubmit, onbeforedomupdate, oncomplete):

<h:selectOneMenu value="#{bean.text}">
   <f:selectItem itemValue="United States" itemLabel="United States"/>
   <f:selectItem itemValue="Australia" itemLabel="Australia"/>
   <f:selectItem itemValue="United Kingdom" itemLabel="United Kingdom"/>
      <a4j:support event="onchange" reRender="text"
          onsubmit="if(!confirm('Are you sure you want change the country?')) 
                {form.reset(); return false;};"
          oncomplete="alert('Country changed. We told you so.')"
          onbeforedomupdate="alert('Just before DOM update')"/>
</h:selectOneMenu>
 
<h:outputText value="Current selection:"/>
<h:outputText id="text" value="#{bean.text}"/>

First you will see the message "Are you sure you want to change the country"?. You will then see "Just before DOM update". At this point the response has come back but the DOM hasn't been updated. Lastly, after the DOM has been updated you will see "We told you so".

When using a4j:commandButton or a4j:commandLink, onclick attribute is used instead of onsubmit:

<a4j:commandButton value="Click" onclick="alert('hi');"/>

Complete summary of all tags and which attributes are supported:

This is a very powerful feature and allows you to invoke any JavaScript at three points during an Ajax request. Also, these are client-side events which means they are processed in the browser.

28 Jul 2010 9:43pm GMT

JSF 2 provides two new scopes on top of the standard Servlet scopes (request, session, application). One of them is the view scope. View scope was covered in Managed beans article. The other scope is Flash which I'm going to cover here. Let's start with a very simple example.

Managed bean:

@ManagedBean(name = "bean")
public class Bean {
   private String text;
   // getter and setter
 
   public String nextpage (){
       return "page2";
   }
}

As scope is not specified, the default scope is request.

JSF page (page1.xhtml):

<h:form>
   <h:panelGrid>
        <h:outputText value="Text:" />
        <h:inputText value="#{bean.text}" />
        <h:commandButton action="#{bean.nextpage}" value="Click" />
   </h:panelGrid>
</h:form>

JSF page (page2.xhtml):

<h4>#{bean.text}</h4>

This application is very simple. The first page will render this (shown after entering text):

Once button is clicked, we navigate to the next page and text value is displayed:

One thing to note. We didn't define a navigation rule in JSF configuratin file. We used JSF 2 implicit navigation feature:

public String nextpage (){
       return "page2";
 }

JSF will try to locate page called page2.xhtml and navigate to it. Navigation was was covered in this article.

Another thing to keep in mind that by default JSF does server forward when it invokes navigation. You probably noticed this this causes the URL in browser address bar always be one behind the actual page. This happens because we do a postbback (submit the page to itself) but return a different page to the browser.

One way to solve this problem is to use a redirect. A redirect can be defined in JSF configuration file or also added to our implicit navigation:

public String nextpage (){
       return "page2?faces-redirect=true";
 }

Running the application with above change and navigating to the second page will produce an empty page. When using a redirect, a page is submitted and once we reach the navigation step, the server sends the browser back a response telling it to send a new request to a specified URL. Now, this URL now matches the actual page we would be displaying. While we solved the URL/page matching problem, we now created another problem. As the browser sends a new request, any request-scoped objects will be recreated (or the old one gone). As our bean was in request scope, a new one was created and we lost the original text. That's where the new Flash scope can help us.

Objects placed inside the Flash scope will be available for the subsequent request and then cleared. In other words, objects placed in Flash scope will survive a redirect. The Flash scope is very similar to temporary Seam conversation.

To place an object into Flash scope we use this:

public String nextpage (){
   JSFUtils.flashScope().put("bean", this);   
   return "page2?faces-redirect=true";
 }

public class JSFUtils {
   public static Flash flashScope (){
        return (FacesContext.getCurrentInstance().getExternalContext().getFlash());
   }
}

Then, to read the values from Flash scope on the result page, we update the page like this:

<h4>#{flash.bean.text}</h4>

this will also work:

<h4>#{flash['bean'].text}</h4>

View scope wouldn't work here as it works when we are staying on the same view (page). In our case, we navigated to a different view (page).

27 Jul 2010 8:44pm GMT

I and members of the Drools and jBPM teams will be attending two conferences in October. Rules Fest and RuleML, both are great conferences that I strongly recommend to anyone wanting increase their understanding of rules, cep, workflow or semantics. Rules Fest will also be doing an all day Drools Boot Camp, where we will cover Drools basics and help people with questions on their projects and architectures.

RuleML


The International Web Rule Symposium has evolved from an annual series of international workshops since 2002, international conferences in 2005 and 2006, and international symposia since 2007. This year, the 4th International Web Rule Symposium (RuleML-2010) will be held near Washington, DC, USA. RuleML-2010 is devoted to practical distributed rule technologies and rule-based applications, which need language standards for rules (inter)operating in, e.g., the Semantic Web, Enterprise Systems, Intelligent Multi-Agent Systems, Event-Driven Architectures, and Service-Oriented Applications.
Want to Sponsor RuleML?
Registration, Early Bird Specials still available

Rules Fest 2010


Rules FestTM is the world's only technical conference devoted to the practical application of all rule-based and knowledge-based reasoning, inferencing, and decisioning technologies.

Rules Fest brings you the best and brightest speakers from industry, academia, and private research to share practical knowledge and techniques for creating, utilizing, and managing software that incorporates rule engines, inference engines, logical reasoners, or other rule-based and reasoning technologies.

Rules Fest exists to serve the:

• Architects
• Engineers,
• Developers, and
• Programmers

who use these technologies to solve complex information processing and decision-making problems.

Want to Sponsor Rules Fest
Registration, Early Bird Specials still available

27 Jul 2010 8:19pm GMT

I've composed a series blog entries on Ode architecture, because riftsaw leverages the Ode's bpel runtime, so it applies to the riftsaw project also, hope it will help you easily understood how riftsaw works.

1. Bpel Compiler and its internal model.
2. Jacob framework.
3. Ode's architecture and module introduction.
4. BpelServer API illustration.
5. Architecture of simple scheduler module.

27 Jul 2010 12:17pm GMT

I guess many people are often "unsatisfied" with how JSF works and how much time it sometimes takes to do a simple thing. That's why we are trying out a new combination: RoR for the frontend and CDI for the backend. How?

Deploying RoR applications to JBoss AS is really easy thanks to the TorqueBox project. You just deploy a .yml file using the provided rake tasks and you can develop the application "live" - no redeploys, instant changes, and so on.

Using RoR as a frontend to a CDI/Weld based application requries two more steps, so that RoR can see the business logic classes and share the same http session with CDI (so it's possible to access @SessionScoped beans from RoR and CDI code).

First you need to deploy your application in the DefaultDomain (at least until TORQUE-85 is fixed). To do this, add a jboss-classloading.xml file to the META-INF directory with this content:

<classloading xmlns="urn:jboss:classloading:1.0"
              domain="DefaultDomain"
              top-level-classloader="true"
              export-all="NON_EMPTY"
              import-all="true">
</classloading>

Secondly, you need to add a filter to RoR's web application, so that Weld and RoR share the same session. Just edit config/web.xml in your RoR application (the magic in the RoR deployer will add it to the virtual .war deployment it creates) and add the following:

<web-app>
    <listener>
        <listener-class>org.jboss.weld.servlet.WeldListener</listener-class>
    </listener>
</web-app>

Now RoR and CDI share the same session (so you can use @SessionScoped beans etc, probably also @ConversationScoped, but I haven't tried that). You can lookup CDI beans from RoR code using e.g. the BeanInject class from cdi-ext, or just by writing a very simple utility method which lookups the BeanManager.

Adam

27 Jul 2010 12:07pm GMT

When designing complex software system, modularity in one of the key aspects that folks have in mind. When I say "complex" I mean more than a handful of subsystems that evolve with individual life cycles and are developed by possibly geographically disconnected teams. Key to success are well defined integration points that also have the flexibility to evolve.

Naturally you separate API from implementation and have some way or another to discover/load the implementation for a given API. If your chosen infrastructure is worth telling your friends about, it supports multiple versions of any API and can dynamically start/stop/update the services that your subsystems use to collaborate with each other. The installed pieces form consistent class spaces with the same class possibly loaded multiple times in different versions and wired such that shared types are loaded from the same source. Any container environment that supports user defined plugins would have requirements similar to these. Take Eclipse , or a J2EE application server for example. 

As my colleague Hal puts it

"OSGi is like toilet paper, sooner or later you are going to want to use it. "

Capabilities and Requirements 

An OSGi bundle is an ordinary jar with a couple of standard headers in its Manifest. Here I list a few important ones as a reference. The exhaustive set can be found in the OSGi Core Specification.

Bundle-SymbolicName: com.acme.daffy

The Bundle-SymbolicName header specifies a non-localizable name for this bundle. The bundle symbolic name together with a version must identify a unique bundle.

Bundle-Version: 1.1

The Bundle-Version header specifies the version of this bundle

Export-Package: org.osgi.util.tracker;version=1.3

The Export-Package header contains a declaration of exported packages.

Import-Package: org.osgi.util.tracker,org.osgi.service.io;version=1.4

The Import-Package header declares the imported packages for this bundle.

Require-Bundle: com.acme.chess

The Require-Bundle header specifies that all exported packages from another bundle must be imported, effectively requiring the public interface of another bundle.

In an abstract way, the bundle headers form a set of Capabilities that a bundle provides and another set of Requirements that a bundle has on the environment or other bundles. In most cases Requirements can be mandatory or optional and in some cases Requirements can be satisfied by Capabilities from the same bundle.

When the Framework makes a connection between a Requirement and a Capability it is said to have established a Wire . This happens at the RESOLVE phase of a bundle. The details of how an OSGi Framework works out the wires between the bundles is not our subject. Instead it is sufficient to know that every OSGi Framework implements this non-trivial, non-linear OSGi resolution algorithm in one way or another. Some Frameworks do this more successful than others and a distinguishing metric would be the success/error response time and ability to form consistent class spaces that include if not all but most of the installed bundles.

Why use a standalone Resolver

For most use cases the OSGi resolution algorithm is an implementation detail at the Framework level that you don't need to worry about. You install a few Bundles, start them or trigger a class load on an installed bundle and the Framework resolves the installed bundles transparently. Although there is an API method on the PackageAdmin to resolve bundles explicitly it is not what you would do normally.

The need for a resolver comes into the game when you want to do impact analysis or provide a smart repository. Impact analysis is when you have a running system and want to know if a set of bundles would resolve on that system without actually modifying the system. With a smart repository you can say, if have these requirements, give me the bundles that I need to install to provide the needed capabilities.

The Apache Felix Resolver

Every other month, when we both can make it, I meet Richard at the Enterprise Expert Group (EEG) meetings. Richard rewrote Felix resolver to work on the general notion of capabilities and requirements. This is part of felix-framework-3.0.1 and forms the foundation of what comes next.

Standalone Resolver Requirements

We had a number of requirements on an OSGi Resolver that I'd like to share with you here:

• Independent of Core Framework implementation
• Not bound to the Manifest as the meta data provider
• Works on abstract notion of Module, Capability, Requirement, Wire
• Explicit wiring for all mandatory requirements
• Easy and intuitive user API
• Extensible SPI for Resolver providers
• Sensible default implementation stubs for Resolver providers
• Callbacks for framework integration and resolved modules
• Attachment support on various resolver atrifacts

Every framework parses/validates and caches the Manifest. So we did not want the resolver to do this again. Instead we provide a resolver meta data model that can be constructed in memory (i.e. mapped to from whatever the framework uses internally). Additionally, we provide an OSGi meta data model that can also be constructed in memory or from the Manifest.

In the JBoss Application Server we provide an OSGi view for non-OSGi deployments and the ability to access/inject OSGi services in other component models. For example CDI components can have OSGi services injected and vice versa. You will see this functionality in AS7. For that reason the resolver needs to work on the abstract notion of Module, Capability, Requirement which may come from non-OSGi deployments that nevertheless take part in OSGi resolution.

If a module is resolved, it is guaranteed that every mandatory Requirement has a Wire to a Capability.

Resolver clients can register callbacks to get informed when the Resolver changes the wiring for a Module.

The Resolver object model can have arbitrary state attached to it, which removes the need to map client state to resolver state and vice versa.

Working with the Resolver

The jbosgi-resolver project is hosted on GitHub together with all the other JBoss OSGi projects that we currently work on.  When you use Maven , you can declare a dependency on the resolver like this:

<dependency>
  <groupId>org.jboss.osgi.resolver</groupId>
  <artifactId>jbosgi-resolver-api</artifactId>
  <version>1.0.0</version>
</dependency>
<dependency>
  <groupId>org.jboss.osgi.resolver</groupId>
  <artifactId>jbosgi-resolver-felix</artifactId>
  <version>3.0.1</version>
</dependency>

<repository>
  <id>jboss-public-repository-group</id>
  <name>JBoss Public Maven Repository Group</name>
  <url>https://repository.jboss.org/nexus/content/groups/public/</url>
  <layout>default</layout>
  <releases>
    <enabled>true</enabled>
    <updatePolicy>never</updatePolicy>
  </releases>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>never</updatePolicy>
  </snapshots>
</repository>

Lets start by creating a Resolver instance and add a Module to it that has its Capabilities and Requirements populated from Manifest.

// Create a resolver instance
XResolver resolver = XResolverFactory.getResolver();

// Create the resolver module
XModuleBuilder builder = XResolverFactory.getModuleBuilder();
XModule module = builder.createModule(1, manifest);

// Add the module to the resolver
resolver.addModule(module); 

Now you would create and add a few more modules until you actually trigger the resolve process

// Resolve the modules and report resolver errors
Set resolved = resolver.resolveAll(unresolved);
for (XModule resModule : unresolved)
{
   if (resModule.isResolved() == false)
   {
      Exception ex = resModule.getAttachment(XResolverException.class);
      log.error("Cannot resolve: " + resModule, ex);
   }
} 

The resolver uses the above mentioned Attachement API to feed back the individual resolve exceptions. You can also register a ResolverCallback when you need to do locking or want to get informed about resolver progress.

A few changes were necessary to felix-framework-3.0.1 to abstract resolver dependencies on actual framework implementation. These can be picked up here .

May this be useful

27 Jul 2010 12:56am GMT