-
15. Re: Migration from Tuxedo
Joice Joy wrote:
The QS says :
4. DEPLOY THE BLACKTIE ADMIN SERVICE
Undeploy any older versions of the blacktie admin service
Copy the file $BLACKTIE_HOME/blacktie-admin-services/blacktie-admin-services-<VERSION>.ear into $JBOSS_HOME/server/all-with-hornetq/deploy
Copy the file $BLACKTIE_HOME/blacktie-admin-services/stompconnectservice-<VERSION.ear into $JBOSS_HOME/server/all-with-hornetq/deploy
5. RUN THE APPLICATION SERVER
Make sure that the naming, messaging and transaction services are running, by running the JBoss server:
<JBOSS_HOME>/bin/run.sh|bat -c all-with-hornetq
What should be done instead of the above steps
These instructions look very out of date, sorry about that - we will get it fixed. But for now the equivalents to these instructions will be to deploy the ears to $JBOSS_HOME/standalone/deployments and then run wildfly with the appropriate standalone xml file ie:
$JBOSS_HOME/bin/standalone.sh -c standalone-blacktie.xml
-
16. Re: Migration from Tuxedo
I will fix this issue as soon as possible [JBTM-2498] Incomplete BlackTie quickstart documentation - JBoss Issue Tracker
-
17. Re: Migration from Tuxedo
Is there any type info present in NBF buffers attributes to determine the attribute's data type. Do we have any examples on this.
-
18. Re: Migration from Tuxedo
Any updates on above. As we have field tables in FML, do we have any similar facility in blacktie buffers.
-
19. Re: Migration from Tuxedo
Please help with this. Need a way to identify the type of the attribute.
The current nbf quickstart assumes the data types based on the name of the attribute.
I have seen a jira on the NBF API:
But I don't think it is complete. For eg. I don't see the function "getMaxLength" to get the length of variable length buffers.
Do you have more documentation on the buffers in Blacktie and their APIs.
-
20. Re: Migration from Tuxedo
The current NBF API is here: https://github.com/jbosstm/narayana/blob/master/blacktie/nbf/src/main/include/btnbf.h
The NBF itself is defined in XSD so you can use any tool you like to parse that, e.g: quickstart/employee.xsd at master · jbosstm/quickstart · GitHub
If this doesn't answer your question, please can you provide some pseudo code to show what you would like and we can have a think?
-
21. Re: Migration from Tuxedo
Ok thanks. Missed that one. I was expecting some Api to get the type. I can use this.
-
-
23. Re: Migration from Tuxedo
The XML based buffers are not self-describing as FML buffers are and there is no API which can be used to list the elements in a buffer instance.
So if we have for instance a buffer whose attribute names are not known in advance, how do you suggest we may extract the attributes from the buffer.
Or is it that we need to write our own APIs to parse the XML buffers as per the schema xsd.
-
24. Re: Migration from Tuxedo
Any updates on above. Also is there any function in blacktie which parallels tpsvrinit for initialzation.
-
25. Re: Migration from Tuxedo
Sorry for the delay, there is something weird about the notifications here I think.
Joice Joy wrote:
Or is it that we need to write our own APIs to parse the XML buffers as per the schema xsd.
Yes that is the intention. If there is something we have missed why this is not possible in all circumstances please do let us know (via pseudo code) what isn't possible and we can raise a feature request to add it in.
-
26. Re: Migration from Tuxedo
Thanks for the reply.
I mean to say that if we use our own XML format, will it affect any Blacktie features like content based routing.
Also I see that the buffer is nothing but a char * , can we use a binary buffer instead of XML buffers.
Also in Tuxedo we have a function tpsvrinit which is used to initialize the servers. It is basically a callback function that Tuxedo provides. Do we have
something similar in Blacktie.
-
27. Re: Migration from Tuxedo
I will need to wait for Amos to return from PTO to talk more about CBR - I suggest creating a topic specifically about that one as what we have with JBoss ESB is out of date from what I understand so that aspect is still in development.
In terms of initialization, the following headers are exposed:
Server: https://github.com/jbosstm/narayana/blob/master/blacktie/xatmi/src/main/include/btserver.h
Client: https://github.com/jbosstm/narayana/blob/master/blacktie/xatmi/src/main/include/btclient.h
Hope that helps
-
28. Re: Migration from Tuxedo
I am trying to send our own XML format data in the tpcall send buffer.
It gives the error A NON-BUFFER WAS ATTEMPTED TO BE SENT
I am doing a malloc for the buffer and casting into char *. Not doing a tpalloc for BT_NBF as per the example.
But even tpcall is failing with tperrno. The XML does not follow any schema. Its just a plain XML that we know how to parse.
Please confirm if this is indeed possible.
-
29. Re: Migration from Tuxedo
You need to tpalloc an X_OCTET or redefine the payload to be an NBF one (i.e. not XML directly).