Mike London

Bartender
+ Follow
since Jul 12, 2002
Cows and Likes
Cows
Total received
17
In last 30 days
0
Total given
0
Likes
Total received
49
Received in last 30 days
0
Total given
5
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike London

Problem solved: Bug in Anti-virus program.

-- mike
2 months ago

Zachary Griggs wrote:Sounds like the data isn't in the format you expect. You try to make it into a JSON Array, but it is a JSON Object instead.

As you said, sounds like it's some server inconsistency. If I had to guess, it's sending you a response that looks something like this:

{
   "message":"Request timed out",
   "code":"400"
}

While the usual data has an array in it:
{
   [
   ....
   ]
}

I'd recommend performing some basic validity checks on the data, like check hasJsonArray and if it doesn't have it, then try the request again x number of times. You can print the json string to the console for debugging purposes so you can see exactly what's going wrong.



The problem is that the same code on the same data works sometimes and not other times.  

It worked again this afternoon, but may not, again, tomorrow. Sometimes, stepping through code will make it succeed. And, every time after that. Really strange.

Therefore, it's really not a ClassCast problem. I'm wondering if it's some kind of REST data delay issue, but was just wondering if anyone else has run into this kind of issue.

Never seen anything like this.

Thanks for your reply.

-- mike
2 months ago
Hi,

I have some code that downloads COVID19 data and then processes the JSON.

Normally, the code runs fine.

However, sometimes, when the code runs, I get this error:

Exception in thread "main" java.lang.ClassCastException: class org.json.simple.JSONObject cannot be cast to class org.json.simple.JSONArray (org.json.simple.JSONObject and org.json.simple.JSONArray are in unnamed module of loader 'app')

This is the Corretto, Java 11, latest version.

If I then step through the code, it works fine again. I can then run the code as usual and it's fine.

I'm thinking this might be some latency issue getting the data from the web service, but not sure.

Any ideas?

Thanks,

-- mike
2 months ago

Ron McLeod wrote:The problem is that param is a string, not a JSON object.

I modified your code to construct an object from the string parameter, and then use that object in the subsequent code and it worked as expected:



Thanks very much. I mistakenly thought it was just the JS complexity since I had already used JSON.parse() in another example, but clearly forgot to use it here!

I noticed that in WebStorm IDE, also leading to the confusion, that the JS code worked fine w/o the JSON.parse().

Appreciate your excellent reply.

- mike
3 months ago
Hello all,

I have code that works fine in JavaScript IDE like Webstorm, but when I try to port it to Java, using the Nashorn library (to run JS within a Java program), I get these errors: "Name: undefined, Age: undefined" (with possibly others to follow depending what's wrong here.)

Below is the full code. This coding approach below seems to work in general that is it works with "simpler" JavaScript scripts, but there are cases like this where I don't get the expected results.

Would appreciate any help or suggestions.

Thanks!

3 months ago

Rob Spoor wrote:That's what multipart form-data is for. It uses a boundary between parts (usually a UUID or something similar, but it can technically be anything), and parts can be both files and simple values. Files can be base64 encoded if necessary.

For instance, with content type multipart/form-data; boundary=9fa69c0b-9d14-4e58-92be-599475860bef:
Here, each part starts with --<boundary>, then its headers (one of them needs to be Content-Disposition with value form-data and at least the part name as parameter), then an empty line (like in HTTP headers) and then the value. After the last part comes a line --<boundary>--<\r\n>. Of course you don't want to build that yourself; fortunately, just about any proper HTTP client has support for this.

On the server side, you can receive these parts "low-level" using HttpServletRequest's getPart and/or getParts methods. Frameworks like JAX-RS and Spring MVC have their own abstractions (probably built on top of Part).



Thanks!
5 months ago
I have a client where, currently, she is passing multiple file paths (on the same server) to a micro-service. That micro-service then emails those documents after reading the paths (JavaMail API).

My question is, to make the service more REST-like, how would I best send MULTIPLE binary documents themselves (using Base64 Encoding, etc.) rather than the file paths?

I already understand how I would Base64 the binary documents and can easily do that, but my primary concern is that since all the documents (one or more) would end up in the Request BODY, I need a way to parse them into separate files for emailing.

My idea would be use a UUID between each binary file document on the client side so that on the server side, I would know where one file stops and the next one begins.

Is there a better way to go about this?

Thanks,

-- mike
5 months ago

Tim Moores wrote:Can you post the debug output that should be generated? That often contains valuable hints.



Thanks....I got it working.

The problem was that the com.sun.mail dependency below was 1.5.5. Once i updated it to 1.6.2, mail worked!

Appreciate your reply.

Thanks,

-- mike

   <dependencies>
       <!-- https://mvnrepository.com/artifact/javax.mail/javax.mail-api -->
       <dependency>
           <groupId>javax.mail</groupId>
           <artifactId>javax.mail-api</artifactId>
           <version>1.6.2</version>
       </dependency>

       <dependency>
           <groupId>com.sun.mail</groupId>
           <artifactId>javax.mail</artifactId>
           <version>1.6.2</version>
       </dependency>
       
6 months ago
Hi all,

I have some good JavaMail code that works fine on my Linux server, but when trying to adapt the code to Office 365, I get this error:




Here are my settings:

ENCRYPTED_PORT: 587
SERVER_ADDRESS: smtp.office365.com


Here is the relevant code:




Can anyone see what's wrong here?

Thanks in advance,

- mik
6 months ago

Campbell Ritchie wrote:That readUnsignedByte() method appears to have been introduced at the same time as RandomAccessFile itself (JDK1.0). There were more unsigned methods introduced in some of the java.lang package classes in Java8.



Good info. I get it. Just haven't worked with numerical byte stuff in a long while and mostly forgot about the sign bit.

Thanks to all for the great help and explanations!

-- mike
7 months ago

Mike Simmons wrote:The RandomAccessFile has always been reading the byte array correctly.  The problem is when you interpret this array, you're not getting what you want.

Note that a byte in java is always in the range -128 <= b <= 127.  So 136 becomes 136 - 256 which is -120.  That's the only way to represent this as a Java byte.

Stephan's "offset & 0xFF" is an easy way to reverse this.  You can also use

Byte.toUnsignedInt(b)

which, for b=-120, evaluates to 136.



Thanks Mike!

I created another int header array so I could write the unsigned value back to it and use it later for the offset.

Thanks for your explanation above, also.

-- mike
7 months ago

Stephan van Hulst wrote:You are getting confused by the string representation of the byte.

The point is, it really really shouldn't matter as long as you're not performing a widening conversion. The underlying value is the bit sequence, regardless of whether you interpret it as signed or unsigned numeral. If your ultimate goal is to just display the header, you've already found a solution. If you want to perform other operations, don't worry about the signedness and just treat the byte as what it is: a sequence of bits.



Hello Stephan,

In this case, this byte is the numerical offset into the "DBF" where the first record is.

88 Hex is 136 decimal so I either need to be able to read 88 or 136.

-120 is meaningless as an offset into a file.

What's in the header is 88. I can't get that. The read() gives -120.

Yep, I'm confused by your reply.

Thanks,

-- mike
7 months ago

Mike London wrote:

Carey Brown wrote:Bytes are signed. A byte with the hex value of 88 has the high bit set, meaning it is a negative number. When presented as a decimal integer is -120.




Workaround using RandomAccessFile to get desired result?

Reading with FileInputStream worked OK



Thanks,

-- mike
7 months ago

Carey Brown wrote:Bytes are signed. A byte with the hex value of 88 has the high bit set, meaning it is a negative number. When presented as a decimal integer is -120.



Workaround to get desired result?

Thanks,

-- mike
7 months ago

Mike Simmons wrote:Try using randomAccessFile.readUnsignedByte() for comparison.



I was trying to read in the header using a byte[] buffer and expecting the same bytes as shown in iHex.

The code using the approach you suggested yields the same result (-120):
       

Gotta be a better solution I'm hoping.

Thanks,

-- mike
7 months ago