[JBoss JIRA] Created: (JBESB-1426) CBR XPathDSL should allow namespace aware documents
by Vinicius Carvalho (JIRA)
CBR XPathDSL should allow namespace aware documents
---------------------------------------------------
Key: JBESB-1426
URL: http://jira.jboss.com/jira/browse/JBESB-1426
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Content Based Routing
Affects Versions: 4.2.1
Reporter: Vinicius Carvalho
Priority: Optional
Current version of DSLHelper, does not allow one to use namespace documents to be routed. For instance, the document
<acme:bomb xmlns:acme="http://acme.com/schemas">
<acme:model></acme:model>
</acme:bomb>
does not work with the xpath expression : "//acme:model" since the xpath is not namespace-aware.
The use of a namespace should allow this, the action should support it, for instance:
<action name="ContentBasedRouter" class="org.jboss.soa.esb.actions.ContentBasedRouter">
<property name="namespaces">
<namespace prefix="acme" uri="http://acme.com/schemas"/>
<namespace prefix="foo" uri="http://bar.com/schemas"/>
</property>
</action>
On the configuration of the action (sorry still trying to figure where to put this :( )
the following namespace could be used:
package com.synos.csm.eai.xml;
import javax.xml.XMLConstants;
import javax.xml.namespace.NamespaceContext;
import java.util.Iterator;
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import java.util.ArrayList;
import java.util.List;
public class CustomNamespaceContext implements NamespaceContext {
private Map map;
public CustomNamespaceContext() {
map = new HashMap();
map.put(XMLConstants.XML_NS_PREFIX, XMLConstants.XML_NS_URI);
map.put(XMLConstants.XMLNS_ATTRIBUTE, XMLConstants.XMLNS_ATTRIBUTE_NS_URI);
}
public void addNamespace(String prefix, String namespaceURI) {
map.put(prefix, namespaceURI);
}
public String getNamespaceURI(String prefix) {
return (String) map.get(prefix);
}
public String getPrefix(String namespaceURI) {
Set keys = map.keySet();
for (Iterator iterator = keys.iterator(); iterator.hasNext();)
{
String prefix = (String) iterator.next();
String uri = (String) map.get(prefix);
if (uri.equals(namespaceURI)) return prefix;
}
return null;
}
public Iterator getPrefixes(String namespaceURI) {
List prefixes = new ArrayList();
Set keys = map.keySet();
for (Iterator iterator = keys.iterator(); iterator.hasNext();)
{
String prefix = (String) iterator.next();
String uri = (String) map.get(prefix);
if (uri.equals(namespaceURI)) prefixes.add(prefix);
}
return prefixes.iterator();
}
}
now, inside the DSLHelper, set the namespace aware xpath:
//check if user has set the namespace property
if(namespaceAware)
xpath.setNamespaceContext(customNamespaceForThisAction);
I had to override the DSLHelper in my project, I guess that this approach should help a lot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBESB-1153) File Gateway: Consume only a single file at a time
by Burr Sutter (JIRA)
File Gateway: Consume only a single file at a time
--------------------------------------------------
Key: JBESB-1153
URL: http://jira.jboss.com/jira/browse/JBESB-1153
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.2
Reporter: Burr Sutter
Assigned To: Mark Little
Fix For: 4.3
The current File gateway consumes files at a rate faster than the internal/native listener (typically JMS-based) and its associated action chain. This request is for a configuration property that causes the rate of consumption of the file gateway to match the underlying internal/native listener. Basically a file would not be pulled from disk until it has completely passed through the action chain.
Here are some notes related to this use case:
I have 1000+ files which are very huge in size and when all the
files are kept in the folder they are read at same time and placed in
configured JMS Queue.
- When all the files are placed in Queue there is a chance that the size
of messages in Queue may exceed and it may not accept new messages?
Or
- Sometimes the case may be like the input folder is monitored by one
person and the message processing is monitored by other person. In this
case when all the files are read at once it gives a wrong assumption
that all files are processed but where as due to some application
failure the messages may still be in queue.
Or
- Its always a good option to be able to see how many messages are still
in process in the folder rather than browsing the JMS queue and looking
for Queue depth. In this case if you look at Queue depth sometimes it
may be give you wrong count of messages as there is a chance that some
other application also put message some messages into the same queue,
when Queue is configured for application sharing.
Or
- If you want to replace a single file out of 1000+ files in the input
folder while in middle of processing the files, it will be easy if the
files are read one at a time rather going and deleting the messages from
JMS queue after they are read at once and placed in Queue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Created: (JBESB-643) Add BRMS support to RuleService
by Jeff DeLong (JIRA)
Add BRMS support to RuleService
--------------------------------
Key: JBESB-643
URL: http://jira.jboss.com/jira/browse/JBESB-643
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Content Based Routing
Reporter: Jeff DeLong
Assigned To: Mark Little
Add BRMS support to the platform. In particular the capability to specify a rulesBase in the ruleService configuration and have the ruleService retrieve the ruleBase from the BRMS instead of creating ruleBase on the fly from drl / dsl files on the classpath. This will allow for better maintenance and management of the rules, as well as "hot" deployment on the rules.
Note - I listed this under CBR as there is not a RuleService Component listed, however it applies to both CBR and RuleService.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Created: (JBESB-644) Add support for both stateless and stateful RuleServices
by Jeff DeLong (JIRA)
Add support for both stateless and stateful RuleServices
--------------------------------------------------------
Key: JBESB-644
URL: http://jira.jboss.com/jira/browse/JBESB-644
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Content Based Routing
Reporter: Jeff DeLong
Assigned To: Mark Little
The current JBossRuleRouter (which currently implements the RuleService) uses StatefulSessions in a Stateless way. Which is fine in most cases). JBossRulesRouter creates a new workingMemory (StatefulSession), asserts facts, and should (although it does not currently, disponse of the workingMemory - See also JBESB-642. ).
JBoss Rules support StatelessSessions. The need to dispose of workingMemory is eliminated if StatelessSessions are used. StatelessSession have some limitations compared to Stateful, but are designed for instance, for rule applications deployed as web services, where basically a single method needs to transfer all the data, create the workingMemory, assert the data (as a single object or list of objects) and fire the rules. CBR can be thought of as a stateless service. A single Message object is asserted into working memory, and the rules are fired. Many rule application will be like this.
However, some rule applications are truly stateful. For example, the rules accumulated facts with specific attribute values over time and then fired when a certain number was reached. These types of services would require that the workingMemory not be re-created with the receipt of each message, and disposed of after the rules have fired, but have a long-lived working memory that gets added to over time. The current JBossRulesRouter cannot support truly stateful services because it creates a new workingMemory with each message. Truly stateful interactions would require a way to identify the stateful session / working memory that a message is for, and also when to finally dispose of it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months