• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

how to write into a property file from web browser

 
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

i wanted to know how to wrote into a property file during run time ( while running applets from tomcat)

i used the following code in applets while running from eclipse.



but this code is not supported with tomcat

so i used the following code to read from property file



now reading is working fine. now i want to write into a property file.
how to do it.


thanks in advance
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
how to write intp a property file during run time( running an applet in tomcat)


than you in advance
 
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

but this code is not supported with tomcat


The code runs in an applet - Tomcat has nothing to do with it. Of course, if you use file I/O in an applet, then the applet must be signed, and the client's file system is accessed, not the server's file system. The way to access files on the server is through the classloading mechanism, as you have discovered.

how to write intp a property file during run time( running an applet in tomcat)


Again, Tomcat has nothing to do with it - the applet runs on the client. If the file should reside on the client file system, then you can use the java.io classes (and the applet needs to be signed in order to do this). If the file should reside on the server file system, then this is not possible directly; you'll need to post the data to a server-side component (like a servlet) that has access to the server's file system.
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi ulf,

i do not know what is server side ans client side.
what i'm trying to do is run the tomcat server on my system, and run the applet from the browser in my system.

i said that code to write in property file is not working in tomcat because i'm getting this



the code i used to write into the property file is




i'm getting the correct value in the first test print, but the value is not storing in the property file..

it is thowing error in the properties.store(new FileOutputStream("conf/propert.properties"), null); line..

please help.

thanks inadvance
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomcat is the server, while the browser and applet are the client. You need to realize that those generally are NOT running on the same machine, but on different machines. That means that they have different file systems. Plus, a file accessed as "conf/propert.properties" through the classloading mechanism can NOT be accessed under the same name using regular file I/O. In fact, since that file lives on the server file system, it can not be accessed from the applet AT ALL. (Unless you intend for the applet always and only to be run on the same machine as Tomcat - in which case it would be a bit silly to make it an applet in the first place.)
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi ulf,
thank you for the clarification.

the ultimate goal of my product is to run server on one machine and have many clients( applets running ) in different machines.

let us say we have only 1 client and 1 server.
i start the server here and client starts the applet/browser in his machine. he should be able to update the property file residing on my machine ( server ).

so for this to happen, i'm initially trying to do the same with only one machine ( acting as server and the client ) but it is failing to store the values in the file while the values that are to be stored are correctly generating ( see first test print which generated the correct value of usn in java console window in the IE, and the out put is missing[ intentionally left out ] from the output console errors i posted in my last post)

i need to store those values for their respective keys in the property file. but that is not happening.
i was told that i should be using getRealPath() to locate the file by my colleague.
but if it cannot locate the file, how is it generating right values ( i mean it is reading the file perfectly)

any help
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

so for this to happen, i'm initially trying to do the same with only one machine ( acting as server and the client ) but it is failing to store the values in the file while the values that are to be stored are correctly generating


As I said before, you can't use file I/O from the applet to write to a file that is on some other machine. The applet will need to send whatever is to be stored to a servlet via HTTP, and then the servlet can write to the file.

You'll need to think about what happens if several of the client applets try to do that at the same time - which update should be the one that becomes permanent? The first one to arrive? The last one to arrive?
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you ulf..

i got bit more clarity now..
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You'll need to think about what happens if several of the client applets try to do that at the same time - which update should be the one that becomes permanent? The first one to arrive? The last one to arrive?



this was really a good suggestion.

so it would be better to have seperate property file in each of the clients machine...i suppose


As I said before, you can't use file I/O from the applet to write to a file that is on some other machine. The applet will need to send whatever is to be stored to a servlet via HTTP, and then the servlet can write to the file.



but how to proceed with what you suggested..

any clues??..

i know it is none of your concern to code what i'm supposed to, but i'm no where to go..



 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

so it would be better to have seperate property file in each of the clients machine...


Only if the properties are different for each client. And, again, applets can't use file I/O unless they're signed. Just something to consider.

Of course, if the applet is signed, you might as well use the Preferences API for storing client-side settings, instead of mucking about with files (where lots more can go wrong than with Preferences).

but how to proceed with what you suggested..


For starters, you'll need to put in place applet/servlet communication. If you search these forums (or the web at large) you'll find much material about that. If you have questions about what you found, you can start a new topic here.
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you ulf.
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi ulf,

some more clarification

you said

a file accessed as "conf/propert.properties" through the classloading mechanism can NOT be accessed under the same name using regular file I/O. In fact, since that file lives on the server file system, it can not be accessed from the applet AT ALL. (Unless you intend for the applet always and only to be run on the same machine as Tomcat - in which case it would be a bit silly to make it an applet in the first place.)



you mean that an applet cannot write to a file to the server ( if server and client are different systems) using regular file i/o.
you also mean that it is possible if server and client are on the same machine.
and you also mean that it is some thing weird to run server and client on same machine.

but my question is why can't i write a file from applet if the server is also on the same machine?? ( if it is signed )

and by the way i was surfing to make the applet signed...
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html

is this really neccesary to write to a file.

the code i have is writing to file in eclipse and not in browser... any changes in code???


thanks in advance
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

you mean that an applet cannot write to a file to the server ( if server and client are different systems) using regular file i/o.


Yes.

you also mean that it is possible if server and client are on the same machine.


Yes.

and you also mean that it is some thing weird to run server and client on same machine.


It happens frequently in development, but once an applet gets deployed it'll be two different machines. So that's the underlying assumption that any applet developement should start out with.

but my question is why can't i write a file from applet if the server is also on the same machine?? ( if it is signed )


It is possible, and we both agree on that (see the second point).

is this really neccesary to write to a file.


Yes, that's necessary. Applets runs in a security sandbox that does not allow access to the file system, unless the applet is specifically allowed to jump out of that sandbox.

the code i have is writing to file in eclipse and not in browser... any changes in code?


IDEs frequently relax the security restrictions of applets, so the code you write may run inside the IDE, but then throw security exceptions in the browser if they're not signed. That's not really a code issue, though. The code should not have to change.
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi ulf thanks for your reply and time..


IDEs frequently relax the security restrictions of applets, so the code you write may run inside the IDE, but then throw security exceptions in the browser if they're not signed. That's not really a code issue, though. The code should not have to change.



does this mean, we can still write a file from applet is we catch the exceptions thrown without being signed.

i do not know if my coding is signed.. i think it is not because i did not follow that long procedure given in the sun.com website.

and by the way i have seen an example



there, they have granted some permissions so that they can write to a file.. but not property file though..

thanks in advance..
 
Ulf Dittmer
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

does this mean, we can still write a file from applet is we catch the exceptions thrown without being signed.


The IDE may allow you to do it; but the browser won't allow it.

http://www.roseindia.net/java/example/java/applet/WriteFile.shtml


Yes, changing the local security policy is another way (besides signing the applet) to give permissions to applets. (See HowCanAnAppletReadFilesOnTheLocalFileSystem for details.) But it's not a good choice for applets that are distributed to a wide range of users.
 
bharani rao
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you ulf
 
There were millions of the little blood suckers. But thanks to this tiny ad, I wasn't bitten once.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic