[Design of JBoss ESB] - Message Store - new implementation changes
by daniel.brum＠jboss.com
I have committed some changes to the Message Store with the way the connection manager works. It's now possible to use the datasource provided in an app. server, tomcat, etc. The design also supports adding in your own connection pooling logic, through a factory. 2 managers are provided
- StandaloneConnectionManager which uses 3CPO for it's connection pooling management.
- J2EEConnectionManager which allows you to use the jndi datasource of your choice.
Some changes have been made to the config of the ESB through the jbossesb-properties.xml to support this:
| <!-- connection manager type -->
| <property name="org.jboss.soa.esb.persistence.db.conn.manager" value="org.jboss.soa.esb.persistence.manager.StandaloneConnectionManager"/>
| <!-- property name="org.jboss.soa.esb.persistence.db.conn.manager" value="org.jboss.soa.esb.persistence.manager.J2eeConnectionManager"/ -->
|
| <!-- this property is only used if using the j2ee connection manager -->
| <property name="org.jboss.soa.esb.persistence.db.datasource.name" value="java:/JBossesbDS"/>
|
You specify the manager type, and if you want to use a datasource, just give it's jndi name. All other settings for a stanadlone deployment stay as they were before.
Please let me know if you have any questions, or issues. I have run all the tests and tested with a SAR deployment inside of JBoss AS only.
thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024881#4024881
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024881
19 years, 1 month
[Design of Management Features on JBoss] - Using xinclude in config files
by scott.stark＠jboss.org
Something I have been meaning to look at for a while now is whether we could use xinclude processing to allow the default dist config files to remain untouched by users. It seems to work as expected and can be used for this, but we need to make some changes to fully support it. First, a little testcase to illustrate some xinclude behaviors:
| package xml.xinclude;
|
| import java.io.FileNotFoundException;
| import java.io.IOException;
| import java.io.InputStream;
|
| import javax.xml.parsers.DocumentBuilderFactory;
| import javax.xml.parsers.DocumentBuilder;
|
| import org.junit.Test;
| import org.w3c.dom.Document;
| import org.w3c.dom.ls.DOMImplementationLS;
| import org.w3c.dom.ls.LSSerializer;
|
| /**
| * Basic tests of xinclude behavior.
| * @author Scott.Stark(a)jboss.org
| * @version $Revision:$
| */
| public class XIncludeTests
| {
| @Test
| public void testInclude() throws Exception
| {
| Document doc = getDocument("testInclude.xml");
| printDoc(doc);
| }
|
| @Test
| public void testIncludeFallback() throws Exception
| {
| Document doc = getDocument("testIncludeFallback.xml");
| printDoc(doc);
| }
|
| @Test
| public void testIncludeFallbackNoBaseUri()
| throws Exception
| {
| Document doc = getDocument("testIncludeFallback.xml",
| "http://apache.org/xml/features/xinclude/fixup-base-uris", false);
| printDoc(doc);
| }
|
| Document getDocument(String name) throws Exception
| {
| return getDocument(name, null, false);
| }
|
| Document getDocument(String name, String feature, boolean flag)
| throws Exception
| {
| DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
| dbf.setNamespaceAware(true);
| dbf.setXIncludeAware(true);
| if (feature != null)
| {
| dbf.setFeature(feature, flag);
| }
| DocumentBuilder builder = dbf.newDocumentBuilder();
| InputStream is = getResource(name);
| Document doc = builder.parse(is);
| is.close();
| return doc;
| }
|
| InputStream getResource(String name) throws IOException
| {
| InputStream is = getClass().getResourceAsStream(name);
| if (is == null)
| throw new FileNotFoundException(name);
| return is;
| }
|
| void printDoc(Document doc)
| {
| DOMImplementationLS ls = (DOMImplementationLS) doc.getImplementation()
| .getFeature("LS", "3.0");
| LSSerializer serializer = ls.createLSSerializer();
| System.out.println(serializer.writeToString(doc));
| }
| }
|
testInclude.xml:
| <?xml version="1.0" encoding="UTF-8"?>
| <a name="a-name">
| <xi:include href="b.xml"
| xml:base="/home/starksm/java/workspace/JavaTests/src/xml/xinclude/"
| xmlns:xi="http://www.w3.org/2001/XInclude"/>
| </a>
|
b.xml:
| <?xml version="1.0" encoding="UTF-8"?>
| <b name="b-name">
| <c name="c-name" />
| </b>
|
testIncludeFallback.xml:
| <?xml version="1.0" encoding="UTF-8"?>
| <a name="a-name">
| <xi:include href="b.xml"
| xmlns:xi="http://www.w3.org/2001/XInclude">
| <xi:fallback>
| <b name="fallback-b">
| <c name="fallback-c" />
| </b>
| </xi:fallback>
| </xi:include>
| </a>
|
The resulting dom for the 3 tests are,
testInclude:
| <?xml version="1.0" encoding="UTF-16"?>
| <a name="a-name">
| <b name="b-name" xml:base="/home/starksm/java/workspace/JavaTests/src/xml/xinclude/b.xml">
| <c name="c-name"/>
| </b>
| </a>
|
testIncludeFallback:
| <?xml version="1.0" encoding="UTF-16"?>
| <a name="a-name">
|
| <b name="fallback-b" xml:base="" xmlns:xi="http://www.w3.org/2001/XInclude">
| <c name="fallback-c"/>
| </b>
|
| </a>
|
testIncludeFallbackNoBaseUri:
| <?xml version="1.0" encoding="UTF-16"?>
| <a name="a-name">
|
| <b name="fallback-b" xmlns:xi="http://www.w3.org/2001/XInclude">
| <c name="fallback-c"/>
| </b>
|
| </a>
|
The changes needed are:
1. Come up with a convention of xml:base location and href to define where overriden config files go by default, and how the override files are names.
2. Incorporate xinclude statements in the config files with fallbacks that correspond to the default out of the box configuration. For some config files we may want the xinclude statements on a per bean level, while others (jms destinations as an example) may only want an include on the root element.
3. Enable xinclude processing on the dom/sax factories. If you don't call setXIncludeAware on the parser factory the xinclude statements are just passed through as is.
4. Either rewrite the schemas/dtds to allow for xml:base in elements that are included, or be able to disable the base URI fixup as specified by the XInclude Recommendation.
The profileservice removes the need for this, but until all managable content is editable via the profileservice, there still is a need for better override support, as well as the cases where a full featured profileservice is not being used.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024869#4024869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024869
19 years, 1 month
[Design of JBoss jBPM] - Re: Transaction Management sync between JBPM and Application
by Narasimha_Addanki
To cater the bussiness requirement am creating those many Context Instances as many number of users are being created at the application level.
The Process is executed for every individual user at JBPM iteratively and the context that was opened, process instance id and user status are stored in a collections object. This object is passed to the application for reading the status of the user and pushing the value objects in to the DB. Once the data placing in to application db is successful then application sends the collections object which only contains the context instances' list and process instances' list.
Comit operations is made into a transaction by saving and closing the jbpm context in the same order in which they were created.
And need to be ready with the delete operations if any exception happend at mid of the closing jbpm context operations
Please provide some value addition for the approach by providing your thoughts
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024829#4024829
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024829
19 years, 1 month
[Design of JBoss Portal] - LDAP offset/limit search implementation
by bdaw
I have little problem with implementation of LDAP searches in portal. In our API we have methods such as:
Set findUsers(int offset, int limit)
| Set findUsersFilteredByUserName(String filter, int offset, int limit)
| Set findRoleMembers(String roleName, int offset, int limit, String userNameFilter)
|
For LDAP I use plain JNDI. Problem is that I don't see anything that can be used to implement offset/limit behaviour. In java 1.4 there is a BATCH size. But it doesn't seem to be enough because I don't see a guarantee that same searches will return same set of elements. Am I wrong about it? In typical usage scenario in portal (paginate view of users in UserPortlet) we perform several independent searches.
I know that there is server side sorting control in for jndi but I'm quite sure it can't be considered as supported by all LDAP servers.
I also found that in java 1.5 (we need to be 1.4 compliant) there is a PagedResultControl which is quite cool. The funny thing is the statement:
anonymous wrote : Note: The Paged Search Control is supported by the Windows Active Directory Server. It's not supported by the Sun Java Directory Server version 5.2
Which for me it translates into: useless - unless you implement a dedicated solution. But still if we think about separate searches it may not be the exact solution.
At the moment implementation is dummy - retrieve all, sort and get a sub list - the least efficient solution if you think about LDAP with hundreds of thousand s of users...
The other possible solution is some kind of caching...
Any suggestion from LDAP/JNDI gury?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024825#4024825
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024825
19 years, 1 month