[jbpm-dev] [Design of JBoss jBPM] - Re: Undeployment in JBosss Deployer

kukeltje do-not-reply at jboss.com
Fri Jun 19 06:39:27 EDT 2009


anonymous wrote : Why should it be different then any other Java EE deployment? You guys always try to come up with extraordinary requirements for processes. If you delete an EAR there is no backup either.
  | 
Correct, but normally you do not loose your date in the database that belongs to the application. I do not think Bernds suggestion is that out of the ordinary.

anonymous wrote : I think people are smart enough to understand the impact.
Well, I do want to generalize, but the people at ASP/ISP's that do deployments or people within companies themselves can do and will do strange things and often. Even if they have a script (paper that is in some cases)

anonymous wrote : 
  | But in general you should discuss wether or not to keep the deployer at all. 
  | The way it was written, it did intend additional changes to the core runtime. Especially classloader association upon deployment. In order to get the classloader scoping right, we would need to associate the classloader that the deployer framework provides and not write class info to the database. Similiar to what Bernd did to jbpm3. 
  | 
  | If we would complete it in that way, the question of deletion versus suspension would become different. 
  | 
  | But honestly, that whole deployment discussion has been going on since december last year and I am tired of repeating myself. 
  | I'd say either you complete the deployer or you remove it at all. 

The idea was/is not that wrong, it got the discussion about versioning in the right direction. Personally I do like it but I also do not mind if a kind of startup-servlet did this (AS independent) and took everything from e.g. the war but uses the same versioning rules.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238735#4238735

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238735



More information about the jbpm-dev mailing list