I have ejb message driven bean on was 8 java 6. every think work well.
The message driver bean listened on mq queue .
the queue on MainFrame
I migrated from WAS 8 to WAS 9 (java 8) .
Some messages include characters that cannot converted and cause exception :
JMSCMQ1049: The character set '424(IBM424) Unmappable Action: REPORT
I found an article that talks about the problem
https://www.ibm.com/docs/en/ibm-mq/8.0?topic=java-character-string-conversions-in-mq-classes
Character string conversions in IBM MQ classes for Java
The IBM® MQ classes for Java use CharsetEncoders and CharsetDecoders
directly for character string conversion. The default behavior for
character string conversion can be configured with two system
properties. The handling of messages that contain unmappable
characters can be configured through com.ibm.mq.MQMD.
Before IBM MQ 8.0, string conversions in IBM MQ classes for Java was done by calling the java.nio.charset.Charset.decode(ByteBuffer)
and Charset.encode(CharBuffer) methods.
Using either of these methods results in a default replacement ( REPLACE) of malformed or untranslatable data. This behavior can
obscure errors in applications, and lead to unexpected characters, for
example ?, in translated data.
From IBM MQ 8.0, to detect such issues earlier and more effectively, the IBM MQ classes for Java use CharsetEncoders and
CharsetDecoders directly and configure the handling of malformed and
untranslatable data explicitly. The default behavior is to REPORT such
issues by throwing a suitable MQException.
What I do not know, is how to implement the solution that the article
offers within the JMS settings of the queue in webSphere admin console or in java implementation
Anyone know how to solve the problem?
The link provided has the information below:
com.ibm.mq.cfg.jmqi.UnmappableCharacterAction Specifies the action to
be taken for untranslatable data on encoding and decoding. The value
can be REPORT, REPLACE, or IGNORE.
com.ibm.mq.cfg.jmqi.UnmappableCharacterReplacement Sets or gets the
replacement bytes to apply when a character cannot be mapped in an
encoding operation The default Java replacement string is used in
decoding operations.
If you wanted to mimic the prior behavior you would set the following system properties as generic JVM arguments the following link discusses how to set the arguments: Setting generic JVM arguments in WebSphere Application Server
-Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterAction=REPLACE
-Dcom.ibm.mq.cfg.jmqi.UnmappableCharacterReplacement=63
For a more detailed answer that is not specific to WAS see this:
Special Character Issue : MQ message PUT error : java.nio.charset.UnmappableCharacterException
Related
We are right now on WAS 8.5 and are trying to move to Liberty. Our applications are using a lot of SOAP calls and among them, there is a one that is using a relative namespace that is raising an exception. I know that using a relative namespace is not recommended but we are the client not the producer. There is a way to handle that in WAS 8.5 by adding the parameter "com.ibm.wsspi.wssecurity.dsig.relativeNamespaceAllowed=true".
Is there such a parameter in Liberty ? Otherwise, we are stuck.
Liberty changed it's JAX-WS implementation from what was used with WAS 8.5, and it doesn't support the same behavior that this property allows. That being said it might be possible implement it, if it's a requirement for your application I suggest opening a support ticket with IBM. There have been other JAX-WS behavioral differences that have been brought into Liberty for users that have requested it through support, and this might be such a case.
I'm new to WAS server. I'm doing POC with Java 1.8, Spring(4.3.9.RELEASE), Hibernate(4.2.0), DB2 and WAS 8.5.5(installed java 1.8). Server started successfully but getting below exception while executing createQuery() statement.
java.io.UnsupportedEncodingException: Cp037
at sun.io.Converters.getConverterClass(Converters.java:319)
at sun.io.Converters.newConverter(Converters.java:373)
at sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:98)
at com.ibm.db2.jcc.b.p.a(p.java:435)
... 132 more
2020-01-09 17:20:13 WARN SqlExceptionHelper:143 - SQL Error: -99999, SQLState: 22021
2020-01-09 17:20:13 ERROR SqlExceptionHelper:144 - [ibm][db2][jcc][10275][10041] Unsupported ccsid, encoding, or locale: "Cp037".
It is working fine when i deploy the same into Tomcat. Please help me on this to resolve,
let me know if any info needed. Thank you.
It seems an known behavior of JDK 8. Here is one of references:
UTF-8 encoding/decoding problem in JDK 8
https://www.ibm.com/support/pages/utf-8-encodingdecoding-problem-jdk-8
Cause:
Starting from JDK 8 ,the input data to NIO UTF-8 decoder(Java API) should be of pure UTF-8. Till JDK 8 this rule was not strictly implemented and decoder was able to decode ill-formed UTF-8 byte sequence also. Decoder in JDK 1.8 will throw an exception if it encounters non UTF-8 data and the program cannot proceed with the execution.
Solution: (Does not work for Oracle JDK 8)
A new global property db2.jcc.alternateUTF8Encoding is introduced in JCC. This property can have value 1 and 0 ,the default value is 0 . If this property is set to 1 under IBM JDK 1.8 (db2.jcc.alternateUTF8Encoding=1) for UTF8 encoded data ,JCC uses UTF8J to decode .
This will help to avoid MalformedInputException during decoding. This is a global property and need to be configured in the property file. This property cannot be set using DataSource or Connection and works only with IBM JDK.
It is recommended review the article.
Hope this helps.
I hit this problem, I resolved issue with below actions.
open websphere app server (WAS) admin console.
go to JDBC, JDBC providers, DB2 Using IBM JCC Driver, Class Path;
ensure you have this entry: ${DB2_JCC_DRIVER_PATH}/db2jcc4.jar
go to Environment, Websphere variables, DB2_JCC_DRIVER_PATH should point to folder/path of latest db2jcc4.jar, mine is dated 6/13/2019
I have an EJB which has as input argument and return value a JAXB mapped complex structure (with subclasses etc).
Now I want to deploy this on the Oracle Service Bus 11g. I can create a business proxy invoking the EJB, but only with basic types (int, ...).
How do i tunnel the XML between EJB and OSB? Any advanced OSB information is appreciated, as I don't know much about it.
After playing around, it turns out the OSB supports (afaik only) Apache XMLBeans. Thus if you declare parameters and return values of type org.apache.xmlbeans.XmlObject it works. I did get some errors concerning DOM v3 not being implemented and some crashes in the oracle DOM implementation, so I just use the XmlObject to create an XML string, and the reparse it.
#Euclides: I have XMLObject and XmlObject in my classpath. I need the second (lower case). Thanks for the hint, anyway.
I’m using Jboss 5, and invoking hundreds of EJBs with complex parameters.
There are some performance issues that I think are related to Java Serialization
As Jboss using JbossRemoting for remote invocations, I would like to use JbossSerialization to optimize serialization performance.
Like explained here, I'm using
-DSERIALIZATION="org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager"
at server side and in invocation code.
But JavaSerializationManager is still used by Jboss.
Can someone explain or exemplify how to configure JBOSS for using JBossSerializationManager.
In other words, what is the easiest way to make already deployed EJB application using Jboss Serialization instead of java Serialization?
This is confusing because JBoss remoting is a component that is used by JBoss Server. If you were using JBoss Remoting standalone that works (sort of). JBoss Server has its own set of config files.
For EJB3 calls you will need to update the InvokerLocator connection string in the location defined here. It looks something like below...
socket://myhost:6500/?datatype=test&loaderport=6501&marshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestMarshaller&unmarshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestUnMarshaller
The parameter you want to add is here under 5.11.1
SERIALIZATIONTYPE (actual value is 'serializationtype') - indicates the serialization implementation to use. Currently, the only possible values are 'java' and 'jboss'. Java serialization is the default. Setting to 'jboss' will cause JBoss Serialization to be used. In implementation, this equates to the parameter that will be passed to the SerializationStreamFactory.getManagerInstance() method. This configuration can be set as an invoker locator url parameter (e.g. socket://myhost:5400/?serializationtype=jboss) or as an entry to the configuration Map passed when constructing a remoting client or server.
So you would append
&serializationtype=jboss
Note that there is no way to use JBoss Serialization for JMS that I could find.
I'm currently developing a small EJB 3 application for WebSphere AS 7 with WebSphere-MQSeries. It's a very simple app that mainly consists of one MDB listening on a queue, convert the incoming messages and write the extracted data into a db. I've finally got up it and running, but I'm a bit confused regarding ActivationConfig annotations in the code, the ibm-ejb-jar-bnd.xml and the activation spec in WAS itself. My main question is, why do I need ALL of them? Why should/could I specify things like the queue name or destinaton type via annotation (#ActivationConfigProperty) when I still need a activation spec in WAS where I also specify the destination e.g. Queue-Name? I addition I also need a binding via an xml file? Is that right? Is it also possible to specify the activationspec-name via annotation and thus get rid of the xml binding file? Can I avoid creating the activation spec in WAS?
Hope someone can clarify things, thanks.
You cannot avoid the Activation Spec entity because it is responsible to open connection to your JMS provider, query messages according to various options like the message selector filter.
According to WebSphere 7 InfoCenter EJB-3 annotations can replace activation specification properties from binding file but the properties required by WebSphere are not standard.
So as far as I know, you have to provide:
either the binding file, written manually or edited with the deployer tool
either at deployment setting properties in the administrative console or in automated jython/wsadmin script
Be aware that the Activation Spec is a runtime component that can be stopped, typically after some rollbacks on messages. In that case, it no longer consumes message and your MDB has nothing to process until you re-activate it from the WebSphere console.