What exactly is jbpm.sar good for?

[the_dude]

Hi,

can someone explain the main purpose of this sar? I have a rather vague understanding, for instance: Can I / my application read the jbpm.cfg.xml plus the hibernate settings that are configured in this sar?

[the_dude]

Right now my application (btw. a struts liferay portlet) comes with its own set
of hibernate.cfg.xml and jbpm.cfg.xml. However, it does not 'feel' right, since
these files also lie in the service archive as well.

Maybe I am asking too obvious questions - the problem is I do not find
anything about the jbpm.sar in the documentation, except in Chapter 8.

Thanks for helping me out.

[jglan]

I think the situation is similar to sample mbean (JNDIMap) from the official JBOSS 4.0 guide. According to that (page 95) a simple jndi lookup should make it (to get JbpmConfiguration). But I (as you) have not found anything in the web app that uses this kind of lookup/access of the sar. So I'd really appreciate some guru to answer this 'trivial' question without having to read the complete guide + sources, examples (which also would take a long time to understand, at least for me :-( )
Thanks.

[kukeltje]

hmmm... I looked into this a little since it intriged me and have to take back some of my comments in another thread about this same issue (the jndi name/mbean thing). I did not look into this part of the code since it got restructured from 3.0 to 3.1 and the usage is unclear to me now.

As soon as I know a little more, I'll post it in the forum.

[the_dude]

"kukeltje" wrote:
As soon as I know a little more, I'll post it in the forum.

@Ronald: Thank you. I appreciate your efforts in this forum to help us learn more about jBPM.

[jglan]

Yes thanks Ronald for looking into it.
Yesterday evening (reading a german JBOSS Book) I found another hint in the chapter about the mbean server.
So first one would have to find the mbean server by a MBEanServerLocater.locateJBoss().
Then an ObjectName needs to be created with the name of the requested MBean. With the ObjectName returned one can call the mbean's methods with a ms.invoke(objectName,"mymethod",...) where ms is teh mbean server returned from the locateJBoss().
I have not looked into the webapp for this yet... (have some real work to do)

[kukeltje]

My first impressions:

- the mbean is of type JbpmService
- it creates a JbpmConfiguration which it binds in the jndi tree
- in the webapp (jsf based) the JbpmBean plays an important role, especially the method getJbpmContext()

So most likely it would be enough to do something like

JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();

And as far as I can tell, there is no difference between using jBPM from the sar or embedded. It could be however that there are some changes in this area (I know some things are goiong on to change from mbean deployed to jca)

Further I have not tried this yet (no time today) but asked Tom to give a short comment on this.

[tom.baeyens]

I was just looking at that as well. It seems to me that the approach is broken (redundant).

As far as i can read the current code, the JbpmConfiguration that is put in JNDI is never used.

When the JbpmConfiguration.getInstance() method it used, it lazy initializes a JbpmConfiguration based on the resource 'jbpm.cfg.xml'. This configuration is cached in a static variable in JbpmConfiguration. So the jBPM configuration used is the one that is cached in the JbpmConfiguration static member rather then the JNDI one.

This lead to the following basic question: "what is the benefit of putting something in JNDI ?" http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3942144#3942144 That thread also discusses something relevant. Namely: "should we create a JCA .rar that publishes JbpmConfiguration into JNDI" so that we have a portable way of deploying jBPM on an app server.

So for now, I don't see a problem with the current approach. (except for the redundency that the JbpmConfiguration that is published in JNDI is never used)

[tom.baeyens]

one more thing. i didn't yet answer the question "what is the jbpm.sar good for"

the way we use it now, it is an alternative way to put the jbpm libs on the global classpath.

it also allows us to publish JbpmConfiguration to JNDI, but as stated in the previous post, that is never used and redundant.

[kukeltje]

May I assume that there is no conflict if multiple webapps (which I'm trying now) are using the same config/database/etc...

[kukeltje]

Thanks btw Tom for responding so promptly

[jglan]

Can you explain this a little bit more or give some pointer to the docs to understand this more precisely ?.

the way we use it now, it is an alternative way to put the jbpm libs on the global classpath.

I'd conclude from it that everything that is deployed as a sar (which is the way mbeans are deployed ?) is accessible from any other ear, war and thus I'd never have to use either jndi lookup of the mbean or the other ways mentioned in the JMX Microkernel chapters ? In a german textbook they access the mbean via ObjectName,MBeanServer,invoke (which I have not found in the english doc yet; Ok I did not look closely enough `-:)

[kukeltje]

Partially true. If you just load them as classes, that is just what they are. Loading them via the mbean server gives you additional functionality like stopping it, monitoring it etc via JMX, depending on the functionality in the bean.

[jglan]

OK, thanks for the discussion. I'll think/read about it.
I'm still wondering about the MBeanServer.invoke() vs. accessing it as a static instance...

[tom.baeyens]

indeed no conflict.

to install multiple jbpm configurations in one server is the easiest by using different, non-default configurations e.g. a left.jbpm.cfg.xml and right.jbpm.cfg.xml in the classpath.

then use JbpmConfiguration.getInstance("left.jbpm.cfg.xml"); to get the left jbpm instance.

to have different versions of jbpm in your server, you need to configure scoped classloaders in jboss and package the jbpms into different .ear files.

those are the most straightforward deployment models that you can persue out of the top of my head.