[JBoss jBPM] - Re: bpws.getVariableData as predicate is not supported?
by meghanai_99
Here is what I had to do to get it working.
1. Change query.functions.xml as shown above.
2. Added overloaded method in QueryEvaluator and XPathQueryEvaluator
| public Object evaluate(Node contextNode, Token token) {
| try {
|
| this.setVariableContext( new ScopeVariableContext(token));
| this.setFunctionContext( functionLibrary);
| //TODO: if no where else, add method in SetNamespaceContext to add bpws.
| ((SetNamespaceContext)this.getNamespaceContext()).addNamespace( "bpws", "http://schemas.xmlsoap.org/ws/2003/03/business-process/");
| List nodeset = selectNodes(contextNode);
| return narrowToSingleNode(nodeset);
| }
| catch (JaxenException e) {
| throw new BpelFaultException(BpelConstants.FAULT_SUB_LANGUAGE_EXECUTION);
| }
| }
Note: The namespace context did not have 'bpws' prefix which I have hardcoded here, I will get to fixing that hack next. I added a method in SetNamespaceContext to add a namespace at a time if prefix doesn't exist already.
3. I call this new method in FromVariable.
| value = query.getEvaluator().evaluate((Element) value, token);
|
4. Jaxen only allows 'number' or 'boolean' in predicate. With my original XPath, it was returning nodeset and getting resolved as boolean 'true'. So I had to wrap my 'getVariableData' call inside XPath 'number' function.
| /ns9:GetItemsByQueryResponse/ns9:return[number(bpws:getVariableData("ForEach_index"))]/ns9:genericItem/ns9:itemID
|
This got my while loop working.
Meghana
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083230#4083230
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083230
18 years, 7 months
[JBossCache] - Re: Problems with NodeLocking algorithm
by jacek187
Hi
I found next problem with node locking and transaction timeouts.
On WebLogic (and on another application servers too) if transaction is timed-out and thread witch timed-out transaction is still working on request (i.e. is waiting on locks, reading file etc., important is that transactional method invocation has not ended before timeout) server is calling rollback on timed-out transaction in another, separate thread.
This give a chance to release used resources - db connections, locks etc.
Problem is, that sometimes treecache dosen't release acquired WL when timed-out transaction is rolledback in separate thread.
I have reported some moths ago similar bug http://jira.jboss.com/jira/browse/JBCACHE-923, now effects are identical, but scenario is more complicated.
Scenario4:
Cache has node /a.
new transaction is started. Transactional method is doing something on cache (i.e. /b node is created) (transaction is registered in InvocationContext) and waits until transaction has timed-out. Transaction has timed out (i smarked by container as rollBackOnly). Now method will modify /a node (until now no WL was acquired on this node). Warning about (not ACTIVE or PREPARING) current transaction status from getCurrentTransaction is printed, and null is passed as GlobalTransaction argument, but in InvocationContext is still transaction stored, so pessimistickLockIntercepotr still can use this transaction object.
This Thread has just acquired WL on node /a and now is trying to record this lock. Assume that thread sleeps now in recordNodeLock (simulate heavy-load), gtx is not null. Now container has decide to rollback this transaction. Rollback phase is executed. Most important from this operation is, that TransactionEntry from transactionTable is removed. Rollback phase is finished, Thread-0 can continue execution. Thread-0 is executing:
cache.getTransactionTable().addLock(gtx, lock);
but corresponding transactionEntry couldn't be found, because it was removed in rollback phase. Unfortunally only error is logged, and code execution is continued. Information about acquired WL is never used, and this lock never will be released.
This issue was observed in real application.
I think, that
* additional condition must be added - if acquiredLock can;t be recorded, he must be immediatly released and exception should be thrown.
* what is thew sense of continue cache opertions when transaction is marked as rollbackOnly? maybe immediatly exception should be thrown? (something like container)
Jacek Halat
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083227#4083227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083227
18 years, 7 months
[Management, JMX/JBoss] - Change to newer JDK, MBean is not a NotificationBroadcaster
by jgreif
After upgrading an existing application running in JBoss 4.0.5GA from Java 1.4.2 to Java 1.5.0_12, attempts to establish NotificationListeners on previously working MBeans now fail with the message "The speicfied MBean [com.webalo.am:typeName=UPS Dispatcher] is not a NotificationBroadcaster." The MBean in question extends NotificationBroadcasterSupport.
In compiling and packaging the MBean, all old MX4J libraries have been moved out of the way. During JBoss startup, when the error occurs, tracing of classloading indicates that all the javax.management.** classes are loaded from the JRE's rt.jar as expected, and there appear to be no duplicates. The MBeanServer is loaded from jboss-jmx.jar and is the class org.jboss-mx.server.MBeanServerImpl.
I do not see a setting of the javax.management.builder.initial system property in any configuration file.
Any suggestions will be greatly appreciated.
Jeff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083218#4083218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083218
18 years, 7 months