> >
> > /* ATN: Simplified code */
> > public void filterImage( ImageClass image, FilterClass
> filter, AsyncCallback
> > callback ) {
> >
> > [Set up your filter and your image]
> >
> > for( int part = 0 ; part < maxParts ; part++ ) {
> >
> > // if the call was cancled, return.
> > if( isCanceled() ) {
> > return;
> > }
> >
> > // filter part of the image and get filtered part
> > ImageClass partialResult =
> > someInternalFilterMethod( image, filter,
> > (image.getHeight)/samevalue)*part );
> >
> > // Send the filtered part of the back
> > // The boolean value in the call tells the client
> that there is more
> > to come
> > callback.sendResult( partialImage, ( part ==
> maxParts -1 ) ? false :
> > true );
> > }
> > }
>
> This looks similar to what I proposed. What's the difference?
Sorry, but I don't understand your point here. Where did you
propose something? You always repeat that the spec doesn't
have to be changed to do what I want to do. You never give
any examples! How can I possibly give a callback to an EJB
using only current 1.1 features and make async callbacks?
>
> > > I don't see why you need to change the spec to do this. It seems
> >
> > Sorry? I really don't understand how. I don't think it is
> possible to
> > interrupt a ejb call once it's running. How can I unblock
> my thread in the
> > client? How can I implement different priorities without
> additions to
> > EJB? Please give me an example implementation that is able
> to do this.
>
> What I meant was that the isCancelled call (which is made by the bean)
> can be implemented without changes to the current EJB spec.
How? You are always giving suggestions but you never deliver solutions!
>
> I don't think it's a good idea at all to be able to interrupt an EJB
> call bluntly, as it will in most cases result in unpredictable results
> (depending on where the call was aborted).
If you looked at the above code and read my previous posts, you would
have noticed that I propose that cancelling a call should the way you
interrupt a thread in Java, cooperative that is. That way your code
can determine, where and whether it is appropriate to cancel it (by
returning from the call).
>
> > > I would imeplement the above with a stateless session
> bean. Why would
> > > you want a singleton EJB to do this instead of a Stateless SB?
> >
> > Because your beans may reside in different containers on
> different JVMs
> > and maybe even different application servers!
>
> The only difference between a Stateless SessionBean and a
> Singleton EJB
> that I can think, at least without a formal definition of the
> latter, is
> that it has state that is consistent applicationwide, i.e. in
> a cluster
> there should only be one object that implements this. For some of the
> functionalities you mentioned I do not see the need for
> state, and some
> of the uses you mentioned can be implemented with stateless session
> beans which use a backing db (common to all machines in a cluster for
> example) that keeps the singleton state.
I just don't like to take a detour when there is direct way. Singletons
are a very common design patterns nowadays, there are many uses. I
want to have defined way to have a unique named object in my application
and between different applications. I don't need a crutch I need the
real thing.
>
> > But I should be able to get a list of running instances, don't I?
>
> But this wont give you any interesting information in most cases. Can
> you give me an example of uses of this?
Application Management. I would prefer an container management API, though.
> You're assuming that I do naive code generation, whereas the
> most likely
> way to do this, in order to avoid code duplication, is to collect the
> executing code in a class that is delegated to. See Dynamic Proxies in
> JDK1.3 for an example of how this would work. All problems that you
> outline above would go away.
Good point. Still I also would like to be able to group my EBJs together
and assign error-handlers for things that you cannot catch with your
concept (like low-memory conditions, fatal errors,... ).
>
> > I would like to group EJBs in my application descriptor.
> Group together
> > some EJBs and specify an error handler or error handling
> EJB. Would be
> > a nice and flexible solution. When I say client I don't
> have servlets in
> > mind, but Java clients, different components within your
> application and
> > maybe even components in different applications.
>
> It is not always possible to have callbacks to clients, even
> if they are
> Java clients. And it is not always possible to define "live
> client" even
> if is a Java application or applet.
>
I think you missunderstood me here. The error handling would take place
inside of the container. The handler then can send messages by JMS to
inform clients and other applications.
>
> An EnterpriseBean may not do this, but it may create an RMI
> object that
> uses the underlying RMI framework to do this. No problemo
> there. See the
> thread in the archives on bean restrictions for full
> explanation of why
> this will work.
This is just one of the things that I really hate about the
EJB spec. There is so much unsaid. There should at least
be an faq where issues like this are clarified. Can't
some start this? I'm still not very comfortable with using
(synchronous) RMI.
> This reminds me of CORBA-thinking: put everything in the spec, because
> someone may at some point need it in their application. The discussion
> is whether this should go into the EJB-spec, or if it should go into
> another spec, or if it is just a good idea for a tool that uses spec
> implementations.
Your thinking reminds me a lot of a story I heard about Andrew S. Tanenbaum
and Minix (I hope I get this together correctly): Tanenbaum wrote Minix,
a free unix clone, to teach his students about operating systems. It
contained
no debugger, so a student asked him to write a debugger to make developing
easier. Tanenbaum replied: "Why do you need a debugger? You have printf."
Why do make this all these suggestions to the spec? It's not that I could
not
come up with a workaround myself and I think your "keep the spec pure and
simple"
position is ok as long as you develop in a small team. But once you start
builing large applications in large teams, you want to have things in the
spec.
If it's not in the spec, people will come up with their own workarounds and
if
there are 100 people, you get 100 different workarounds, everyone behaving a
little
different and some of them will not be great at all. This is the least thing
you
want. I hope you unterstand my position.
> Productivity improvers, such as my own CodeGenerator, or
> Together/J, or
> XML4J are best created by commercial vendors (or OpenSoftware
> processes
> and similar).
If a vendor would add async calls to his application server that add-on
would
be *proprietary*, non-portable and hence a bad idea! Do we want proprietary
extensions? Nooooooooo. Write once, run everywhere? Ever heard that
expression? ;)
Bye,
Michael
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
