Tom Katz

Ok, I've got this working now - I think there may have been issues with getting the right GMO values set. Now that I do getPropertyNames("%") does seem to work for querying all properties in a message.

Is there any way to access *ALL* message properties of a message (or at least all their names) using the MQMessage class?

I've tried using getPropertyNames("%") hoping that that would return all the property names, but it doesn't seem to be working. Basically I need the java equivalent of MQINQMP in C.

There's the get*Property methods, but you need to know both the type and name of the property to call those.

I know I'm missing something here, please, be the first to point out my stupidity!

.. any help would be appreciated,
thanks,
Tom

Thanks - that's what I was afraid of.

Clarification: the conversion does not happen on post, that just happened to be when I noticed it. Actually, there's a difference in IE vs. Firefox for displaying '\n'. Firefox's textarea contains only '\n' (0a), while IE will expand it to '\r\n' (0d0a).

JSP contains textarea that can display data with various types of newlines (CR, LF, CR/LF). All various types of newline display fine, the problem is when the data is edited and the form posted.

The only situation where there's an issue is when message data contains '0A' (LF) by itself. On posting the form, these are converted to 'ODOA' (CR/LF). I only see this in Internet Explorer, it does not seem to happen in Firefox.

I've tried to no avail:
* grabbing the value/innerText/innerHTML values
* cloning the textarea element and grabbing that clone's innerText
* setting style=white-space:pre;
* changing the Page/Browser encoding values

Anyone know of way to preserve original newline bytes in IE as I described?

thanks in advance,
Tom

THanks! We don't use JSTL enough in the app, and fixing this problem should give me leeway to make the change.

I'm not sure of the forum this should be in, but thought I'd be safe to start in this one.

I have a JSP that displays string values in HTML input elements. In the code, we enclose the value in double quotes so that string values containing spaces are properly displayed. This was all fine n dandy until someone tried a string containing double quotes. The value displayed would then cut off at the first double quote, since it would see that as the closing quote.

The JSP code in question.

out.print(" <INPUT class=\"attrInput\" type=\"text\""); out.print(" name=\"" + attr.name() + "\" id=\"" + attr.name() + "\""); out.println(" value=\"" + value.valueAsString() + "\">");

So, I would like to find a way to properly display a string that could potentially contain spaces, double quotes and anything, really. I tried using URLEncoder on the values in the JSP code, and then using javascript to decode, but it basically just ends up at square one. I can't quite wrap my head around what I need to do here, and I've done plenty of googling. There seem to be some PHP methods that take care of this (not positive they do what I need) and I've tried the javascript versions of these, but no luck.

If anyone has any ideas/information on this, I'd appreciate it.

thanks,
Tom

Thanks Ulf, Yes, I'm learning a lot about control characters today.

It is more than a nuisance since the actual data length of the message is changed when this occurs. There is also a hex editor that when used, can deal correctly with the values. It's just an issue that the textarea, when posted, converts any line breaks into the CR/LF version. Currently it has no way to know what the original bytes were. I"m wondering if my pageEncoding value, if changed, could alter this behavior. Maybe base it off the MQMD.Encoding value of the original message.
[ August 15, 2008: Message edited by: Tom Katz ]

I have a textarea in a JSP which will display message data bytes as strings. This is an MQ message editor. What I'm finding is that if the bytes '0A' are present in the message data, they'll display the same as if the bytes are '0D 0A'.

Everything's fine until the user posts the form - then any end_of_lines (sorry if my wording's off) are translated to '0D 0A'. In the case where the original bytes were '0A' that means extra bytes are added to the message data.

Not sure if this is a java, encoding, or HTML issue (or none, or all

Any insight would be appreciated.

thanks,
Tom

(PS: Not to hijack this thread or anything, but I believe I'm having nearly the same issue, and rather than opening a new topic, thought I'd try in here since it's pretty recent - if bad form, please let me know.)

I was having the same issue (JDialog in applet) until I added this to the constructor of the dialog:

<blockquote>code:

---

<pre name="code" class="core">
addWindowListener(new WindowAdapter()
{
public void windowOpened(WindowEvent e)
{
inputField.requestFocus();
}
}
</pre>

---

</blockquote>

I think I need to restate the problem.

* I'm using signed SLF4J/LOG4J jars to write to a log on the client machine where the applet is running. I"m replacing tons of out.println calls with slf4j calls.

* So far I've only been able to set the log level by changing the level in the log4j.properties INSIDE the applet jar. Unfortunately, I'd like the user to be able to change the log level when required. So I was wondering if there's any way to have a log4j.properties file on the server that the applet reads from? I was hoping there'd be a way to specify this server-side log4j.properties file in the applet/object tag. It seems like using the codebase/code properties is still pointing to somewhere inside the jar, but if I've got that wrong, I'd be glad to know.

thanks,
Tom

PS: the applet jar is inside a .war which is served up by Jetty.

So I was a bit 'informationally stunted' on using the PARAM tag. I think I gave up that avenue of effort after I tried setting log4j.configuration via the JRE plugin. I set it there, and dumped the system values via the java console, saw the value correctly set there, and the applet classes using log4j weren't picking up the file it was pointing at.

The value gets set fine via the applet's PARAM. I can retrieve it in the applet code, and everything looks fine.

I"m not really using it explicitly. Which is probably my problem. I was thinking that if it was set as one of the parameters that it would be picked up by the jvm (like adding -Dlo4j.configuration), but it would seem not.

I also tried adding a specific props file to java_archive list. I get errors that indicate I should only be putting .jar files in that param (i.e. I got ZipException errors on that file.)

Well, glad to bemuse you - smug much?

I admit, I haven't done the best job of explaining my situation . . I'm a little lost (or wouldn't be asking)

Before converting the code to use log4j/slf4j, the applet code was writing to a log file on the client machine's desktop, by redirecting the stdout/stderr to the file. Basically, I"m hoping to set a log4j priority level for this stdout. I"m hoping to do this in a way that uses the same log level as the code that's running on the server.

Our server code sets log4j.configuration explicitly to use a log4jdebug.properties file.

So, my main issue is somehow passing that log level/priority/filename on the server TO the applet code that runs on the client. I"ve tried through applet params, and I've tried setting the log4j.configuration param in the java plugin params.

Will keep trying, thanks for the suggestions..
Tom

I may have misstated the problem a little.

I *do* have the log4j.properties file in the codebase, and it can be read by the classes there. On the server side, the log4j.configuration property can be changed to point to another file. I was hoping to be able to put multiple log4j.properties in the applet's jar file/codebase, and using applet params (or something) be able to point at a specific file.

After some researching and trying things, I dont think that's possible. If I'm wrong, please let me know. If there's other ideas for doing what I"m attempting, please let me know that also.

I think reading the server file via getResource would require extra coding, and I"m being pushed to do this without any extra coding if possible. I"m really starting to wonder if there's a way to take advantage of the flexibilty of log4j/slf4j in a web app that includes applet code.

Open for any/all suggestions!
thanks