On Fri, 2 Sep 2005 15:50:25 -0400
Dave Cramer <pg@fastcrypt.com> wrote:
>
> On 2-Sep-05, at 3:38 PM, Mark Wong wrote:
>
> > Hi Dave,
> >
> > Oops, EJB's are distasteful? My experience in this area is quite
> > lacking.
> Well, I said "personally" distasteful.
> > Not that I necessarily want to be 100% strict but the spec
> > says this needs to conform to WS-I BP 1.0 specification, which I
> > understand is basically using the SOAP transport? I just thought it
> > would be nice to have something that could be plugged into any
> > application server (Geronimo, JBoss, etc.) with minimal configuration
> > changes and that was where I started. I don't mind doing away with
> > the
> > EJB altogether. What do you suggest?
>
> I use hibernate, which would allow this to be used without an
> application server.
> However strictly speaking, many people are going to want to see EJB's
> as this is
> what the appserver types like to use.
> >
> > To give you a little better idea of where I'm at, I have most of 7
> > of 9
> > interactions implemented, the remaining two I haven't started. The
> > driver needs to be expanded to simulate multiple users. I haven't
> > started any of the post processing or data collection scripts yet and
> > some of that can be used from our other kits. My Java programming
> > style
> > should probably be reviewed too. ;)
>
> I had a very (very) quick look at your code, one suggestion would be
> log4j, (or other configurable logging API ) for your debugging
> statements.
Ok, I'll have to learn how to do that. :)
> If I have some time, I'll look at it some more, I've come to like
> using the spring framework. This allows something referred to as IOC
> (Inversion of Control) Basically, the problem is how to stub test
> code in when we have static factory objects, the solution is to build
> the application using a container which specifies the concrete
> classes which are instantiated. This would in theory allow us to have
> tow versions. One which uses hibernate, and the other which uses
> EJB's. So one thing to think about is to code in interfaces more, and
> instantiate concrete classes which implement the interface.
That sounds like a very good idea. I'll probably need some coaching
though...
Mark