[Design of JCA on JBoss] - Re: JCA AOP-MC Integration
by vickyk
I have been trying to run the jboss-jca test cases with the Jboss5 from the svn trunk . I did the following steps
1) Copied the jboss-jca project from the cvs in the jboss5 trunk.
2) I was able to build the project , but when I am running the testC:\svn\JbossTrunk\jboss-jca>ant -Dtest=org.jboss.test.jca.notx.test.NoTxUnitTest
| Case -buildfile build-test.xml one-test
| Buildfile: build-test.xml
|
| _buildmagic:init:
| Trying to override old definition of task property
|
| _buildmagic:init:buildlog:
|
| configure:
| Overriding previous definition of reference to jboss.test.classpath
| Overriding previous definition of reference to jboss.jca.classpath
|
| _default:task-init:
|
| init:
|
| one-test:
| [junit] Running org.jboss.test.jca.notx.test.NoTxUnitTestCase
| [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0.547 sec
| [junit] TEST org.jboss.test.jca.notx.test.NoTxUnitTestCase FAILED
|
| BUILD SUCCESSFUL
| Total time: 2 seconds
| C:\svn\JbossTrunk\jboss-jca>
In the report folder I see the root cause of the error as Caused by: javax.xml.parsers.ParserConfigurationException: Feature 'http://apache.org/xml/features/xinclude' is not recognized.
| at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
| ... 12 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062656#4062656
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062656
18 years, 9 months
[Design of JBoss ESB] - Re: Uniquely identifying services and actions
by mark.little＠jboss.com
"tfennelly" wrote : I think what you're missing is the difference between the actions "name" and "class". One should be allowed to have multiple action instances having the same "class" attribute value on a single action pipeline, but each of these must have a unique "name" for that chain e.g. in the following action chain, we have 2 transformers with the same "class", but different "name"s. The "name" is what we could use in the global version of this actions name.
Yes, I'd forgotten about the name in the xml config. That makes it easier to do the class name/instance name automatically.
"tfennelly" wrote : Right, but I think it only needs to be unique on a per service/action-chain basis, right? You should be able to have the same action on 2 different chains e.g. "transform_CSV2XML" on 2 different action chains within the same dot esb. Globally, they'd be qualified by their containing service category+service name, which would be unique within the scope of the .esb (right?).
|
| Yeah, so we need to enforce uniqueness wherever we need to.
However, I think we need to be careful about making statements concerning *global uniqueness* based on service category and service name when we don't have a formal policy for federated registries yet.
So it sounds like we have the information for uniqueness within an ESB deployment that we covered earlier today. So now do we go back to the issue of nicknames ;-)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062654#4062654
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062654
18 years, 9 months
[Design of JBoss ESB] - Re: Uniquely identifying services and actions
by tcunning
Yes - this what I was trying to get at - transform_CSV2XML is another good example - two SmooksTransformers and two SystemPrintln actions within the same service.
The problem I see is that we don't enforce uniqueness on either <action name="XXX" .../> within a service or <service name="YYY" .../> within a .esb - for example :
| <actions>
| <action name="print" class="org.jboss.soa.esb.actions.SystemPrintln">
| <property name="message" value="[transform_CSV2Smooks_Intermediate_format] Message before CVS to XML transformation" />
| </action>
| <action name="print" class="org.jboss.soa.esb.actions.SystemPrintln">
| <property name="message" value="[transform_CSV2Smooks_Intermediate_format] Message before CVS to XML transformation" />
| </action>
| </actions>
|
Both actions have the name "print", and this deploys and runs fine. I think that's going to be confusing to the user, and we should probably start enforcing uniqueness at deploy-time.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062613#4062613
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062613
18 years, 9 months
[Design of JBoss ESB] - Re: Uniquely identifying services and actions
by tfennelly
"mark.little(a)jboss.com" wrote : So you're saying that you will never want to deploy multiple actions of the same type within the same chain? Seems like an artifical limitation, but maybe I'm missing something ;-)?
I think what you're missing is the difference between the actions "name" and "class". One should be allowed to have multiple action instances having the same "class" attribute value on a single action pipeline, but each of these must have a unique "name" for that chain e.g. in the following action chain, we have 2 transformers with the same "class", but different "name"s. The "name" is what we could use in the global version of this actions name.
| <action name="transform_01" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
| <property name="resource-config" value="/smooks-res_01.xml" />
| </action>
|
| <action name="my_blah_action" class="com.acme.SomeOtherAction" />
|
| <action name="transform_02" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
| <property name="resource-config" value="/smooks-res-02.xml" />
| </action>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062604#4062604
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062604
18 years, 9 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread
by JerryGauth
Ignoring HAServiceMBeanSupport/HAServiceMBean for the moment, here's what we're now agreeing to implement, pending other objections.
1) Remove the following methods from relevant classes.
ClusterPartitionMBean getClusterPartition()
| void setClusterPartition(ClusterPartitionMBean)
| void setPartitionName(String)
2) Add the following methods as replacements.
HAPartition getHAPartition()
| void setHAPartition(HAPartition)
3) Undeprecate the following "convenience" method.
String getPartitionName()
I'm not familiar with the use of HAServiceMBeanSupport/HAServiceMBean. The javadoc and class names suggest that this class is provided to allow clients to extend the implementation and integrate with their own clustered mbeans. If we modify the mbean/implementation so that clients access the cluster's interface rather than its mbean, does that affect clients who might want access to the mbean itself?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062603#4062603
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062603
18 years, 9 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread
by bstansberry＠jboss.com
Hmm. Hoisted (sic??) by my own petard.
Seems it's pretty consistently "ClusterPartition". HAServiceMBean as well; that's the class end users are likely to use. I named the attribute "ClusterPartition" when I added it for dependency injection of the ClusterPartitionMBean.
OK, then, "Partition" is out. Only reason it was on the list is I thought I'd used it.
I'm inclined to say make it "HAPartition" since the change of the attribute type breaks existing clients anyway.
(I'm not that concerned about client breakage due to API change; AS 5 is going to be a big change in general, and the "ClusterPartition" attribute is only about 1 year old, and was added for internal purposes, not to support some user feature.)
How about this (comments/arguments appreciated):
1) Make it "HAPartition".
2) The one place where the old "ClusterPartition" attribute was likely to be used by end users was HAServiceMBean. People could use it in -service.xml to inject the ClusterPartition. So there we *add* the "HAPartition" attribute, deprecate "setClusterPartition" and remove getClusterPartition. A call to setClusterPartition just calls setHAPartition(clusterPartition.getHAPartition()).
As for getPartitionName(), I just blindly deprecated both the getter and setter. I don't mind un-deprecating the getter.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062575#4062575
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062575
18 years, 9 months