Bryan,
Bryan Field-Elliot wrote:
> Thank you Dan --
>
> As I emailed at around midnight last night, I have everything taken
> care of, using Jason Pringle's pattern. It's probably very similar to
> the Business Delegate pattern you describe (which I will read today).
This is why they call it a
Bill --
I think the important design point to make, is that you want your
business logic (including rules of behavior, state machine, etc) to be
encapsulated within the EJB tier. This makes for tidier code and a more
elegant design, and also makes your code more client-neutral. One of the
sce
Thank you Dan --
As I emailed at around midnight last night, I have everything taken care
of, using Jason Pringle's pattern. It's probably very similar to the Business
Delegate pattern you describe (which I will read today). Basically I implemented
a handler class for the Stateful Session Bean, wh
All,
Sorry to jump in late on this.
Am not monitoring this list real consistently at the moment, but it was brought
to my attention that there were some business tier coupling and EJB issues being
discussed, so I thought I'd make a few quick comments.
Looking back over the thread, there is a ment
Brian,
Disclaimer: I'm new to EJB and still trying to understand when to use
stateful/stateless session beans.
Given that, I found your situation interesting. First I'll try to help you
if I can. There is an article in the February 2001 WebSphere Advisor by Tony
Higham, on page 10, titled "The R
I implemented your solution -- xxxHandler.java for
my stateful session bean, and a new interface which the bean, remote interface,
and handler all implement (or extend). Also added EJB creation, and method
pass-through (with syncronization) to the handler class. Lastly, changed
all my Struts code t
Good grief -- what a twistly little maze of passages,
all alike (or was that, a maze of twisty little passages, all alike?) Thanks
for laying out those extra thoughts. I think you're right that the GP approach
puts too much of a burden on the client to use it correctly. I still maintain
that a REAL
ther ways to do this.
--jason
-Original Message-
From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 11:33 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a
problem.
Thanks,
That proposal would pr
Now that I think about it, perhaps a solution to this would be a great
general-purpose configuration feature for Struts. On a
per-web-application level (e.g. in struts-config.xml), there might be an
option such as:
syncronize_requests = x
where x might be:
none - the default -- the c
AIL PROTECTED]]
Sent: Thursday, April 05, 2001 11:07 AM
To: [EMAIL PROTECTED]
Subject: RE: Frames, concurrency, and EJB Stateful Session beans - a
problem.
Hi Bryan,
Can you put the stateful session bean within a JavaBean with
synchronized
methods so that all access to the stateful sessio
Thanks,
That proposal would probably work, but it might be a little
over-complicated (although I am starting to suspect that every solution
is going to be yucky). I think I couldn't do your idea with just a
simple bean with a simple syncronized getter method; instead, the
wrapper bean would h
Hi Bryan,
Can you put the stateful session bean within a JavaBean with synchronized
methods so that all access to the stateful session bean is through the
JavaBean?
--Abraham
> -Original Message-
> From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2
12 matches
Mail list logo