Enthuware

According to servlet specs 3.0:

"For a servlet defined via the @WebServlet annotation, to override values via the descriptor, the name of the servlet in the descriptor MUST match the name of the servlet specified via the annotation"

Therefore, I believe because of the 2 different names, Container should create 2 instances of that servlet.

Please verify.

Thank you.

You are right. This has been fixed.

Thanks a lot for your feedback.

In my version of this question (I just got the *.ets today - 8/8/11)

//In file WFTestServlet1.java
@WebServlet(urlPatterns={"/wftestservlet1"}, name="WFTestServlet1")
public class WFTestServlet1 extends HttpServlet{
public void init(){
System.out.println("Servlet Name = "+this.getServletName());
}
...
}


//In web.xml
<servlet>
<servlet-name>WFTestServlet1</servlet-name>
<servlet-class>com.enthuware.toywebfragment.WFTestServlet1</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>WFTestServlet1</servlet-name>
<url-pattern>/wftestservlet1</url-pattern>
</servlet-mapping>

Yet it reports that the following is a "correct" answer:
The name of the servlet printed from the init method will be MyServlet.
instead of this:
The name of the servlet printed from the init method will be WFTestServlet1

In the explanation, it has :
In this question, the annotation in the servlet tries to associate the servlet with the name "WFTestServlet1" and tries to bind it to /wftestservlet1 url pattern. In web.xml we are using the same servlet class and same url pattern but with a different servlet name.
Web.xml takes precedence. Therefore, only one servlet instance with the name given in web.xml will be created and it will service the url pattern specified in web.xml i.e. /wftestservlet1, which happens to be same as the one specified in the annotation.

Implying that the problem statement is not correct.? Given the explanation, shouldn't the DD have:
<servlet-name>MyServlet</servlet-name>?

I apologize for the confusion. I was too quick to update the question without realizing what the original intent of author the question. Here is the issue:

As per the specification, it is clear that to override the servlet annotations, the name of the servlet in web.xml must match with the name given in the annotation. However, it is not clear from the specification what happens when the the url pattern in the annotation is same as the one given in web.xml but name is different. Since the servlet name in both the places do not match, two instances of the servlet should be created, but which instance should be used to service the url pattern is not clear. Since web.xml takes precedence, the instance created as per information in web.xml should be used. It follows then, that the name of the servlet printed when the servlet is executed, should be the one given in web.xml.

Tomcat 7.0.2 prints the servlet name specified in the annotation when you try to access the url pattern specified in web.xml. But Glassfish 3.0 prints the name specifed in web.xml, which seems in harmony with the specification.

So, options 2, 4, 6 should be correct.

HTH,
Paul.

I still think that answers of that question are ambiguous.

It is given that this is correct:
The name of the servlet printed from the init method will be WFTestServlet1

and this is not:
The name of the servlet printed from the init method will be MyServlet.

If we know that we will have 2 instances of this servlet class then it is possible that both names will be printed. Of course only WFTestServlet1 will be printed if we try to access the servlet by class, but it is also possible from some other code to dispatch the request to this serlvet by name and to trigger "MyServlet" servlet initialization.

So I would suggest to remove answer 5 from the list of wrong answers.

I configured via both annotation and web.xml the load-on-startup flag to 2 different numbers. Using GlassFish v3.1, upon startup I see in my console that only one instance is created (the name output is as expected "WFTestServlet1"). However up to now we're conjecturing that two instances should be created due to the different names configured. What should I make of that?

Hi Goetz, Did you try to access both from different urls?

I just tried that and interestingly the urlPattern defined in the annotation resulted in a 404 Not Found! It appears that since the spec is not completely clear on this point, GlassFish decides to ignore the annotations altogether in favor of a single instance defined via web.xml.

I also tried the same in Tomcat 7, and it resulted in 2 instances, each tied to its own urlPattern (as well as its own name). Not sure who's implementation is more "correct"...

Hi,
i have similar concerns as "Mindmap" user above....Maybe some refactoring of the last two options should be done as they are pretty debatable..or at least option 5 should not be considered wrong...

thanks

In the Explanation:

4. If web.xml specifies metadata-complete=true, then no class is parsed for annotations.

According to specification (8.1 Annotations and pluggability) no class in web application's JAR files will be parsed:

The “metadata-complete” attribute defines
whether the web descriptor is complete, or whether the class files of the jar file
should be examined for annotations and web fragments at deployment time.

Also,

5. If any web-fragment.xml specifies metadata-complete=true, only annotations specified in classes contained in that web fragment are ignored.

did you mean

classes contained in web fragment's JAR file are ignored

.

tori3852 wrote:Also,

5. If any web-fragment.xml specifies metadata-complete=true, only annotations specified in classes contained in that web fragment are ignored.

did you mean

classes contained in web fragment's JAR file are ignored

.

Yes, I think that is the intent.
-Paul.

@tori , if you specify metadata-complete=true on the web.xml file then no class file whether in the jar or in the classes directory will be scanned. you are right that in the spec it is written otherwise but i think it is not rigid. i tested it on tomcat 7.0.34 and setting metadata-complete=true didnt scan my clasess present in classes directory for annotation. never tried on glassfish though

Apache Tomcat 8.0.3 and Apache Tomcat 7.0.41

Caused by: java.lang.IllegalArgumentException: The servlets named [WFTestServlet1] and [MyServlet] are both mapped to the url-pattern [/wftestservlet1] which is not permitted

There is no correct answer ?

As the explanation says, it is not clear what should happen:

As per the specification, it is clear that to override the servlet annotations, the name of the servlet in web.xml must match with the name given in the annotation. However, it is not clear from the specification what happens when the the url pattern in the annotation is same as the one given in web.xml but name is different. Since the servlet name in both the places do not match, two instances of the servlet should be created, but which instance should be used to service the url pattern is not clear. Since web.xml takes precedence, the instance created as per information in web.xml should be used. It follows then, that the name of the servlet printed when the servlet is executed, should be the one given in web.xml.

HTH,
Paul.

Hi.

"However, it is not clear from the specification what happens when the the url pattern in the annotation is same as the one given in web.xml but name is different"

If it's not clear what happens how we can be sure that "2 instances of WFTestServlet1 will be created" ?
Because using Tomcat 7.0.68 I get an exception during deployment:

java.lang.IllegalArgumentException: The servlets named [...] and [...] are both mapped to the url-pattern [...]

The same exception with Glassfish 3.1.2

And the empty constructor for this servlet is not being called. So no instances.

Well, it is a matter of interpretation. Annotations are embedded in class files. The source for such classes may not necessarily available to the end user (in case of packaged applications). The deployment descriptor allows the end user to customize the behavior. I think it is quite plausible for a user to map a particular url pattern to a different servlet. There is nothing extra ordinary about this. Why should there be an exception?

I believe this was tested on the most recent version of tomcat available at the time and that version didn't generate the exception.

In any case, the specification is silent on this and it is up to you to decide which interpretation you want to follow.

HTH,
Paul.