[Installation, Configuration & DEPLOYMENT] - Re: Upgrading hibernate in JBoss 4.2.2.GA
by jinpsu
Well, this still isn't working correctly. My .war file within the .ear is still trying to use the old hibernate version in the jboss lib directory. I see this exception when the .war tries to use hibernate:
| Caused by: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class,
| java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map,
| org.hibernate.annotations.common.reflection.ReflectionManager)
| at java.lang.Class.getConstructor0(Class.java:2678)
| at java.lang.Class.getDeclaredConstructor(Class.java:1953)
| at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:357)
| ... 67 more
|
The ClassValidator class is in the bundled jboss hibernate jars, not the jars in my .ear.
Not sure if this matter or not, but I'm using oracle and my jdbc driver (ojdbc14.jar) is in server/< config >/lib/. My oracle-ds.xml is in the root of my ear.
How can I debug this further?
thanks.
justin.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170769#4170769
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170769
17 years, 11 months
[JBoss jBPM] - Re: Terminated or deleted process instance?
by lblaauw
Sure,
I dont claim this to be perfect but hey it works, so here is the code for the handler:
| public class VerwijderProcessInstanceHandler extends JbpmHandlerProxy{
| private static final long serialVersionUID = -6125309218094541298L;
| /** Logger available to subclasses */
| protected final Log logger = LogFactory.getLog(getClass());
|
| @SuppressWarnings("unchecked")
| @Override
| public void execute(ExecutionContext executionContext) throws Exception {
| try {
| logger.debug("executing VerwijderProcessInstanceHandler...");
| ProcessInstance pi = executionContext.getProcessInstance();
| logger.debug("ProcessInstance is null? " + (pi==null));
| List<Token> allTokens = pi.findAllTokens();
| logger.debug("allTokens of processInstance: " + allTokens.size());
|
| //clear taskinstances from comments
| Collection<TaskInstance> taskInstances = pi.getTaskMgmtInstance().getTaskInstances();
| for(TaskInstance ti : taskInstances){
| ti.getComments().clear();
| executionContext.getJbpmContext().save(ti);
| }
|
| //clear tokens from comments..
| if(allTokens.size() > 0){
| for(Token t : allTokens){
| //get all comments per token...
| if(!t.getComments().isEmpty()){
| logger.debug("cleared comments before deleting? " + t.getComments().isEmpty());
|
| for(Object o : t.getComments()){
| Comment c = (Comment)o;
| c.setTaskInstance(null);
| }
|
| //clearing comments on taskinsantce manually... pfff
| t.getComments().clear();
| }
|
| executionContext.getJbpmContext().save(t);
| logger.debug("t.getComments().size(): " + t.getComments().size());
| }
| }
|
| //saving without comments and taskinstances within comments...
| executionContext.getJbpmContext().save(pi);
|
| executionContext.getJbpmContext().getGraphSession().deleteProcessInstance(pi, true, true);
| } catch (Exception e){
| //Exception upon deleting processinstance..
| e.printStackTrace();
| logger.error(e.getMessage());
| }
| }
| }
|
Basically I have this handler configured in a Spring application context and then use the spring-jbpm integrationproxy. So I call this handler from within my jBPM process on the action like so:
| <end-state name="end-bevestigRelatieVerzoek">
| <event type="node-enter">
| <action name="verwijderProcessInstanceAction" class='org.springmodules.workflow.jbpm31.JbpmHandlerProxy' config-type="bean">
| <targetBean>VerwijderProcessInstanceHandler</targetBean>
| </action>
| </event>
| </end-state>
|
Allthough I strongly agree with you that I expect the jBPM (engine) to cleant up all process data after a processinstance finishes and I consider it to be a bug that it doesnt ! Coming from working for years with commercial workflow engine products the default behaviour I have allways encountered is to purge all data from the BPM database upon completion. This ensures a lean and mean processing database necesary for speedy processing with large numbers of processinstances or cases. If you then need historical data you as a developer store that in a seperate database....
But maybe some of the core jBPM folks in here could comment on this ?
Greetings and now off to my weekend,
Leo
"twiceknightly" wrote : "lblaauw" wrote : Hey,
| |
| | I just wrote a handler to get rid of all the process instance data including the cascades.
|
| Care to share what you did? I'm sure a fair few people would appreciate it. It seems an big ommission if the one "out of the box" doesn't clean up properly
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170764#4170764
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170764
17 years, 11 months
[EJB 3.0] - Exception on trying to persist more than one object
by jaki
I get the following exception on trying to persist more than one bean object:
anonymous wrote :
| Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.um2.mauction.entity.Enchere.bidder -> com.um2.mauction.entity.Utilisateur
| at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:353)
| at org.hibernate.engine.Cascade.cascade(Cascade.java:139)
| at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:131)
| at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:122)
| at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
| at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
| at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
| ... 48 more
|
The objects to be added are related to each other via foreign keys so I'm guessing it's because a dependent object can't find the parent object in the database (which is getting persisted just above in the same function). Anyway to remedy this behaviour?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170757#4170757
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170757
17 years, 11 months