April 2017
« Sep    
Your widget title

Posts Tagged ‘TibcoRV’

PostHeaderIcon Cannot run this command because Java services are not enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java.


An object is marshallized and sent on TibcoRV 8.1. An instance of Mule ESB 2.2.1 listens to TibcoRV, reads the message, unmarshalls the object and builds an SQL insert query.

The query is very simple:

insert into myTable(dateColumn, stringColumn) values(...)

It is executed in a Jdbc connector declared on Mule configuration file:

    <jdbc:connector name="jdbcConnector" dataSource-ref="mySybaseDB" pollingFrequency="1000">
        <jdbc:query key="writeTest"
                    value="INSERT INTO myTable(dateColumn, stringColumn)

The DB is Sybase. The first column is of type datetime, the second one is varchar. The values are retrieved from a java.util.Date and a java.lang.String.


When the query is run, I get the error:

java.sql.SQLException: Cannot run this command because Java services are not enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java.

(you may get a com.sybase.jdbc2.jdbc.SybSQLException instead of java.sql.SQLException)

Explanation – Fix

The error is related only to Sybase, and not to TibcoRV and Mule: by default, Sybase cannot manage Java Dates (java.util.Date). You have to start explicitly the Java services. To perform that:

  • login with an username owing the rights “sa_role
  • run the SQL query:
    sp_configure 'enable java', 1
  • the restart the Sybase server

Now it should work. A similar error may occur with JBoss.

PostHeaderIcon TibrvException[error=4,message=Tibrv not initialized]


In a JUnit test, I send a message on a TibcoRV, but I get the following error:

TibrvException[error=4,message=Tibrv not initialized]


In order, proceed as this:

  1. check an RVD daemon is running 😉
  2. check tibrvj.jar is in your classpath 😉
  3. check the instanciation of transport layer new TibrvRvdTransport(service, network, daemon); is done within your public void testXXX(), and not in the setUp().

PostHeaderIcon org.springframework.beans.factory.xml.XmlBeanDefinitionReader: Ignored XML validation warning org.xml.sax.SAXParseException: SchemaLocation: schemaLocation value = … must have even number of URI’s


Mule 2.2.1 ESB config file with a TibcoRV connector, under Windows XP SP2 and Java 5.
The error happened in this context, yet I assume it would occur in any occurence related to XSD / XML schemas.


org.springframework.beans.factory.xml.XmlBeanDefinitionReader: Ignored XML validation warning
org.xml.sax.SAXParseException: SchemaLocation: schemaLocation value = '                                                      ' must have even number of URI's.

Headers of XML config file:

<mule xmlns=&amp;quot;;quot;

Explanation – Fix

Each time, the attribute xsi:schemaLocation must have an even number of lines: a “public” XSD address and a “non-public” one. For non English-fluent speakers, I remind that a number is even if, and only if, it is a multiple of 2 ; otherwise it is odd.

In our case, one line is redundant. To fix this issue, you have to remove the redundant line, and ensure each line belongs to a consistent pair of lines: for instance:

PostHeaderIcon TibrvException[error=901,message=Library not found: tibrvjsd]


TibrvException[error=901,message=Library not found: tibrvjsd]

and below:

java.lang.UnsatisfiedLinkError: no tibrvjsd in java.library.path

The error appears also with tibrv instead of tibrvjsd.


Mule ESB 2.2.1 using TibcoRV 8.1.2, under Windows XP, with Java 1.5

Explanation – Fix

  • Explanation:
    • the Mule tries to load a DLL, here tibrvjsd.dll. Its path should be available in the property java.library.path.
    • Unlike what may be found on the net, the right DLL cannot be found under
      %TIBRV_HOME%/lib, where only jars are available, not DLLs.
  • Backup the file %MULE_HOME%/conf/wrapper.conf
  • Edit it
  • After the lines
# Java Native Library Path (location of .DLL or .so files)

add the line:

PostHeaderIcon Use TibcoRV connector with Mule ESB



Priori to following the current tutorial, you must have installed

  • a Java JDK/JRE 1.5+, with a parameter JAVA_HOME already set
  • a TibcoRV 8.1, with a parameter TIBRV_HOME already set. You can consult a short tutorial here to perform this.


  • Get Zip version of “Mule ESB Full Distribution”, version 2.2.1, on this page.
  • Unzip the content in a folder, eg: C:\exe\mule-standalone-2.2.1
  • Add a environment variable MULE_HOME and update your path, eg:
    set MULE_HOME=C:\win32app\mule-standalone-2.2.1
    set PATH=%PATH%;%MULE_HOME%\bin
  • To check the Mule is well installed, you can launch the “Hello World” application:

Specific for TibcoRV

  • Get mule-transport-tibcorv-2.2.1.jar, available at this link.
  • Copy it into %MULE_HOME%/lib/mule
  • Get the jar %TIBRV_HOME%\lib\tibrv.jar
  • Copy and rename it into %MULE_HOME%/lib/opt/tibrvj-8.1.2.jar
  • Tip: to know the exact version of the Jar you have just copied, you can open it, explore and decompile the class com.tibco.tobrv.tibrvj_id. The exact version must appear.
  • Copy %MULE_HOME%/conf/wrapper.conf as %MULE_HOME%/conf/wrapper.conf.old
  • Edit %MULE_HOME%/conf/wrapper.conf:
    • replace


Here is for the very configuration.

“Hello world” for “TibcoRV via Mule”

Configuration file for Mule/TibcoRV “Hello World”

Code below is commented. Save it into a file named mule-config.xml.

<?xml version="1.0" encoding="UTF-8" ?>
<mule xmlns=""
 <!-- The TibcoRV we're listening is on the IP# -->
 <tibcorv:connector name="myTibcoConnector" network=""/>
 <model name="fromTibco2stout">
 <service name="fromTibco">
 <!-- We follow all subjects, on the TibcoRV connector defined above-->
 <tibcorv:inbound-endpoint connector-ref="myTibcoConnector" subject="*"/>
 <!-- Messages received are displayed on standard output -->
 <stdio:outbound-endpoint address="stdio://OUT"/>

Run TibcoRV

Launch the daemon

Launch the daemon on localhost on port 7580:

%TIBRV_HOME\bin\rvd -http 7580

Launch a listener

Possibly, you can run a listener in a separate frame, in order to double check whether messages are sent and received in the right way, independantly of what happens on Mule side.
Listen to all messages with subject mySubject on localhost:7580

%TIBRV_HOME\bin\tibrvlisten.exe" -network localhost mySubject

Launch the Mule

  • Now run the ESB:
    %MULE_HOME%\bin\mule.bat -config path\to\file\mule-config.xml
  • Send a message:
    %TIBRV_HOME\bin\tibrvsend.exe -network  mySubject HelloWorld
  • Expected outputs:
    • On sending frame:
      Publishing: subject=mySubject "HelloWorld"
    • On listening frame:
      tibrvlisten: Listening to subject mySubject
      2010-01-21 17:51:43 (2010-01-21 16:51:43.109000000Z): subject=mySubject, message={DATA="HelloWorld"}
    • On Mule ESB frame:
      INFO  2010-01-21 17:53:02,860 [Bus] org.mule.transport.tibrv.TibrvMessageReceiver: message received
      on: *
      INFO  2010-01-21 17:53:02,860 [fromTibco.4] org.mule.transport.tibrv.TibrvMessageAdapter: The newThreadCopy method in AbstractMessageAdapter is being used directly. This code may be susceptible to 'scribbling' issues with messages. Please consider implementing the ThreadSafeAccess interface in the message adapter.
      INFO  2010-01-21 17:53:02,860 [fromTibco.4] org.mule.component.simple.LogComponent:
      * Message received in service: fromTibco. Content is: '{                       *
      * DATA="HelloWorldOfTheWorld" }'                                               *
      INFO  2010-01-21 17:53:02,860 [connector.stdio.0.dispatcher.3] org.mule.transport.stdio.StdioMessageDispatcher: Connected: endpoint.outbound.stdio://OUT
      {DATA=HelloWorldOfTheWorld, __send__subject__=mySubject}