[Design of JBoss ESB] - Re: Publish ESB services to web services
by jim.ma
anonymous wrote : Generating the schema is also an option, perhaps by specifying the types rather than the xsd.
Agreed. So we can modify the configuration file as this :
<service category="ServiceESB" name="helloworld" description="Hello World">
| <actions mep="OneWay" input="org.jboss.esb.Request" output="org.jboss.esb.Response" fault1="org.jboss.esb.Fault">
| <action name="action1"
| class="org.jboss.soa.esb.actions.Action1"
| process="displayMessage"/>
| <action name="action2" class="org.jboss.soa.esb.actions.Action2" process="invokeCount"/>
| </actions>
| </service>
org.jboss.esb.Request , Response and Fault class can be a java bean and inherits from a mew class XMLMessageBase .
XMLMessageBase is a sub class of xml MessageImpl . In XMLMessageBase, we can put the request part value in Esb message body . Also by invoking the method in XMLMessageBase, we can retrieve the response part value from esb message body .
By reflecting the Request class, we can generate schema using apache XMLSchema even there is no annotation in it.
anonymous wrote : Again, there is no easy answer to this at the moment.
|
| What do you feel is the right approach for handling this?
So far ,what I have in mind is building the SOAPFault message using ActionProcessingException.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146447#4146447
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146447
16 years, 5 months
[Design of JBoss ESB] - Filters in ESB
by jeff_yuchang
Hi Team,
1. Deployment of the "jbossesb-properties.xml".
Looked at the "Meta-data and Filters" section in the programmers Guide, it doesnt talk about the deployment of the "jbossesb-properties.xml", also, the note makes me a bit confused.
anonymous wrote :
| Note: you will need to place any changes to your jbossesb-properties.xml file on each ESB instance that is deployed in your environment. This will ensure that all ESB instances can process the same meta-data.
|
What does the "all ESB instance" mean here? Say, I have deployed the Trailblazer .esb, and also I have jboss.esb, jbossesb.sar deployed in my application server. Does it mean the "Jobss esb instance", instead of the ".esb" deployment.
I think it should be the "JBoss ESB instance", as I didn't see the "jbossesb-properties.xml" in the ".esb" archive. Just think we might need to mention this a bit in the document, and also needs to describe it will affect the whole deployment, mean all the ".esb" archive the in ESB instance.
2. Register other additional filters in the ESB.
Right now, I know if I want to add my custom filter, I need to add the filter in the "jbossesb-properties.xml" in the "jbossesb.sar" archive, take the Trailblazer" as an example again.
Say, my filter is "com.example.trailblazer.MointerFilter", and then I need to add it to the file in the "jbossesb.sar", this kind of making me feel that now the "jbossesb.sar" is depend on the class in the traillblazer.esb archive.
I am looking for is there a way to define my filter in my own archive's jbossesb-properties.xml file, and then the ESB instance will pick it up automatically. I know, using this approach could make some side-effect, I mean it is a global-scope filter, it might make people hard to find all the on-going filters.
Whats the trade-off here?
In fact, I'd like the approach:
I'll add my filters on the jbossesb-properties.xml in my own .esb archive, and then the infrastructure will pick it up automatically? I dont know can we do it right now (JBossESB 4.2.1 GA)?
Thanks
Jeff
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146442#4146442
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146442
16 years, 5 months
[Design of JBoss IIOP on JBoss] - Re: CORBA_BAD_INV_ORDER running AS 5 IIOP tests with JDK 6
by Jeff Zhang
I add the throwable.printStaceTrace in the JacORB source code ORB.shutdown():
public void shutdown( boolean wait_for_completion )
{
if(logger.isInfoEnabled())
{
logger.info("prepare ORB for shutdown...");
Throwable ex = new Throwable("shutdown");
ex.printStackTrace();
}
Then I get the log information:
[junit] java.lang.Throwable: shutdown
[junit] at org.jacorb.orb.ORB.shutdown(ORB.java:1772)
[junit] at org.jacorb.orb.ORB.destroy(ORB.java:1870)
[junit] at com.sun.jndi.cosnaming.OrbReuseTracker.decRefCount(OrbReuseTracker.java:49)
[junit] at com.sun.jndi.cosnaming.CNCtx.close(CNCtx.java:1133)
[junit] at com.sun.jndi.cosnaming.CNCtx.finalize(CNCtx.java:1138)
[junit] at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
[junit] at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
[junit] at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
[junit] at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
There is an OrbReuseTracker to decrease the reference count from JVM Finalizer.
In JDK5, there isn't OrbReuseTracker class in JVM rt.jar.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146382#4146382
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146382
16 years, 5 months
[Design of JBoss IIOP on JBoss] - Re: CORBA_BAD_INV_ORDER running AS 5 IIOP tests with JDK 6
by Jeff Zhang
I had tested both JDK5 and JDK6 and mix them.
AS Server Tests
JDK5 JDK5 PASS
JDK6 JDK6 FAIL
JDK5 JDK6 FAIL
JDK6 JDK5 PASS
So JDK6/JacORB client failed the tests.
There are log information in test.log:
=================
2008-04-22 21:20:23,546 DEBUG [jacorb.orb.giop] ClientConnectionManager: cannot release ClientGIOPConnection to 127.0.0.1:3528 (115d06c) (still has 1 client(s))
2008-04-22 21:20:23,546 DEBUG [jacorb.orb.delegate] Delegate released!
2008-04-22 21:20:23,546 INFO [jacorb.orb] prepare ORB for shutdown...
2008-04-22 21:20:23,546 INFO [jacorb.orb] ORB going down...
2008-04-22 21:20:23,546 DEBUG [jacorb.orb.giop.conn] GIOPConnectionManager.shutdown(), 0 connections
2008-04-22 21:20:23,546 DEBUG [jacorb.giop.conn] ClientGIOPConnection to 127.0.0.1:3528 (115d06c): close()
==================
Please see the log "prepare ORB for shutdown..."
If we use JDK5, we can't find the same information in the log file.
Some code call the shutdown() somewhere.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146381#4146381
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146381
16 years, 5 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo
by ron.sigal＠jboss.com
"galder.zamarreno(a)jboss.com" wrote :
| Client.invoke() is the interface Unified invokers and others deal with and this method throws Throwable so your users have to be prepared for anything anyway...
|
Good point. That relieves my unfounded anxiety.
"galder.zamarreno(a)jboss.com" wrote :
| By the way, how would you turn InterruptedException into an InterruptedIOException? You can't set a cause Throwable to InterruptedIOException, so you can't really wrap IE around a InterruptedIOException,
|
I was just going to do
| catch (InterruptedException e)
| {
| throw new InterruptedException(e.getMessage);
| }
|
I'm looking at JBossMessaging as a test case. org.jboss.jms.client.delegate.DelegateSupport filters any Throwable thrown by org.jboss.remoting.Client.invoke() through the following code:
| public JMSException handleThrowable(Throwable t)
| {
| // ConnectionFailedException could happen during ConnectionFactory.createConnection.
| // IOException could happen during an interrupted exception.
| // CannotConnectionException could happen during a communication error between a connected
| // remoting client and the server (what means any new invocation).
|
| if (t instanceof JMSException)
| {
| return (JMSException)t;
| }
| else if (t instanceof CannotConnectException)
| {
| boolean failover = true;
| CannotConnectException cc = (CannotConnectException)t;
| Throwable underlying = cc.getCause();
| if (underlying != null && underlying instanceof SocketException)
| {
| //If remoting fails to find a connection because the client pool is full
| //then it throws a SocketException! - in this case we DO NOT want to failover
| //See http://jira.jboss.com/jira/browse/JBMESSAGING-1114
| if (underlying.getMessage() != null &&
| underlying.getMessage().startsWith("Can not obtain client socket connection from pool"))
| {
| log.warn("Timed out getting a connection from the pool. Try increasing clientMaxPoolSize and/or numberOfRetries " +
| "attributes in remoting-xxx-service.xml");
| failover = false;
| }
| }
| if (failover)
| {
| return new MessagingNetworkFailureException(cc);
| }
| }
| else if ((t instanceof IOException) || (t instanceof ConnectionFailedException))
| {
| return new MessagingNetworkFailureException((Exception)t);
| }
| //This can occur if failure happens when Client.connect() is called
| //Ideally remoting should have a consistent API
| else if (t instanceof RuntimeException)
| {
| RuntimeException re = (RuntimeException)t;
|
| Throwable initCause = re.getCause();
|
| if (initCause != null)
| {
| do
| {
| if ((initCause instanceof CannotConnectException) ||
| (initCause instanceof IOException) ||
| (initCause instanceof ConnectionFailedException))
| {
| return new MessagingNetworkFailureException((Exception)initCause);
| }
| initCause = initCause.getCause();
| }
| while (initCause != null);
| }
| }
|
| return new MessagingJMSException("Failed to invoke", t);
| }
|
I gather that a MessagingNetworkFailureException indicates the need to try to do a failover.
1. In its current state, this code would take an InterruptedException wrapped in a CannotConnectException and initiate a failover.
2. If Remoting replaced InterruptedExceptions by InterruptedIOExceptions, JBM would see an IOException and initiate a failover.
3. If Remoting wrapped InterruptedExceptions in RuntimeExceptions, JBM would return a MessagingJMSException and, presumably, not initiate a failover.
So, it turns out that strategy 3 is best for JBossMessaging. But it looks like good luck more than anything else. The treatment of CannotConnectException looks for one known anomaly (which, by the way, no longer exists) and does a failover by default. The treatment of RuntimeException looks for three particular cases and *doesn't* do a failover by default.
The fact is that none of us anticipated an InterruptedException in these circumstances. It seems to me that any existing code is equally likely to react well or badly in response to either wrapping InterruptedExceptions in RuntimeExceptions or replacing InterruptedExceptions by InterruptedExceptions.
The bottom line is that (1) something has to be done, and (2) there doesn't seem to be a solution that leaves the Remoting API unchanged and guarantees that no code suffers.
Is there any reason to prefer one solution over the other? One could argue that an interruptible EJB or JMS client *should* declare that it throws an InterruptedException, but that discussion might be more theological than technical. I'm leaning towards wrapping in RuntimeExceptions, which seems more straightforward and avoids the UndeclaredThrowableException problem.
There's one more concern. Suppose a Remoting user detected the InterruptedException possibility and their code looks for InterruptedExceptions wrapped in CannotConnectExceptions. Then replacing CannotConnectExceptions with RuntimeExceptions might break their code. I'm leaning towards
1. for Remoting 2.2.2.SP8
a) leaving the current behavior in place as the default behavior, and
b) making the new behavior a configurable alternative.
2. for Remoting 2.4.0, replacing the current behavior with the new behavior.
Now WDYT?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146373#4146373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146373
16 years, 5 months