Peter Michael wrote:
> > 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 did give an example (although it was very short). I quote myself:
"But then your interface could look something like:
public void doSomething(MyBean myCallBack)
i.e. no return values, but the bean could send results to MyBean through
the given callback."
Which is similar to what you did. If the invocation of the bean was done
asynchronously (using a wrapper over JMS, or similar) it would produce
the same result, and with no changes to the current spec.
> > 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!
Ok, fair enough. You could have a session bean that has a method:
public void cancel(BeanPK pk);
which sets a flag in a database that the EntityBean invocation of id
"pk" has been cancelled. isCancelled() in this EntityBean can use then
check the db and see whether it has been cancelled or not.
> > 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).
Ok, I understand. Much better then, that I can agree with. And it can be
implemented as outlined above.
> 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.
You can do this by simply registering a RMI-object in the
JNDI-namespace, which is the common way today to do this if you
absolutely need state that is singleton-ish. If there is no state, then
a Stateless SessionBean works as well. A Stateless SessionBean that
stores the singleton state in a db would work too.
> > > 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.
That was not very informative. What would you do with the information?
Since it only says which instances that happen to be alive at the very
moment of the call (the next microsecond it might have changed) it
doesn't provide very usual information IMO.
> 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 can catch this with my design; catch (Throwable) works pretty well.
> 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.
Ok.
> > 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.
The APM takes care of many loose ends in this regard. Yes, I have
considered starting such as FAQ (basically a compilation of the postings
at E-I would be useful), but haven't found the time just yet.
> > 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.
Oh definitely, and I agree. The point is just what belongs in the EJB
spec, and what should be put in other specs. Check the JSR list, there
are a ton of related specs that cover many of your wishes.
> 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? ;)
If someone made a asynch call library that worked on top of JMS and EJB,
it would be portable and not any different from any other library you
would use in your app. I would be surprised if any larger apps do not
have any libraries included besides the raw beans.
That said, I understand your point.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
