[JAVA] FileWriting probleem met RMI opslaan op server

[Verwijderd]

Dag Tweakers,

Ik heb het volgende probleem, ik ben een Client/server applicatie aan het maken welke gebruik maakt van een MS-SQL-Sever (2000)

Nu heb ik bij een van de object de mogelijkheid dat ik er documenten aan moet koppelen die bij een gebruiker op de lokale schijf staan.

Daarvoor zou ik graag dit document(object) naar de server willen sturen waarna het daar opgeslagen wordt in een op voorhand bepaalde map.

Ik heb dit geprobeerd door aan de client het object in te lezen in een BufferedReader en die dan te sturen naar de server om daar met een BufferedWriter weg te schrijven.

Dit lukt niet omdat ik een seriazible exception krijgt. Nu heb ik het vermoeden dat dit ook nooit kan werken omdat ik een soort van stream.

Ik heb op internet gezocht naar een oplossing hiervoor.

Nu is mijn vraag hoe doen jullie dit? En is hier een standaard manier voor om dit te doen?

[Janoz]

Wat probeer je nu over te sturen? Als dat de BufferedReader is dan lijkt het me redelijk logisch dat deze niet werkt. De server kan immers niet bij de schijf van de client en de Reader heeft op de server dan ook geen enkel nut. Als je nu eens een byteArray maakt en daar het hele bestand in zet en deze overstuurd zal het een stuk beter gaan.

[Verwijderd]

Oke zoiets dacht ik dus ook al, Ik moet dus even gaan uitzoeken hoe ik eerst mijn bestand in kan lezen en weg kan schrijven in een array. Waarna ik die array overstuur (dus echt heb object) en dat dan vervolgens ga wegschrijven

[Verwijderd]

Dankje Geluk!!

Dankzij jou aanwijzing en dit voorbeeld

code:

package test;

import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;

public class Test {

    public static void main(String[] args) {

        File inputFile = new File("c:/java/input.txt");
        File outputFile = new File("c:/java/output.txt");

        try {
            FileReader reader = new FileReader(inputFile);
            FileWriter writer = new FileWriter(outputFile);

            // Downcast de hoeveelheid karakters van long naar int.
            int length = (int) inputFile.length();

            // Declareer en initialiseer een char array. De array
            // index accepteert alleen een int, vandaar de downcast.
            char[] content = new char[length];
            
            // Zet de inhoud van het invoerbestand in de char array.
            reader.read(content);

            // Zet char array in het uitvoerbestand.
            writer.write(content);

            reader.close();
            writer.close();

            System.out.println("Kopieren gelukt.");
        } catch (IOException e) {
            System.out.println("Kopieren mislukt.");
            e.printStackTrace();
        }
    }
}

[Robtimus]

Paar opmerkingen:
1) gebruik een byte[]. Een byte[] is toch 2x zo klein als een char[] van dezelfde lengte (byte = 1 byte, char = 2 bytes). Aangezien de chars niks extra toevoegen kun je zo je netwerkverkeer halveren.
Verder moet je nooit Reader en Writer gebruiken tenzij je zeker weet dat je text files behandeld. Deze zijn specifiek voor character streams - gebruik InputStream en OutputStream, deze werken voor elk type*. Op deze manier ga je ook met byte[] werken ipv char[].


2) wat ga je doen als je bestanden van groter dan Integer.MAX_VALUE = 2^31 - 1 = 2147483647 bytes (bijna 2GB) worden geselecteerd? Je moet niet zomaar denken dat het niet gebeurt, zorg daar zelf voor door het te verbieden.
Ter referentie, door een long naar een int te casten kap je de 32 bits met hoogste significantie af. Als daardoor een 1 de hoogste significante bit wordt, dan wordt je integer negatief en wordt er een java.lang.NegativeArraySizeException gethrowd.


* Alleen als je ook de text wilt uitlezen is een Reader beter dan een InputStream.

[Verwijderd]

IceManX schreef op donderdag 21 september 2006 @ 13:20:
Paar opmerkingen:
1) gebruik een byte[]. Een byte[] is toch 2x zo klein als een char[] van dezelfde lengte (byte = 1 byte, char = 2 bytes). Aangezien de chars niks extra toevoegen kun je zo je netwerkverkeer halveren.
Verder moet je nooit Reader en Writer gebruiken tenzij je zeker weet dat je text files behandeld. Deze zijn specifiek voor character streams - gebruik InputStream en OutputStream, deze werken voor elk type*. Op deze manier ga je ook met byte[] werken ipv char[].


2) wat ga je doen als je bestanden van groter dan Integer.MAX_VALUE = 2^31 - 1 = 2147483647 bytes (bijna 2GB) worden geselecteerd? Je moet niet zomaar denken dat het niet gebeurt, zorg daar zelf voor door het te verbieden.
Ter referentie, door een long naar een int te casten kap je de 32 bits met hoogste significantie af. Als daardoor een 1 de hoogste significante bit wordt, dan wordt je integer negatief en wordt er een java.lang.NegativeArraySizeException gethrowd.


* Alleen als je ook de text wilt uitlezen is een Reader beter dan een InputStream.

Oh oke ja das logisch tenslotte heb je aan 0 en 1 voldoende dus een Byte[].
Ga nu even omzetten na een Outputstream en dan dus een BufferedOutputstream want das toch sneller ook in dit geval ? dan wil ik het ook nog even in een thread zetten want anders staat mijn server dadelijk stil ;-)


Ja maar kan dus ook op de filedialoog die ik dadelijk gaan ga gebruiker een size opvragen en dan vervolgens een if statement erop zetten? Maar kan het dus ook inderdaad doen door te casten en dan een response melding te geven via de try en catch

Thanks

[ Voor 3% gewijzigd door Verwijderd op 21-09-2006 13:34 ]

[Robtimus]

Verwijderd schreef op donderdag 21 september 2006 @ 13:30:
Oh oke ja das logisch tenslotte heb je aan 0 en 1 voldoende dus een Byte[].

byte[] graag, Byte[] bevat Byte objecten

Ga nu even omzetten na een Outputstream en dan dus een BufferedOutputstream want das toch sneller ook in dit geval ? dan wil ik het ook nog even in een thread zetten want anders staat mijn server dadelijk stil ;-)

BufferedOutputStream schrijft idd meerdere bytes in 1x weg ipv byte per byte.

Ja maar kan dus ook op de filedialoog die ik dadelijk gaan ga gebruiker een size opvragen en dan vervolgens een if statement erop zetten? Maar kan het dus ook inderdaad doen door te casten en dan een response melding te geven via de try en catch

Ik zou de if-statement gebruiken. Sommige exceptions kun je vermijden, en dat zou je dan ook beter kunnen doen.
Dus:

Java:

if (file.exists()) { /* read from file */ } else { /* show error to user */ }

ipv

Java:

try { /* read from file */ } catch (FileNotFoundException e) { /* show error to user */ }

Zo ook:

Java:

if (file.length() <= Integer.MAX_VALUE) { /* continue */ } else { /* show error */ }

ipv

Java:

try { /* continue */ } catch (NegativeArraySizeException e) { /* show error */ }

Bovendien: wat als door het casten je toevallig een positieve integer krijgt? Dan gaat alles goed, alleen stuur je maar een deel van je file over.

Dus daarom: gewoon even checken of je file niet te groot is. Eventueel kun je nog een FileFilter gebruiken in je dialog dat controleert of de size niet te groot is:

Java:

public boolean accept(File file)
{
    return file.isDirectory() || file.length() <= Integer.MAX_VALUE;
}

(Niet vergeten de All files filefilter uit te zetten.)