4:07 p.m.
[
https://issues.jboss.org/browse/JBTM-1576?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1576:
--------------------------------
Description:
Currently the XATMI services must be deployed in the standalone "Server" CORBA
container
It is expected to be advantageous to support the deployment of the services into JBoss for
ease of management and performance.
It is expected that the user will deploy a .war file containing a btconfig.xml defining
the .so/.dll (also contained in the .war).
BlackTie java code will read the btconfig.xml and calculate the path of the .so based on
the place that AS7 unzips war files to during deployment PLUS the path defined in the
users btconfig.xml
If AS7 does not explode war files during deployment, it will not be possible for the user
to package their .so in their .war file (I don't think - please do investigate this)
and so a java.native.library.path will need defining at boot time and the user will need
to place all their jni code in there thereby not supporting hot deploy unfortunately but
still gaining the benefits of performance (not requiring socket comms between java and
C).
Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services
deployed into the AS to use the existing JCA connections
was:
Currently the XATMI services must be deployed in the standalone "Server" CORBA
container
It is expected to be advantageous to support the deployment of the services into JBoss for
ease of management and performance.
It is expected that the user will deploy a .war file containing a btconfig.xml defining
the .so/.dll (also contained in the .war).
BlackTie java code will read the btconfig.xml and calculate the path of the .so based on
the place that AS7 unzips war files to during deployment PLUS the path defined in the
users btconfig.xml
If AS7 does not explode war files during deployment, it will not be possible for the user
to package their .so in their .war file (I don't think - please do investigate this)
and so a java.native.library.path will need defining at boot time and the user will need
to place all their jni code in there thereby not supporting hot deploy unfortunately but
still gaining the benefits of performance (not requiring socket comms between java and
C).
Introduce a JBoss deployable artifact for the C++ XATMI services
----------------------------------------------------------------
Key: JBTM-1576
URL: https://issues.jboss.org/browse/JBTM-1576
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: BlackTie, Tooling
Reporter: Tom Jenkinson
Attachments: onmessage.tgz
Original Estimate: 1 week
Remaining Estimate: 1 week
Currently the XATMI services must be deployed in the standalone "Server" CORBA
container
It is expected to be advantageous to support the deployment of the services into JBoss
for ease of management and performance.
It is expected that the user will deploy a .war file containing a btconfig.xml defining
the .so/.dll (also contained in the .war).
BlackTie java code will read the btconfig.xml and calculate the path of the .so based on
the place that AS7 unzips war files to during deployment PLUS the path defined in the
users btconfig.xml
If AS7 does not explode war files during deployment, it will not be possible for the user
to package their .so in their .war file (I don't think - please do investigate this)
and so a java.native.library.path will need defining at boot time and the user will need
to place all their jni code in there thereby not supporting hot deploy unfortunately but
still gaining the benefits of performance (not requiring socket comms between java and
C).
Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services
deployed into the AS to use the existing JCA connections
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)