6 Replies Latest reply on May 8, 2008 4:53 PM by kukeltje

    enterprise container resources

    tom.baeyens

      in the deployment descriptors of the enterprise beans, there are references to queues and datasources.

      we can take two options:

      1) use the names that are already configured in the default jboss installation. that gives less configuration to do in jboss. but that means that it can easily overlap/conflict with other existing usages of those resources

      2) use Jbpm-specific names for the resources. that requires more configuration to set up jboss (or other app servers) to prepare it for running pvm on it. but on the other hand, there is no conflict possible. then users can deploy the pvm enterprise beans as-is without worry.

      WDYT ?

      Alejandro, which approach did you take now ?

        • 1. Re: enterprise container resources
          aguizar

          Summary. I took (1) for the data source, (2) for the queue. I am considering (1) for both.

          Details. I use the default data source because a transaction involving the ejb timer service and a custom data source would require at least one of them to connect to an XA-enabled database. Since I do not have such a database installed locally (it would kill my machine), I can only share a single data source.

          On the other hand, I use a custom queue. JBoss is forgiving and creates a temporary queue if the JNDI name in the deployment descriptor is unbound. It emits some warnings, tough. Some folks feel uncomfortable with the warnings (I know through many forum postings), so I'm considering to use one of the predefined queues.

          I'm in favor of easing the product evaluation experience by postponing the moment in which you have to touch the app server. If you encounter conflicts then you are already running the product along other software, which means you are past initial evaluation. At that point it is imperative that you become familiar with the operating environment and allocate separate resources for jBPM.

          • 2. Re: enterprise container resources
            tom.baeyens

             

            "alex.guizar@jboss.com" wrote:

            <strong>Details</strong>. I use the default data source because a transaction involving the ejb timer service and a custom data source would require at least one of them to connect to an XA-enabled database. Since I do not have such a database installed locally (it would kill my machine), I can only share a single data source.


            that makes sense. well spotted.

            however, XA *is* core business of an app server :-) and i don't see the need for an XA-enabled database in development/testing.

            "alex.guizar@jboss.com" wrote:

            On the other hand, I use a custom queue. JBoss is forgiving and creates a temporary queue if the JNDI name in the deployment descriptor is unbound. It emits some warnings, tough. Some folks feel uncomfortable with the warnings (I know through many forum postings), so I'm considering to use one of the predefined queues.


            so you don't copy/overwrite some configuration files to jboss to actually create a new jms queue ?

            can't this be done just like in jBPM 3 ?

            "alex.guizar@jboss.com" wrote:

            I'm in favor of easing the product evaluation experience by postponing the moment in which you have to touch the app server.


            the evaluation is based on the suite that we distribute and it contains a preconfigured jboss installation.

            and for the next step, deployment of the .ear can be done as-is, if we use other then the default resources. in that case, the user will only have to configure the data source and queue, something which is much more known and easier to explain.

            this way we're sure to prevent conflicts *and* only simple work is required when deploying the enteprise jar (as-is) into a clean app server.

            the alternative is that if people run in to a conflict, will have to
            1) open up the pvm enterprise jar, modify configuration files, zip it back together and deploy it.
            2) configure the datasource and queue in the app server.

            that is a big treshold and much harder to document.

            i think that we should go for custom jbpm resource names and provide a preconfigured jboss like we used to do.

            • 3. Re: enterprise container resources
              kukeltje

               

              i think that we should go for custom jbpm resource names and provide a preconfigured jboss like we used to do.


              +1

              • 4. Re: enterprise container resources
                aguizar

                Right now I don't put any queue deployment descriptor in the deploy directory. I just reference queue/JbpmCommandQueue and JBoss creates a temporary queue for me.

                The descriptors reference a custom queue name, just like in jBPM 3. If you deploy the jbpm 3 enterprise jar to an unprepared JBoss AS installation, you will see the JbpmCommandQueue and the JbpmJobQueue created for you.

                Regarding your last comments, I hadn't thought of the suite distribution. With that in place the custom resources are an easy choice. Agreed, unzipping the enterprise jar to change the name of the data source or queue is kinda dirty and error prone. With custom resource names, the data source is your only immediate concern. The queues even get created for you.

                • 5. Re: enterprise container resources
                  tom.baeyens

                  good point. good discussion. and good conclusion.

                  congrats to all involved :-)

                  • 6. Re: enterprise container resources
                    kukeltje

                    I'll file a jira issue also for configuring a jndi mail session to be used in enterprise envs, one of the other resources (and a valid commment imo from one of our developers)