-
1. Re: enterprise container resources
aguizar May 6, 2008 7:52 PM (in response to tom.baeyens)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 May 7, 2008 3:19 AM (in response to 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 May 7, 2008 8:31 PM (in response to tom.baeyens)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 May 8, 2008 3:34 AM (in response to tom.baeyens)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 May 8, 2008 4:06 AM (in response to tom.baeyens)good point. good discussion. and good conclusion.
congrats to all involved :-) -
6. Re: enterprise container resources
kukeltje May 8, 2008 4:53 PM (in response to tom.baeyens)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)