-
1. Re: EAR-based ProcessDefinition deployment
Hi Rainer,
Are you referring to hot-deploying of pars or merely creating a session bean?
Regards,
Elmo -
2. Re: EAR-based ProcessDefinition deployment
Sorry I clicked submit instead of preview. Just another question, why would you want to redeploy process definion everytime. Just curious.
Regards,
Elmo -
3. Re: EAR-based ProcessDefinition deployment
Hi Elmo,
My problem is that the ONLY access I have to production machines is by way of EAR File. And no, I don't want to redeploy ProcessDefinitions in a static initializer(!yuck) every time. That's what I'm doing now because I haven't solved the problem yet.
The problem is basically that if an EAR is deployed neither the app server nor the application has a chance of knowing if the contained ProcessDefinitions are changed or not. jBPM does not provide an equals() method to compare two definitions (I could build that myself... :-( ) So in order to deploy any changes I have to reploy definitions upon every restart of the app server / redeploy of the EAR.
Maybe I'm just looking at the problem from the wrong direction and don't see obvious other solutions. Any suggestions?
Greeting
Rainer -
4. Re: EAR-based ProcessDefinition deployment
Hi Rainer
I've taken a completely different approach. I use the gpd to edit my process definitions from within eclipse, and then I have an eclipse launch configuration that can load any process definition straight into the database given a parameter (the process definition's name). The class invoked by the launch config can be made to point to different databases. The gpd is interactive, so why not make the loading of the process definition interactive also. Or you could also invoke the same class from an ant build to load the process definition into some database.
My ear(s) then only contain the code that interact with the process definition. For example, token.signal(), etc. - no code for loading a fresh process definition. So, when I use the application in the ear, it just uses the latest version of the process definition. Obviously I could use a specific (property driven) version of the process definition if it is a production environment. Because of the versioning jBPM does, I think it is safe to load the process definition straight into the production database - once I've tested it in my test environment of course.
Hope this helps
Johan -
5. Re: EAR-based ProcessDefinition deployment
Hi Johan,
thanks for the tip but my only access to the productions servers is the EAR ( + database scripts). I don't even know where the machines are hosted! All I can do is give the company with the three letter name an EAR and say 'deploy'. That's it. NO database access, NOTHING interactive, NO webapp.
So... your suggestion wouldn't work. But thanks anyway.
Rainer -
6. Re: EAR-based ProcessDefinition deployment
How about your static initializer checks to see if the processdefinition already exists with a specific version number (which you get from a property in a properties file). If not, then you load it (from the processdefinition.xml file in the ear).
-
7. Re: EAR-based ProcessDefinition deployment
Hi Rainer,
I don't know if I got you correctly, but you want everything packaged in the ear file. If that is what you want, I know in Jboss but I dont know in other environments. You place everything, the sars, jars, ds files and everything you need for your application inside the ear. All you need to is to add a jboss-app.xml configuration for the services. Tell me if this is what you need I will give you the details.
Regards,
Elmo -
8. Re: EAR-based ProcessDefinition deployment
BTW, I also forgot. You can place a servlet just for starting up and nohting more just to deploy your definitions. Just put the methods inside a service or init (not doPost or doGet)
Regards,
Elmo -
9. Re: EAR-based ProcessDefinition deployment
Thanks for all the responses!
@Johan
Version numbers in props? I'll probably go in that direction, but having the jBPM version number in props would bring up all sorts of problems. What happens if I or the three letter company misses a deployment. What happens if someone goofs. Once the system is out of sync you would have a pretty hard time figuring out what is going on and getting back on track. But it could work. Have to go through the error szenarios.
Another idea would be to place some kind of marker in the processDefinition itself and check if that exists / matches. Worstcase would be an unconnected 'marker node' with a version number coded in a transition or something like that (yuck, maybe I'll find something better.)
@Elmo
Sure everything is contained in the EAR. The problems is getting it into the database. jBPM can't do very much with *.pars in a EAR :-(
Still taking suggestions :-)
Rainer -
10. Re: EAR-based ProcessDefinition deployment
You could add a file to your par archive containing the particular version of the processdefinition in your ear file. And then I would also opt for the init mechanism of a dedicated servlet to do the verification if a redeployment is necessary and actually do the redeployment if this is the case.
Regards,
Koen -
11. Re: EAR-based ProcessDefinition deployment
Yes, you will have to keep track of the version number. But you do use cvs (or something) and ant don't you?
Then you will have your processdefinition.xml and your properties file in cvs. And the properties file goes into the ear.
This way only one file gets deployed (the ear) and you "only" have yourself to blame if things go out of sync.
Oh, this means the rest of your production system must always work with the latest version... I don't think you want another properties file with the version number to use for the rest of your system.
I'm more worried about the static initializer. It only gets invoked if your class gets loaded, not so? And the class only gets loaded if it is needed. So what will need your class to be loaded, mmm?
Maybe the idea about an application server-specific service that loads at startup is not a bad one... -
12. Re: EAR-based ProcessDefinition deployment
... I agree with Koen about using a servlet. I do so myself. Inside a war inside the ear.
-
13. Re: EAR-based ProcessDefinition deployment
Ok guys,
so it's going to be work. No 'magic' solution :-(
Oh well... thanks for trying.
The static initializer is ugly and has big comments above it "remove before production release" but its in a central place and will always get called. I'll have to check if a war even gets deployed. This is the most paranoid - ah.. sorry 'security concious' :-) - environment I have ever worked in.
Koens suggestion is what I was going for with the version number (not the hibernate version number) in the processDefinition. Only if its not in the processDefintion itself I'll have to store version numbers in an own DB table :-( I'll try out both approaches, but I like the 'dummy' Node approach best.
@Johan Shit happens. What I'm going for is a fail safe process. (I randomly sprinkle Exceptions at a 60% rate and still expect everything to workout fine.) I haven't checked the possible szenarios but anything that relies on hibernate version numbers is critical as I have no way of knowing the current hibernate version number when packaging the ear.
Thanks again
Rainer -
14. Re: EAR-based ProcessDefinition deployment
I'm not sure I understand what you mean with Hibernate version numbers????
The version number I'm talking about is the version of the process definition.