Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About guidojansen

  • Rank
  • Birthday 01/01/1
  1. Ok, to be consequent (in answering myself) and to help potential others that have such a problem - I have solved the problem with the help of other guys in my conmpany. Good news - it's not JET-specific! The problem was as I described that the InputStream got read before I told it to... The guys that helped me have told me of situations where they had similar problems and always was "a different system" involved. In the one case it was a different server that was redirected to, in the other a dll and in my case it's the exe that is "different enough". Different enough seems to lead to a FULL READ of the request and all its parameters, inputStreams and so on as soon as ANY of the requests attributes is really accessed. In the other guys case this was a request.getAttribute() that was performed before they accessed the inputStream, in my case it was the request.getSession() call before reading from the inputStream. So in order to NOT READ my InputStream before I wanted to, I just had to do it FIRST in the servlet's method (service() in my case) - then it worked just fine. Hope this helps anybody and sorry for spamming your forum
  2. Ok, it may look funny to always answer myself, but I want to get this solved so I again post the latest stuff I found out and again ask if anybody can help me, because it strongly smells like a JET-problem (as it doesn't happen without JET). I said that the InputStream was not correctly "recognized" or "filled". Now, after looking into the source code of the Tomcat classes involved (InputBuffer and ByteChunk), I have further investigated and seen that the bb attribute IS the correct one to store the information, but that it IS BEING READ before I try the first read on the recipient's side. (the start and end attributes point to the same number and that is the length of bytes I put into the sender's OutPutStream - by looking into the source code I found out that this should only happen AFTER THE BUFFER HAS BEEN READ)... So any idea who reads this request's InputStream before I programtically try to on server side? The exe itsself when sending it? Tomcat when it creates the Request? But then why does everything work alright (i.e. the start points to 0 before the first read on server side) with the same code, only NOT-JET-compiled? Thanks for reading just one more and of course your help... Guido
  3. Ok, to clearify this issue as soon as possible, I will write what I have found out in the meantime. This is NOT a serialization issue, the stuff gets serialized well enough (though I might face some problem similar to some other guy with loosing the serialVersionUID, but that will bother me later on...). The problem is that the InputStream which the exe write doesn't get recognized though it is being transmitted. My suspicion was correct, the bb "ByteChunk" attribute of the CoyoteInputStream contains exactly the stuff I want. (tested by using a simple InputStream and writing a list of numbers into it, exactly the same list appears in the bb attribute) Unfortunately, the "inputChunk" attribute (also type ByteChunk) is empty, I guess that's where it tries to read from, because when it does, the result of the read is -1. So anybody experience with what could cause this? Again, I don't have this problem when sending a request from the applet (JRE compiled), only when doing it from the Jet-compiled exe. Thanks for any answers, Guido
  4. Hello all, I will try to describe what we are using JET for and after that describe the problem. We are using an applet.jar which is started by a web application. This applet gets multiple infos from the servlet side during its startup routine, then offers some functionality and afterwards writes back some data to the server side where it gets saved in the context of the web application. The part we want to native-compile is the applet part, which means you still talk to the web application on startup and on exit of the applet/exe. The problem I am facing is that serialization doesn't seem to be a problem from servlet to exe, but from exe to servlet, it fails. Whatever there is in the ObjectInputStream of the request (the request that the servlet gets from the exe), the PeekInputStream.readFully fails, giving back an EOFException. Of course, this does not happen with the original applet as a JRE-comipled jar. I have already changed the JET environment to use 1.4.2, just as the original build script for our web application does, but it didn't help. It even fails on simple Strings with the same exception, though I see slightly different bytes in the ByteChunk of the InputStream (CoyoteRequestFacade) (-84, -19...). So the real assumption I have is not that it doesn't serialize anything at all, I conclude from those numbers in the ByteChunk that there is "something" the InputStream that there is something but then I don't understand why I get this exception... Any help will be appreciated. Thanks in advance, Guido