[JBoss ESB Development] - Re: JBESB-2805 - Splitter EAI Pattern
by tfennelly
Hey Ricardo.
This looks great and I'm sure it would be a great addition to the ESB!!
A few small comments...
1. I think the implementation of the Splitter class could be optimized greatly.... create and cache the ServiceInvoker and Smooks instances up front, from the ConfigTree, as part of the constructor. I think this should make a huge difference to your performance.
2. Load all the Smooks configs into one Smooks instance. Then, you can do all the splitting in a single pass of the message, versus iterating over the destination list. Again... this should make a big difference to performance!!
3. I think a great extension to this action might be a "shorthand" config version where you don't need to specify a Smooks config at all. Instead, the route-to config just specifies an XML fragment path that the user wants split out of the message. Of course, this would only split and route XML fragments, but that's probably fine for many use cases.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252681#4252681
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252681
15 years, 3 months
[JBoss OSGi Development] - All OSGi enterprise examples pass
by thomas.diesler＠jboss.com
Folks,
I'm happy to announce that all jboss-osgi examples pass with the new MC based OSGi framework
| [tdiesler@tdvaio example]$ mvn -Dframework=jbossmc test
|
| Running org.jboss.test.osgi.example.blueprint.BlueprintTestCase
| Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.909 sec
| Running org.jboss.test.osgi.example.xml.jaxb.JAXBTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.372 sec
| Running org.jboss.test.osgi.example.microcontainer.MicrocontainerTestCase
| Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.848 sec
| Running org.jboss.test.osgi.example.xml.parser.SAXParserTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.376 sec
| Running org.jboss.test.osgi.example.simple.SimpleFrameworkLaunchTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.312 sec
| Running org.jboss.test.osgi.example.http.HttpServiceTestCase
| Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.133 sec
| Running org.jboss.test.osgi.example.xml.parser.DOMParserTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.376 sec
| Running org.jboss.test.osgi.example.jndi.JNDITestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.833 sec
| Running org.jboss.test.osgi.example.jmx.JMXTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.861 sec
| Running org.jboss.test.osgi.example.simple.SimpleTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.414 sec
| Running org.jboss.test.osgi.example.simple.SimpleHuskyTestCase
| Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.645 sec
|
I would now wrap up and hopefully have a release ready for JBW.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252636#4252636
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252636
15 years, 3 months
[JBoss ESB Development] - Re: Http Gateway - requirements please...
by Kevin.Conner＠jboss.com
"tfennelly" wrote : The HttpGateway always returns a response, no matter what, right? HTTP is a synchronous protocol, at least as implemented by the serlvet spec, which is what we're using. So as far as I see, it's not so much whether the gatway responds sync or not (because it always responds sycn). It's whether it puts a payload into the response, and where it gets that payload from if it does. So when I say sync/async, I just mean payload/no-payload on the servlet response from the http gateway.
Yes, when referring to sync/async I had assumed you meant the invocation on the ESB service so I believe we are talking about the same thing.
"tfennelly" wrote : No, I'm not expecting this. As far as the client of the http gateway is concerned, it's a HTTP invocation so I'm expecting them to expect a sync response.
Sorry, was talking about the sync/async context so the gateway is the client of the ESB service as far as my posting was concerned.
"tfennelly" wrote : Right... and just for clarity... in this case, the caller to the Service is the HttpGateway and not the "Client" invoking the gateway.
It is any invoker of an ESB service but, in this case, I am talking about the gateway.
"tfennelly" wrote : And since the caller of the service is the gateway, how would we implement this? How do we decide whether or not the gateway makes a sync or async invocation (using ServiceInvoker) on the OnWay Service?
This is the reason why you cannot use the mep as the source of that decision and why you need the parameter on the gateway. It is not possible to use the mep in this way.
"tfennelly" wrote : So the gateway makes a sync invocation on the OneWay Service?
Yes. Did you look through the continuation example I posted earlier in this thread? It contains an example of this.
"tfennelly" wrote : I can obviously see how this could work, but I personally think this is going to lead to a lot of confusion and is going to be quite brittle and hard to support.
Brittle and hard to support in what way? This is nothing more than basic routing, passing a request over to another service to fulfil.
"tfennelly" wrote : For example, wouldn't the person implementing serviceA (oneway service, being sync invoked by gateway) need to know that they can't use InVM from the gateway to serviceA, if serviceA and serviceB (the downstream service that's going to respond to the sync invoke from the gateway) are not in the same VM?
Yes, and this is a major problem with the way in which the current transport layer is implemented and does not just affect InVM.
"tfennelly" wrote : But doesn't this then hardcode a decisoin for all clients calling through this gateway?
It is not the HTTP client which is making this decision, rather it is the gateway acting as a proxy for the ESB service. It is deciding whether it should be exposing any response to the HTTP client.
"tfennelly" wrote : As I see it, in this case the service being called by the gateway is able to produce a payload for the gateway response. Some HTTP clients (to the gateway) may want this payload in the HTTP response and other clients may not. Seems to me like the clients that are not interested need can just ignore the response payload, no? I don't get the logic of hardcoding this into the gateway.
Sorry, but why is this behaviour any different from any other servlet/HTTP provider? If I have a servlet returning a response and the HTTP client chooses to ignore it then that is a decision for that HTTP client.
"tfennelly" wrote : I suppose what we could do for this is support a "noResponsePayload" http query parameter on the gateway (or a HTTP header ala the "Accepts" header). That way, individual clients can indicate whether or not they want a payload in the response (whether they "accept" a response payload).
I don't think the HTTP gateway should be providing this behaviour as it is really a decision for the ESB service, i.e. the business logic, to make. The ESB service understands the request better than the gateway and is free to make this type of decision based on all the criteria that it is aware of.
"tfennelly" wrote : Anyway... after all that... I'll just go and implement a "sync" flag on the gateway as you request :) I just wanted my thoughts on the record because I know Burr etc will be pointing the finger at me down the line :)
ROFL, I'm sure that will happen anyway.
"tfennelly" wrote : Thanks again Kev!!
No problems, keep the questions coming ;)
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252613#4252613
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252613
15 years, 3 months