Valentin Floarea

Greenhorn
+ Follow
since Mar 30, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
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 Valentin Floarea

I used Enthuware in my preparation for EJB3.0/JPA1.0 exam. It is a good simulator with questions a little bit more difficult than the real exam. In mock tests I obtained between 80% and 90% scores. In real exam I had 95%. Anyway, probably I would have passed the exam without it, but definitely it helped me to improve the score. I didn't buy Whizlabs because they had some free questions on their site and I found wrong answers even in these. I remember something about the mandatory/non-mandatory ejb-jar.xml descriptor. I suspect they got that question from ejb2.1 (where the descriptor was mandatory) mock test and put it in ejb 3.0 mock without checking.

Dan Fow wrote:I'm a newbie to JEE and EJB's so forgive me if this is a stupid question.

I want to have an EJB that extends the java.util.Properties class however, it is my understanding that I need to have an interface for the Bean that I inject. Properties does not have an interface so I don't know how to expose the Properties methods in my beans interface.

How can I create a Bean that extends Properties and has an interface that also exposes the Properties methods (without having to rewrite all of them myself)?

is there a way to create a bean without an interface?



If I correctly understand, you want to expose the methods from java.util.Properties as EJB methods. Why do you need this? First, the EJB rules restrict the use of java.io package in the EJBs and some methods from Properties class use a couple of classes included in this package. Second, you cannot create stateless bean extending the Properties class because the stateless bean does not maintain the conversational state. So when you add a property you don't know the instance where that property will be added (usually the servers keep in memory several instances of a bean). You could use a stateful bean, but I don't see the benefit over a simple instantiation of the Property class. You should use EJBs when you need services provided by the container (e.g. transactions, security, pooling,....).

Anyway, for the sake of illustration you could accomplish your task using EJB 3.0 too. You could define an interface containing the signature of the public methods from the Properties class. Your bean has to implement this interface and extend the Properties class, but not provide any implementation for the methods defined in the interface (the bean will inherit these methods). But again, this is against the rules and the purpose of the EJBs.