Hi there, I'm trying to get the ServletContext AttributeListener (this is 1 word, but Javaranch doesn't like words more than 30 letters long, hence the space) to work. I've been using a servlet which implementing this. However none of the 3 methods... attributeAdded,attributeRemoved,attributeReplaced seem to be invoked when I use the code:
and then change the value using:
I'm using netbeans 3.5, I don't know if I have to change anything in the deployment desciptor or not.
Please can some one show me a simple servlet which implements this Listener ,showing how one of these methods(eg attributeReplaced) works, perhaps by incrementing an integer that is a class variable.
I didn't put it in a package, I just put it in the classes directory of WEB-INF. Does it definatley need to be in a package? I'm always told packages are a good idea, but didn't think it was a mandatory requirement in this situation. [ December 13, 2005: Message edited by: colin shuker ]
Yes, it needs to be in a package. And, you were informed correctly...using packages is a very good idea, and in some cases absolutely neccessary.
Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
Joined: Apr 11, 2005
Conise answers and straight to the point, I like it. I'll try it out. Thanks
Joined: Apr 11, 2005
Hi, I tried using packages, but It still didn't work. Maybe I'm using setAttribute in the wrong way, I'm basically calling it several times in the doGet method. Heres my code if you want to see. The class is called ch.chserv
The problem is that you've ganged up the servlet and the listener into one class. Not only is this an odd thing to do, it's not going to work the way you intend.
The container will create one instance of the class as a listener, and then yet another instance as the servlet. So when your servlet performs a setAttribute(), the listener instance is notified. Therefore the num instance in the servlet instance is never changed.
So to fix your problem, separate the disparate functions into separate classes: one servlet, and one listener.
I also have the following unrelated recommendations:
Use standard Java naming conventions. It's surprisingly hard to read Java code that does not. Take for example, you servlet chserv. You should uppercase the first letter of each word. Also, why make me guess what ch stands for? Charley? Name the servlet something like CharleyServlet.
As dicsussed, always put classes in a package other than the default.
Never ever ever, and did I mention ever, use instance variables in a servlet. I realize that in this case you were trying to use it as a communication mechanism between the listener portion of the class and the servlet portion, but doing so is just asking to get hit with threading issues.
Why use a servlet to emit markup when a JSP is so much better suited for it? (The converse is also true: processing should be done in a servlet, not a JSP).
[ December 13, 2005: Message edited by: Bear Bibeault ]
Joined: Apr 11, 2005
Thanks for the advice, maybe I can explain a little better what I'm trying to do now that I've thought about it. I want to create a chat application, similar to yahoo messenger, but just very basic. My plan is to use 2 servlets, and a bean. Call the first servlet Display.java This is going to display 10 lines of text say, and underneath, will be a space for Text Input, (with name="line"), alongside a SUBMIT button. Upon clicking submit, the sentence written in the box will retrieved in the second servlet(Data.java) by using
Now in this second servlet (Data.java), a bean (scope="application") will be updated, basically as:
Then control will be forwarded back to Display.java, and the entered text should be displayed on screen.
Here is the problem with the listener, when a 2nd user submits a line of text, the 10 lines of text will be updated, but the 1st users screen will need to be refreshed to see the new text, which is why I wanted to use a ServletContext AttributeListener to listener out for changes to context attributes (ie, the bean) so that the Display.java page can be redisplayed.
Hope that makes some sense Please let me know if you think I can implement this listener in Display.java, I don't think I can going on from what u said in last post.
Originally posted by Pradip Bhat: I thought that the default package problem was only with tomcat. I am eagerly waiting to read the link. :roll:
No, it's with Java. Unfortunately, Sun's site seems to be in a state of flux (as if it's ever been anything else). That link which laid out changes between 1.4 and 1.3 now redirects you back to a general page which states:
The compatibility documents are divided to track incompatibility only between adjacent versions. For example, this 1.4.2 compatibility page details only 1.4.2 incompatibility with 1.4.1 and not previous versions. Therefore, to find how 1.4.2 is incompatible with all versions, you would need to look on all compatibility pages.
They then give you 5 links to the pages that show the incompatiblities among prior versions. Yesterday, these links worked. Today, they just redirect you back to the current page. Frustrating!