RE: [Xdoclet-user] Session bean pattern

[Vincent Harcq]

Title: Message

I want to (when I will find some time) generate JUnit unit test case for session bean methods.

Of course it requires more thinking that simply saying it because some SetUp/tearDown will be needed.

As Unit testing argue why not but these somewhere along with the session bean itself (write your test when writing your code)

There is also Cactus or JUnit for J2EE that I never look at but could be helpful as well.

The problem with xdoclet is that it gives so many idea but it never gives you time...

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of James Hughes
Sent: jeudi 24 janvier 2002 18:21
To: '[EMAIL PROTECTED]'
Subject: [Xdoclet-user] Session bean pattern

I would like to use this pattern to turn pojo's into session beans:

Start with:

// not abstract
// doesn't implement anything
public class WorkerBean
{
        public void DoSomething(String s){
                ...
        }
        public String DoSomethingElse(String s){
                ...
        }
}

And have xdoclet gen something like this:

public class WorkerEJB extends WorkerBean implements implements SessionBean
{
        private SessionContext sessionContext;
        public void DoSomething(String s){
                try{
                        super.DoSomething(s);
                }
                catch(Exception e) { throw new EJBException(e); }
        }
        public String DoSomethingElse(String s){
                try{
                        return super.DoSomethingElse(s);
                }
                catch(Exception e) { throw new EJBException(e); }       }
       
        public void setSessionContext(SessionContext context){this.sessionContext = context;}
        public void ejbRemove(){}
        public void ejbActivate(){}
        public void ejbPassivate(){}
}

...along with the remote interface and the home stuff, etc.

Can I do this now with xdoclet?  If not, how hard would it be for me to change it?  Could I do this with just a custom merge file, or by subclassing some of the tasks?

I like to use this pattern because it allows me to unit test the business logic within the regular beans outside the app server context.  Any criticism of this way of writing EJBs would also be very welcome.

Thanks,

Jim Hughes
RIA