| Author |
Message
|
| tuftyjugs |
 Posted: Wed Jun 20, 2012 6:41 am Post subject: BIP4041E/BIP4500E deployment failure |
 |
|
Newbie
Joined: 20 Jun 2012
Posts: 2
|
 I have built a simple JavaCompute node which references a more complex Java Project. This project is an attempt to migrate a Web Logic application under WMB. The application is quite complex and my aim was to utilise the complex java classes which processes messages and generate changed ones with some DB updates. I have reduced the project down to the complex code excluding any MQ functionality which I assumed could be replaced by that passed to java compute note. The application did have log4j under the covers.
In my javacompute node I am simply invoking one class/method in the built java project. To build this project it requires the following jars
- commons-dbcp-1.2.1
- commons-collections-3.1
- commons-logging
- commons-pool-1.2
- j2ee
- log4j-1.2.8
- ocrs12
- ojdbc14
- xbean
+ a few application common generated ones relating to schemas
My message flow using this java compute nodes builds and the bar file contains all the jars listed above. However it fails with the following messages
BIP4041E: Execution group 'MF_DriverEnquiry_Grp' received an invalid configuration message. See the following messages for details of the error.
The broker was asked to deploy a message flow which contained properties that were not recognized by the broker. This typically results from a message flow requiring a version or type of node that is not supported by the broker installation.
Check that the message flow is only using properties or nodes that are supported on the broker. Check that all necessary user-defined extensions are installed and that they are of a version that is compatible with the message flow
BIP4500E: Failed to deploy Java code resource 'CJSETransformsJava.jar'. The Java stack trace is: 'Frame : 0 com.ibm.broker.plugin.MbConfigurationException: [BIPmsgs:4500]BIP4500E: Failed to deploy J... (data of len 3476 truncated)'
The Java JAR file deployment to the broker failed.
This is an internal error. Contact your IBM support center.
My Windows Toolkit and Broker are at v7.0.0.3
I have also done a mqsideploy, rather than toolkit to get a verbose (available to send if required) version of the trace to determine whether this could give me a clue to the problem... however no luck here....
Is it related to versions of the jars above or am I trying to deploy something which is defined as a User extensions (property/node) - although I don't know what these are... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jun 20, 2012 11:32 am Post subject: Re: BIP4041E/BIP4500E deployment failure |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| tuftyjugs wrote: |
| I have built a simple JavaCompute node which references a more complex Java Project. This project is an attempt to migrate a Web Logic application under WMB. The application is quite complex and my aim was to utilise the complex java classes which processes messages and generate changed ones with some DB updates. I have reduced the project down to the complex code excluding any MQ functionality which I assumed could be replaced by that passed to java compute note. The application did have log4j under the covers. |
Don't do that. WMB is not a J2EE container.
Java can do a lot of things. Should it do all those things? Certainly not if run from inside WMB. Know your limitations... It would probably be better for you to start from scratch and only incorporate snippets of code as needed... Remember though that the frameworks are not the same and this has its implications...
| tuftyjugs wrote: |
In my javacompute node I am simply invoking one class/method in the built java project. To build this project it requires the following jars
- commons-dbcp-1.2.1
- commons-collections-3.1
- commons-logging
- commons-pool-1.2
- j2ee
- log4j-1.2.8
- ocrs12
- ojdbc14
- xbean
+ a few application common generated ones relating to schemas |
Too many jars here...
Here are some jars that probably should not be on the list:
- commons-dbcp-1.2.1 (? may be... what are you using it for?)
- commons-pool-1.2 (seriously ... what do you need pooling for in the WMB context?)
- j2ee (WMB is not a J2EE container. Please don't attempt to make it be one, convince us you need this jar)
- ojdbc14 => transfer to configurable properties... JDBC setup broker V7
- xbean ? (depends what you are using it for)...
| tuftyjugs wrote: |
My message flow using this java compute nodes builds and the bar file contains all the jars listed above. However it fails with the following messages
BIP4041E: Execution group 'MF_DriverEnquiry_Grp' received an invalid configuration message. See the following messages for details of the error.
The broker was asked to deploy a message flow which contained properties that were not recognized by the broker. This typically results from a message flow requiring a version or type of node that is not supported by the broker installation.
Check that the message flow is only using properties or nodes that are supported on the broker. Check that all necessary user-defined extensions are installed and that they are of a version that is compatible with the message flow
BIP4500E: Failed to deploy Java code resource 'CJSETransformsJava.jar'. The Java stack trace is: 'Frame : 0 com.ibm.broker.plugin.MbConfigurationException: [BIPmsgs:4500]BIP4500E: Failed to deploy J... (data of len 3476 truncated)'
The Java JAR file deployment to the broker failed.
This is an internal error. Contact your IBM support center.
My Windows Toolkit and Broker are at v7.0.0.3
I have also done a mqsideploy, rather than toolkit to get a verbose (available to send if required) version of the trace to determine whether this could give me a clue to the problem... however no luck here....
Is it related to versions of the jars above or am I trying to deploy something which is defined as a User extensions (property/node) - although I don't know what these are... |
O.K I get the mqsideploy to get more info... However you already have quite a lot of things stacked against you.
In cases like this it is nearly always better to get back to the functional requirements and see how they can be accomplished by WMB than taking on code, especially if it was written (and optimized) for a completely different framework (J2EE).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Jun 20, 2012 11:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I think maybe your application is better housed in WPS rather than WMB. With your current approach (ie. "the application is quite complex and my aim was to utilise the complex java classes which processes messages and generate changed ones with some DB updates."), your better off in WPS.
Don't take this approach with WMB. You wont' be happy with the outcome in either project simplicity or performance.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 20, 2012 12:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 20, 2012 12:29 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The problem is that a decent migration to broker requires a lot of re-writing of code, for example to convert JDBC logic to use Broker JDBC connections rather than hand-built ones...
This can take a lot of time, and you may need to get "up and running" quicker than "in a lot of time".
In this case, I'd suggest actually troubleshooting the deployment issue.
i.e. I'd see if I can find out what's in the
| Quote: |
| (data of len 3476 truncated) |
for example by taking a user trace.
Remember that class initiators may be run at deploy time, and if they throw exceptions this can cause the deploy to fail. |
|
| Back to top |
|
|
| tuftyjugs |
| Posted: Mon Jun 25, 2012 5:05 am Post subject: Deployment Issue |
|
|
Newbie
Joined: 20 Jun 2012
Posts: 2
|
| Quote: |
In cases like this it is nearly always better to get back to the functional requirements and see how they can be accomplished by WMB than taking on code, especially if it was written (and optimized) for a completely different framework (J2EE).
|
Many thanks for your help. It seems that part of the deployment issue may have been down to a control of previous related topics that I tried to follow to resolve my issue. a) I found a mention of adding jars to ..../lib/ext and b) using the command mqsichangebroker xxxxx -f all
Having tried other changes to deploy I found that a) was totally incorrect and actually causing the underlying issue and b) actually resolved the deployment issue in the first place.
If I had just done b) 'align the version of toolkit and broker for the fix packs installed'.. I would not have got the deployment problems raised.
However based on the quote above I would agree and that I would be taking too much effort in trying to remove J2EE framework to work within the WMB framework. I have therefore gone back to the actual functional requirements and are now mapping these correctly into WMB. Hopefully the rewrite effort will be less.
Thanks again |
|
| Back to top |
|
|
|
|
