3 Replies Latest reply on Aug 17, 2005 1:05 PM by adrian.brock

    Repackaging Embeddable EJB3

    christian.bauer

      Should we consider repackaging to make it really a product that can be embedded easily? Maybe a few variations of a single JAR depending on the native integration someone wants. I'd love to get rid of the "what libraries do I need" FAQ right at the download button.

        • 1. Re: Repackaging Embeddable EJB3
          bill.burke

          The JBoss Microkernel has the notion of "On Demand". This means that the bean will not be created until it is needed. Doesn't having one or two large jar files mean that the entire jar gets loaded into memory? The On Demand thing, when we get the EJB3 container set up to support it, will allow us to have a smaller memory footprint if we dont use things like JMS, security, etc...

          What do you suggest?

          • 2. Re: Repackaging Embeddable EJB3
            christian.bauer

            We can still provide a special packaging for people who like to run this on their cellphone. Otherwise I'm going to vote for the 99% common case, users who'd certainly prefer not to worry at all about JAR and classloading issues. I suggest a few common profiles, depending on what we can actually re-use, integrate with, and what people want. I'm also certain that we'll have to change this packaging once or twice until we get it right.

            • 3. Re: Repackaging Embeddable EJB3

              It's interesting you called it a profile.

              One of things we are doing for JBoss5 in the MC is to have versioned "profiles".

              This incorporates your requirement and some other features like:
              * Versioned configuration
              * Rollback to last known good state
              * Retrieval of up-to-date config from the cluster or reference site(s) (rewrite of netboot)
              * VFS semantics - ability to create logical deployments, e.g. deploy "packages" from your IDE without actually having to do the packing.
              * etc.

              See the POJO forums or the discussion in the clustering forum about
              improvements to the farm/singleton deployment including "Transactional Deployment".