2 Replies Latest reply on May 21, 2010 6:15 AM by aslak

    Is Arquillian appropriate?

    bob.mcwhirter

      As part of my work on TorqueBox, I want to be able to re-use small portions of my deployers, to deploy small portions of people's Ruby apps.

       

      My understanding of Arquillian is minimal, but the idea of an embedded container is exactly what I'm looking for.  But I don't want it tied to any sort of testing harness or framework.

       

      The basic idea is that a Ruby script will be used to instantiate the container (or a simplified interface to the MC), configure deployers, add deployments and then run the whole thing until I catch a ^C or otherwise the script is shutdown.

       

      I've worked directly with VSF/VDF stuff previously, then I've started to consume ALR's bootstrap-vdf-minimal, but was wondering if moving up the stack to Arquillian is appropriate for using completely outside of a testing scenario, as just an easy way to get a useful MC going.

       

      Thanks,

       

      -Bob

        • 1. Re: Is Arquillian appropriate?
          alrubinger

          This is to say, Bob doesn't need lifecycle events fired from TestNG or JUnit (he can do that manually), but would still like to benefit from the injection services and boilerplate reduction that's in place in the ARQ Reloaded Container.

           

          S,

          ALR

          • 2. Re: Is Arquillian appropriate?
            aslak

            *snip*snip* IRC Conversation #jboss-dev

             

             

            <aslak> bobmcw, just as quick summary: you want to use Arquillian Core (Enrichers/Containers/ShrinkWrap) to create a 'deployable' script engine in a sense..  dropping the test front end ?
            <bobmcw> yah, production/runtime minimal container, into which I can add my own deployers/deployments, via Ruby
            possibly long-lived, not just test-duration type container
            <aslak> bobmcw, short answer on top of my head, it should be doable. We have some internal Contexts/Scopes that might not quite fit in your model, (Suite/Class/Test), but the rest is pretty pluggable in every direction..
            <bobmcw> if I can ignore'em, or give no-op/empty impls, I can work with it
            <aslak> bobmcw, the core it self is basically just a multi Scoped Event Machine in a sense. Via ProfileBuilders you bind Handlers to different events(BeforeClass, AfterClass etc) in the different Scopes.  Handlers use the Contexts to share state. 
            <bobmcw> so, I could probably just ignore all of that, and just spin up the container a-la-carte?
            <aslak> bobmcw, so the Container starters /stoper deployers etc etc are all just loosely coupled pluggable Handlers. Events can be anything. but the Scopes are hardcodes atm. in your case i guess you can bind and operate on a single Context/Scope and ignore the rest
            <bobmcw> can I get access to the KernelController and all of that MC innards?
            or just via injections into a POJO?
            <aslak> bobmcw, that's up to the DeployableContainer to expose to the Context. then Other handlers can access and extend on that as much as they want.
            <aslak> bobmcw, in your case, i think you can get away with: a new ProfileBuilder impl that binds all handlers(container controllers deployers etc) in the SuiteContext. Then a new DeploymentGenerator to create your Archive(since you don't have a TestCase to look for(or do you?)). You then use Arquillian core directly and fire the events like BeforeSuite AfterSuite as you see fit in your 'Main'
            <aslak> bobmcw, the ProfileBuilder part is not properly dynamifyed(?) yet.. but it's comming