One of the primary things in software design is to place services into a
service layer. There should be service failure exceptions and those should be
distinctly different from “transport” or “implementation” exceptions. If your
code has “RemoteException” visible in the business logic, then yo
Just a comment on the complexity of Jini services. I agree that starting up
Jini services using the ServiceStarter is overly complex and arcane, which is
why other service frameworks like Rio, StartNow, and river-service-container
exist.
I’m hoping the river-examples project makes things a li
On 12/06/2015 05:34, Palash Ray wrote:
> In my 2 years of using Jini, one feedback that I have as a developer is its
> overtly complex. For instance, if I want to configure security, its so
> complex, that I have to spend days together to get it up.
>
> I strongly believe that we should try to make
My two cents:
I am in favour of having runtime exception. We are facing a huge problem as
our code base is too cluttered with this kind of code:
try{
remoteProxy.callRemoteMethod();
} catch (RemoteException e){
throw new RuntimeException(e);
}
Instead of that, I would like not to have to catc
My two cents:
I am in favour of having runtime exception. We are facing a huge problem as
our code base is too cluttered with this kind of code:
try{
remoteProxy.callRemoteMethod();
} catch (RemoteException e){
}
On Thu, Jun 11, 2015 at 10:52 AM, Dawid Loubser
wrote:
> On 11/06/2015 16:24, Gr
On 11/06/2015 16:24, Greg Trasuk wrote:
>> * It's perfectly fine to still enforce service implementations to
>>declare RemoteException, as a "tag" / "reminder", but honestly, it's
>>not the client's concern. Depending on the reliability requirements
>>of the client, they need to handle
Hi David:
Discussion below…
Cheers,
Greg Trasuk.
> On Jun 11, 2015, at 4:45 AM, Dawid Loubser wrote:
>
> I agree wholeheartedly with Palash Ray. The problem with this principle
> of "RemoteException" in River, which I have never agreed with, is twofold:
>
> * The most common and correct int
I agree wholeheartedly with Palash Ray. The problem with this principle
of "RemoteException" in River, which I have never agreed with, is twofold:
* The most common and correct interpretation of checked / unchecked
exceptions in Java, seen in the light of design-by-contract, is
o Unche
Thanks a lot Gregg. This is certainly an interesting idea worth exploring.
I will let you know how it goes.
Thanks,
Palash.
On Tue, Jun 9, 2015 at 8:45 AM, Greg Trasuk wrote:
>
> If you’re making remote calls, then there is a definite chance that you
> will have communications errors. So, it’s
If you’re making remote calls, then there is a definite chance that you will
have communications errors. So, it’s probably not a good idea to just hide the
errors, especially since the application handling/response to a communications
error really should be different from the handling of an ap
Devs,
I have long struggled with the fact that we have to declare a
RemoteException for every Remote method that I expose. I do not like
the try catch, which is pretty verbose, and in our application, when
we do encounter a RemoteExceotion, its always fatal, and there is no
way we can, or want, to
11 matches
Mail list logo
