David Harrigan

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

Recent posts by David Harrigan

Hi,
Usually it takes a looooong time for something like this to make its way into an actual round of tests. It has to be accepted by the industry, then it has to be proved in the field, then the programmers have to learn it and understand it....
I would reckon that perhaps you won't see a EJB2.1 exam until late next year.
-=david=-
Hi,
I think you are getting slightly confused.
For a stateful *session* bean, you are correct - it will not be passivated whilst in a tx.
For an Entity bean, it may be passivated by the container whilst that Entity bean is participating within a tx.
That is what the spec is alluding to.
-=david=-
It is perfectly valid to use a collection to return results, however the objects in that collection must a serializable type. For example, when I run the EJB Validator over our EAR for WebSphere, it warns that some of the return types *must* be serializable at *runtime* (e.g., we have a method that returns a List, but the things in that list are of type ArrayList, which does implement Serializable).
It's just one of those things and best to look out for it, but accept it for what it is.
-=david=-
The ":" in your classpath is incorrect. This is a unix way of separating the classpath (or environment variables). In Windows/Dos you need to use the ";" version.
-=david=-
Hi,
IMHO it is worthwhile taking the exam. It will be about 1-2 years before EJB2.1/J2EE1.4 becomes embedded within the mainstream development arena. During that time, the majority of the work will still be in J2EE1.3. Now, it is worthwhile keeping an eye on the future, hence when coding for J2EE1.3, nothing wrong in "future-proofing" your code to easy make it work with 1.4.
So, yes, I believe it is worthwhile taking the exam.
-=david=-
Hi Keith!
I believe the answer can be deduced from the following. According to the spec, only primitive types and serializable objects can be used for assignments (setters) to cmp-fields for a cmp entity bean. It doesn't explicitly say anything about getters, but I would say that the same rules apply - you can get primitives and serializable objects.
Page 130, last bullet point on the EJB 2.0 spec.
-=david=-
Hi Keith!
I believe the answer can be deduced from the following. According to the spec, only primitive types and serializable objects can be used for assignments (setters) to cmp-fields for a cmp entity bean. It doesn't explicitly say anything about getters, but I would say that the same rules apply - you can get primitives and serializable objects.
Page 130, last bullet point on the EJB 2.0 spec.
-=david=-
Hi Colin,
Those are excellent questions. I hope I can clarify the situation a bit.
In Weblogic, one can set the idle-timeout-seconds to a really low value (say 1) that would /in-effect/ cause the stateful session bean to be removed PDQ.
In Websphere, one can se the timeout value (in the DD) to achieve the same effect as in Weblogic.
I couldn't see anything about JBoss, but I'm sure it's there somewhere.
However, if a stateful session bean is participating in a Tx, then it will *never* be removed until that Tx has completed (either commit or rollback)
If I client calls remove() on a passivated bean, then the container will simple destroy it. It would be a waste of resource to load it back into memory (using some type of serialization-type process) just to then destroy it. So ejbRemove() doesn't get called nor does ejbActivate().
If a system exception is thrown (say out-of-memory) - uncheckable exceptions, then the bean moves to the Does Not Exist state and ejbRemove() is never called.
-=david=-
Hi,
I believe that if a select method doesn't find anything then the collection returned is not null, but simply empty, i.e., size() returns 0.
This is alluded to on page 233 of Enterprise JavaBeans by Richard Monson-Haefel (top of the page).
-=david=-
Hi,
Good question. I believe what is mis-leading is the use of the <--> arrows (which to me, on first glance means bi-directional, n-m relationship). What I had to look for was the (1) and the (n). Looking at the spec, and at the question, to me D is incorrect!
Basically, what it is saying is that:
An Order can contain many LineItemsBeans
i.e., it's a 1 to Many relationship.
So, to explain the answers.
Why is A incorrect?
Because it doesn't have Object(o), and we are selecting objects.
Why is B correct?
It is correct because the select is finding all objects from all the orders out there that are of type lineitems.
Why is C incorrect?
That would return Orders that /dont/ have lineItems.
Why is D incorrect?
According to the spec, this select will simply return all OrderBeans, with no qualification that they must contain lineItems. So it would be my understanding that some of the OrderBeans return could contain lineItems and some may not...
Perhaps someone could clarify this?
-=david=-
I would heartly recommend the advice given and use the RI. I use WebSphere at work, and it's a pain...
Hi There!
Good question, but you are assured by the container that no two clients will be executing in the same method of the same stateless session bean. So, having multiple clients access, say, 1 or 2 stateless session beans will cause no problems (apart from why a container is only creating 1 or 2 stateless session beans if a lot of clients are hitting it....but that's another story :-) )
-=david=-
It all depends on what *you* want to do.
Both exams are necessary, imho. However, you may wish to concentrate on just Servlets and JSPs and be an expert on the presentation layer. Or, you may choose to concentrate on EJB's and become an expert at the domain/business layer.
It's how you want to play it that counts. You can always find a job that utilises both set of skills.
You don't need to be SCWCD to become a SCBCD. The SCBCD exam makes no reference to Servlets/JSPs or any thing associated with that exam.
-=david=-
[ January 12, 2004: Message edited by: David Harrigan ]
Hi,
Seems that the compliation can't find the j2ee.jar.
This is what I have in order to successfully compile. Compare it with your command and see if you can progress from there.
CLASSPATH=,;c:\javastuff\j2ee1.3.1\lib\j2ee.jar
javac -classpath %CLASSPATH%;adviceclientjar.jar AdviceClient.java
java -classpath %CLASSPATH%;adviceclientjar.jar AdviceClient
The adviceclientjar.jar is the jar that is generated by the J2EE RI by Sun on deploymnet (tick the box) that contains the stubs and skeletons used by RMI. You need to put this on your classpath so that the compile works (e.g., your AdviceClient java class can find AdviceHome, Advice etc...)
Of course this is just for compiling the AdviceClient. To compile the bean, remote home and component interfaces simple cd into the relevant directory, keep the classpath (as described above - modified to suit your program locations) the same and type...
javac -classpath %CLASSPATH% *.java
Hope this helps.
-=david=-
[ January 11, 2004: Message edited by: David Harrigan ]