Sheldon Fernandes

Ranch Hand
+ Follow
since Aug 18, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Sheldon Fernandes

After doing a bit of reading up on struts 2, it appears it uses a Filter (as the controller I'm assuming).

I hope someone replies to your query, I'm interested in knowing the answer too

[Edit]
If it is possible to get access to the Filter's FilterConfig you could use that to get access to the ServletContext of the Web application
[ March 23, 2007: Message edited by: Sheldon Fernandes ]
17 years ago
I'm not too familiar with the struts 2 framework, but if you could explain the problem you are trying to solve, then someone might be able to suggest a different approach, possibly.
17 years ago
I'm glad that worked. You are welcome sreenivas.
17 years ago
You are welcome. Glad that you found the problem.
17 years ago
I think I may have found the problem.


In the first line of the above code, form is the action form bean that is created and stored in request scope.

In line 2, you are retrieving a new instance of the PatientDetailsForm and referencing it in via variable pdform. So now you have 2 instances of PatientDetailsForm, one that is in request scope (that was passed to the action method) and the one returned from the DAO. The request scope form is still empty.

You can copy the properties from one bean to the other using

OR

You can forcibly set the one returned by the DAO in request scope so that it overwrites the existing empty instance (key="PatientDetailsForm").

Let us know if this works.
[ March 22, 2007: Message edited by: Sheldon Fernandes ]
17 years ago
Can you paste the <action> defined in struts-config.xml corresponding to the path "/PatientDetails" ?
17 years ago
I'm assuming that the debug statement "Forwarding to getQuestion" is getting logged.

Do you have any debug statements in your JSP "GetQuestion.jsp"?

Do you have a try catch in your JSP? Are you eating up exceptions that might be thrown in your JSP?

Do you see any output on your server console? or in the server logs?
17 years ago
Do you always need to validate ONLY one field out of the 12?
OR
Is the validation of 1 versus 12 fields conditional?

Please provide some detail regarding what you intend to achieve and why?
17 years ago
Could you post the relevant portion of your action class? That might provide some insight.
17 years ago
With AJAX, there is a need to use javascript to perform a little bit of your "logic" apart from the usual "presentation" changes that we are used to doing using DHTML. Previously the trend was to keep only presentation related information on the generated web page, but now with AJAX some of the server-side logic needs to be part of the generated web page. Doesn't it make web development a little more difficult? Does the book give techniques/patterns to use when developing using AJAX?

No doubt we are achieving a richer web experience for the user, but there seems to be some new problems that arise when adopting AJAX. Searching the net I see that there appears to be solutions to the commonly raised questions like the "Back Button" issue. An article on the Sun site talks about the problems that may arise due to "viewable source", problems like security concerns and plagiarism. Ryan/Nathaniel, could you'll please comment on the same?

Sheldon
Hi All,

I posted my question on wickedlysmart.com and received a very prompt reply from Kathy herself. Thanks Kathy for taking time to answer my question. Below is her reply, just in case you were interested.


Hello there Sheldon,
Yes, this is a very confusing one that almost everybody wonders about. We should have put it in the book!


Your logic is correct, but the Container is able to do this because it is a *stateless* bean. Since any stateless bean is the same as any OTHER stateless bean, the Container is required to give *something* to the bean that acts as an EJBObject for that bean type. The EJBObject for stateless beans are not associated with any client-specific state, so it does not matter which EJBObject it gets. In other words, the Container is required to provide a stateless bean with a "placeholder" EJBObject that it can use if it needs to send a reference to itself to some other part of the system. But that reference would be for an EJBObject that could actually represent *any* of the stateless beans of that type.


So, even though there is no client yet associated with the stateless bean, the Container does not NEED to have client-specific information in order to create an EJBObject for the bean. This DOES mean that the two parts of the bean's lifecycle are not consistent -- for the reasons you state -- how can the EJBObject be created if it is not created until there is a client? But the answer is that the lifecycle diagrams in the EJB spec (and often in our book) do not represent *real* internals, but rather the way you are supposed to conceptually think about it. And this is one of those areas where you just have to trust that the Container has a way to make this work... for example, the Container could simply create *one* EJBObject shared by all stateless beans, until there is a client for that bean. At that point, the Container can swap the "placeholder" EJBObject for a real one, or have some other mechanism. It might not even use different EJBObjects for the different clients if it is a stateless bean.


This is part of what you are not allowed to know -- how the Container actually implements the spec. The only thing you MUST know, is that within your ejbCreate() for a stateless bean, you can ask for your EJBObject, and *something* will be returned that works. That's all you have to know, and it does not matter how the Container makes that work.


Cheers,
Kathy : )


Good luck with your studies.

If you want to post this to the javaranch forum, please do.

No replies yet!!!



This is what I am trying to ask.
The above code is for a Stateless Session Bean. Why is the call to get a reference to the EJBObject valid from the ejbCreate() method? The question applies to ejbRemove() also.

Originally posted by Johann Evans:
The EJB spec mentions:
The container invokes the ejbRemove method on an entity bean instance with container-managed persistence in response to a client-invoked remove operation on the entity bean�s remote home or remote interface.



The above statement is present in section 14.1.3, and section 14 is titled "EJB 1.1 Entity beans with container-managed persistence". That's probably why only the remote interfaces are mentioned.

I searched in the specs but could not find anything. So still have no answer to your question. Its strange, I (or most people for that matter) would expect the same behaviour for local beans, but then you are saying it is not happening. Hope someone has an explanation. By the way, which application server are you using?

- Sheldon Fernandes
I wonder if its a problem with the DTDs. The ValidatorResources class tries to register these DTDs.



To verify if this could be the problem, trying commenting/removing the DOCTYPE declaration from both the xml files.

Just a guess. Worth trying I feel.

EDIT: Making the assumption that the xml files are valid and well-formed.
[ June 29, 2005: Message edited by: Sheldon Fernandes ]
19 years ago