The Java code is
ObjectInputStream ois=new ObjectInputStream(new FileInputStream("src/Stringdata.txt"));
String s=(String)ois.readObject();
System.out.println(s.toString());
} catch (IOException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
here am getting java.io.StreamCorruptedException: invalid stream header: 4D6F7374 this error please help me
An ObjectInputStream deserializes primitive data and objects previously written using an ObjectOutputStream. src/Stringdata.txt is probably not a file of serialized objects previously written using an ObjectOutputStream. You probably want to use InputStreamReader instead
java.io.StreamCorruptedException: invalid stream header: 4D6F7374
4D6F7374 is "Most".
This is not a file of serialized objects. It is a text file. Read it with BufferedReader.readLine().
Your problem is:
Server send/receive data using DataOutputStream/DataInputStream and you are trying to read it in the client side using ObjectOutputStream/ObjectInputStream
Just make sure Server/Client sockets are reading/writing using the same input/output stream types.
Khalil.
Related
Let's say I have a method store(Flux<DataBuffer> bufferFlux) which receives some data as a flux of DataBuffers, calculates an identifier, creates an AsynchronousFileChannel and then uses DataBufferUtils the data to the channel.
I started like this. Please note, that the following code will not work. It should just illustrate how I create a FileChannel and how I would like to write the data, while releasing used buffers and closing the channel afterwards.
public Mono<Void> store(Flux<DataBuffer> bufferFlux) {
var channelMono = Mono.defer(() -> {
try {
log.info("opening file {}", filePath);
return Mono.just(AsynchronousFileChannel
.open(filePath, StandardOpenOption.CREATE_NEW, StandardOpenOption.WRITE));
} catch (IOException ex) {
log.error("error opening file", ex);
return Mono.error(ex);
}
});
// calculate identifier
// store buffers to AsynchronousFileChannel
return DataBufferUtils
.write(bufferFlux, fileChannel)
.doOnNext(DataBufferUtils.releaseConsumer())
.doFinally(f -> {
try {
fileChannel.close();
} catch (IOException ioException) {
log.error("error closing file channel", ioException);
}
})
.then();
}
The problem is, that I just started with reactive programming and have no clue how I could bring these two building blocks together, so that
the data is written to the channel
all buffers are gracefully released
the channel is closed after writing the data
the whole operation just signals complete or error (I guess this is what Mono<Void> is used for)
Can anyone help me choose the right operators or point me to a conceptual problem (perhaps there is a good reason why I cannot find a suitable operator)? :)
Thank you!
According to Microsoft's samples, here's how one would go about streaming a file throuhg WCF:
// Service class which implements the service contract
public class StreamingService : IStreamingSample
{
public System.IO.Stream GetStream(string data)
{
//this file path assumes the image is in
// the Service folder and the service is executing
// in service/bin
string filePath = Path.Combine(
System.Environment.CurrentDirectory,
".\\image.jpg");
//open the file, this could throw an exception
//(e.g. if the file is not found)
//having includeExceptionDetailInFaults="True" in config
// would cause this exception to be returned to the client
try
{
FileStream imageFile = File.OpenRead(filePath);
return imageFile;
}
catch (IOException ex)
{
Console.WriteLine(
String.Format("An exception was thrown while trying to open file {0}", filePath));
Console.WriteLine("Exception is: ");
Console.WriteLine(ex.ToString());
throw ex;
}
}
...
Now, how do I know who's responsible for releasing the FileStream when the transfer is done?
EDIT: If the code is put inside a "using" block the stream gets shut down before the client receives anything.
The service should clean up and not the client. WCF's default for OperationBehaviorAttribute.AutoDisposeParameters seems to be true, therefore it should do the disposing for you. Although there doesn't seem to be a fixed answer on this.
You could try using the OperationContext.OperationCompleted Event:
OperationContext clientContext = OperationContext.Current;
clientContext.OperationCompleted += new EventHandler(delegate(object sender, EventArgs args)
{
if (fileStream != null)
fileStream.Dispose();
});
Put that before your return.
Check this blog
Short answer: the calling code, via a using block.
Long answer: sample code should never be held up as an exemplar of good practice, it's only there to illustrate one very specific concept. Real code would never have a try block like that, it adds no value to the code. Errors should be logged at the topmost level, not down in the depths. Bearing that in mind, the sample becomes a single expression, File.OpenRead(filePath), that would be simply plugged into the using block that requires it.
UPDATE (after seeing more code):
Just return the stream from the function, WCF will decide when to dispose it.
The stream needs to be closed by party who is responsible to read it. For example, if service returns the stream to client, it's client application responsibility close the stream as Service doesn't know or have control when client finishes reading stream. Also, WCF will not take care of closing the stream again because of the fact that it doesn't know when receiving party has finished reading. :)
HTH,
Amit Bhatia
I must implement an AXIS 1.4 client which consume an AXIS2 1.4 method. AXIS 1.4 client is made by creating the stubs. The client send a request and get back a response from service with some attachment (MTOM). When I call the method (operation) by AXIS 1.4 port type object I got an error:
org.xml.sax.SAXException: SimpleDeserializer encountered a child element, which is NOT expected, in something it was trying to deserialize.
I think MTOM messed up with AXIS. So here is the question: how did I get the attachment the AXIS2 1.4 (MTOM) web service return me back? TIA.
Francesco
P.S: here is the code. There are stubs generated by WSDL. The problem is: i get the exception when I call the port's stub method. There are attachments in the message I get back.
String codistat = "CODISTAT";
OrdinanzeViabilitaLocator ovlocretreive = new OrdinanzeViabilitaLocator();
ovlocretreive.setOrdinanzeViabilitaHttpSoap11EndpointEndpointAddress(".. the service url + action..");
try {
OrdinanzeViabilitaPortType ovretreive = ovlocretreive.getOrdinanzeViabilitaHttpSoap11Endpoint();
((Stub) ovretreive)._setProperty(javax.xml.rpc.Call.USERNAME_PROPERTY, "username");
((Stub) ovretreive)._setProperty(javax.xml.rpc.Call.PASSWORD_PROPERTY, "password");
//problems began here
MessageReqOrdinanze mrq = new MessageReqOrdinanze();
mrq.setCodistat(codistat);
Calendar date_from = Calendar.getInstance();
date_from.setTimeInMillis(0);
Calendar date_to = Calendar.getInstance();
date_from.setTimeInMillis(0);
mrq.setDate_from(date_from);
mrq.setDate_to(date_to);
// the next line generate the exception
MessageOrdinanze mretreive = ovretreive.getOrdinanze(mrq);
} catch (AxisFault e) {
e.printStackTrace();
} catch (RemoteException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (ServiceException e) {
e.printStackTrace();
}
The message I get back has a
<xop:include href="cid... >...< ../xop/include"/>
tag inside, it's MTOM (it cause the exception I guess).
Hope this helps.
There are two things that need to be done to make MTOM work on the client side:
Ensure that in the stubs, the xs:base64Binary type is mapped to java.activation.DataHandler instead of byte[].
Set up a (runtime) type mapping for xs:base64Binary and java.activation.DataHandler that uses JAFDataHandlerSerializer and JAFDataHandlerDeserializer (which support MTOM).
The second part is fairly easy. Simply set up a client-config.wsddfile with the following type mapping:
<typeMapping languageSpecificType="java:javax.activation.DataHandler" qname="xs:base64Binary"
deserializer="org.apache.axis.encoding.ser.JAFDataHandlerDeserializerFactory"
serializer="org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory"
encodingStyle=""/>
The first part is more tricky because the tooling (wsdl2java) in Axis 1.4 doesn't support changing the Java type associated with a given XML type. There are several ways to work around that limitation:
Edit the generated stubs by hand and change byte[] to javax.activation.DataHandler. Depending on how you manage generated code in your project, that may or may not be an acceptable solution.
It is probably possible (although I didn't test that) to trick wsdl2java into using javax.activation.DataHandler by giving it a modified WSDL where the type {http://www.w3.org/2001/XMLSchema}base64Binary is replaced by {java}javax.activation.DataHandler.
I fixed the tooling in the current Axis trunk so that it supports this type of configuration. Note however that this is only implemented in the wsdl2java Maven plugin (but not in the Ant task or the command line tool). You could use the 1.4.1-SNAPSHOT version of that plugin; the generated code would still work with Axis 1.4. You can find some documentation here.
Above solution is great. However those who might be struggling to make above code snippet work, please use xmlns:xs="http://www.w3.org/2001/XMLSchema", then only given typeMapping snippet works.
<typeMapping qname="xs:base64Binary" languageSpecificType="java:javax.activation.DataHandler"
deserializer="org.apache.axis.encoding.ser.JAFDataHandlerDeserializerFactory"
serializer="org.apache.axis.encoding.ser.JAFDataHandlerSerializerFactory"
xmlns:xs="http://www.w3.org/2001/XMLSchema" encodingStyle="" />
How to get http response contents when status >=400 is returned. That's my code sample :
try {
ChatService client = ProxyFactory.create(ChatService.class, apiUrl);
client.putMessage(dto);
} catch (ClientResponseFailure ex) {
System.out.println(ex.getResponse().getEntity().toString());
}
This throws :
Exception in thread "main" org.jboss.resteasy.spi.ReaderException: java.io.IOException: Stream closed
at org.jboss.resteasy.core.messagebody.ReaderUtility.doRead(ReaderUtility.java:123)
at org.jboss.resteasy.client.core.BaseClientResponse.readFrom(BaseClientResponse.java:246)
at org.jboss.resteasy.client.core.BaseClientResponse.getEntity(BaseClientResponse.java:210)
at org.jboss.resteasy.client.core.BaseClientResponse.getEntity(BaseClientResponse.java:171)
at App.main(App.java:40)
Caused by: java.io.IOException: Stream closed
at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:134)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at org.jboss.resteasy.client.core.SelfExpandingBufferredInputStream.read(SelfExpandingBufferredInputStream.java:58)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.jboss.resteasy.client.core.SelfExpandingBufferredInputStream.read(SelfExpandingBufferredInputStream.java:68)
at org.jboss.resteasy.util.ReadFromStream.readFromStream(ReadFromStream.java:30)
at org.jboss.resteasy.plugins.providers.ByteArrayProvider.readFrom(ByteArrayProvider.java:32)
at org.jboss.resteasy.plugins.providers.ByteArrayProvider.readFrom(ByteArrayProvider.java:23)
at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105)
at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:46)
at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108)
at org.jboss.resteasy.core.messagebody.ReaderUtility.doRead(ReaderUtility.java:111)
... 4 more
I'd like to have more details than just status code 400.
Is that the exception you meant to send?
Unfortunately the RestEASY client framework doesn't support Exception marshalling per se, and instead adapts it into the HTTP framework. Exceptions should still be thrown on the server though. I've never done it, you can use ExceptionMappers for checked Exceptions.
http://docs.jboss.org/resteasy/docs/1.2.GA/userguide/html/ExceptionHandling.html
When debugging I noticed that the details I needed were in the 'streamFactory' object as a byte stream of XML. I found this help topic in the RestEasy docs about ClientResponse. It says
getEntity(java.lang.Class<T2> type)
where getEntity can marshal the output to the desired class. In my case, I have a custom class for errors returned from services called ServiceError. So, that was the class I passed to getEntity:
try {
serviceResult = proxy.addCustomer(customerName, customerProfile);
} catch (ClientResponseFailure ex) {
ClientResponse<String> cResp = ex.getResponse();
ServiceError myEntity = cResp.getEntity(ServiceError.class);
System.out.println("myEntity errorText=" + myEntity.getErrorMessage().getErrorText());
System.out.println("myEntity errorCode=" + myEntity.getErrorMessage().getErrorCode());
}
We're using WCF to build a simple web service which our product uses to upload large files over a WAN link. It's supposed to be a simple HTTP PUT, and it's working fine for the most part.
Here's a simplified version of the service contract:
[ServiceContract, XmlSerializerFormat]
public interface IReplicationWebService
{
[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "agents/{sourceName}/epoch/{guid}/{number}/{type}")]
ReplayResult PutEpochFile(string sourceName, string guid, string number, string type, Stream stream);
}
In the implementation of this contract, we read data from stream and write it out to a file. This works great, so we added some error handling for cases when there's not enough disk space to store the file. Here's roughly what it looks like:
public ReplayResult PutEpochFile(string sourceName, string guid, string number, string type, Stream inStream)
{
//Stuff snipped
try
{
//Read from the stream and write to the file
}
catch (IOException ioe)
{
//IOException may mean no disk space
try
{
inStream.Close();
}
// if instream caused the IOException, close may throw
catch
{
}
_logger.Debug(ioe.ToString());
throw new FaultException<IOException>(ioe, new FaultReason(ioe.Message), new FaultCode("IO"));
}
}
To test this, I'm sending a 100GB file to a server that doesn't have enough space for the file. As expected this throws an exception, but the call to inStream.Close() appeared to hang. I checked into it, and what's actually happening is that the call to Close() made its way through the WCF plumbing until it reached System.ServiceModel.Channels.DrainOnCloseStream.Close(), which according to Reflector allocates a Byte[] buffer and keeps reading from the stream until it's at EOF.
In other words, the Close call is reading the entire 100GB of test data from the stream before returning!
Now it may be that I don't need to call Close() on this stream. If that's the case I'd like an explanation as to why. But more importantly, I'd appreciate it if anyone could explain to me why Close() is behaving this way, why it's not considered a bug, and how to reconfigure WCF so that doesn't happen.
.Close() is intended to be a "safe" and "friendly" way of stopping your operation - and it will indeed complete the currently running requests before shutting down - by design.
If you want to throw down the sledgehammer, use .Abort() on your client proxy (or service host) instead. That just shuts down everything without checking and without being nice about waiting for operations to complete.