jbpm.sar access

[jglan]

As a newbie I wonder how the web application or e.g. some other ear gains access to jbpm. I looked at the jboss-service.xml for the mbean definitions and would expect some place where this jndi-name is used in some ctx.lookup(), but it looks I'm too stupid to find it.
I know I should start reading many books first, but Iam too impatient right now. So I really appreciate some hints (what to read first etc) or pointers into the examples/tests etc. that could help me to understand how to access jbpm from within some other ear e.g. in order to start a deployed process or so.
Thanks a lot in advance.

[kukeltje]

Explicitly stating "it looks I'm too stupid" and "I'm too impatient" and expecting an answer from us? ok... the thing to read first is the source, or if reading it takes to much time, try searching it.

[jglan]

Well, I know these questions must be boring for you...
Anyway, I have to decide for or against using jbpm in our project and unfortunately have to argue against some guy who would prefer doing all himself. We'd like to setup some job queuing system (for doing protein ID searches) based on jbpm for the actual execution of jobs. There can be long running parallel jobs (several hours) that need some post processing once both "splits" are done. I know that jbpm can't really handle parallel execution (except when you use async flag), so its not so easy as it appeared first. This means I have to do a lot testing/playing I guess and read a lot before things become clear. I wished there is some guide that explains from scratch how to use jbpm from within another ear. Testing and running it standalone is not very helpful for me (besides looking at the tests/examples).
So is there any good guide to look at ?

[the_dude]

"jglan" wrote:
I wished there is some guide that explains from scratch how to use jbpm from within another ear. Testing and running it standalone is not very helpful for me (besides looking at the tests/examples).

I second that. I am very happy for all you jbpm experts, congratulations for knowing that much. However, I think it is not ok for just answering again and again with a vague "look at the source / test cases". Could you be just a bit more concrete?

I have to do many switches between process instances and had to test quite some time to figure out how this is (probably) done. Or the usage of the jbpm.sar: I have searched the source code for the jndi name 'java:/jbpm/JbpmConfiguration' that I found in the jboss-service.xml. Guess what: I only got hits inside the build\jbpm.sar.dir, doc\userguide\, src\resources\jbpm.sar and src\userguide.
Does it help me to find out how you guys use this service? Not really.

@JBoss: What does it tell you about your documentation when so many people, perhaps not all beginners, keep asking 'trivial' questions about jbpm?

Right now I am a bit disappointed. Getting started with jBPM is not straightforward - at least not for me.

[kukeltje]

As I posted in another forum, things changed on this subject and it is indeed not possible to find this out by using the source... Sorry, I take some of my comment back, but still do not appreciate the 'stupid' (even if it was not towards us) and the 'lazy' remarks.

Sometimes people post questions in a way that are so short. They do not describe what they tried to find out themselves, at least not in some detail, that you realy get the impression that people are lazy e.g. thinking my time is expensive, let someone else answer it. Well guess what. My (personal, private often nightly) time is also expensive (I hope someone knows the "for everything else there is mastercard" advertisement and no, it is not the everything else)

Ok, now back to your question. It is not trival as I found out after I needed something similar in the company I work for. The real trivial questions are mostly posted by people who have now java knowledge at all and try to modify the webapp or sometimes even more trivial things. That is the downside of opensource, even a 6th grade kid can start with it and ask questions. Most people with some java knowledge *can* work with the testcases/examples/documentation/wiki/... and come a long, long way.

If you would have put the

I have to do many switches between process instances and had to test quite some time to figure out how this is (probably) done. Or the usage of the jbpm.sar: I have searched the source code for the jndi name 'java:/jbpm/JbpmConfiguration' that I found in the jboss-service.xml. Guess what: I only got hits inside the build\jbpm.sar.dir, doc\userguide\, src\resources\jbpm.sar and src\userguide.

in the originl post, It would have given us some more detail and the response would have been different.

With regard to using jbpm in another ear, you do not HAVE to use the .sar file. The other solution, including everything in the ear is a different and easy to setup solution. Using it from a sar has (that is where I agree) become a different issue.

So, lets summarize. The getting started is fine but it lacks "how to use jbpm sar from a different app than the default webapp". imo it is an 'advanced' subject and not the 'getting started' but I agree it could be addressed in a little more detail

[jglan]

Well, sorry for not having been precise enough and for the lazy statement.
Actually I'm new to all this J2EE business (moving from a long C/C++ (solaris and now last 6 years Microsoft only) background to J2EE) and have a hard time learning. So I often feel stupid right now and may have not tried hard enough (several hours). So I think I wasn't really lazy...
Anyway, wouldn't using the jbpm libraries directly within your ear conflict with some j2e standards ? e.g. "don't using threading,"don't write to disk"
So there seems to be a good reason having jbpm in a separate sar, isn't it ?
At least that has become my understanding (from reading) why you would need a separate sar/MBean (to do all the things that are "forbidden" by the ejb specs)

[kukeltje]

Thanks for responding. The thing is that without some context it is difficult for us to differentiate between beginners and realy lazy people ;-) Therefor my suggestion to give som context.

Using the SAR is not because of the j2ee specs, it is more to have a single jBPM 'instance' that can be accessed from different applications. Embedding it is also possible, but then there can be db conflicts etc if used with the same database. You'd have to configure separate db's and jbpm configs then for multiple instances

Threads are not 'forbidden' from servlets afaik, as long as you use it for things like quartz or our scheduler does. You should not create threads for each request that comes in etc. About the not writing to disk, I've never heard of that, but it is true that writing to disk cannot participate in a transaction, so if you need transacted persistence it is a no-no

[kukeltje]

btw, also lool at the other post: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82440

[jglan]

Thank your for your answer. I switch between the 2 threads...
Although I must say that I'm not really satisfied yet regarding the single instance that can be accessed from everywhere...

[jglan]

Threads are not 'forbidden' from servlets afaik, as long as you use it for things like quartz or our scheduler does. You should not create threads for each request that comes in etc. About the not writing to disk, I've never heard of that, but it is true that writing to disk cannot participate in a transaction, so if you need transacted persistence it is a no-no

I agree this (may) be true for servlets. What about the ejb a sevlets accesses ? So within an ejb threads seem to be forbidden (as disk access I guess because of clustering issues e.g). It seems to be vague for many people. Whenever I ask one who had been/is using ejb for some time I got a ' I heard about it'. I can only say the same. Looks like once you feel comfortable in using it this question is not important anymore..

[kukeltje]

"jglan" wrote:
Looks like once you feel comfortable in using it this question is not important anymore..

Yep. Never ever had a problem with it for the last 6 years ;-)

[koen.aers]

"the_dude" wrote:

@JBoss: What does it tell you about your documentation when so many people, perhaps not all beginners, keep asking 'trivial' questions about jbpm?

Right now I am a bit disappointed. Getting started with jBPM is not straightforward - at least not for me.

Please bear with us, we are doing the best we can. While I agree certain areas in the docs could be much more elaborated, I nevertheless think that most of the stuff is treated fairly extensively.
Starting with jBPM is not 'trivial'. Keep in mind that it is an integration platform and that a lot of complex interactions with other technologies come into play. So in the meantime we will keep helping you with answering questions. The only thing we expect is that you at least read the docs and search the forums for similar problems before asking...

Regards,
Koen