What the FuseSource team is saying

  • We Only Notice When It Is Bad

    by Eric J. on Thu May 10 15:30:00 UTC 2012

    One of the frustrating things about working in technical documentation is that people only notice the documentation when their is something wrong with it. Customers rarely mention that the documentation is excellent because they just expect it to be complete and thorough. The comments only ever come in when the documentation does not meet a customer's needs. Sometimes the complaints about the documentation are really about a lack in the actual product, but the user only notices it when it they are looking at the documentation.
    This fact has several impacts on documentation teams:
    The most obvious is that writers can easily get demoralized. It is imperative for internal customers-the tech support team, the sales team, the development managers, the product managers-provide some positive feedback. The documentation team will get plenty of negative feedback, so there is no danger that their heads will swell.
    Because customers rarely think about the documentation, they rarely provide requirements for the documentation. This means that the product management team rarely provides detailed guidance for the documentation team. Most often, the guidance is that we need to document the new features. Occasionally, if a customer has complained about something it is listed as a requirement, but without any clear information about what the underlying issue the customer is having. The requirement will be something like "we need more documentation about Java development."
    The largest impact that customer's lack of thinking about documentation is that it results in a lack of investment. The lack of investment is monetary, personnel, and time. Because customer's generally don't have requirements for documentation, the impression is that it isn't important. Because the only comments that are received about documentation, the impression is that the documentation team is less than good. The result is that development teams are always looking for ways to hire less writers and squeeze more efficiency out of the documentation process. The result is that the documentation usually gets poorer and the complaints go up.
    Curating knowledge for complex technical products is an inefficient process. Dragging information out of SMEs takes time, organizing the information takes time, trying out the processes takes time. There is no real way to improves the speed of these steps. The push for modular, context free documentation is an outcrop of this push for efficiency, and it also, generally, creates poorer documentation. Context is an important part of written content.
    What can we do to address these issues? Educate internal customers about the importance of documentation. Make sure they understand that the fact that customers complain shows that they care. The fact that they don't mention the documentation probably means that the documentation team is doing a good job. As writers we need to remember that silence from the customers is the biggest compliment.

  • What's new for Stomp in ActiveMQ 5.6

    by Tim on Tue May 08 21:25:00 UTC 2012

    Version 5.6 of ActiveMQ has been a long time coming but its finally here and brings with it some great new features. In this post I'm going to cover what's new for those of you using STOMP clients to communicate with ActiveMQ.
    STOMP v1.1 Support Probably the biggest change in ActiveMQ 5.6 is that we now support STOMP v1.1 but that's not the only thing we've done, there's plenty of new goodies even if you are stuck using a STOMP v1.0 based client. With the addition of STOMP 1.1 support STOMP you get:

    • protocol negotiation to allow for interoperability between clients and servers supporting successive versions of STOMP
    • heartbeats to allow for reliable detection of disconnecting clients and servers
    • NACK frames for negative acknowledgment of message receipt
    • Support for virtual hosting.

    I won't spend a lot of time rehashing the STOMP 1.1 spec here as its laid out quite nicely in the protocol specification page here.
    Other New STOMP Features and FixesOf course support for STOMP 1.1 isn't the only thing we added to our STOMP support, there's several other new goodies in there as well. Lets take a look at what else you can now do with the STOMP Transport in ActiveMQ 5.6.

    Queue Browsing A normal subscription on a queue will consume messages so that no other subscription will get a copy of the message. If you want to browse all the messages on a queue in a non-destructive fashion, you can create browsing subscription. To make a a browsing subscription, just add the browser:true header to the SUBSCRIBE frame. For example:

    SUBSCRIBE
    id:mysub
    browser:true
    destination:/queue/foo

    ^@Once the broker sends a browsing subscription the last message in the queue, it will send the subscription a special end of browse message to indicate browsing has completed and that the subscription should not expect any more messages. The end of browse message will have a browser:end header set. Example:

    MESSAGE
    subscription:mysub
    destination:
    message-id:
    browser:end

    ^@The Queue browsing support works for both STOMP 1.0 and STOMP 1.1 clients so you don't need to upgrade your client in order to take advantage of this new feature.

    Message Selectors and Numeric ValuesPrior to the 5.6 release you couldn't specify a numeric selector expression on a STOMP subscription, this has now been fixed so you are free to subscribe to a destination via STOMP using selectors such as the following:

    SUBSCRIBE
    id:mysub
    selector:someId = 42
    destination:/queue/foo

    ^@With this subscription any JMS Message's sent to this destination with an numeric message property named 'someId' and a value of 42 will be picked up as expected.

    STOMP+NIO+SSL TransportIn 5.6 we've added NIO+SSL transports for both Openwire and STOMP clients which allow you to connect large numbers of SSL based STOMP clients to a single broker instance. You can configure a STOMP+NIO+SSL TransportConnector in you broker as follows:


    transportconnector name="stomp+nio+ssl" uri="stomp+nio+ssl://0.0.0.0:61616"

    STOMP 1.0 default heartbeat configurationUnlike STOMP 1.1 the original STOMP 1.0 does not provide for an inactivity monitor since there was no defined hear-beat capability. A client connect that stays idle will remain active on the broker indefinitely. With STOMP 1.1, the inactivity monitor has come into play in response to the heart-beat header. Since not all your clients might not be upgraded to STOMP 1.1 right away we added the capability to specify a default heart-beat value to the transportConnector so that you can still timeout idle STOMP connections. You can setup this default value on your connector as follows:

    stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0

    In the absence of a heartbeat header, as in the STOMP 1.0 case, this default value would cause an InactivityMonitor with read check interval of 5 seconds to be installed on each new broker stomp transport connection. Any client that remains inactive (sends no messages) for more than 5 seconds will have their broker connection closed. You should tune this value based on the exceptions of the behavior of you clients.

    Wrap UpI've tried to just quickly touch on some of the enhancements that we've made for those of you using STOMP clients in ActiveMQ v5.6. There's a ton of other new and improved features in 5.6 as well given that there were some 435 issues resolved for this release. I encourage you to download this new release and take it for a spin. If can ask questions on our mailing list if you run into trouble.

  • ActiveMQ 5.6.0 and other news

    by Dejan Bosanac on Tue May 08 14:22:45 UTC 2012

    We just released Apache ActiveMQ 5.6.0. It was a long-awaited maintenance release, but however there are a few very significant new features that was worth waiting for. Those include a new LevelDB store, MQTT and Stomp 1.1 protocols support and self-balancing cluster clients, to name a few. I already written about clustering here and there sure will be a lot of things to write about these other features as well in coming days.

    Also, next week Ill be at CamelOne in Boston and JEEConf In Kiev (a bit too much traveling for my taste, but there you go). Ill talk about Enterprise deployment of ActiveMQ using Fuse Fabric (a topic already covered here in a nutshell) and Apache Apollo, the next generation of the broker. All these projects that are coming in the pipeline are pushing the possibilities of our integration infrastructure one step further. It will allow people to do complex deployments easier and connect to the infrastructure from virtually everywhere. It was a very exciting first half of the year, and it looks like things are going to be even more interesting going forward.

  • Understanding how OSGI bundles get resolved part II

    by admin on Tue May 08 00:17:14 UTC 2012

    In my previous post, I introduced the rules for how bundles get resolved in an OSGI container. In this post, Id like to demonstrate each rule step using the Apache Karaf OSGI container. Karaf is based on the Apache Felix core, although the Equinox core can be substituted if desired. Karaf is a full-featured OSGI container and is the cornerstone of the Apache ServiceMix integration container. ServiceMix is basically Karaf but specifically tuned for Apache Camel, Apache ActiveMQ and Apache CXF.

    This tutorial will require Maven and Karaf. Download maven from the maven website. Download and install karaf as described in the getting started guide on the Karaf website. You will also need the code that goes along with this example. You can get it at my github repo. After getting it, make sure to run mvn install from the top-level project. This will build and install all of the bundles into your local maven repository. Although you can install bundles a couple different ways, using maven is easiest. Note that this sample code is mostly made up of package names without any real Java classes (except where the tutorial specifies).

    First thing to do is start up karaf. In a plain distribution there should be no bundles installed. Verify this by doing osgi:list at the karaf commandline. Going in order, we will test out the rules from part one of this two-part series:

    For every Import-Package package declaration, there must be a corresponding Export-Package with the same package

    To test this rule, lets install Bundle A from our sample bundles. Bundle A specifies an Import-Package of org.apache.foo package. According to the first rule, this bundle cannot move to the Resolved state since there is no corresponding bundle with an Export-Package of org.apache.foo.

    From the karaf commandline, type osgi:install mvn:explore-bundle-resolution/bundleA/1.0. This will install the bundleA bundle. Now do a osgi:list again. You should see the bundle installed, and under the State column, it should say Installed. Now try osgi:resolve bundle id where bundle id is the ID listed from the osgi:list command. This will try to resolve all bundle dependencies and put it into the Resolved state. It wont resolve, however. Type osgi:list again to see the state of the bundle. Its still in Installed state even though we asked OSGI to resolve it. Lets find out why. Execute the osgi:headers bundle id. Under the Import-Package, you should see the package name org.apache.foo listed in a red color. This dependency is missing, so lets add it. Type osgi:install -s mvn:explore-bundle-resolution/bundleB/1.0. Note the -s switch in the command. This tells OSGI to start the bundle once its installed. Now type the osgi:resolve command again (with the appropriate bundle ID). This will now resolve the bundle.

    Import-Package dictates exactly what version (or attribute) it needs, and a corresponding Export-Package with the same attribute must exist

    Lets install bundle C: osgi:install -s mvn:explore-bundle-resolution/bundleC/1.0 List the bundles again, and youll see that although bundle C depends on org.apache.foo, it specifies an Import-Package with a specific version=1.5. There is no version 1.5 that is resolved, so bundle C will also not resolve. Bundle D happens to export a package org.apache.foo with a version equal to 1.5. Install bundle D the same way weve installed the others, using the -s to start it. Now try to resolve bundle C and it should work (osgi:resolve bundle id).

    Bundles installed first are used to satisfy a dependency when multiple packages with the same version are found

    This rule says that if there are multiple packages exported with the same version, OSGI will choose the first-installed bundle to use when trying to resolve bundles that import the package. Continuing on with the previous example where we installed bundle C and D consider that bundle D exports org.apache.foo;version=1.5. So if we install bundle F that exports the exact same package and version, we should see that bundle C is resolved with the package from bundle D and not bundle F. Lets see.. install bundle F: osgi:install -s mvn:explore-bundle-resolution/bundleF/1.0. Do an osgi:list and see that both bundle D and F are correctly installed and Active. This is a cool feature of OSGI: we can have multiple versions of the same package deployed at the same time, (including in this example the exact same version). Now we should uninstall bundle C and re-install it to see which bundle it uses to resolve for its import of org.apache.foo. Try running osgi:uninstall bundle id to uninstall bundle C. Now re-install it using the command from above. It should resolve to use bundle D. Use package:import bundle id to verify. You can try switching things around to get F to resolve. You may need to use osgi:refresh to refresh the OSGI bundles.

    Bundles that have already been resolved have a higher precedence that those not resolved

    In a way, we have already seen this with the previous rule, but this rule comes into play when hot deploying. This is left as an exercise to the reader as this post is already getting pretty long and I would like to cover the uses directive next.

    Bundle uses directive

    The uses directive adds one of the last rules and constraints to avoid runtime class-cast exceptions. Please review my previous blog post for details about the uses directive. To simulate how the uses directive works, we will install bundles G, H, I, and J and notice how the container enforces the uses directive.

    Bundle G represents a sort of service module that client modules can call to execute some form of processing and return a result. The result it returns is an object of type BarClass that comes from Bundle H. But if a client makes a call to bundle G, it too must use the BarClass from bundle H or it will result in a class cast exception. In our samples, Bundle I is the client code and Bundle J represents a different version of the BarClass. Install the bundles in any order you like, but my demonstration followed this order: J, H, G, I. Note that the version of org.apache.bar is indeed the 2.0.0 version which comes from bundle H even though bundle H was installed second (contrary to the rule above). This is because bundle G specified the uses directive to depend on a specific version of org.apache.bar.

  • Apache ActiveMQ 5.6 is released

    by Rob Davies on Mon May 07 16:07:00 UTC 2012


    Apache ActiveMQ is the most widely used open source messaging solution, with many organizations using it for the reliable integration of applications across there enterprise infrastructure.

    Today, Apache ActiveMQ 5.6 has been released - its been more than a year since the last point release.This release has over 370 issues resolved, with 130 improvements including:


    • LevelDB message store.LevelDBis a fast key-value library written by google, but themessage store implementation that combines LevelDB with persistent message logs can be found infuse-extras. This message store implementation can be five times faster than the default message store implementation - KahaDB.
    • MQTT support - MQTT is an extremely light weight messaging transport designed for machine to machine devices - I described this in more detail in an earlier post.
    • Stomp 1.1 support - which adds heartbeats, NACK frames and support for virtual hosting.
    • Configuration checks - providing warnings about incorrectly configured brokers
    • Prevention of denial of services attacks



  • Apache.NMS.ActiveMQ v1.5.5 Released

    by Tim on Fri May 04 18:51:00 UTC 2012

    Announcing the official release of Apache.NMS.ActiveMQ v1.5.5. We put a lot of work into this one fixing bugs that were found since the 1.5.4 release. There was an additional issue with advisory monitoring and Temporary Destinations that was resolved in this release along with a couple other minor bugs. Also some improvements to the failover transport are included. Highlights of the things in this release:


    * Sending to non-existent temp queue causes consumer to shutdown
    * Consumers frequently fail to reconnect after broker outage/failover.
    * FailoverTransport doesn't trigger a reconnect on send of a Tracked Command.
    * ActiveMQ.NMS hangs sometimes due to concurrency problems while accessing static IDictionary
    * Apache.NMS.ActiveMQ discovery protocol throwing ArgumentOutOfRangeException

    Grab in from the Apache.NMS.ActiveMQ downloads page.

  • From inside the code: ActiveMQ Network Connectors

    by admin on Wed May 02 00:44:33 UTC 2012

    This post is more for me and any ActiveMQ contributors that may be interested in how the Network Connectors work for ActiveMQ. I recently spent some time looking at the code and thought that it would be good to draw up some quick diagrams to help me remember what I learned and help to identify where to debug in the future if there are issues I am researching. If I make a mistake and youd like to add clarification, please do so in the comments.

    First, you set up your network connectors by configuring them in the ActiveMQ configuration file. This configuration gets mapped to the corresponding ActiveMQ beans using the xbean library for which I have a separate blog post which explains exactly how this is done. To specify network connectors, you add the <networkConnectors/> element to your configuration file and add a <networkConnector/>, <multicastNetworkConnector/>, or <ldapNetworkConnector/>. These three different types of network connectors can be used to establish a network of brokers with <networkConnector/> being most common. Heres how the three map to Java classes:

    <networkConnector/> maps to org.apache.activemq.network.DiscoveryNetworkConnector
    <multicastNetworkConnector/> maps to org.apache.activemq.network.MulticastNetworkConnector
    <ldapNetworkConnector/> maps to org.apache.activemq.network.LdapNetworkConnector

    Each of those inherit from the org.apache.activemq.network.NetworkConnector super type as depicted in this diagram:

    Network Connectors Diagram

    So when you have a configuration like this:

    <networkConnector uri="static://(tcp://localhost:61626,tcp://localhost:61627)" />

    a new DiscoverNetworkConnector will be configured, instantiated, and added as a connector to the BrokerService (which is the main class for where a lot of the ActiveMQ broker details is handled). While the DiscoverNetworkConnector is being assembled from the configuration, the URI that you specify is used to create a DiscoveryAgent. The discover agent is in charge of assembling the connection and handling failover events that are packaged as DiscoverEvents. Determining which DiscoverAgent is picked depends on the DiscoverAgentFactory and the URI specified. In the case of static, the SimpleDiscoverAgent is used. Each URI in the list of possible URIs are treated differently and are assigned their own Transport (more on this in a sec). Which means, for each URI you list, a new socket will be established and the broker will attempt to establish a network connector over each of the sockets. You may be wondering how to best implement failover then? In the case described above, you will have multiple connections, and if one of those connections is to a slave that isnt listening, you will see that the connection fails and the discover agent tries to establish the connection again. This could go on infinitely which consumes resources. Another approach is to use just one URI for the static discover agent that utilizes the failover() logic:

    <networkConnector uri="static:failover:(tcp://localhost:61626,tcp://localhost:61627)" />

    In this case, only one transport will be created, and the failover logic will wrap it and know about both URIs. If one is not available, it wont keep retrying needlessly. Instead it will connect to whichever one it can and only reconnect to the failover URL if the current connection goes down. Note this approach had a bug in it before ActiveMQ version 5.5.1.-fuse-00-06.

    The discover agent is in charge of creating the bridge, but it delegates that responsibility to a DiscoverListener. In the example from above, the DiscoverListener interface is implemented by the DiscoverNetworkConnector.onServiceAdd() method.

    To establish the bridge, a transport is opened up for both the local broker (using VM) and the remote broker (using the specified protocol, in this case TCP). Once the local and remote transports are created, the bridge can be assembled in the DiscoverNetworkConnector.createBridge() method. This method uses the Factory pattern again to find which bridge to use.

    The possible bridge implementations are shown below:

    Network Bridge Implementations Diagram

    By default, with conduitSubscriptions=true, the DurableConduitBridge is used. Conduit subscriptions establish a single flow of messages to a remote broker to reduce duplicates that can happen when remote topics have multiple consumers. This works great by default, but if you want to load balance your messages across all consumers, then you will want to set conduit subscriptions to false (see the documentation for conduit subscriptions at FuseSources documentation on Fuse Message Broker). When set to false, the DemandForwardingBridge is used. Once the bridge is assembled, it is configured in the NetworkConnector.configureBridge() method.

    Once everything is assembled and configured on the bridge, its then started. Once its started, it begins sending broker Command objects to the remote broker to identify itself, set up a session, and demand consumer info from it. This is in the DemandForwardingBridgeSupport.startRemoteBridge() super class method as seen from the diagram.

    If youre debugging errors with the network connectors, hopefully this helps identify possible locations for where errors can take place.

  • ActiveMQ-CPP v3.4.2 Released

    by Tim on Sat Apr 28 22:08:00 UTC 2012

    Its official, AcitveMQ-CPP v3.4.2 has now been released.

    This is a bug fix release of the ActiveMQ-CPP client which includes some
    fixes since the v3.4.1 release. A couple important failover fixes in
    this one so grab it if you are on an earlier version.

    Some highlights for this release:

    * Some build issues on various platforms were resolved.
    * A problem with setting the username / password from the Connection
    Factory was fixed.
    * A problem with expired messages and DLQ processing was addressed.
    * An issue with the failover transport and hangs in Connection start()
    was fixed.
    * A couple of race conditions on Connection close() were addressed.

    You can download the source package from here:

  • Real Time HTML5 application with Websocket and ActiveMQ/camel

    by Charles Moulliard on Thu Apr 26 13:00:00 UTC 2012

    As part of my CamelOne presentation, I have prepared some examples to dig into what Apache ActiveMQ and Camel propose to work with HTML5 and WebSocket technology.
    Developing "Real Time Web Applications" has always beenpainfulnot matter if the technology used was based on Java Applet, Adobe Flash, Adobe ShockWave, Microsoft Silverlight and the protocol (HTTP, RMI, ...).

    Since HTML5 publication (2009) and the work done by W3C and IETF organisations, we now have a standard rfc-6455 that we can use to exchange in a bi-directional way "messages" between the browser and the Web Server. Only one HTTP(s) request is required to initiate the WebSocket communication and later on the exchange of data frames (text or bytes).

    ActiveMQ (release 5.6) like Camel (release 2.10) proposes a WebSocket Transport Connector or Endpoint using Jetty WebServer WebSocket implementation (v7.5). This allow not only to retrieve data from topics but when combining the EIP patterns of Camel and some components like : sql, jpa, file, rss, atom, twitter, ... we can "aggregate", "enrich" or "filter" content receive from feed providers before to publish them for feed consumers.

    ActiveMQ uses Stomp as a wired format to send WebSockets messages between the WebSocket server running within the ActiveMQ broker and the Web browser. In this context, we must use one of the two javascript librairies available (stomp.js, stomple) to develop the project

    $(document).ready(function() {
    var client, destinationQuotes;
    $('#connect_form').submit(function() {
    var url = $("#connect_url").val();
    client = Stomp.client(url);

    // the client is notified when it is connected to the server.
    var onconnect = function(frame) {

    var stockTable = document.getElementById("stockTable");
    var stockRowIndexes = {};

    client.subscribe(destinationQuotes, function(message) {
    var quote = JSON.parse(message.body);
    $('.' + "stock-" + quote.symbol).replaceWith("" +
    "" + quote.symbol + "" +
    "" + quote.open.toFixed(2) + "" +
    "" + quote.last.toFixed(2) + "" +
    "" + quote.change.toFixed(2) + "" +
    "" + quote.high.toFixed(2) + "" +
    "" + quote.low.toFixed(2) + "" +
    "");
    ...

    client.connect(login, passcode, onconnect);

    and of course the WebSocket protocol must be enable.

    <transportconnectors>
    <transportconnector name="websocket" uri="ws://0.0.0.0:61614">
    </transportconnector></transportconnectors>
    Camel does not need a special format to exchange the data between its WebSocket endpoint and the browser as JSon text will be send through the WebSocket Data Frames to the browser. We must just expose a Camel Route as a WebSocket Server.

    public class WebSocketStockPricesRoute extends RouteBuilder {
    @Override
    public void configure() throws Exception {

    from("activemq:topic:stockQuoteTopic")
    .log(LoggingLevel.DEBUG,">> Stock price received : ${body}")
    .to("websocket:stockQuoteTopic?sendToAll=true");

    }
    }

    and use in the browser the WebSocket HTML5 js script.

    var socket;
    $('#connect_form').submit(function () {

    var stockTable = document.getElementById("stockTable");
    var stockRowIndexes = {};
    var host = $("#connect_url").val();
    socket = new WebSocket(host);

    // Add a connect listener
    socket.onopen = function () {
    $('#msg').append('
    Socket Status: ' + socket.readyState + ' (open)
    ');
    }

    socket.onmessage = function (msg) {
    // $('#msg').append('
    Received: ' + msg.data + "
    ");

    var quote = JSON.parse(msg.data);

    ....

    In both cases, you can combine other javascript librairies (jquery, jquery-ui) to improve the design of the JSon objects to be displayed in the browser.

    Here are some screenshots about the demos

    Stock Trader
    Chat Room








    Twitter and News Feed










    Code can be retrieved from FuseByExampleweb site. Look to "websocket-activemq-camel" git hub project.

    Enjoy WebSocket with Apache Camel and ActiveMQ.

  • Great Akka and Camel presentation video from ScalaDays 2012

    by Claus Ibsen on Sat Apr 21 09:48:00 UTC 2012

    ScalaDays 2012 took place recently in London.

    I just wanted to highlight the presentation from PeterGabryanczy - Migrating akka-camel module to Akka 2.x.

    In this video Peter demonstrates how well Camel and Akka works together, showcasing demos with code that's less than a page, but still does powerful stuff, integrating mail, jms, file, akka, twitter, aws and whatnot.
    Akka Consumer Actor using camel-jetty The video is available from this link, where the video player is on the top right corner.

    In the end of the presentation Peter talks about jobs application he has built that gathers details about new Scala jobs.

    Jobs Application using Akka and Camel Peter is using Camel 2.8, and therefore the integration with twitter and AWS dynamoDB is not yet available. However the Camel team is as usual busy and in the upcoming Camel 2.10, we have these components out of the box. So Peter can build his application using all out of the box Camel components.

    In the end Peter thanks a bunch of people who have helped make this possible. I want to highlight Martin Krasser who is the original author of the akka-camel module. Martin also contributed to the Camel in Action book, where he wrote a piece on his work.

    Kudos to Martin, Peter, and the Akka Team.

  • Why Im excited to attend Camel One

    by admin on Thu Apr 19 13:57:14 UTC 2012

    Ill be attending CamelOne this year, and Im pretty excited. I didnt make it to the event last year, but judging by the speaker line up and the presentations given last year, this conference is definitely a must for developers involved in enterprise integration. Check out the presentations from last year. As you can see, the content covered is applicable even if youre not using the Apache projects. But of course if you are, all the better.

    Of course attending a conference like this and hanging out with and listening to some of the leaders in open-source integration software like James, Strachan Claus Ibsen, Jon Anstey, Rob Davies, and many others, is awesome, theres another reason to attend. Being around people who are highly dedicated to the software craft and developing best-of-breed software really gets you excited and motivated. Seeing others excited and passionate about their projects is contagious. Looking at this years conference, the speaker list and sessions here are the ones that appeal to me and I hope to get the most from:

    A Hundred Departments, Same Integration Solution

    Overview: How integration and SOA fit in a broad enterprise architecture; techniques for adding APIs to and integrating with legacy systems; design patterns for building new enterprise systems with integration in mind; techniques and code for business process management (BPM) using Camel & ActiveMQ; and how the new paradigms are enabling us to work with external partners, lower the cost of software development, and offer new innovative services.

    Next Generation Open Source Messaging with Apollo

    Overview: Apache Apollo is built from the foundations of the Apache ActiveMQ project but with a radically different threading architecture which lets it scale to large number of concurrent connections and destinations while using a constant number of threads.

    Replacing MQSeries with ActiveMQ in Large Scale Retailer

    Overview: This session will discuss the development, deployment and lessons learned in a large scale retail implementation (1,000s of stores) where we are converting from IBM MQ Series to ActiveMQ and ServiceMix in a gradual manner

    Using Apache Camel in ServiceMix

    Overview: Jon Anstey (co-author Camel in Action) will show you the best practices for deploying Camel applications to ServiceMix. Since ServiceMix is built on top of Apache Karaf, most tips are applicable to that container as well.

    Apache Camel in Action: Common Problems, Solutions and Best Practices

    Overview: Advanced topics like transaction management in Camel (XA and non XA) and when you can live without it. This talk will give examples for how to start, stop, create, or modify Camel routes at runtime. It will also cover basic questions like Java DSL vs. XML DSL, Exchange In-Message vs. Exchange Out-Message or whether you should use one or multiple Camel contexts.

    Apache Camel at a Top 3 Online Retailer

    Overview: A Top 3 online retailer recently completed a live integration of their warehouse management and fulfillment systems with those of their parent company. The integration and cutover event was described as open heart surgery on a moving train by their CEO. This presentation will highlight how Apache Camel helped to make the integration possible, and how Camel is being leveraged at the online retailer today for a variety of integration solutions. Best practices, lessons learned, and insights based upon use cases from one of the worlds largest online retailers.

    There are many others, so check out the complete list. You can use the following discount codes:

    SpeakerFriend $150 off registration
    AMQAction -$100 off, and free ebook of ActiveMQ in Action
    CamelAction $100 off, and free ebook of Camel in Action

    Hope to see you there!

  • Getting Started with Fuse ESB Webinar

    by Jonathan Anstey on Wed Apr 18 13:12:00 UTC 2012

    Last week FuseSource announced two new enterprise products: Fuse ESB Enterprise and Fuse MQ Enterprise. Both of these are currently in beta so this of course means that you can download and try them out for yourself :)
    If you want to learn more about how to get started with the new Fuse ESB Enterprise product, I'm giving a webinar next Tuesday April 24th at 11:00am EDT. You can register with the link below:

    Getting Started with Fuse ESB Enterprise 7.0

    So, what's covered? I'll be going over all the new stuff that is in this release like Fuse Fabric and FAB (Rob Davies posted some great teasers last week), but also features that Apache ServiceMix users know and love: interactive shell & OSGi container from Apache Karaf, integration flows with Apache Camel, web services with Apache CXF, and reliable messaging with Apache ActiveMQ. Basically everything you need to get started in your integration projects.
    Hope to see you (virtually) there!

  • Apache.NMS.ActiveMQ v1.5.4 released.

    by Tim on Wed Apr 18 12:29:00 UTC 2012

    Announcing the official release of Apache.NMS.ActiveMQ v1.5.4. We put a lot of work into this one fixing bugs that were found since the 1.5.3 release. There was an issue with advisory monitoring and Temporary Destinations that was resolved in this release along with a couple other minor bugs.

    Grab in from the Apache.NMS.ActiveMQ downloads page.

  • Focused, informative documentation for ActiveMQ, Camel, ServiceMix and CXF

    by admin on Mon Apr 16 15:03:43 UTC 2012

    What criteria do you use when evaluating whether to use a commercial product or open-source project to support your system-integration development? Is documentation near the top? To me it seems the commercial vendors pump out volumes upon volumes of documentation which makes finding what you need a needle in a haystack. On the other hand, open-source projects seem to have very little documentation and what they do have presupposes non-trivial knowledge of the project. Which makes total sense to me. The commercial vendors are trying to sell you on the multitude of capabilities their product supposedly has, so they better have reams of documents to show somebody. The open-source developers want to write code and expect anyone interested in their work to read their code. They dont want to be bothered writing documentation that will probably be outdated as soon as they make their next commit.

    I wanted to quickly point out something that Ive noticed to be quite different for the open-source projects supported by FuseSource. Apache ActiveMQ, Camel, ServiceMix and CXF have documentation at their Apache sites that varies in terms of quality. But FuseSource has put together top-quality docs for each of the aforementioned projects focused on helping the reader quickly come up to speed and understand how to use the important features of a product. And its not just mickey-mouse examples either. Theyve put together examples gathered from years of experience consulting at various types of clients that focus on the intended way of using the product . When it comes to wanting to know how to use, for example ServiceMix, and the pitfalls to avoid and best practices to employ, having the FuseSource docs for ServiceMix (aka Fuse ESB) close at hand is a must.

    Another thing that can frustrate developers is outdated documentation. You may find a page, even hosted at the projects website, that explains a certain way to develop a solution, but when you try it yourself, it doesnt work. You can spend hours trying to figure out what you did wrong only to find youre actually not supposed to do it that way anymore. The FuseSource documentation solves that by organizing all of the documentation for a specific version. When you click on a doc set for a particular version, you can be sure that the features and examples covered are specific for that version and not just clobbered together with whatever else used to work and is outdated.

    The docs at FuseSource are tailored to help you quickly coming up to speed and are focused on solving problems with the technology without the unnecessary fluff to get in your way. If you are using ActiveMQ, Camel, ServiceMix, or CXF, I highly recommend checking out the FuseSource docs. If you dont use those products yet, consider that the documentation is an asset as you explore whether or not to use them.

  • Quick Note on How to remove/change /cxf from context path of CXF OSGi service.

    by Mazya uchapati (my low-tech efforts) on Mon Apr 16 14:50:00 UTC 2012

    By Default, when a CXF servlet endpoint is deployed in Servicemix OSGi container the context path for the endpoint address contains "/cxf".
    This causes resulting endpoint URL being something like http://localhost:9090/cxf/myservice . This is not always a desirable URL and many times needed to change to more generic (technology neutral) URL for publishing the endpoint.

    This default context can be changed in one of the two ways as follows:

    1. It can be changed by addingorg.apache.cxf.servlet.context=/myserviceto etc/org.apache.cxf.osgi.cfg.

    2. By running following commands to alter configuration in container usingconfigurationmanagement service in Servicemix container.
    config:edit org.apache.cxf.osgiconfig:propset org.apache.cxf.servlet.context /myserviceconfig:update

  • 3 reasons to use FuseSource Documentation

    by Charles Moulliard on Fri Apr 13 12:08:00 UTC 2012

    As an Apache Committer but also FuseSource Consultant and Solution Architect, the documentation and its quality is a critical factor in my day by day work. Until now, even using google search engine, that was difficult to find in one place all the information required and a wasting time.
    This situation has changed and I will give you three reasons to use/adoptFuseSource documentationfor your Apache Camel, Apache ServiceMix and Apache Karaf projects.


    Reason 1 : Fuse maintains history of Apache releases
    Apache websites uses Atlassian Confluence to maintain content publishes for each Apache project. This tool does not allow to create a history of the different releases of Camel by example (2.6, 2.7, 2.8). This is not the case with FuseSource documentation which allow you to browse a specific version like the current. And with the help of google, you can make specific search like that site:fusesource.com/docs/router/2.8/ "followed by the keywords"or site:fusesource.com/docs/router"followed by the keywords"
    Reason 2 : Javadoc and Schema are well documented
    Javadoc like XML Schema are also 2 interesting examples as there is no XML Schema javadoc on Apache websites for by example Spring DSL language. This is completely different on FuseSource web site as you can read the documentation and discover what are the tags or attributes to be used for specific Apache Camel DSL words. Here is an example containing the options proposed for Apache Camel Dataformat. http://fusesource.com/docs/router/2.8/xmlref/http.camel.apache.org.2033734988/element/dataformats.html




    Reason 3 : New chapters have been added
    FuseSource documentation contains missing pieces of information or cover in depth points which are described poorly on Apache websites or in an disparate way. So take the time to read the following chapters when you need more info about Transactions, Security, ...

    • Camel and Transactions : http://fusesource.com/docs/router/2.8/transactions/front.html
    • Camel and WebServices :http://fusesource.com/docs/router/2.8/camel_cxf/front.html
    • Fuse ESB - Security guide : http://fusesource.com/docs/esb/4.4.1/esb_security/front.html
    • Transactions with Fuse ESB : http://fusesource.com/docs/esb/4.4.1/camel_tx/front.html
    • ActiveMQ - Security : http://fusesource.com/docs/esb/4.4.1/amq_security/front.html
    • ActiveMQ - Tuning Guide : http://fusesource.com/docs/esb/4.4.1/amq_tuning/front.html

    ____________________________





  • What to look out for at CamelOne

    by Rob Davies on Fri Apr 13 07:31:00 UTC 2012


    The open source integration event - CamelOne, which is being hosted by FuseSource,is only a month away - and the agenda is coming together to provide so really interesting talks. If you haven't registered yet, there's still time - here's some reasons why you should think about attending:

    Firstly, its a great opportunity to meet a lot of the developers who work on Apache Camel, ActiveMQ, ServiceMix and CXF.Most of the Apache committers from FuseSource will be inattendance,and some of them will be talking.However, most of the real talking, just like all conferences, will be the side conversations that happen in the corridors in breaks and the social events that happen after the conference days - usuallyin a pub somewhere.

    However, there are going to be some great sessions - and I particularly like listening to the real world stories of the people who use Apache open source in production - like Christian Muller, Atos Worldline, and Christopher Hazlett from the Gilt Groupe. There's also going to be a great session on tracking real-time weather using big data and camel by David Reiser et. al. - i've seen their demo - its awesome :).

    My favorite though will probably be Felix Nikolaus Ehm, who will be talking about using ActiveMQ and Camel tocontrol the accelerator complex at CERN. I was lucky enough to get a tour of CERN complex a few weeks ago - its literally the coolest place in the universe.

    There's also going to be some great subject matter talks and discussions - the full agenda, as it stands is here.

  • Apache Camel at CamelOne

    by cmoulliard on Fri Apr 13 07:26:00 UTC 2012

    FuseSource organises for the second time an event dedicated to the famous Apache Camel EIP Framework - CamelOne, the 15th and 16nd of May. This conference is not only a vitrine dedicated to Apache CamelIntegration frameworkor FuseSource productsbut related technologies like ESB, SOA, BPM, Cloud, MOM, HTML5, Big Data and Real Time applications will be presented through a panel of different CamelOne talks and speakers (Rob Davies, James Strachan, Claus Ibsen, Hiram Chirino, Tony Shan, Robin Howlett,Dan Kulp,Jon Anstey, Kai Wahner, Charles Moulliard, Jazon Van Zyl, ...).

    A special attention was also given this year to present projects deployed and running in Enterprise (Christian Mueller - Atos, Rob Terpilowski - Lynden,Matt Pavlovich - Media Driver,David Reiser, Ram Raju and Shane Kent -- Department of Transportation,Robin Howlett - Silver Chalice) proving that Apache Camel is not only used by early adopters but is now part of the Enterprise Software Architecture like RDBMS and Web Technologies.
    If your are not yet registered, I recommend to do it to have the chance to meet some Apache Committers and people working every day with SOA and Integration projects. This is incredible opportunity which is only offered one time a year. Do not forget that the CamelOne conference include also a program to train people on Apache Camel, ActiveMQ and Apache ServiceMix.


  • Fuse Enterprise and EPubs

    by Eric J. on Wed Apr 11 17:26:00 UTC 2012

    FuseSource just released a public beta of our Enterprise open source integration products. The idea behind the Enterprise versions of the products is to make the underlying Apache software more accessible for typical enterprise customers. A big part of that push was around improving the documentation and examples. We took a long look at our content and tried to reorganize it to be more user task oriented as opposed to feature oriented. We also tried to add more "intro" level content. It was quite a bit of work and it is still on going.
    Another thing the doc team added to make the content more accessible is add a new publication format: EPUb. All of the documentation for the enterprise products are available in EPub and look great on iPads. Most of the work for making this happen was done by the excellent people who work on the DocBook XSLT project. Using the work they did on transforming DocBook into EPub along with help from them on the mailing list, I managed to integrate the EPub transforms into our publication system.
    Check them out at Fuse MQ Enterprise Documentation and Fuse ESB Enterprise Documentation

  • MQTT support added to upcoming Apache ActiveMQ 5.6 release

    by Rob Davies on Wed Apr 11 15:35:00 UTC 2012



    The MQTT protocol is an extremely light weight publish/subscribe messaging transport - targeted at machine to machine (mobile, industrial control, asset tracking etc) devices that came out of IBM in 1999. Its incorporated into Websphere MQ via the WebSphere MQ Telemetry product.

    A key driver for MQTT is the explosion in connected devices - its predicted to be in the range of 50 billion by the year 2020. ActiveMQ already provides connectivity for asset tracking, smart devices and vehicle trackingvia its ability to be deployed as a small footprint broker and utilizing store and forward for connectivity across unreliable networks. But it makes sense to extend the protocols ActiveMQ already supports (like OpenWire and STOMP) to support MQTT too (ActiveMQ Apollo already supports MQTT - and its the release where AMQP is being developed).

    There's also an excellent open source broker called Mosquitto, that implements MQTT, but ActiveMQ gives you the advantage of interoperability with JMS,STOMP or C/C++/ clients over open-wire. In addition to providing enterprise features (clustering, networks, etc) - and of course - enables integration with Apache Camel (either embedded inside ActiveMQ or via the ActiveMQ Component).

  • ActiveMQ in the cloud

    by Dejan Bosanac on Tue Apr 10 09:24:27 UTC 2012

    FuseSource just announced a public beta of new Enterprise products (Read more about it in Robs post). So its time to give you a bit more details on what we were working on for the past few months. One thing I want to emphasize in this post is how this project improves the experience of deploying and managing ActiveMQ brokers. Fuse Fabric (the central engine behind Fuse Enterprise) can help you provision and manage your brokers better and additionally help with cloud deployments.

    Provisioning

    While classic server software (ActiveMQ included) deployment scenarios, which include unpacking a distro, setting a config and starting/stopping software, works OK for small deployments, there are a lot of challenges people encounter when trying to set and manage a large number of instances. Here are some of them:

    • Enormous amount of work needed to set everything - imagine a large cluster you need to set, ssh-ing, unpacking, copying and tweaking config files is very tedious and error-prone process
    • Changing configuration during runtime - you need again to manually tweak every file and restart the server, which is all but fun
    • Upgrading - can also be a challenge and time consuming

    Some of the things folks usually do to make their life easier is to:

    • Keep XML config part of the spec as a template and in version control system and tweak as much things as possible with properties - this makes it easier to keep things under control and minimize the potential of an error when managing a configuration on large number of instances.
    • Keep configuration separate from distribution to make it all easier to upgrade
    • Use tools like Puppet or Chef to even further make things easier in these scenarios

    One of the things where Fabric excels is centralized configuration management. In Fabric its really easy to spin new container instances on your servers (using ssh) or to the public cloud. Additionally its really easy to deploy ActiveMQ broker to those containers, by simply applying appropriate profile to them. So generally, you can predefine a template for your broker, like XML configuration template and all necessary properties in a profile and then with a simple Karaf command (or even mouse click in our tools, like FuseIDE and Fuse Management Console) deploy as many instances as you like of that broker (no matter if its a physical box in your data center or a VM at the public could provider).

    Discovery

    Fabric uses Apache ZooKeeper as its central registry of container instances running. This same registry is used to keep track of all brokers running inside a Fabric instance. This means that we can use this registry to discover all brokers inside a certain group. Therefore we created a new discovery protocol (called fabric of course) that can do that. So clients can connect to the broker group (think of it as a cluster) without any need to know exact location of the brokers. So now you can see how Fabric helps deploying your brokers to the cloud. First, you can use its ability to start containers (and deploy brokers on them) on any server or cloud provider available. And than clients can use Fabric to discover brokers and connect to them, all location agnostic.

    Topologies

    ZooKeeper as a central registry allows us to do some more nice things in domain of broker topologies. For example, currently the master-slave topology of ActiveMQ brokers depends on shared storage (either shared file system or enterprise JDBC database). In this scenario the master election and slave locking depends on the locking ability of the shared storage, limiting it to certain type of hardware. With ZooKeeper as a distributed registry, battle-proven for this kind of use cases, its easy to create a master-slave topologies with master election done on ZooKeeper locks. If you want to have a persistent master-slave, you still gonna need to store your messages in a some kind of a shared storage, but locking is not stores job any more. And on the other hand its really easy to create non-persistent cluster of brokers with shared-nothing philosophy. Creating a master-slave is as simple as creating a multiple brokers with the same name in the group. The first one started will become a master, while others will be slaves waiting for the master to fail.

    Another example of enhanced topology possibilities with ActiveMQ and Fabric is new ways you can set networks of brokers. Just as clients can use ZooKeeper registry to discover brokers, network connectors can use the same discovery protocol to connect the broker with all other brokers in the certain group. Again, brokers are mutually totally location agnostic, which is something desired in deployment scenarios with modern infrastructure. Could it be done any easier? Finally, you might want to mix these two topologies and create connected networks of master/slave broker, which with Fabric, is just easy to do as those basic topologies.

    Upgrades and Patching

    And now you say you need to upgrade all of the dozen brokers you have? No problem, with Fabric you can centrally update any bundle youre using in your profile and that change will be propagated to all brokers. Now its time to talk about risk management of upgrades and this is where profile versions come into play. Instead of messing with profiles that are used in production at the moment, you can create a new version of it with updated versions of all bundles you plan to use. Once you have that profile ready, you can test it out on one or a few instances. And only after youre certain that everything is OK, you can apply a new profile to all brokers. Of course, its easy to rollback to the previous version if anything goes wrong.

    Fabric also provides you with the mechanism to provide a simple incremental patch jar with only certain classes modified (a single bug-fix). These classes will be then used instead of old ones and will allow us to provide a fix for a critical bug without need to upgrade the project version. This can be useful for dealing with critical production bugs, where waiting for the next release is not an option.

    More resources

    This post was just meant to give you a glance view of whats coming from FuseSource regarding easier deployment, provisioning and managing of your messaging (and generally integration) infrastructure. You can check some more docs on the projects. Especially, theres some more info that explains ActiveMQ concepts explained here in more details and shows how to run examples. You will definitely hear more from us on this topic in coming days, so stay tuned.

  • Beta release of FuseSource Enterprise products

    by Claus Ibsen on Tue Apr 10 08:31:00 UTC 2012

    Today FuseSource is launching a beta release of our upcoming Fuse Enterprise products.

    Rob Davies, our CTO, have written a very nice blog entry with more details about this release.I took the liberty to quote a teaser from his blog post here:
    FuseSource has launched the Beta program for two new Enterprise products its launching today. FuseSource Enterprise These products, Fuse ESB Enterprise and Fuse MQ Enterprise, provide the capabilities to make integration and messaging even easier to deploy and manage. Central to the new functionality the Enterprise products provide are Apache licensed open source projects that that FuseSource has been working on outside of the Apache Software Foundation, called Fuse Fabric and FAB (Fuse application bundles), which have been designed to work seamlessly with Apache Camel, ActiveMQ, Karaf, CXF and ServiceMix. You can read more about this release from Robs blog.

  • Beta release of FuseSource Enterprise Products

    by Rob Davies on Tue Apr 10 08:10:00 UTC 2012

    FuseSource has launched the Beta program for two new Enterprise products its launching today.
    These products,Fuse ESB Enterprise and Fuse MQ Enterprise, provide the capabilities to make integration and messaging even easier to deploy and manage.

    Central to the new functionality the Enterprise products provide are Apache licensed open source projects that that FuseSource has been working on outside of the Apache Software Foundation, called Fuse Fabric and FAB (Fuse application bundles), which have been designed to work seamlessly with Apache Camel, ActiveMQ, Karaf, CXF and ServiceMix.

    The Enterprise products are about providing stable, production ready integration platforms for large scale deployments. As well as the additional system and platform testing that goes beyond what we do at the Apache Software Foundation, we also run the products through independent security and license validation, and provide platform installers. For developers, we provide Fuse IDE - Eclipse based tooling for deploying and managing running integration routes based on Enterprise Integration Patterns from Apache Camel. For FuseSource subscribers, we will also be providing incremental patching, and configuration and deployment tooling for the remote management of enterprise deployments (Fuse Management Console) and FuseHQ for operational monitoring.

    Fuse FabricThe main project providing the deployment and configuration required for enterprise deployments isFuse Fabric, which provides a centrally managed distributed configuration, provisioning and runtime registry for services deployed on-premise, in the cloud or both. The main driver for Fabric is that deployments of more than one Apache ServiceMix or ActiveMQ instance can get complex pretty quickly, and FuseSource has customers who deploy with thousands of instances of these projects. So an Enterprise deployment requires a lot of upfront knowledge, and its easy to get wrong. They also require location transparency and the ability to support the failover of endpoints. Fuse Fabric has been developed to solve these problems, and to make the creating interconnected services, clusters and networks of brokers simple. Ioannis Canellos has a nice video demonstration of Fuse Fabric and Camel here.

    The Fuse Enterprise products utilize the power provided by Fuse Fabric, and key to that is the Fuse Management Console and the new functionality built in to Fuse IDE.

    A central part of the Fabric is the deployment container, which can manage and control child containers, and is based on Apache Karaf, which is a small OSGi based runtime and a project which we developed out of Apache ServiceMix. OSGi is great technology for providing modularity and services for Java applications, but it can be difficult to migrate existing applications or create new ones to use OSGi - which is why FuseSource has created Fuse Application Bundles.

    Fuse Application BundlesOSGi is an ideal micro container for the JVM, its small and modular, simple yet powerful. OSGi supports hot (re) deployment of services at runtime and has framework support from blueprint or Spring-dm.
    However, OSGi bundles ate very fine grained and use package level metadata. To control bundle dependencies requires defining version ranges for every bundle, and typically an application will consist of 10s or even 100s of bundles - thats a lot of packaging and metadata, which often leads to mistakes - and it can be very time consuming to get right. Developers just want to get their applications deployed and working quickly - hence Fuse Application Bundles (FAB).
    The goal of FAB is to provide a simple way of managing dependencies and class loaders so developers can concentrate on developing value to the business, and avoid learning new ways of dealing with dependencies just for OSGi. FAB enables developers to use a common model of class loaders across build tools, IDE and the OSGi container - how often does code work in the IDE, only to fail when its deployed to an OSGi container?
    FAB works by using the transitive dependencies all ready defined in an application jar which has been built by maven or sbt. It also enables you to define what to dependencies you wish to share, or you expect to be provided. There's some great examples of using FAB provided with Fuse ESB Enterprise.

  • New Camel example to compare with Spring Integration simple example

    by Claus Ibsen on Tue Apr 10 06:20:00 UTC 2012

    One of the blogs I follow is from Gunnar Hillert, whom back in 2009 discovered Camel and wrote a nice blog entry. He also did some investigation of Camel alternatives as well. One of the alternatives is Spring Integration. Gunnar have since joined VMWare to be part of the Spring team.

    So this morning I read the new blog post by Gunnar, how to create a Spring Integration project in STS tooling, which is posted here. The STS creates a simple out of the box example, that provides the following XML (in screenshot) as the main logic. Take a moment to see if you can figure out what it does. And then compare to theequivalentCamel example below.

    Spring Integration - Simple Example created by STS tooling And here is the Camel example using XML as well:

    Apache Camel - The same example as above Having both screenshots, I guess you can figure out that the example:

    • reads input from the console
    • upper case the input
    • and prints it back on the console

    • This example will be provided out of the box in the upcoming Apache Camel 2.10, in the examples/camel-example-console directory. You can see the source code here.

      You can run it from command line using Maven
      mvn compile exec:java

      And then press ctrl + c to stop the application.

      Running the Camel example from command line Or you can run it from within your IDE of choice, such as IDEA / Eclipse / FuseIDE by running the CamelConsoleMain class. For example as the screenshot shows below from IDEA.
      Running the example from your editor such as IDEA
      To create a new Camel project you can use the Camel Mavenarchetypes. Or useFuse IDEwhich has a wizard just like STS to create a new Camel project.

      A few notes about Camel. The example uses Spring and XML, however Camel can be used without Spring at all. We could use pure Java and define the Camel route in a Java class. You can also use Scala. And for XML we could also have used OSGi Blueprint.

      In the example we use the built-in Simple language to upper case the input. You can chose to use more powerful dynamic languages such as Groovy, OGNL, Mvel, JavaScript etc as well.

      With Camel you simply have morechoices, and dont have to use XML at all.

  • Using Excel Templates with Excel Mac 2011

    by admin on Mon Apr 09 20:55:18 UTC 2012

    I use a Mac for all of my development (where I can), but one thing I had to do recently was use Excel on a Mac and create a new spreadsheet from a template. To my surprise and frustration, I could find no reliable documentation online. I figured it out.Heres what I did (and if anyone has a link to where it was on Google or the MS website, please share with me. I wasted time and my own frustration trying to find the correct solution, but was instead pointed to many directions that ended up being absolutely wrong): I created a new template in Excel and saved it. Then I checked the properties for that file and where it was located on the disk. I ended up with this location for templates:
    > /Users//Library/Application Support/Microsoft/Office/User Templates/My Templates

  • Test Entry From TextMate

    by admin on Mon Apr 09 20:45:23 UTC 2012

    Using the amazing TextMate editor to blog offline and publish when readyI was looking recently for a good solution to blog offline and later publish to wordpress. Iv also wanted to get more familiar with Markdown, so I found the [Blogging bundle][http://blog.macromates.com/2006/blogging-from-textmate/] for TextMate that allows me to write my blogs in text with Markdown and publish when Im ready. Heres my first post, with many more to come.

  • Serious about your software career? Leave your job

    by admin on Mon Apr 02 15:45:21 UTC 2012

    I recently resigned my position as senior software engineer and technical lead for a middleware services group at Wells Fargo. The job was great: work from home, great immediate manager, respected among the team members, trusted to explore new technologies when justified, boss stood up for us and got us the tools, training, and working environments we needed, etc, etc. Something still prompted me to move, and its not the first time Ive done so. Ive opted to resign jobs that had great setups in the past, either as a full-time or consultant, and in this blog I try to articulate why.

    I believe to be successful and well-rounded in the technology/software space, you have to change jobs every few years or so. Ultimately, as a software engineer, your job is to solve problems using technology. In most cases, a problem can be solved in many different ways, but not all solutions are created equal. The more problems and solutions youve seen and experienced, the more apt you are to solve the problem with a better or elegant solution. In my opinion, you have to experience how problems are solved in different groups, and different companies using different methods, different approaches, etc etc to really become proficient at problem solving and weigh the benefits and tradeoffs that come with a solution. Otherwise, the traditions and customs of a single company crush your mind from thinking outside the box or evaluate how similar problems have been solved in the past by similar companies.

    Another part of the equation is ability to learn and your exposure to new technologies. Big companies offer the this is the way weve always done it and were not going to change mentality which is really a career killer for a software engineer. If youre career goals involve trying to climb the corporate ladder, then by all means embrace the corporate mindset but if you want to stay in the technology space and excel, you will have to seek out opportunities to expose yourself to new technologies and problems..

    I feel at this point in my career, I cant settle for all the comforts of a cushy corporate job. I am still young enough and interested enough in technology to the point that I want to push myself. I want to get out and be exposed to new problems. I crave learning and the challenges of doing so. I honestly feel that if youre not learning and not solving new problems and not thinking outside of the box youre going to end up like those technology folks complaining about not having a job because the technology they cling to is slowly going away or drying up. I dont want to end up complaining about something that I have control over right now. In the end, the technology industry is about problem solving, ability to learn, and pushing yourself to not get comfortable. Maybe Im cynical in this respect, but the longer you stay at a big company, the more locked-in you get and the more dependent you become on that company (pension, retirement, tenure, job-security, whatever). The longer you stay, the less motivated you get to learn the new technologies that arent being used at your company. The longer you stay, you *think* you become critical to their operations, but before you know it the operations themselves are being phased out and your chances of being kept around are becoming slimmer and slimmer. I believe times have changed, and trying to stay at a corporate job in a company for 30 years is a career killer for a software engineer. I want my resume to be my job security, not the number of years Ive had the corporate mentality beaten into me.

    Who knows, though. My wife and I are expecting our first child in the next few weeks, and I know my priorities will shift big time. My focus will be on her and my family. Maybe Ill do a 180 change of opinion about staying at a big company. But while Im still motivated, I have to explore other options and opportunities that I know will solve all three of those items mentioned above: exposure to problem solving, learning, and staying hungry. So I continue my journey in the software craft by taking on the role of Principal Consultant at an open-source subscription company, FuseSource, who is the support company behind Apache Camel, ActiveMQ, ServiceMix, CXF, and a few others. I will be helping different companies use these open-source projects, facilitate proper design of their architecture, deliver training, and im sure much more. It seems to be a good balance of exposure to new problems, learning opportunities, and working with some of the smartest people in the open-source space which will drive me to stay hungry. Wish me luck!

  • How to use JDBC driver in OSGi container

    by Freeman Fang on Fri Mar 30 07:24:00 UTC 2012

    One frequently asked question on the FuseSource forum and several Apache projects like Apache servicemix/Karaf/Camel/CXF which I'm working on is that how to use JDBC driver in OSGi container? why I always encounter ClassNotFoundException?

    Users usually use some third party libs like spring-jdbc or commons-dbcp to maintain the connection pool, so they configure it like
    <bean id="databaseConnection" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost:3306/schema" />
    <property name="username" value="***" />
    <property name="password" value="***" />
    </bean>

    or

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="${jdbc.driver.class}"/>
    <property name="url" value="${jdbc.url}"/>
    <property name="username" value="${jdbc.user}"/>
    <property name="password" value="${jdbc.password}"/>
    </bean>

    Those beans always work in standalone mode, but when users deploy it in OSGi container like FUSE ESB or Apache Servicemix/Karaf, they will see the JDBC driver ClassNotFoundException.

    This error actually is from how OSGi classloader works, say, if bundleA need use some package, it need explicitly import it before hand.

    However, if a bundle(let's say it bundle A) using some code like classForName(jdbc_driver_classname) to init a jdbc driver class, this is a big issue in OSGi world, as if BundleA not import package for jdbc_driver_classname, you'll see the problem. Unfortunately BundleA actually can't know about package name for jdbc_driver_classname beforehand, as the jdbc_driver_classname generally is passed in through configuration during runtime, it can't be determined during build time, so you can't add correct package import when you generate bundle A.

    Back to our original issue, spring-jdbc and commons-dbcp is Bundle A here.

    How to resolve it?

    Well, we have several options

    1. Put all possible necessary packages in Import-Package OSGi metadata header, this is exactly how spring-jdbc do . spring-jdbc optionally import packages like
    com.ibm.websphere.rsadapter;resolution:=optional;version=0,
    com.ibm.ws.rsadapter.jdbc;resolution:=optional;version=0,
    com.mchange.v2.c3p0;resolution:=optional;version="[0.9.1, 2.0.0)",
    oracle.jdbc;resolution:=optional;version=0,
    oracle.sql;resolution:=optional;version=0,
    org.apache.derby.impl.io;resolution:=optional;version="[10.5.0, 11.0.0)",
    org.apache.derby.jdbc;resolution:=optional;version="[10.5.0, 11.0.0)",
    org.h2;resolution:=optional;version="[1.0.0, 2.0.0)",
    org.hsqldb;resolution:=optional;version="[1.8.0, 2.0.0)",
    org.jboss.resource.adapter.jdbc;resolution:=optional;version=0,
    weblogic.jdbc.extensions;resolution:=optional;version=0
    com.sun.rowset;resolution:=optional;version="[1.0.1, 2.0.0)",
    pretty much all popular used JDBC drivers is available, but not include mysql.
    Of course we can hack the bundleA to add any Import-Package we want, it's not a big deal as we always hack, but it's not very graceful, especially sometimes we can't hack some bundles for license reason.

    2. Make bundleA have DynamicImport-Package OSGi headers, this is the way how Servicemix wrapped commons-dbcp do.It works, but we all know using DynamicImport-Package isn't the best practice in OSGi world. To support JDBC out of the box, we have to do some trade-off.

    3. What I prefer to is the fragment bundle way, that said, you create JDBC driver as a fragment bundle, and attach it to bundle A(bundle A is host bundle now), so that all resource from fragment bundle is available for the host bundle. This way you needn't hack bundleA.

    Finally, I'd say the fragment bundle is very useful when you try to get around some legacy libs in OSGi, it allow you pass the classname during runtime between bundle(like the JDBC driver we discuss here), it also can allow you to pass some resource files between bundles, I hope I can find some time to elaborate this issue later one.

  • Maven, M2_HOME, and IntelliJ on a Mac

    by admin on Tue Mar 20 23:42:46 UTC 2012

    Apparently, even if you put your environment variables into your .profile, IntelliJ wont pick it up. Which makes sense since .profile is for setting your shell environment. To set environment variables that IntelliJ (or any non-bash app) can see, such as the M2_HOME var needed for maven integration, create a file in /etc called launchd.conf (if it doesnt already exist if it does, then just add the lines to it) and add a line such as setenv M2_HOME /usr/bin/maven

  • Fuse Fabric and Camel

    by iocanel on Sun Mar 18 16:01:00 UTC 2012

    Prologue


    I have already blogged aboutCamelOnewhich is going to take place on May 15 - 16 at Boston this year. I am really excited about it, as a lot of new things are going to be talked about there.

    So I'd like to share my excitement with you and give you a small preview of "Using Fuse Fabricwith Apache Camel".

    Fuse Fabric

    Fuse Fabricis a distributed configuration, management and provisioning system forApache Karafbased containers such asApache ServiceMixandFuse ESB.


    Fabric provides a distributed configuration registry and also tools for:

    • Installing and managing containers to your private or public cloud.
    • Deployment agent for configuring and provisioning distributed containers.
    • Discovery of Camel endpoints & message brokers.
    • A lot more ...


    Fuse Fabric and Camel preview
    What I am going to show you, is a video thatdemonstrates how fabric makes it easy to:

    • Use a single host for installing containersto your local network.
    • Deploy and configure applications to distributed containers.
    • Discover & use message brokers in your camel routes.

    <object class="BLOGGER-youtube-video" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" data-thumbnail-src="http://i.ytimg.com/vi/VgaBVPgAaa0/0.jpg" height="266" width="320"><param name="movie" value="http://www.youtube.com/v/VgaBVPgAaa0?version=3&amp;f=user_uploads&amp;c=google-webdrive-0&amp;app=youtube_gdata"/> <param name="bgcolor" value="#FFFFFF"/> <embed width="320" height="266" src="http://www.youtube.com/v/VgaBVPgAaa0?version=3&amp;f=user_uploads&amp;c=google-webdrive-0&amp;app=youtube_gdata" type="application/x-shockwave-flash"></embed></object>
    I hope you enjoyed it! See you atCamelOne!