[jBPM] New message: "Re: getting name of leaving transition from decision node (jbpm 4.0)"
by praneet nandan
User development,
A new message was posted in the thread "getting name of leaving transition from decision node (jbpm 4.0)":
http://community.jboss.org/message/529770#529770
Author : praneet nandan
Profile : http://community.jboss.org/people/praneet
Message:
--------------------------------------------------------------
> there is no such method available in public API
i know this there is no such method like this ,but i am expecting if there such
> From JSP page point of view it's transparent either you will use dynamic query of node's transitions or set it manually as process variable in the model.
suppose if tomorrow i have to include two more transition then i need to set these two also using processvariable which is not good as i have to modify this code.so i want solution like this so that if new transition come there is no need to change the code.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529770#529770
16 years, 1 month
[Beginner's Corner] New message: "Jboss fails to start No error in console or logs."
by Dan Murphy
User development,
A new message was posted in the thread "Jboss fails to start No error in console or logs.":
http://community.jboss.org/message/529769#529769
Author : Dan Murphy
Profile : http://community.jboss.org/people/djm_learningJboss
Message:
--------------------------------------------------------------
Windows xp jboss 4.2.2.GA
2010-03-03 21:01:27,753 DEBUG [org.jboss.system.pm.AttributePersistenceService] Started jboss:service=AttributePersistenceService
2010-03-03 21:01:27,753 DEBUG [org.jboss.management.j2ee.LocalJBossServerDomain] handleNotification: javax.management.Notification[source=jboss.system:service=ServiceController][type=org.jboss.system.ServiceMBean.start][message=]
2010-03-03 21:01:27,753 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss:service=AttributePersistenceService dependent components: []
2010-03-03 21:01:27,753 DEBUG [org.jboss.system.ServiceController] starting service jboss.system:service=ThreadPool
2010-03-03 21:01:27,753 DEBUG [org.jboss.management.j2ee.LocalJBossServerDomain] handleNotification: javax.management.Notification[source=jboss.system:service=ServiceController][type=org.jboss.system.ServiceMBean.start][message=]
2010-03-03 21:01:27,753 DEBUG [org.jboss.system.ServiceController] Starting dependent components for: jboss.system:service=ThreadPool dependent components: [ObjectName: jboss:service=WebService
State: CREATED
I Depend On:
jboss.system:service=ThreadPool
, ObjectName: jboss:service=Naming
State: CREATED
I Depend On:
jboss.system:service=ThreadPool
jboss:service=NamingBeanImpl
]
2010-03-03 21:01:27,753 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=WebService
2010-03-03 21:01:27,753 DEBUG [org.jboss.web.WebService] Starting jboss:service=WebService
Then exits. Wonder how to approach finding the issue?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529769#529769
16 years, 1 month
[jBPM] New message: "Trouble with jBPM 4 job executor and context reloading."
by Caine Lai
User development,
A new message was posted in the thread "Trouble with jBPM 4 job executor and context reloading.":
http://community.jboss.org/message/529756#529756
Author : Caine Lai
Profile : http://community.jboss.org/people/unsavory
Message:
--------------------------------------------------------------
In my development environment I have resorted to disabling the jBPM 4.3 job executor because when I publish any changes to my jBoss server which results in a context reload, the job executor thread doesn't die off. The old thread continues to run and I get the following exception:
14:36:44,981 SEVERE [org.jbpm.pvm.internal.jobexecutor.DispatcherThread] exception in job executor thread. waiting 5000 milliseconds: java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext
at org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:171)
at org.springframework.context.support.AbstractApplicationContext.getBeanNamesForType(AbstractApplicationContext.java:1101)
at org.jbpm.pvm.internal.env.SpringContext.get(SpringContext.java:59)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:139)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:130)
at org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:201)
at org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:190)
at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.resolveTransactionManager(SpringTransactionInterceptor.java:89)
at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:52)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)
Does anyone have any ideas how to get around this? I am using the jBoss server adapter within eclipse.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529756#529756
16 years, 1 month
[JBoss Tools] Document updated/added: "A good start!"
by Robert (Bob) Brodt
User development,
The document "A good start!", was updated Mar 3, 2010
by Robert (Bob) Brodt.
To view the document, visit:
http://community.jboss.org/docs/DOC-14913#cf
Document:
--------------------------------------------------------------
Not just the punchline to an indelicate lawyer joke and a memorable quote from a 90's movie, “a good start” also describes the BPEL tooling that is offered as part of the http://in.relation.to/Bloggers/JBossTools31CR2CDILessTypingAndTheLastPolish. While this release focuses mainly on stabilizing existing tools and the addition of new features, the BPEL Editor User Experience (as I'm sure the JBossTools team will agree) still leaves much to be desired.
Besides having an incredibly non-intuitive user interface bordering on the user hostile, the eclipse BPEL Editor still has quite a few serious bugs and gaps in functionality. After having played with Riftsaw and the JBossTools for about a month, I came up with a list of fixes and enhancements I'd like to see implemented within the next few releases. Some of these are “nice to have”, others are a definite “must have”.
“Must have” Features:
* Validation: While there has been a great deal of work already done to improve the BPEL validation, I still ran across some compilation errors that the in-built validator did not catch. My recommendation would be to run the Riftsaw bpelc compiler during a project build to ensure the bpel will compile. Compilation is relatively fast and I don't anticipate this being a huge problem if the user has “Build Automatically” enabled on the eclipse Project.
* Refactoring: Often times I find myself changing the names of variables, port types, partner links, etc. either in the Property sheet or directly on the editor canvas without thinking; what I really wanted to do was refactor the name change and have it propagate through to the WSDL or XSD where the element is defined. It would be simple enough to provide a change listener that prompts you with “Hey, I noticed you changed the name of this <thing> - did you intend to refactor instead?” possibly with a “Don't ask me again!” checkbox. The same functionality should be provided for the WSDL and XSD editor. This would go a long way to better integration within the tooling.
* Better synchronization between design & source views and Property sheets.
“Nice to have” Features:
* Complex variable initialization within Assign: this could easily be solved with the addition of a button to the Assign Properties/Details tab which displays a variables selection dialog. The editor could then generate the appropriate XML to initialize complex variables. Apparently, the Riftsaw engine requires the structure of complex variables to be set before they can be accessed.
* Debugging (really, really nice to have): At the least I would like to be able to set breakpoints and inspect variables at runtime; of course a full-featured interactive debugger, which allows single-stepping, changing variables, watchpoints, etc. would be nice to have.
* “Follow link” capabilities from the BPEL editor to WSDL/XSD and from WSDL editor to XSD for messages, port types and partner links.
Must fix Bugs:
* The namespace cache is not being refreshed correctly when editing in source view. This causes some strange validation errors, as message parts and variables may no longer be resolved correctly.
* The validator does not understand return types of xpath functions; e.g. starts-with() returns boolean, but when used in a condition, the validator reports this as “not a boolean expression”
* The concat() function argument validation appears to have a bug; not all arguments are recognized correctly as variable references.
* There appears to be some kind of caching problem in the validator (unrelated to namespaces) which prevents it from correctly resolving variable parts. Sometimes the only way to remove Error Markers is to close and reopen a project.
I'd like to use this wiki document as a "wish list" for new features, so please feel free to add your $0.02 worth!
--------------------------------------------------------------
16 years, 1 month