aspose file tools*
The moose likes JSF and the fly likes application scope problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "application scope problem" Watch "application scope problem" New topic
Author

application scope problem

Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
Hi guys!

Whether this is a basic question or not I have to post it because I haven't found something that helps me till now.

I have a application-scoped bean that runs and manages an application for the web-application. Since I need to refer it with other beans and don't know how to do this I'm asking you for some ideas.

You know womething like:
for request scope
for session scope
for application scope

Thanks in advance
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
You should use ExternalContext#getRequestMap(), getSessionMap() and getApplicationMap() respectively.

Please read the Javadocs before asking this kind of trivial questions: http://java.sun.com/javaee/5/docs/api/javax/faces/context/ExternalContext.html
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Everybody wants to do this the hard way. Just inject the application scope bean into the classes that need them.

http://www.coderanch.com/t/433650/JSF/java/access-another-bean-information

I do this all the time for things like menu lists that I fetch from the database at app startupm get used frequently, but rarely if ever change during the life of the webapp. An application scope bean is an ideal container for that kind of data.


Customer surveys are for companies who didn't pay proper attention to begin with.
Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
@ Bauke Scholtz: Thanks for the code sniplet and sorry for the trivial question. Looks like I missed it in the Javadoc.

@ Tim Holloway: Thanks for the hint. Yeah, I have seen an application some while ago where it was done like in your example, but I have never used it till now. Because of the easiness and because I am interested in I'll give it a try (but sounds great). Also a special thanks for your help.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Inversion of Control (IoC) can be a pain. You have to interact both with the code and with the wiring mechanism (faces-config.xml), and it's always a nuisance when you have to open up and edit multiple files to get something done. Or, if you use auto-wiring, making sense of why the magic didn't happen as expected. I hate magic.

It also requires twisting your design ideas upside down, as its name suggests. If you're a take-charge, go-out-and-get-it kind of person, the idea of having your code sit passively by and be injected is a little disturbing.

But there's a very good reason why IoC is so popular these days. Precisely because components no longer need to know where other components are located or how they are constructed, it's possible to make them more reusable, less dependent on specific frameworks, and more flexible,

As an example, I'm working on a webapp that's crammed full of code that sends emails. Too many emails, I think, but that's something to be looked at later. Because I didn't want it to be spamming me silly while developing, I made the actual email interface a Java interface.

There are 2 beans that implement this interface. One is a dummy mailer. All it does is log that an email is being "sent". The other one actually connects to JavaMail, and is the live mailer.

For testing, I wired in the dummy mailer. When it goes live, I'll change faces-config to use the production mailer. No code editing required. No code editing means fewer chances to muck things up. About the worst I can do is misspell the bean name, and if I do that, the app will instantly blow. No subtlety to that kind of bug!

In the mean time, I don't get an inbox full of junk, and the testing goes just a little bit faster, since it doesn't spend time networking with the mailserver.
Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
Uhh, it doesn't work. Just because the application-scope bean I have integrated into another bean as a bean-property isn't available (not instantiated at application start) I get following error message.


Is there a comfortable way to initialize the application-scoped bean at startup. I have looked threw some web-sites Google has provided me after some search ;), and there are only minor solutions that are not described in an appropriate way.
Thanks in advance for your hel.p

edit: Just saw the new post of you Tim. Yeah, not only Inversion of Control has such a dilemma, also when you get into grid middleware and application development, it's not that good ;).
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

You did something wrong. If you wire a bean into another bean, the framework will automatically ensure that the dependent bean(s) were constructed before injecting them.

What that message actually means is that it didn't find a "public void setXxx(datatype varname)" method defined in the "yyy" bean.

"datatype" being the class (data type) of your app-scope bean, varname being whatever you want. In other words, a standard POJO setter method.
Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
Would have done, but I'll check it if I had missed a letter.

I think it has something other. Just have a quick look at my code.

edit: it works now --> server restart didN#t work -> shutdown + start was necessary ;)
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Oh yeah. Although like I mentioned the app-scope bean is constructed as needed by the framework, there is a way to create it at startup, and times when it's a good idea to do do. About the cleanest way I know of is to create a Null Servlet (one without service methods like doGet/doPost). In its init() method, construct and initialize the application scope javabean in the usual (non-JSF) way. There's nothing magic about the JavaBeans that JSF creates.

To make it work on startup, set the auto-start option in web.xml so that the servlet in question will be initialized on app startup instead of waiting for a request. Which, since a Null Servlet doesn't service requests, would never happen!
Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
Man you are so fast, amazing; sorry it was my fault; server is crap :/.

Thanks for your assistance.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

Oops. I missed your sample. I don't see anything wrong. It's possible that you have a stale copy of the target class cached somewhere. This can be all too easy in some containers, including certain versions of Tomcat.

Try this:

1. Stop the server.

2. Remove the current app deployment (for Tomcat, that means that if there's an exploded WAR in the webapps directory, delete it. Delete the WAR file as well, if there is one.

3. Clear out any work directories (Tomcat's work/Catalina/localhost/xxxxx and temp directories - for Tomcat6. YMMV).

4. Do a clean build of the webapp and deploy it. Start the server.

You shouldn't have to flush your browser cache, but if it make you feel better...
Tom Kepler
Greenhorn

Joined: Mar 03, 2009
Posts: 6
Yeah, good idea. I have done it. Sometimes Tomcat is a little fractious ;).
Thanks for the ideay and help. You have helped me on very good. Thanks.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: application scope problem