Peter Michael wrote:
> Ok. Let's asume you have a bean that renders applies a filter to an image.
> You
> want to return parts the parts of the image that you already filtered. If
> will also
> include how is should behave if the call was canceled.
>
> /* 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?
> > 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.
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).
> > 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.
> 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?
> I think code generation cool, but what if you want to alter the code
> once it has been generated (maybe in the next version of your app).
> Then you would have to go through your app and change everything by
> hand. Now take the above 50 EJBs. That would require a lot of time.
> Apart from that, what you propagate here is code duplication, which
> IMHO is never a good thing. Hard to maintain and error prone. I a
> large development team there is always someone who changes the
> generated code and all of a sudden strange effects happen. I would
> be much more comfortable if there were one place where this
> stuff is handled. If you want to use code generation a better way
> would be aspect programming. See http://www.aspectj.org
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.
> 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.
> How would you simulate this across multiple examples. Could you give
> an example? What do you mean by 'use RMI object'. You are not allowed
> to use RMI from within an EJB due to the following restriction:
>
> An enterprise bean must not attempt to listen on a socket, accept
> connections on a socket, or use a socket for multicast.
> (EJB 1.1 Spec 18.1.2)
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.
> > The requirements are definitely real-world, no argument there, but I
> > don't agree that your proposals make sense in the EJB spec.
> > All of them
> > can easily be put on top.
>
> If I start to build frameworks on top of EJB/J2EE on top, why would I use
> EJB/J2EE in the first place? I could start writing my own spec and build my
> own container, but that's not something I want to do. I want EJB and J2EE to
> deliver me the functionality that I need to write advanced enterprise
> applications.
> Just give us users the technology and let us decide what we need.
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.
Which is largely a matter of opinion, and I don't think any of the
things we have discussed now belong in the EJB-spec. IMHO etc.
> > The key question is whether any of your changes require the contract
> > between the container and the bean to be changed. I don't
> > think it have
> > to do this for most of your suggestions.
>
> Again, I beg to differ. If it makes the life of hundreds of developers
> easier:
> Put it in the spec. Why are there collection classes in Java? Every one of
> us
> could make his own. But they really improve the productivity, that's why
> they
> are there. The same thing is true for the EJB spec. The Spec is not
> something
> puristic that should just contain the bare-bone essentials, but build a
> *broad*
> foundation to craft our applications upon. Hey, EJB has been invented so we
> can
> concentrate on business logic, not frameworks!
I have (of course :-) a differing view: the Collections classes in Java
was introduced because they are often used in the interface between
different packages/API's/specs. Because of this one needs a good set of
standard interfaces, which is what the Collections API provides. The
implementations available in the Collections API could be seen as a kind
of reference implementation, and yes it is useful, but not the main
reason for including Collections into the core API: the main reason is
for its value as interface glue. IMHO of course.
Productivity improvers, such as my own CodeGenerator, or Together/J, or
XML4J are best created by commercial vendors (or OpenSoftware processes
and similar).
/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".
