Win a copy of Java by Comparison (eBook) this week in the Java in General forum!

varun Dosapati

Ranch Hand
+ Follow
since Nov 18, 2010
varun likes ...
Java Spring Tomcat Server
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
4
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by varun Dosapati

Hi All,

On October 25 2014 I have passed "Java EE 6 Web Component Developer" 1z0-899 exam with 78% score.

I have prepared with HFSJ, , Servlet 3.0 Spec, Enthware tests for OCEWCD 6 .

Thank You Coderanch

3 years ago
if we see the example from the servlet spec 3.0

web-fragment.xml
<web-fragment>
<name>MyFragment1</name>
<ordering><after><name>MyFragment2</name></after></ordering>
...
</web-fragment>
web-fragment.xml
<web-fragment>
<name>MyFragment2</name>
..
</web-fragment>
web-fragment.xml
<web-fragment>
<name>MyFragment3</name>
<ordering><before><others/></before></ordering>
..
</web-fragment>
web.xml
<web-app>
...
</web-app>
In this example the processing order will be
web.xml
MyFragment3
MyFragment2
MyFragment1



From the spec


If a web-fragment.xml file does not have an <ordering> or the web.xml does
not have an <absolute-ordering> element the artifacts are assumed to not
have any ordering dependency.



So the result should be
MyFragment3
web.xml
MyFragment2
MyFragment1

Please correct me if I am wrong.

Thanks
Varun

Ishan Pandya




Yes I tried and it is throwing an error by the container.

When you define an URL-pattern in both the web.xml and in a @WebServlet annotation for the same Servlet, the URL-pattern in the deployment descriptor overrides the URL-pattern of the annotation.

From Servlet 3.0

8.2.3 Assembling the descriptor from web.xml, webfragment.xml and annotations
n. iv.) url-patterns, when specified in a descriptor for a given servlet name overrides the url patterns specified via the annotation.




Frits I wonder what would be the preference if we declare the servlet in web.xml and add pro-grammatically with same servlet name and different url-pattern.

Frits Walraven


Thanks for pointing....


Alex Theedom


I agree with your explanation alex but I was trying to find the reason but once frits pointed it make more sense for me.

Thanks though ....

What exactly is your question?



Below in my scenario I don't understand why it fails when I am trying to access with "sample.do"

For example
scenario 1:

In the below scenario
localhost:8081/contextroot/websample.do - works
localhost:8081/contextroot/sample.do - fails

web.xml
<servlet-mapping>
<servlet-name>ServletExample1</servlet-name>
<url-pattern>/websample.do</url-pattern>
</servlet-mapping>

ServletExample1.java

Scenario 2 :

If the content from web.xml is commented out

localhost:8081/contextroot/sample.do - works
in servlet3.0 on @webServlet if the name is specified the urlpattern is being ignored.

But I don't see anything in the spec mentioning about it.

Please advise.

Thanks
Varun

Hi Anirudh

firstly thanks for taking time to explain me...

NOW here in lies the rub, All AsyncContext initiated dispatches will wait till the HTTP thread initiated dispatch
has completed it's job and has returned back to the container. The AsyncContext initiated dispatches will follow
the completion of HTTP thread's dispatch.



But I am confused with your statement.

I don't know what you mean by HTTP thread initiated request(is that mean Servletrequest ).. Not sure

Also I will try to recreate your issue in my machine and will get back to you....


Thanks
Varun





Hello

I am preparing for OCPJWCD. I hope this is the right place to ask. I came across some statements while reading the spec which doesn't make sense for me.

"If any of the dispatch methods are called before the container-initiated dispatch that called startAsync has returned to the container, then the call will not take effect until after the container-initiated dispatch has returned to the container. Invocation of the AsyncListener.onComplete(AsyncEvent), AsyncListener.onTimeout(AsyncEvent) and AsyncListener.onError(AsyncEvent) will also be delayed till after the container-initiated dispatch has returned to the container."

I would appreciate if some one explains.

Thanks
Varun
Hi Nam Ha Minh,

I have 3+ years in Java programming and its related technologies.

Please let me know if you are still looking for java geeks.

Thanks,
Varun Dosapati
5 years ago

3. Would you ever have a source file without a package statement (making it a default package) containing a public class - that would be used for anything other than a small test program? After all, a default package can't be imported.

Yes you are right

Just an example




Try to compile and execute the code So it will be more helpful


Confusion 2:
If we are allowed to do this then why is it mentioned in Head First Servlets on pg.no 137 that once committed too late rule applies also to setting headers,cookies,status codes,content type and so on.



Head Frist Servelt book is not a spec. It is just a reference which can have mistakes in it.

See this link: http://oreilly.com/catalog/errata.csp?isbn=9780596005405

So I you need accurate information go through the Servlet/JSP specification.
Sagar

I found some of the resources which might helpful to understand how the response.sendRedirect(/path) and dispatcher.forward(request,response) works.

http://www.theserverside.com/discussions/thread.tss?thread_id=26425

The below resource is for out.flush().
http://www.coderanch.com/t/172181/java-Web-Component-SCWCD/certification/flush-jsp-include

It looks like response.sendRedirect(/path) and out.flush() might having some temporary behavior.

Hope this helps.

Thanks
Varun Dosapati
Sagar





Are you trying to access directly the jsp.

Thanks
Varun Dosapati
Sagar

below is the code generated once the jsp becomes servlet.





Thanks
Varun Dosapati