2 Replies Latest reply on Jul 12, 2007 9:58 AM by Burr Sutter

    JBoss ESB changes and the LGPL

    Wade Whynot Newbie

      There are currently 2 main pieces of code I'm writing that are using the JBoss ESB framework.

      1) New listener that polls for new files in directory

      The ESB comes with a standard file poller that looks for files in a directory, then reads them in memory, renames them, and moves them around.

      For our project, this default behaviour will not work. We want to change the way the files are renamed, we need to pick up the files in order of timestamp, and we only pass the file name instead of its contents (for performance reasons).

      In order to do this, a new listener must be written. This listener must extend from a JBoss ESB specific abstract class in order to use some functionality so the new piece will plug properly into the framework.

      The new listener will extend from this class:

      Does extending from this JBoss ESB class enforce the LGPL licence to the new listener, or can it remain proprietary?

      2) New Action class that processes a specified message from the listener

      This class is a normal implementation of new functionality within an (any) ESB framework. However, JBoss ESB specific Java objects and references are being used as part of this implementation.

      For instance, the message itself that is passed to the action class is of type org.jboss.soa.esb.message.Message. Then you can read the body from the message: org.jboss.soa.esb.message.Body. Plus at instantiation time, some configuration data is passed to the class as well: org.jboss.soa.esb.helpers.ConfigTree.

      Keep in mind this is normal use of the JBoss ESB framework. We're not extending any functionality here, only using JBoss specific objects. Would this enforce the LGPL licence to these new classes? In other words, would simply using the JBoss ESB framework enforce the licence to the product we're developing?