• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Handling dynamic configuration data

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

my first post

I have a web application with a servlet and a jsp page
The servlet is done in a way that inside the init() method reads a property file with its configuration data and puts this data into class scope variables (so I dont need to read them in every doGet, doPost)
The jsp page has some input fileds that let me change the configuration property file
My problem is that I cant find a way to signal the servlet to re-read those properties once the user changes them from the jsp page
Is there a way to call a servlet public method from jsp ?
Should I use something like that:

and inside the doGet of TEST check for the "reload" property ?
Is there a more elegant way ?
 
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I really don't forsee problems nor see any need to reread the properties file?

You just have an instance of java.util.Properties which you create in init()? You just change the properties by setProperty() and save it by store()? There's no need to reload it as the changes are already reflected in the instance of java.util.Properties.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks

is there something I cannot understand or is there some sort of synchronization mechanism in this java.util.Properties class ?

The jsp page reads and write from/to the property file
The servlet reads from the property file and configure itself to use those data during requests
Now if the servlet is just started with a configuration and then I alter those property file thru the jsp page (new configuration), class scope variables of the servlet are out of sync with the new properties, so I should stop the servlet and then restart it from the application server but its not elegant
So in a way I need to make the servlet understand that properties changed and that it needs in some way to resync its vars
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How are you accessing the properties? Are you accessing the same java.util.Properties instance or a different one? If a different one, then you should indeed reload THAT different one.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Its a different one for sure its the one that is declared in the TEST servlet and that lives from the call to init()
Your last reply make me think that there could be a way to share a single instance of a Property class between the jsp and servlet class...mmm
Btw how can I solve my problem ?
Everytime I read something about increasing servlet performances everyone says to move static data into class scope and push values into it from the init() method to do it one time only in the servlet life cycle, I agree I dont want to play with the same vars in each call to the get method BUT this way I have no possibility to update those data if someone (jsp in this case) changes it.

I'd like to do THIS but from jsp to servlet
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Lucius Fulcius wrote:Its a different one for sure its the one that is declared in the TEST servlet and that lives from the call to init()
Your last reply make me think that there could be a way to share a single instance of a Property class between the jsp and servlet class...mmm

Wrap it by an application scoped bean?


I'd like to do THIS but from jsp to servlet

Ignore that whole site. It's from 1999 and it has still a lot of "old" and currently bad practices around.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Wrap it by an application scoped bean?


I dont know how to do it I'v never worked with beans, is it difficult to implement ?
Keep in mind that its a big public customer with various teams so if I need to deploy "extra" stuff I need to ask and receive green light and I cannot deploy directly
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Lucius Fulcius wrote:I dont know how to do it I'v never worked with beans, is it difficult to implement ?

No, it's just a class with private properties and public accessors.

Have you ever followed a decent JSP/Servlet tutorial or book? I would start doing it so. For example the Sun Java EE tutorial and the Head First Servlets & JSP.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I need to do it for work and I have little time I'v fear I could lose myself in the overwhelming world of ejb but I'll give it a try
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Lucius Fulcius", please check your private messages for an important administrative matter.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nobody said any about EJB which has nothing to do with the beans being referred to here.

Without a good understanding of beans, you are going to have a hard time in the world of JSp and servlets.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nobody said any about EJB which has nothing to do with beans


I said I'v never worked with beans and it seems to me EJB stand for enterprise java beans so what beans are you talking about ?

Without a good understanding of beans, you are going to have a hard time in the world of JSp and servlets


I'm working on a simple servlet with a simple jsp page and from my point of view I dont see these beans so important, perhaps your referring to projects with more complexities and advanced requisites
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just plain vanilla Javabeans. Or DTO's or VO's or POJO's or whatever you call it and how you want to generalize it.

But I did in no way mention about Enterprise Javabeans or EJB's. That's a completely different chapter.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Lucius Fulcius wrote:

Nobody said any about EJB which has nothing to do with beans


I said I'v never worked with beans and it seems to me EJB stand for enterprise java beans so what beans are you talking about ?


Unfortunate naming. Ignore EJB completely for now (and probably later on as well).

And, did you read my PM? Do so before posting again.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bauke Scholtz wrote:Just plain vanilla Javabeans. Or DTO's or VO's or POJO's or whatever you call it and how you want to generalize it.

But I did in no way mention about Enterprise Javabeans or EJB's. That's a completely different chapter.


Yes I understand it now but from a newbie point of view (me) when you say beans or javabeans it can be also enterprise javabeans for short
But I'm not improvising!
I'v read Java Servlet Programming 2nd Ed. but there is neither a single reference to Javabeans nor EJB
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Javabeans = java class ?
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's a quite old book. It's from 2001 (and originated in 1998)! Get a book which covers at least Servlet 2.4 and JSP 2.0. I highly recommend you Head First Servlets & JSP.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are in a replies war!

I highly recommend you Head First Servlets & JSP.


I'll try to get it, thanks

 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JavaBeans are normal Java classes that follow certain rules that make them easy to deal with because they follow those rules. They have nothing to do with EJB which is a subject you do not need to concern yourself with at all.

As Bauke recommended, get yourself an up-to-date reference or will have nothing but trouble trying to deal with JSP and servlets in a modern environment.
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll do it thanks
 
Alessandro De Sanctis
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As per your suggestion I'v bought the "Head First - Servlets and JSP" book and found it extraordinary usefull in general but with no direct explanation on how to handle application scoped data.
I saw one can use the ServletContextAttributeListener to implement a class that acts as a listener to ServletContext attribute manipulation BUT it seems to me of no use in my situation.
I explain....the best thing for me is that my servlet reacts directly to attribute changes not another class (the listener) so first idea one can have is to let implement the servlet the ServletContextAttributeListener interface just to find out that this is not the best way, as doing so, another instance of the servlet class is created to handle listener implementation
It seems to me from other similar topics no one has provided a direct and clear solution to this problem.
A simple idea could be to handle all datas into a POJO/class (as before) in the ServletContext attribute so everything the jsp changes into that instance will be read from the servlet BUT without calling any listener into play, is it something safe to do ?
 
reply
    Bookmark Topic Watch Topic
  • New Topic