Bob Wheeler

Ranch Hand
+ Follow
since Apr 24, 2009
Merit badge: grant badges
For More
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
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bob Wheeler

Thank you for your effort. Indeed this is also a solution for my problem. Not perfect, but it is a solution.
But luckily, for me, my boss changed his mind, and didn't want to use the eMail address as an ID.

But still thank you,
Robin
12 years ago
Hi,

I have a problem with Spring, RequestMapping and eMail-Addresse which I send to my controller method. Actually every email address is received without the ending (after the last point) So if I send this
name@domain.com the controller method receives name@domain.
I found this as a bug but the workaround didn't help me: https://jira.springsource.org/browse/SPR-6164
It's all because of the dots I learned. I build a workaround by replacing the dots with dollarsigns, but this is really ugly and also is shown in the address bar, which is forbidden.

Has anybody an idea?

Thank you.
cheers
Robin

Here is my controller method. Well only the header:
13 years ago

Paul Anil wrote:Congratulations!!!
Glad to know Enthuware tool helped!!!


Yeah, it did. It was a good investment from me

Also, thanks to all Java Ranch people, who have contributed to a thread, which came my way. THANKS.

cheers
Bob
13 years ago

Mikalai Zaikin wrote:

Bob Wheeler wrote:Hi,
I can proudly announce that I successfully passed the SCBCD 5 certification exam with 83%.


Hey, well done !
Congratulations !!!


Your study work deserves a personal thank you. Good work!

cheers
Bob
13 years ago
Hi,

I can proudly announce that I successfully passed the SCBCD 5 certification exam with 83%.
The questions were much or less like here described.

Books and other material I used:
- Book: EJB3 In Action
- Mock Exams Enthuware
- Java EE API
- Java Ranch Forum
- SCBCD 5.0 Study Guide
- Last Minute Refresher
- EJB3 Notes

Now, where to go? I guess my next step is to learn more about Spring, Hibernate and stuff.

Thanks for the help.
cheers
Bob
13 years ago
Congrats
and thanks for your detailed report.

Have fun with EJBs
Bob
13 years ago

amit punekar wrote:
The transaction and Persistence Context are different from each other.


Thanks for your answer. I sort of mixed transaction and persistence context.

Cheers
Bob
Hi Amit,

thanks for your answer.

amit punekar wrote:Hi,
AFAIK this condition would happen if the bean uses bean managed transactions. In this a method would start a transaction but leave it open to be committed by another method. Due to this the container will not passivate the SFSB instance as it would still be servicing the client.


Why should it only happen in a BMT (bean managed transaction)? The extended persistence context could be also used with a CMT (container managed transaction). Or, do I mix something?


amit punekar wrote:
As per the core Ejb specs a client to such bean should take care not to call remove method.
See 4.4.4 ejb core specs.



I guess you mean this paragraph:


If a session bean instance is participating in a transaction, it is an error for a client to invoke the
remove method on the session object’s home or component interface object. The container
must detect such an attempt and throw the javax.ejb.RemoveException to the client.
The container should not mark the client’s transaction for rollback, thus allowing the client to
recover.


Now you have me at a complete loss. I thought that an extended context maintains its managed objects between transactions and all objects accessed or created hang around until the bean goes away. Which means until the @Remove method is called. Now, that should result in an exception. I am confused

Cheers,
Bob
Short question:
From the Enthuware test I have the following statement marked as true:

"A stateful session bean cannot be passivated if it is in a transaction."


Does this mean, that in an extended transaction a stateful bean will never be passivated unless the @Remove method is called?

Thank you.
Bob
Thanks mate.
I will definitely listen this talk. Sounds interesting for a newbie in this area like me.

cheers Bob
Thanks guys (and girls )

cheers
Bob
14 years ago
congrats

cheers
Bob
14 years ago
Hi,

I'm not very satisfied with the result, but in the end it doesn't matter.
I used the Head First book and also did most of the mock exams listed on the SCWCD link page.
I will head now to the EJB Certification ( I guess, not sure now).

Thanks to all of you for your posts.
cheers
Bob
14 years ago
Great score. Congrats.

cheers
Bob
14 years ago

Maciek Mike wrote:Hi,
D: If the second <auth-constraint> tag is removed, the constrained resource can be accessed by both roles.
Is wrong and answer F:


You have only one role (student). With the second auth-constraint tag nobody (to be precise, no role) has access to the constrained HTTP method. But if you remove the empty auth-constraint tag the role student has access again.

EDIT: I just read the post from Ankit. It's right, if you remove the auth-constraints altogether everybody has access. Still D is wrong, because I don't see a second role in the code (Or so ). Must be a trap for the poor coders


cheers
Bob