You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by "Fernandez Martinez, Alejandro" <a....@ibermatica.com> on 2002/02/01 11:40:21 UTC
RE: [OT] J2EE considered harmful
I do not agree with that. More robust how?
If you want to signal that something can go wrong on the remote side, throw
an exception; if you want to signal that the remote connection does not
work, then delay the call and/or send a runtime exception.
Otherwise, what is the purpose of AltRMI? I thought it was to avoid the
cumbersomeness of throwing RemoteException all the time.
Un saludo,
Alex.
> -----Mensaje original-----
> De: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> I think that the key bit is:
> > and it is a mistake to try to program
> > as though a
> > remote call had the same characteristics as a local one.
>
> Your app will always be more robust if you do NOT ignore the
> specific issues of a remote call.
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Fernandez Martinez, Alejandro
> > [mailto:a.fernandez.martinez@ibermatica.com]
> > Sent: Thursday, January 31, 2002 1:50 PM
> > To: 'Jakarta General List'
> > Subject: [OT] RE: J2EE considered harmful
> >
> >
> > Hi Tim.
> >
> > I agree with your point of view, we've been trying to avoid EJBs
> > as much as
> > possible. But there's one thing I don't understand.
> >
> > > -----Mensaje original-----
> > > De: Tim Hyde [mailto:timovdh@csi.com]
> > > Yes, EJB is a complete bodge of a design, and RPC invocation
> > > techniques
> > > would only be acceptable if they were completely transparent,
> > > instead of
> > > requiring you to do so much plumbing yourself. But
> > > personally, I think RPC
> > > is entirely overrated, and it is a mistake to try to program
> > > as though a
> > > remote call had the same characteristics as a local one.
> >
> > Why is it a mistake? I think a remote proxy is a great way
> to make remote
> > calls, shielding the developer from the complexity of it
> all. The recent
> > discussion about AltRMI has shown that there's a lot of
> interest in using
> > proxies, but it was Sun's implementation (the Remote*
> stuff) that was
> > flawed.
> >
> > Un saludo,
> >
> > Alex.
> >
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] J2EE considered harmful
Posted by "Andrew C. Oliver" <ac...@apache.org>.
On Fri, 2002-02-01 at 06:44, Paul Hammant wrote:
> Alex,
>
> My experience is that people either immediately decide they like AltRMI
> or strongly dislike it. One of my strongest critics (in commons mail
> list) is coming round to it after much effort :-)
>
> For many it is inline with something they have felt for ages : Remote
> interface and RemoteException suck. Many other are quite happy with RMI
> as is and always have been.
>
> AltRMI is really about remote publishing an object via it's normal Java
> interfaces. It also has local publishing capabilities for complex
> classloader situations.
>
> >I do not agree with that. More robust how?
> >
> You can set retry policies. In the middle of a method invocation and
> unknown to the caller, the connection can be reestablished. It is a
> programmable API in that the developer can choose between the two
> extremes "never retry, log & fail imediately" and "retry eternally".
>
> >If you want to signal that something can go wrong on the remote side, throw
> >an exception; if you want to signal that the remote connection does not
> >work, then delay the call and/or send a runtime exception.
> >
> Or a derivative (AltrmiInvocationException). You can catch it or not.
> In the case of 'not' I'd hope the container/handler knows what to do
> with it .
>
> >Otherwise, what is the purpose of AltRMI? I thought it was to avoid the
> >cumbersomeness of throwing RemoteException all the time.
> >
> It is.
>
> I've started a project "Enterprise Object Broker" at Sourceforge to try
> out the use of AltRMI. -> http://eob.sourceforge.net/
> It is Apache license, and if it is any good and has built a community, I
> think Jakarta would be its natural home.
>
+1 You rule. This looks awesome! One question (perhaps if its detailed
I should move it to the eob mailing list if there is one already): how
would you load balance this? If I had several remote servers, I'd need
to load balance it for scalability concerns, how would I go about it?
Thanks,
Andy
> - Paul H
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AltRMI chat (was: [OT] J2EE considered harmful)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Moving this to the Commons. Please reply only in the commons-dev list.
Sorry Paul, I meant AspectJ.
I do not understand the incompatibility between Dynamic proxies and
BeanShell. What is it.
Did you try pnuts? I already found a documented way to run a pnuts
compiled class, although it demands the presence of some Runtime
support classes.
Anyway, with pnuts you can generate/compile code in memory.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Friday, February 01, 2002 3:33 PM
> To: Jakarta General List
> Subject: Re: [OT] J2EE considered harmful
>
>
> Paulo,
>
> >Paul just answered to what I meant in a better way than I would be able
> >to do.
> >
> >BTW Paul, you know JAspect and Dynamic Proxies don't you?
> >
>
> Yes, BUT : I am not skilled enough in Jaspect, AspectJ, BCEL, JCFE to
> able able to use them for AltRMI's proxy generation. I know *exactly*
> what I need to do in Java so have ripped (with attribution) Jaspers
> compiler invoker and placed it in the tree for AltRMI, then written Java
> source to a temp dir. This can be done in advance (like rmic) or at
> runtime on the server for truly dynamic opration.
>
> Refelctions Dynamic proxys were not quite good enough for AltRMI either.
> Reason - I love beanshell and use it to poke interfaces for testing. An
> example I always cite is for JAMES :
>
> bsh> jamesAdmin = getAltRMIObject("james.host",8999,"JamesAdmin");
> bsh> fred = jamesAdmin.addUser("Fred Flintstone");
> bsh> jamesAdmin.enableUser(fred);
>
> All that is possible (given the JAMES API) with beanshell / AltRMI now
> without and James classes pre-existing in beanshell's classpath. The
> thing that makes it so much easier to use is that the arriving
> jamesAdmin instance supports getMethods() in the nromal way which is
> very beanshell friendly.
>
> - Paul
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AltRMI chat (was: [OT] J2EE considered harmful)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Moving this to the Commons. Please reply only in the commons-dev list.
Sorry Paul, I meant AspectJ.
I do not understand the incompatibility between Dynamic proxies and
BeanShell. What is it.
Did you try pnuts? I already found a documented way to run a pnuts
compiled class, although it demands the presence of some Runtime
support classes.
Anyway, with pnuts you can generate/compile code in memory.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Friday, February 01, 2002 3:33 PM
> To: Jakarta General List
> Subject: Re: [OT] J2EE considered harmful
>
>
> Paulo,
>
> >Paul just answered to what I meant in a better way than I would be able
> >to do.
> >
> >BTW Paul, you know JAspect and Dynamic Proxies don't you?
> >
>
> Yes, BUT : I am not skilled enough in Jaspect, AspectJ, BCEL, JCFE to
> able able to use them for AltRMI's proxy generation. I know *exactly*
> what I need to do in Java so have ripped (with attribution) Jaspers
> compiler invoker and placed it in the tree for AltRMI, then written Java
> source to a temp dir. This can be done in advance (like rmic) or at
> runtime on the server for truly dynamic opration.
>
> Refelctions Dynamic proxys were not quite good enough for AltRMI either.
> Reason - I love beanshell and use it to poke interfaces for testing. An
> example I always cite is for JAMES :
>
> bsh> jamesAdmin = getAltRMIObject("james.host",8999,"JamesAdmin");
> bsh> fred = jamesAdmin.addUser("Fred Flintstone");
> bsh> jamesAdmin.enableUser(fred);
>
> All that is possible (given the JAMES API) with beanshell / AltRMI now
> without and James classes pre-existing in beanshell's classpath. The
> thing that makes it so much easier to use is that the arriving
> jamesAdmin instance supports getMethods() in the nromal way which is
> very beanshell friendly.
>
> - Paul
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] J2EE considered harmful
Posted by Paul Hammant <Pa...@yahoo.com>.
Paulo,
>Paul just answered to what I meant in a better way than I would be able
>to do.
>
>BTW Paul, you know JAspect and Dynamic Proxies don't you?
>
Yes, BUT : I am not skilled enough in Jaspect, AspectJ, BCEL, JCFE to
able able to use them for AltRMI's proxy generation. I know *exactly*
what I need to do in Java so have ripped (with attribution) Jaspers
compiler invoker and placed it in the tree for AltRMI, then written Java
source to a temp dir. This can be done in advance (like rmic) or at
runtime on the server for truly dynamic opration.
Refelctions Dynamic proxys were not quite good enough for AltRMI either.
Reason - I love beanshell and use it to poke interfaces for testing. An
example I always cite is for JAMES :
bsh> jamesAdmin = getAltRMIObject("james.host",8999,"JamesAdmin");
bsh> fred = jamesAdmin.addUser("Fred Flintstone");
bsh> jamesAdmin.enableUser(fred);
All that is possible (given the JAMES API) with beanshell / AltRMI now
without and James classes pre-existing in beanshell's classpath. The
thing that makes it so much easier to use is that the arriving
jamesAdmin instance supports getMethods() in the nromal way which is
very beanshell friendly.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [OT] J2EE considered harmful
Posted by Paulo Gaspar <pa...@krankikom.de>.
Paul just answered to what I meant in a better way than I would be able
to do.
BTW Paul, you know JAspect and Dynamic Proxies don't you?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Friday, February 01, 2002 12:44 PM
> To: Jakarta General List
> Subject: Re: [OT] J2EE considered harmful
>
>
> Alex,
>
> My experience is that people either immediately decide they like AltRMI
> or strongly dislike it. One of my strongest critics (in commons mail
> list) is coming round to it after much effort :-)
>
> For many it is inline with something they have felt for ages : Remote
> interface and RemoteException suck. Many other are quite happy with RMI
> as is and always have been.
>
> AltRMI is really about remote publishing an object via it's normal Java
> interfaces. It also has local publishing capabilities for complex
> classloader situations.
>
> >I do not agree with that. More robust how?
> >
> You can set retry policies. In the middle of a method invocation and
> unknown to the caller, the connection can be reestablished. It is a
> programmable API in that the developer can choose between the two
> extremes "never retry, log & fail imediately" and "retry eternally".
>
> >If you want to signal that something can go wrong on the remote
> side, throw
> >an exception; if you want to signal that the remote connection does not
> >work, then delay the call and/or send a runtime exception.
> >
> Or a derivative (AltrmiInvocationException). You can catch it or not.
> In the case of 'not' I'd hope the container/handler knows what to do
> with it .
>
> >Otherwise, what is the purpose of AltRMI? I thought it was to avoid the
> >cumbersomeness of throwing RemoteException all the time.
> >
> It is.
>
> I've started a project "Enterprise Object Broker" at Sourceforge to try
> out the use of AltRMI. -> http://eob.sourceforge.net/
> It is Apache license, and if it is any good and has built a community, I
> think Jakarta would be its natural home.
>
> - Paul H
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] J2EE considered harmful
Posted by Paul Hammant <Pa...@yahoo.com>.
Alex,
My experience is that people either immediately decide they like AltRMI
or strongly dislike it. One of my strongest critics (in commons mail
list) is coming round to it after much effort :-)
For many it is inline with something they have felt for ages : Remote
interface and RemoteException suck. Many other are quite happy with RMI
as is and always have been.
AltRMI is really about remote publishing an object via it's normal Java
interfaces. It also has local publishing capabilities for complex
classloader situations.
>I do not agree with that. More robust how?
>
You can set retry policies. In the middle of a method invocation and
unknown to the caller, the connection can be reestablished. It is a
programmable API in that the developer can choose between the two
extremes "never retry, log & fail imediately" and "retry eternally".
>If you want to signal that something can go wrong on the remote side, throw
>an exception; if you want to signal that the remote connection does not
>work, then delay the call and/or send a runtime exception.
>
Or a derivative (AltrmiInvocationException). You can catch it or not.
In the case of 'not' I'd hope the container/handler knows what to do
with it .
>Otherwise, what is the purpose of AltRMI? I thought it was to avoid the
>cumbersomeness of throwing RemoteException all the time.
>
It is.
I've started a project "Enterprise Object Broker" at Sourceforge to try
out the use of AltRMI. -> http://eob.sourceforge.net/
It is Apache license, and if it is any good and has built a community, I
think Jakarta would be its natural home.
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>