s communication in error, please notify
> the sender by reply email and permanently delete all copies of the email
> and its contents and attachments.
>
> On Fri, Sep 11, 2015 at 12:38 PM, Palash Ray wrote:
>
>> Hi,
>>
>> I have a Jini server, and I am doin
Hi,
I have a Jini server, and I am doing a lookup from a Jini registry and
then making a call on the remote.
The client code is:
LookupLocator lookupLocator = new LookupLocator(jiniRegistryUrl);
return (Remote) lookupLocator.getRegistrar().lookup(new
ServiceTemplate(null,
May I suggest that we should name com.sun.jini to
org.apache.river.internal? I agree that com.sun.* meant to be internal and
discouraged for public use.
Thanks,
Palash.
On Tue, Sep 1, 2015 at 6:33 AM, Bryan Thompson wrote:
> Dennis, can you comment on how much pain (and what steps) were involve
11, 2015 at 11:29 PM, Palash Ray wrote:
> 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){
>
>
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
ust
> write a smart proxy that converts the IOExceptions to some runtime
> exception (you could probably even do this generically using
> “java.lang.reflect.Proxy”), and register the smart proxy with Reggie rather
> than the actual exported endpoint.
>
> Cheers,
>
> Greg Trasuk
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
). The workers take as fast at they're able
> to do work, but no faster, so they don't get overloaded. You can bring
> workers up, and shut them down, with zero reconfiguration.
>
> Cheers,
> Simon
>
>
> On Tue, Jun 2, 2015 at 8:13 PM, Palash Ray wrote:
>
>
ply round robin across them. You might want to start looking at the
> ServiceDiscoveryManager and the LookupCache for this.
>
> HTH
>
> Dennis
>
>
> On Tue, Jun 2, 2015 at 9:16 PM, Palash Ray wrote:
>
> > Excellent. May be we can help each other here.
> >
&
ash:
>>
>> Could you expand on your need for a “clustered Jini server”? What
>> features are you looking for, and what aspects of the application need to
>> be clustered? This might provide fertile grounds for development.
>>
>> Cheers,
>>
>> Greg
Hi Greg, Patricia,
Really happy to see:
https://github.com/trasukg/river-container
I think we are off in the right direction. I have been using river for
almost 2 years now, but only recently started taking an interest in
the code that makes it tick.
Our organisation is facing some scalability i
Hi Devs,
We use lot of Jini as our middleware platform across various applications
in our organisations.
I see that there has been no activity for the last couple of years. To
spurt interest in this wonderful, and powerful project, we can actually
mirror it on github like Apache JMeter has done.
Hi,
Jini is a RMI based server and a lot more than that. It is used to build
high-end middlewares. Though it is a bit obsolete and no one uses this as
frequently these days, it is still used in many Banks as their preferred
middleware.
We use Jini based servers as our middleware platform for a co
13 matches
Mail list logo
