Sun Raj

+ Follow
since Mar 09, 2005
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 Sun Raj

I think the question is vague.
I am a bean provider and in one of the bean implementations I have a overloaded ejbCreate. One of the ejbCreates has the common functionality which other ejbCreates call. Is this not possible? Therefore, as a bean provider I am able to call ejbCreate.
Would appreciate clarification.

How did it print 0?
The print line in the extended class is commented thereforte, will not call the print method. Or am I missing something?

Thanks for your reply.

The construction and lifecycle management of the individual state tax info objects is managed elsewhere in the application. The new class that was added does the following:
Based on the a state(s) selection, for each selected state (which it gets from some other part of the application), it interacts with a factory object to get the corresponding state tax info object and runs the getInfo method on the taxinfo object and collects the returned value(in this case pdf byte[])
Finally it reutrns the pdf output (with some formatting such as page numbering etc.) of the tax info of all the selected states.

Please clarify the following:
Are Composite and Mediator/Adapter mutually exclusive?

I don't think it is a Composite. The class here knows about the colleague classes but does not contain instances of the ccolleague classes.
Based on the selection just invokes methods (described on the interface) on the colleague objects.

I have the following situation:
There is a tax info interface.
Different states implement this interface.
There about 50 classes that implement this interface.
The new requirement is to implement a class that instantiates one or more of these
(based on some settings) and display tax information of each of the selected states.

Will this be called a mediator pattern or an adapter pattern?

The reason I have this doubt is that like Mediator the new class mediates on behalf of the client and
the colleague classes. It does add new functionality.
But unlike classic definition of Mediator does not have a separate interface but does implement the same
interface as the colleague. The constructor takes a list of selected states.

The reason I think is an adapter is that it is one more implementation of the interface by adapting the user
data to call various objects and collecting and formatting the output from various objects
so that the user sees it as one unit.


The relation to a bean to its respective home object is many to one (typically, but some situations may warrent to have multiple home object each handling some set of beans).
Therefore for your CustomerBean object there should be a home (say CustomerHome) object. Otherwise, how will CustomerBean get instantiated? The create signatures of you CustomerBean is known only to the home (CustomerHome).
Therefore, every bean has a corresponding home object. The reference to the home object in the bean context refers to that bean's home object.

Hi Amol,
I did not refer to HF or the ejb spec. I have just started preparing for the SCBCD but have gone thru Mastering EJB by Ed Roman both 2 & 3 Editions at my work.
I was refering to pg 241 & 242 of Mastering EJB Edition 3.
The following is the text:
MDBs do not run in the same tx as the producer who sends the messages, because there are typically 2 tx associated with every durable JMS message (one tx for producers to put the message on the q, and another tx for the JMS mdb to get the message off the queue). It is theoretically impoissible for the JMS mdb to participate in the same Tx as the producer, because until the producer commits the tx, the message would'nt even appear on the q.

I was struggling with this problem all day yesterday. Today I fixed it.
I found the following link that helped me:

Thanks for the questions:
Here are my answers.

1. Most part is true, but, the old tx is not suspended.
It is only when the old Tx is committed that the message is sent to the destination.

2. Most part is true, but, the message is put on the queue/topic only after the ut.commit().

3. Not sure what exception will be received.

If that is the case then what is the point in having the switch, to indicate whether it is a sateful or stateless, in the DD?