Ana Nava

+ Follow
since May 25, 2004
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ana Nava

Option A,B & D are incorrect because static inner class or static methods cannot access non-static instance variables (here d1) directly.
Sometime back I was in the same position as well, trying to figure what to do next after learning the fundamentals and not willing to cross over to J2EE.

First I also tried to go by learning different packages. But I was not satisfied because nothing was concrete. My experience was just a bunch of examples here and there. That is when I came across Sun certified Java Developer Exam and following are the advantages that I derived from it.

  • Allows you to develop a concrete project
  • Gives you an opportunity to design, develop and test
  • Sun tests you for all the J2SE packages that are normally used in real time application
  • You are evaluated by Sun which lets you know where you stand
  • Basically you get hands on experience in variety of packages and design tools

  • Hope this helps
    18 years ago

    No. This is not directly related to the RequestDispatcher question. You have to remember that you get the IllegalStateException because you cannot invoke both getWriter() and getOutputStream on the same response object. (Nothing to do with RequestDispatcher in this case.)

    Thanks for the response. Sorry for not being clear with my example.

    I did the following :-

    Servlet 1 : Used getWriter and println method, followed by forward method. This did NOT throw any error.

    Servlet 2 : Used getOutputStream and write method (no flush method), followed by forward method. This threw the above stated error.

    Servlet 3 : Used just getOutputStream (no write and no flush method), followed by forward method. This threw the above stated error as well.

    I did NOT invoke both getWriter() and getOutputStream on the same response object as they were in two "DIFFERENT" servlets.

    The error is due to RequestDispatcher, because calling both getOutputStream and forward method in the same service method causes this exception.

    so my question still remains

    HF -> Page 209 -> Chapter 5 -> Coffee Cram Question no : 1.

    Following is the Question along with its options.

    When using a RequestDispatcher, the use of which methods often lead to an IllegalStateException.

  • A. read
  • B. flush
  • C. write
  • D. getOutputStream
  • E. getResourceAsStream

  • Although the answer in page 215 has just option B (flush) selected, in the errata they have stated to include option C (write) as well.

    When I tried an example in Tomcat 5.0, I used getWriter and println method before calling forward method, it did not cause any error. But when I tried with getOutStream and write, before calling forward method following was the error message I got.

    java.lang.IllegalStateException: getOutputStream() has already been called for this response

    Above error occurred when I just called getOutStream without write method.

    Did NOT use flush method in any case.

    In Spec Servlet 2.4 page 167, following is stated.

    forward should be called before the response has been committed to the client (before response body output has been flushed). If the response already has been committed, this method throws an IllegalStateException.
    Uncommitted output in the response buffer is automatically cleared before
    the forward.

    What I understand from the spec is that, only calling flush method should cause an error.

    So these are my questions.

    1.In the errata, it has stated to include option C (write) but not option D (getOutStream). Should option D (getOutputStream) be included as well?

    2.Is this behavior vendor-specific that is, does all servlet-containers throw error when getOutputStream or write method is called before forward method?

    3.If this question is in exam, what option(s) should I select?

    In Servlet Spec 2.4, page 25 under the title SRV.2.3.1 Loading and Instantiation, following is stated :

    The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the container is started, or delayed until the container determines the servlet is needed to service a request. When the servlet engine is started, needed servlet classes must be located by the servlet container.

    From this I infer that, when the servlet engine starts it "locates" all the servlet classes via <servlet> element from web.xml file.

    But the "loading" of the servlet class, entirely depends on the container's implementation. If the container is implemented to load all the servlet class when it is started, then the loading would precede the mapping. If the container is implemented to load the servlet class, only when it is needed to service a request, then mapping would precede the loading.
    18 years ago
    I would alter it a tiny bit for clarity sake .

    1 bean in "ready state"
    2 transaction begins
    3 afterBegin is called
    4 business method is called
    5 beforeCompletion is called
    6 transaction is committed or rolledback
    7 afterCompletion is called
    Roger, thanks for explaining again.

    I am NOT confused. I just restated the initial confusion, and the reason for that confusion to Vijay. That is the reason I stated that "One can come to a conclusion". From Kathy's response, I clearly understood that creation of EJBObject is not as sequential as depicted in OID.

    Also for sure setSessionContext and ejbCreate are called before the bean comes to the pool. No CONFUSION on that

    Thanks again .
    Thanks Adri and Roger ... now it is clear.

    Quote from Vijay Dasari

    However, the container handles the create and remove calls without necessarily creating and removing an EJB instance".

    So we can access the EJBObject in the ejbCreate() of the Stateless Session bean.

    Vijay, the question here is "BECAUSE" the Statless session bean is created at the will of the Container and not the client, how can it have access to EJBObject.

    The OID both HFEJB page : 227 and in spec Page : 92 suggest that the new EJBObject is created when the "client" calls create method of Home interface. So by this diagram one can come to a conclusion that during ejbCreate() of stateless session bean we cannot get access to EJBObject, because it will be created only when the client calls create() method.

    But from Kathy's response (thanks to Adri Smith for pointing me to it) it appears that EJBObject can be created anytime and the bean's context will get reference to it during ejbCreate().

    Quote from Roger Chung-Wee

    that the container will pull a bean instance from the pool and associate the instance with its SessionContext and EJBObject by invoking the bean's setSessionContext() and ejbCreate() methods.

    Roger, according to both life-cycle diagram and OID, setSessionContext() and ejbCreate() are called before the bean comes to the pool.
    Well it is a tricky option in an exam question. In EJB the system exception are not just "unchecked exception", but includes "RemoteException and its subclasses" (which are checked exception) as well.

    If there was a question like "What is true about Exceptions in EJB" and there were following options like

    a. application exceptions must be checked exceptions
    b. system exceptions are unchecked exceptions.

    I would select a and not b, because, system exceptions includes "RemoteException" as well.
    Meg, I also had the very same question. But after little bit of thinking this how I convinced myself. There is a subtle difference between them. If you say "Required" then it means that you need a transaction. But it is the container that decides to give you a new one, if one is not present or an existing one, if one is present. But if you say "RequiresNew", you could assume that there is a possibility that you might be given an existing transaction, so you are telling to the container, do not ever me an existing transaction and always give me a new one. In case of MDB there is NO such possibility so in order avoid this ambiguity (the assumption that you might be given an existing one), "RequiresNew" is not an option.

    It means you as a bean developer can get a reference to the EJBObject[/QB]

    So what I infer from this is that for every Stateless Session Bean in the pool there is corresponding EJBObject/EJBLocalObject created by the container to which a bean can get reference to. That doesn't sound right to me.

    Originally posted by Kev Miller:
    on page 227 (Head First EJB) it says that ejbCreate is invoked by the container without a client request. On the following page, however, it says that you can get a reference to your EJBObject from within ejbCreate. How can you get such a reference when the container invokes ejbCreate without any client request? Isn't an EJBObject instance only created when the client invokes create on his home object stub (whereas the EJBObject instance is not linked to an actual bean instance until a business method call)?

    I tried to figure out how and but could not come up with an answer for Kev's question. Any one..any explanation for this?

    But, how can we access resource managers in ejbCreate() and ejbReomve() methods? I know these run in unspecified transaction. So, is this unspecified transaction a 'meaning transaction context'?

    Not in case of Entity Beans. Check out spec 10.5.2
    in page 171 under "public PrimaryKeyClass ejbCreate<METHOD>(...);" and
    in page 173 under "public void ejbRemove();".
    Although objective 4 is not explicitly specified in the beginning of any chapter, these objectives are covered in Chap 4. If you think that is not enough, just check out the EJB2.0 Spec (using Valentin Crettaz's spec-objectives mapping) or Mikalai Zaikin's SCBCD Guide.
    Ok lets analyze the question piece by piece...

    Given a remote client R, that has valid reference to session beans A and B

    As R (a remote client) has "valid" reference this means that it has a remote reference to A and remote reference to B.

    1. R cannot pass his reference for A, to B

    This is not a right choice because R can pass his remote reference of A to B as per the Spec "A client can pass a remote home object reference to another application".

    and given that A is a local client to B

    Although R has a remote reference to B, A has a local reference to B. (yes it is possible, but should be done with attention due to the reasons stated in page, 164 of HFEJB).

    So choice 2 would be right because we cannot pass a local reference (A) to a remote reference (B to R).

    Choice 3 is not right because, A can invoke methods on B.

    Hope this helps...