File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes How make custom object avail to JSPs/Servlets? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "How make custom object avail to JSPs/Servlets?" Watch "How make custom object avail to JSPs/Servlets?" New topic
Author

How make custom object avail to JSPs/Servlets?

Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I have a "main" servlet that does some processing of some configuration files and creates a bunch of objects (some relevant for request and some for a session) and then needs to make these available to all other servlets and JSPs. What's the best way to do this? I'd prefer not to put it into the Session for a number of reasons (bogging it down, requiring knowledge not only of the objects but also of the key names for them, allows accidental/on-purpose removal of those objects from the session by the other servlets). Is there a better way?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42367
    
  64
If you don't want to put those objects in a session, then I'm guessing that you also don't want to store them in the application context.

How about a global configuration class/object that has static getter methods for those custom objects?


Ping & DNS - my free Android networking tools app
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Originally posted by Ulf Dittmer:
If you don't want to put those objects in a session, then I'm guessing that you also don't want to store them in the application context.

How about a global configuration class/object that has static getter methods for those custom objects?


But wouldn't a class with static objects/methods mean the objects are application-wide no matter what?
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I know for JSP's people sometimes use JSP beans (via useBean), but:
1. That's only JSP's, not Servlets
2. that wouldn't allow my servlet to create the object, correct? (or is there a way to do this?)

I also know there are certain objects avail. to a jsp page (like the "exception" object) - is there a way to do this with custom objects? for servlets?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42367
    
  64
But wouldn't a class with static objects/methods mean the objects are application-wide no matter what?


Yes. Isn't that what you were asking?

What is the rationale for preventing certain servlets/objects from acessing the configuration - are they untrusted?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61450
    
  67

The generally accepted practice for what you are talking about is to place the objects in application scope.

If you want to avoid having to know the key names for the object, you can create a facade object that regulates access to the data using "getters".
[ August 28, 2006: Message edited by: Bear Bibeault ]

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Originally posted by Bear Bibeault:
The generally accepted practice for what you are talking about is to place the objects in application scope.

If you want to avoid having to know the key names for the object, you can create a facade object that regulates access to the data using "getters".

[ August 28, 2006: Message edited by: Bear Bibeault ]


Thanks. Just a quick request, can you show me the proper code to do this (placing an object in application scope)?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42367
    
  64
In your servlet, you would do a



In your JSP page you can use



Access through EL (expression language) is also possible. Of course, this gets you back into a situation where every servlet can remove or alter these attributes.
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Of course, this gets you back into a situation where every servlet can remove or alter these attributes.[/QB]


Thanks. Question: can't they still remove/replace the attribute (via setAttribute)? I'm not so concerned from a security standpoint as from an accidental removal, or simply causing problems within the application.

The best I could come up with is configuring a ServletContextAtrributeListener, but is the only way to add that via the web.xml file? I'd prefer doing it in code so I can pass the correct object to it and it can then make sure that's always the object in that attribute. Is this possible?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61450
    
  67

Originally posted by Dan Bizman:

Thanks. Question: can't they still remove/replace the attribute (via setAttribute)? I'm not so concerned from a security standpoint as from an accidental removal, or simply causing problems within the application.


If you use a facade object, the code won't have knowledge of the keys.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18709
    
    8

Originally posted by Dan Bizman:
Thanks. Question: can't they still remove/replace the attribute (via setAttribute)? I'm not so concerned from a security standpoint as from an accidental removal, or simply causing problems within the application.
Well, sure. If these attributes are meant to be immutable, then as Bear suggested, make an immutable facade object that contains them and put that object into the application context. But if they are meant to be mutable or removable, then the easiest way to deal with code that incorrectly changes or removes them is to find that code and fix it so that it doesn't do that.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61450
    
  67

Paul's got a good point. Just how anal do you need to be to protect code from itself? Is it that you have a large staff full of junior engineers that can't be trusted not to boof things up?

If not, any such worrying about accidentally removing the scoped variables once they are set up (by a conext listener, rather than a servlet, right?) is rather over-the-top, in my opinion.
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Originally posted by Bear Bibeault:


If you use a facade object, the code won't have knowledge of the keys.


I apologize, but I'm not sure I understand how this would work. What code would the JSPs and servlets use to access the attribute? Wouldn't they have to call:



Is there another way for them to get that object (which, yes, I'm going to have as a facade object to all the "relevant" objects created by my servlet) which is stored in the attribute?
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Originally posted by Bear Bibeault:
Paul's got a good point. Just how anal do you need to be to protect code from itself? Is it that you have a large staff full of junior engineers that can't be trusted not to boof things up?

If not, any such worrying about accidentally removing the scoped variables once they are set up (by a conext listener, rather than a servlet, right?) is rather over-the-top, in my opinion.


Yeah, I guess you're right. It's just that I've seen way too many dumb mistakes over the years that I'm probably doing overkill to protect them from themselves. I just wanted to "guarantee" that the object would properly be available to everyone's code, and allowing someone to accidentally (or even purposefully) alter the attribute means it's not guaranteed.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61450
    
  67

These are the types of things that testing should uncover. If someone removes the scoped variable, somewhere there's bound to be an NPE or other exception. This really isn't the type of thing you should have to worry about in run-time code.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61450
    
  67

That said, an example from a static facade object could be:



This hides the key from the callers. But of course, nothing can prevent anyone from removing it if they really set their minds to it.

There are other patterns that could be used as well.

I've used this sort of thing now and again -- not to prevent any accidents, but just to make access to the scoped variable easy from servlet code.

In JSPs I use the EL, so such constructs are necessary.
[ August 28, 2006: Message edited by: Bear Bibeault ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How make custom object avail to JSPs/Servlets?