Nabble - Sun - Jini-Users

Re: Jini Starter Kit installer can't find JVM

2009-08-19T23:51:11Z

Hi,

I am facing the same problem, the Jini Starter Kit v2.1 can't find the JVM in Windows Vista with JDK 6 update 10 installed. Please reply if anyone has any ideas as what to do.

Thanks
Ayesha

Dan Creswell-3 wrote:

Hello,

What JVM (vendor and version) do you have installed?

Dan.

PennyLane wrote:
> Hi,
>
> I have a problem installing the Jini Starter Kit (version 2.1) under Windows
> Vista. It just won't find my JVM and thus the installation cannot be
> completed successfully. Does anyone have an idea what I could do?
>
> Thx,
> PennyLane
> --
> View this message in context: http://www.nabble.com/Jini-Starter-Kit-installer-can%27t-find-JVM-tf3764876.html#a10642766
> Sent from the Sun - Jini-Users mailing list archive at Nabble.com.
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@java.sun.com
>

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@java.sun.com

registrar.lookup <-> out.writeObject() vs registrar.lookup<->out.writebyte => OptionalDataException

2009-07-01T06:44:59Z

Hi,
Till now I can have a server java app that writes a serializable (proxy) class to
a socket using writeObject() and a client app getting that serializable object
using an http server for . class and registrar.lookup to get the serializable
proxy object and even can invoke methods on that object after reconstruction.

So, the pair: registrar.lookup <-> out.writeObject() works fine!

Now, i would like to replace the server side code: out.writeObject() by writing
it object to a file first and then read the file byte by byte and send those
bytes through the socket. Client must be able to reconstruct object using registrar.lookup as usually.

When I try this second approach client fires the OptionalDataException
exception in java.io.ObjectInputStream.readObject0(). I cant find out why.

Please, could you help me on this?

Thanks a lot

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Reggie

2009-06-30T04:34:23Z

Could be, don't really know. I don't have the abillity to test this out, but we now have more surveillance of the jvm status of the webapps and making manual restarts when memory becomes too close to max. After this we haven't had any issues at all.

It seamed like reggie ran out of thread's trying to notify (don't know how many it used), and this caused a big queue of jobs and in that q there where other jobs that would timeout as well witch led to new services wouldn't get the serviceId and stuff like that.

/Per

On Fri, Jun 26, 2009 at 2:39 PM, Gregg Wonderly <gregg@...> wrote:

On Jun 26, 2009, at 3:29 AM, Per Edlund wrote:
As it seams, this issue is related to client machines. If a client machine get's memoty issues, and reggie is trying to notify the client (which uses a servicechache listening on all service events), reggie chokes when the client can't reply to reggie.

Could this also be an issue for clients with firewalls up which can't accept connections for the notifications, and the notification connections timeout? I've seen some strange things from time to time on more restricted networks and not really been able to pinpoint the issues. Many times, it seems like discovery degenerates into a really slow and painful process. An outbound call, initiating a TCP connection which must timeout before anything can be done to eliminate the call context, can be quite long lived, on the order of minutes. I wonder if this would cause other discovery/notification to be delayed and thus build up more held context in the reggie JVM and elsewhere.

Gregg Wonderly

Fixiing the memory issues on the client get's rid of the behaviour on reggie

Just thouth I should tell

Cheers
/Per

On Wed, May 27, 2009 at 3:47 PM, Juan Ramirez <Juan.Ramirez@...> wrote:

Hi, Peter. Reggie does queue up discovery requests and event notifications and services these with threads from the same pool. It is possible that there is a large number of event notifications to be delivered to the LookupCache instances thus delaying the processing of discovery requests. You could set Reggie's logging level to FINEST to see what Reggie is doing at the time it appears to "choke". There is additional info on this scenario in the following CRs.

https://issues.apache.org/jira/browse/RIVER-52
https://issues.apache.org/jira/browse/RIVER-197

Hope this helps,

Juan

On 05/27/09 07:17, Per Edlund wrote:

Hi!

We'ev been using Jini for quite som time now but havn't upgraded after the 2.1 release. We're currently experiencing some issues with reggie choking the machine and we can't really tell why. The number of jiniservices we have is around 60 (these are client's as well, and on top of this we have webservers which are clients (around 100-200)) , we use the LookupCache etc, but efery now and then we have to restart the VM running reggie. Doing a discovery during this time get's no lookup, and services can't be found.

If we look at how services register/unregister, that seam to take an aweful long time when reggie is starting to choke, and out theory is that reggie uses some kind of queue which grows more than it can be processed.

Does any one have an idea on how to dig into this?

Env: Linux Debian, Sun Java 1.5&1.6

Kind regards
/Per
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

--
********************************************
Per Edlund
www.bozoka.com
per@...
+46(0)8 545 068 05
+46(0)703 71 70 02
********************************************
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

--
********************************************

Per Edlund Bozoka.com, per@...
Web: www.bozoka.com
Office: +46(0)8 545 068 05
Mobile:+46(0)703 71 70 02
Address:
Tegnérgatan 28, 2tr
113 59 Stockholm
Sweden
********************************************
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Project of patterns

2009-06-29T14:14:45Z

Will work for $69 per hour in California, and NYC, USA on W2. Austin $45, Rest of USA 60

Applying for any new positions that you may have! My resumes are online http://www.gecpvt.com/IpResume55.docx, http://www.gecpvt.com/IpResume55.docx. I am now in Del Valle (Near Austin), Texas, USA. I am a US Citizen.

I have 20 Years of professional experience with MSEE degreee with in depth Software, Hardware, and managerial Skills.

Will work for $40 per hour. I will relocate within USA, for other places please contact me first. I am a US Citizen. I also have work permit for India
and can get work permit for Australia.

Software, FPGA, VLSI, ASIC, DFT, RFIC, Databases, Internet,Networks, TCPIP, Embedded, Firmware, Bios, SS7, and many more ......
Please do not apply on my behalf for any position without contacting me.

To save Computer disk space, performance, and network bandwidth, I placed my resume files to

Resumes are at

http://www.gecpvt.com/IpResume55.docx
http://www.gecpvt.com/IpResume55.ppdf
http://www.gecpvt.com/IpResume56.docx (Management and India and USA).

All my 72 patents soft copies are at
http://www.gecpvt.com/future_patents/filed

I am hoping you can help me find another position!. I am qualified for lot of positions.

I put usual detail below.

Austin, Texas 45 an hour on w2

Resume is at

http://www.gecpvt.com/IpResume56.docx

San Antonio, Temple, Waco, texas 50 an hour on w2
Texas 55 an hour on w2.

California 72 an hour on w2.
NYC 78 an hour on w2.

Every where else. 66 an hour w2.

I have strong Communications, Electronics, Electrical, Software, DBMS, VLDB, SQL, Database,

Firmware,BIOS, embedded, ASIC, DFT, Allegro, VHDL, Verilog, Cadence, and AutoMobile. Heat Transfer, EMI,High End Electronics Manufacturing Management, Process Control, and Mechanical background with lot of management expeience also.I have 72 patents files and one granted and 4 of therm about to begranted and many trade secrest also.

http://www.gecpvt.com/IpResume56.docx.

I have MSEE and 2 year phd in Computer Science and Engineering.

I am gong to become automobile engineer also. Just not to sit around, I am working towards Auto ASE cetrificed Master Mechanic and I am fullyback into Electronic CAD, CAM. I am fully learning Mechanical, Cvilland Architectural CAD also.

I will be doing BIOSInstrumentation, Industrial Controls, Robotics,Semiconductor Manufacturing equipment process and software,PhotoVoltiaics, DSP, Medical Imaging, and Wind, Solar & alternatepower and machines.

I am very talented and I am very accomplished.

*************
My resume copies are at

http://www.gecpvt.com/IpResume55.pdf
http://www.gecpvt.com/IpResume55.docx
http://www.gecpvt.com/IppResume56.docx <<<<<<<<<<< latest for People and Project management.

Phone numbers are

408-329-7307,212-203-0684,512-524-3905. (CELL) 512-773-8922

srinivas

************
This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.

> Date: Wed, 24 Oct 2007 13:28:05 -0600
> From: jddahl@...
> Subject: Project of patterns
> To: JINI-USERS@...
>
> Wasn't there a project back on jini.org that was a collection of pattern
> implementations? I don't remember the name and can't seem to find it now.
>
> Thanks,
> Jeff
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@...

Windows Live™ SkyDrive™: Get 25 GB of free online storage. Get it on your BlackBerry or iPhone. -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Any way to see the codebase of an object?

2009-06-26T08:09:16Z

Alex Co wrote:
> Solved.
> It seems that client can not receive
> -Djava.rmi.server.codebase=http://localhost:8080/
> during launch
>
> Only the server needs that.

Yes, java.rmi.server.codebase is a property used by the RMI/Jini mechanisms
through the RMIClassLoaderSPI to cause MarshalledObject() use by RMI/Jini to
attach the indicated URLs as the annotations for "server" exported objects.

The client's URLClassLoader (or like class loader implementation per
RMIClassLoaderSPI) use (through the implementation details in RMI/Jini
endpoint/invocation layer activities) will use those annotations to download and
resolve classes.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Any way to see the codebase of an object?

2009-06-26T07:56:50Z

Solved.
It seems that client can not receive
-Djava.rmi.server.codebase=http://localhost:8080/
during launch

Only the server needs that.

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Any way to see the codebase of an object?

2009-06-26T06:57:02Z

Hi
Is there any way to print or see the codebase of an object that is about to be
serialized to a socket?

This is because I have a client server and server sends an object throught the
socket to client and if the .class of that object does not exists on client side
the client throws an exception of java.lang.ClassNotFoundException.

I have the jini web server running and the www dir has the .class. If i try to
access the .class through web browser there is no problem. The browser asks
to save the file.

It seems that the object do not carries a valid codebase?!

Thanks

Alex
PS: Both client and server are running on the same machine for now. When
running client and server i pass the following:

-Djava.rmi.server.codebase=http://127.0.0.1:8080/

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Reggie

2009-06-26T05:39:44Z

On Jun 26, 2009, at 3:29 AM, Per Edlund wrote:

As it seams, this issue is related to client machines. If a client machine get's memoty issues, and reggie is trying to notify the client (which uses a servicechache listening on all service events), reggie chokes when the client can't reply to reggie.

Could this also be an issue for clients with firewalls up which can't accept connections for the notifications, and the notification connections timeout? I've seen some strange things from time to time on more restricted networks and not really been able to pinpoint the issues. Many times, it seems like discovery degenerates into a really slow and painful process. An outbound call, initiating a TCP connection which must timeout before anything can be done to eliminate the call context, can be quite long lived, on the order of minutes. I wonder if this would cause other discovery/notification to be delayed and thus build up more held context in the reggie JVM and elsewhere.

Gregg Wonderly

Fixiing the memory issues on the client get's rid of the behaviour on reggie

Just thouth I should tell

Cheers
/Per

On Wed, May 27, 2009 at 3:47 PM, Juan Ramirez <Juan.Ramirez@...> wrote:

Hi, Peter. Reggie does queue up discovery requests and event notifications and services these with threads from the same pool. It is possible that there is a large number of event notifications to be delivered to the LookupCache instances thus delaying the processing of discovery requests. You could set Reggie's logging level to FINEST to see what Reggie is doing at the time it appears to "choke". There is additional info on this scenario in the following CRs.

https://issues.apache.org/jira/browse/RIVER-52
https://issues.apache.org/jira/browse/RIVER-197

Hope this helps,

Juan

On 05/27/09 07:17, Per Edlund wrote:

Hi!

We'ev been using Jini for quite som time now but havn't upgraded after the 2.1 release. We're currently experiencing some issues with reggie choking the machine and we can't really tell why. The number of jiniservices we have is around 60 (these are client's as well, and on top of this we have webservers which are clients (around 100-200)) , we use the LookupCache etc, but efery now and then we have to restart the VM running reggie. Doing a discovery during this time get's no lookup, and services can't be found.

If we look at how services register/unregister, that seam to take an aweful long time when reggie is starting to choke, and out theory is that reggie uses some kind of queue which grows more than it can be processed.

Does any one have an idea on how to dig into this?

Env: Linux Debian, Sun Java 1.5&1.6

Kind regards
/Per
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

--
********************************************
Per Edlund
www.bozoka.com
per@...
+46(0)8 545 068 05
+46(0)703 71 70 02
********************************************
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Reggie

2009-06-26T01:29:26Z

Hi!

Thanks for the replys!

As it seams, this issue is related to client machines. If a client machine get's memoty issues, and reggie is trying to notify the client (which uses a servicechache listening on all service events), reggie chokes when the client can't reply to reggie.

Fixiing the memory issues on the client get's rid of the behaviour on reggie

Just thouth I should tell

Cheers
/Per

On Wed, May 27, 2009 at 3:47 PM, Juan Ramirez <Juan.Ramirez@...> wrote:

Hi, Peter. Reggie does queue up discovery requests and event notifications and services these with threads from the same pool. It is possible that there is a large number of event notifications to be delivered to the LookupCache instances thus delaying the processing of discovery requests. You could set Reggie's logging level to FINEST to see what Reggie is doing at the time it appears to "choke". There is additional info on this scenario in the following CRs.

https://issues.apache.org/jira/browse/RIVER-52
https://issues.apache.org/jira/browse/RIVER-197

Hope this helps,

Juan

On 05/27/09 07:17, Per Edlund wrote:

Hi!

We'ev been using Jini for quite som time now but havn't upgraded after the 2.1 release. We're currently experiencing some issues with reggie choking the machine and we can't really tell why. The number of jiniservices we have is around 60 (these are client's as well, and on top of this we have webservers which are clients (around 100-200)) , we use the LookupCache etc, but efery now and then we have to restart the VM running reggie. Doing a discovery during this time get's no lookup, and services can't be found.

If we look at how services register/unregister, that seam to take an aweful long time when reggie is starting to choke, and out theory is that reggie uses some kind of queue which grows more than it can be processed.

Does any one have an idea on how to dig into this?

Env: Linux Debian, Sun Java 1.5&1.6

Kind regards
/Per
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

--
********************************************
Per Edlund
www.bozoka.com
per@...
+46(0)8 545 068 05
+46(0)703 71 70 02
********************************************
-------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Help needed on returning serviceregistrar by hand

2009-06-25T12:38:56Z

By the way, the file is written using the writeObject method (Java) but then
the file is read using Windows C API and sent to client via winsock api.
Hence, at client side there is a typical Jini Java client application.

I will try your advices.

Thank you very much

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Help needed on returning serviceregistrar by hand

2009-06-25T12:34:36Z

Alex Co wrote:
> I am trying this on MyLUS
>
> MyRegistrarProxy p = new MyRegistrarProxy();
>
>
> out.writeObject(new
> MarshalledInstance(p,Collections.EMPTY_LIST).convertToMarshalledObject());

Just from my perspective:

The purpose of MarshalledInstance is to provide some separation from
MarshalledObject. In your case, you can just use MarshalledObject to wrap the
proxy object with the codebase that the associated classloader is advertising
via the RMIClassLoaderSPI.

To your problem, look at how you are doing the writeObject() and readObject().
I suspect that you have corrupted the stream by intermingly I/O with the
Object(Input/Output)Stream and the underlying InputStream/OutputStream and not
flushing at the appropriate times to make sure the bytes that go out the
OutputStream or come in the InputStream are properly ordered.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Help needed on returning serviceregistrar by hand

2009-06-25T11:45:52Z

I am trying this on MyLUS

MyRegistrarProxy p = new MyRegistrarProxy();

out.writeObject(new
MarshalledInstance(p,Collections.EMPTY_LIST).convertToMarshalledObject());

Then another thread reads the file (out) and sends byte by byte to receiver.

but on receiver (client) when the line

ServiceRegistrar registrar = lookup.getRegistrar();

is executed JVM says:

Exception in thread "main" java.io.StreamCorruptedException: invalid type
code:00

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Help needed on returning serviceregistrar by hand

2009-06-25T11:04:01Z

Serialization is "Serialization". The issue is which object is serialized
across the wire. For Reggie, you need to look at the implementation of lookup()
in the RegistrarProxy class. The MarshalledWrapper class is what the server
returns to the client.

Gregg Wonderly

Alex Co wrote:

> Hi all,
>
> Jini serialization is not the same as writeObject/readObject serialization, right?
>
> Suppose I have a compiled class file called MyServiceRegistrarProxy that
> implements ServiceRegistrar, Serializable.
>
> MyServiceRegistrarProxy x= new MyServiceRegistrarProxy();
>
> Now I want to store the x object into a file but following the same serialization
> protocol that reggie follows when it returns its serviceregistrar to clients by
> sockets.
>
> I want that the file contents be compliant with the future use of:
> ServiceRegistrar registrar = lookup.getRegistrar();
>
> e.g on future i want to have a second thread or something reading the file and
> sending file data to clients and clients building ServiceRegistrar objects from
> my MyServiceRegistrarProxy type.
>
>
> To serialize the object to file using standard serialization i do this:
>
> String filename = "myserviceregistrar.svr";
>
> FileOutputStream fos = null;
> ObjectOutputStream out = null;
>
> MyServiceRegistrarProxy p = new MyServiceRegistrarProxy();
> try
> {
> fos = new FileOutputStream(filename);
> out = new ObjectOutputStream(fos);
> out.writeObject(p);
> out.close();
> }
> catch(IOException ex)
> {
> ex.printStackTrace();
> }
>
>
> whichs classes can i use to serialize it to file in a Jini compliant way?
> An example would be very appreciated.
>
> Thanks a lot
>
> Alex
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@...
>

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Jini.org

2009-06-25T10:06:59Z

jini.org is currently hosted at Dreamhost and is run on Mediawiki.

I'm open to whatever the community decides. It's been frustrating combating the spammers while trying to keep jini.org as open as possible (per wiki culture). I'd be more defensive of keeping the site if the community had taken greater ownership of it, but a lot of the content is stuff I copied from the previous site (like the Jini specs and all the content from Jini Community Meetings). I'd really hate to lose the JCM stuff, in particular.

-jeff

On Thu, Jun 25, 2009 at 8:23 AM, Rick Innis <rick@...> wrote:

This is just a heads up that we have to decide if we want to
keep Jini.org around. The site has been around since the
inception of the Jini Community in 1999, and has gone through
a number of transformations over the years. It's current state
is that it is wiki-based and hosted by Dreamhost.

I use Dreamhost for my own hosting, and I'd be happy to add the jini.org site to that.

We have an outstanding bill for $239.40 that is due by July 8th to keep
the site going.

I' also happy to chip in towards this.

We can either:
- try to consolidate and move the content to Apache River,
- figure out how to fund the Jini.org site, or
- just let the site (and content) expire.

I agree with Patrick that the domain name should be kept up. I think migrating the useful content to the Apache River project is probably a good idea, and eventually redirecting jini.org there - it makes it clear that there's one source for the project.

R.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVASPACES-USERS". For general help, send email to
listserv@... and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

Help needed on returning serviceregistrar by hand

2009-06-25T08:00:32Z

Hi all,

Jini serialization is not the same as writeObject/readObject serialization, right?

Suppose I have a compiled class file called MyServiceRegistrarProxy that
implements ServiceRegistrar, Serializable.

MyServiceRegistrarProxy x= new MyServiceRegistrarProxy();

Now I want to store the x object into a file but following the same serialization
protocol that reggie follows when it returns its serviceregistrar to clients by
sockets.

I want that the file contents be compliant with the future use of:
ServiceRegistrar registrar = lookup.getRegistrar();

e.g on future i want to have a second thread or something reading the file and
sending file data to clients and clients building ServiceRegistrar objects from
my MyServiceRegistrarProxy type.

To serialize the object to file using standard serialization i do this:

String filename = "myserviceregistrar.svr";

FileOutputStream fos = null;
ObjectOutputStream out = null;

MyServiceRegistrarProxy p = new MyServiceRegistrarProxy();
try
{
fos = new FileOutputStream(filename);
out = new ObjectOutputStream(fos);
out.writeObject(p);
out.close();
}
catch(IOException ex)
{
ex.printStackTrace();
}

whichs classes can i use to serialize it to file in a Jini compliant way?
An example would be very appreciated.

Thanks a lot

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Jini.org

2009-06-25T07:51:55Z

It may be obvious, but--the most important thing in my mind is that
the jini.org domain name be retained. It can point to the Apache River
servers. Old links still in search engines will then at least hit a
live server (and perhaps we can set up the webserver to redirect to a
page explaining the name change).

If we can host the wiki content somewhere we could scrape it for
goodies afterwards. My recollection is that the content on jini.org
was fairly mixed, with quite a bit being outdated. I haven't looked in
awhile, since last year at least, though. I would volunteer to help
look through the wiki for usable content. What software is hosting the
wiki itself?

If we do keep the domain name, then we just have to figure out how to
fund the domain-name registration, for which I'm happy to contribute
(for the time being, anyhow!).

Patrick

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Jini.org

2009-06-25T07:39:34Z

I'm a big fan of consolidation. It helps make things easier to get into.

-bp

On Jun 25, 2009, at 6:36 AM, Alexander R. Krapf wrote:

> What are the cost details on the account? Codemesh would definitely
> chip in if
> people thought there was a benefit to keeping it alive. I could see
> different
> opinions on it though. Maybe it would be better to consolidate
> under the River
> name. Maybe keeping Jini.org up is a temporary fix while content is
> migrated
> over.
>
> Alex
>
>
>>> This is just a heads up that we have to decide if we want to
>>> keep Jini.org around. The site has been around since the
>>> inception of the Jini Community in 1999, and has gone through
>>> a number of transformations over the years. It's current state
>>> is that it is wiki-based and hosted by Dreamhost. We have an
>>> outstanding bill for $239.40 that is due by July 8th to keep
>>> the site going.
>
>>> In the past Sun has solely funded the site -- I'm assuming that's
>>> not going to be the case going forward.
>
>>> We can either:
>>> - try to consolidate and move the content to Apache River,
>>> - figure out how to fund the Jini.org site, or
>>> - just let the site (and content) expire.
>
>>> Thoughts?
>
>>> thanks -Jim
>
>>> --------------------------------------------------------------------------
>>> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
>>> Community Web Site: http://jini.org
>>> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
>>> Unsubscribing: email "signoff JINI-USERS" to listserv@...
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@...

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Jini.org

2009-06-25T05:36:58Z

What are the cost details on the account? Codemesh would definitely chip in if
people thought there was a benefit to keeping it alive. I could see different
opinions on it though. Maybe it would be better to consolidate under the River
name. Maybe keeping Jini.org up is a temporary fix while content is migrated
over.

Alex

>> This is just a heads up that we have to decide if we want to
>> keep Jini.org around. The site has been around since the
>> inception of the Jini Community in 1999, and has gone through
>> a number of transformations over the years. It's current state
>> is that it is wiki-based and hosted by Dreamhost. We have an
>> outstanding bill for $239.40 that is due by July 8th to keep
>> the site going.

>> In the past Sun has solely funded the site -- I'm assuming that's
>> not going to be the case going forward.

>> We can either:
>> - try to consolidate and move the content to Apache River,
>> - figure out how to fund the Jini.org site, or
>> - just let the site (and content) expire.

>> Thoughts?

>> thanks -Jim

>> --------------------------------------------------------------------------
>> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
>> Community Web Site: http://jini.org
>> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
>> Unsubscribing: email "signoff JINI-USERS" to listserv@...

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Jini.org

2009-06-24T19:34:30Z

This is just a heads up that we have to decide if we want to
keep Jini.org around. The site has been around since the
inception of the Jini Community in 1999, and has gone through
a number of transformations over the years. It's current state
is that it is wiki-based and hosted by Dreamhost. We have an
outstanding bill for $239.40 that is due by July 8th to keep
the site going.

In the past Sun has solely funded the site -- I'm assuming that's
not going to be the case going forward.

We can either:
- try to consolidate and move the content to Apache River,
- figure out how to fund the Jini.org site, or
- just let the site (and content) expire.

Thoughts?

thanks -Jim

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: list going away

2009-06-24T13:45:48Z

Hi all

Jim Waldo was went the extra mile and has uploaded the listserv
archives for Jini-users and Javaspace-users to the Apache River issue
tracking list. MarkMail has emailed me that they can host them, but
will need them in mbox format. If anyone has experience with listserv
to mbox conversion and can give tips, or would like to help, please
write back. Otherwise I will take a swing at the conversion this
weekend.

Cheers
Patrick

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-23T08:05:45Z

Thanks Gregg,
Lots of usefull explanation you wrote. I am afraid of not understood all you
recommend to me because my skills on Jini ar far way from yours.

It seems that even Jeri is too much for my toy :-(

I have to use plain sockets between server and (smart) proxy. No serialization
at all... :-(

MAy be the solution is to use slp or upnp to discover service (as someone
already recommended to me in this forum) and then download the class file
from the server and do not support serialization (data) at all. Just class file
download for instantiation on client side. No more solutions i think...

Thanks

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T14:35:25Z

Alex Co wrote:

> Thanks Gregg,
>
> I think i did not explain well the surrogate issue. Of course my device and my
> tiny vm can interact with jini federation through surrogate. But i dont want to
> have my device depending of another device/computer to participate on the
> jini federation. That could introduce more point of failures and more setup
> effort. I want that my tiny device could participate on jini federations by its
> own, not relying in others get get is participate job done. The idea is to
> transform my device in a Jini device that could offer and consume jini services
> in a transparent way.

When the surrogate architecture was conceived, the JERI subsystem was in its
infancy as an idea and as working code I believe. Since surrogate was
published, JERI came around and we had a very customizable stack to allow things
to be non-JRMI based. Deserialization is a very powerful and important part of
"joining" a random network, because you can't know the "implementations" on all
networks and thus you need to be able to download the appropriate implementation
definitions (class files), and deserialize the instance data for them so that
you can instantiate something that works.

The URLClassLoader is, more or less, the foundation of this from my perspective.
Jini references this class and extends it with the PreferredClassLoader, and
the RMIClassLoaderSPI is wired into this API to help define how a serialized
object can be deserialized later, and even elsewhere.

If you can't really provide a URLClassLoader kind of deserialization
implementation, than you have to step back and look at what you think you need
to accomplish with some ideas of minimization I believe.

> So, let me know if i understood
>
>> People have done wide and varying things to get a service object active. I've
>> heard of http download of a serialized object stream. You could do this by
>> writing a MarshalledObject instance to a file, for example.
>
> Well, in this case we have an extra mean to store already serialized objects on
> lus may be by serializing them in compile time or something. in this case only
> clients must include deserializing capabilities. As i wat my device to be server
> and client, it just have to embed deserializing capabilities, right?

I think yes, but what about outbound calls?

Note that there are two ways that I think about deserialization. First question
from my perspective is, can you understand the serialized data stream? There
are standards for Java Serialization, so for that, its more of a question of can
you swallow what you are being fed from a size and complexity perspective
including complex object graphs with duplicate references for example.

So deserialization is a big part. Making calls out to a server requires some
degree of serialization too, as I believe you understand.

>> But, you could also have all the "classes" "known" in your application and just
>> have the client ready to instantiate an instance, and just have "data"
>> transported back and forth with XML, or JSON or something else.
>
> In this case there is no objects running over the wire, right? there is only
> classes stores in a http server and client downloads them and instantiate them
> and call the methods. Obviously client must have some form of identify the
> classes it needs for the service in wants to use. Those classes (smart proxies
> can create sockets and speak with the server). In this case all works but
> location abstraction is sacrificed, right?

If you don't "download class definitions", you don't have to have "class
loading" built into your JVM. Instead, you already have the class definition
available, and you just deserialize instances, using the noargs constructor and
other serialization mechanisms to get an instance.

The instantiated classes will be "java" code, so they can do what you need them
to do, based on what you've decided should happen with their communcations, API etc.

>> There are choices for using services, but not a lot of choices if you want to
>> use a ServiceRegistrar instance for your lookup service.
>
> Well, this ServiceRegistrar is also a stub that my device as a client must get in
> order to speak with the lus, right?

Yes, you need to be able to implement the "semantics" of what the reggie proxy
does. If you decide that you need an instance of reggie, deployed with a
particular kind of endpoint and invocation layer, than you can "decide" ahead of
time how clients will use that reggie instance.

If you want to join the network arbitrarilly, than you have to be prepared to
accept a lot more variation, which most likely includes the ability to download
and instantiate a wide range of classes because of how rich the JERI stack is in
flexibility and capability.

Think about what it might mean to provide a "Configuration" for Reggie that
specified a custom end-point and invocation-layer implementation that you need,
along with a small jar containing the needed classes.

Then you could say "deploy an instance of reggie with this configuration for my
devices to use". As long as the client endpoint was down loadable and worked,
than all services would have no problem connecting to that reggie instance and
registering so that your simple devices could find them.

> What about modify the LUS to support what it supports now but also to
> support servicing class downloading also and provide a new way to interact
> with it in order to avoid ServiceRegistrar ?

ServiceRegistrar can be part of the problem to solve, but it may also be
possible to make a configuration change that limits what you need to be able to
"load", because you've set the JERI configuration to a fixed set of classes
that you can provide implementations of.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T14:01:48Z

Thanks Gregg,

I think i did not explain well the surrogate issue. Of course my device and my
tiny vm can interact with jini federation through surrogate. But i dont want to
have my device depending of another device/computer to participate on the
jini federation. That could introduce more point of failures and more setup
effort. I want that my tiny device could participate on jini federations by its
own, not relying in others get get is participate job done. The idea is to
transform my device in a Jini device that could offer and consume jini services
in a transparent way.

So, let me know if i understood

>People have done wide and varying things to get a service object active. I've
>heard of http download of a serialized object stream. You could do this by
>writing a MarshalledObject instance to a file, for example.

Well, in this case we have an extra mean to store already serialized objects on
lus may be by serializing them in compile time or something. in this case only
clients must include deserializing capabilities. As i wat my device to be server
and client, it just have to embed deserializing capabilities, right?

>But, you could also have all the "classes" "known" in your application and just
>have the client ready to instantiate an instance, and just have "data"
>transported back and forth with XML, or JSON or something else.

In this case there is no objects running over the wire, right? there is only
classes stores in a http server and client downloads them and instantiate them
and call the methods. Obviously client must have some form of identify the
classes it needs for the service in wants to use. Those classes (smart proxies
can create sockets and speak with the server). In this case all works but
location abstraction is sacrificed, right?

There are choices for using services, but not a lot of choices if you want to
use a ServiceRegistrar instance for your lookup service.

Well, this ServiceRegistrar is also a stub that my device as a client must get in
order to speak with the lus, right?

What about modify the LUS to support what it supports now but also to
support servicing class downloading also and provide a new way to interact
with it in order to avoid ServiceRegistrar ?

Thank you

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T11:18:47Z

Niclas Hedhman wrote:

> On Mon, Jun 22, 2009 at 4:32 PM, Alex Co<alexe100@...> wrote:
>> If my client device do not suports even (de)serialization, is there any way to
>> integrate that device in the jini federation (without using surrogate) in order to
>> give the chance to it to expose and consume Jini services, even sacrificing (a
>> little) the whole jini federation?
>
> As I mentioned just now, I think you will be in for a tough ride. Even
> surrogate won't help you, since Jini basically requires a full JVM on
> the client, whereas you are much more free to do what you like on the
> server. I think that you may have better luck with either UPnP or
> perhaps SLP. If you are into OSGi, check out r-OSGi which may (I have
> not looked at the details) suit your needs, as I know Jan Rallermeier
> is biased heavily towards the embedded space.

The specification of JERI/RMI and Serialization has a lot of freedom allowed if
you stick with the term "semantics" and not with the term "specifics". What has
to happen is that you need to be able to "act" with behaviors that mean the
semantic meaning of what should happen but you need to do that by implementing
the "specifics" of what is known as (de)serialization.

In particular, you can provide end point and invocation layer activities in your
service endpoint that only require http and transfer XML data.

When you talk about service discovery, than you have a different issue. Because
the LUS specification already exists, and because LUS implementations are pretty
much just Reggie, you have to go to some more direct steps to get a "services
client endpoint" in your "jini client".

People have done wide and varying things to get a service object active. I've
heard of http download of a serialized object stream. You could do this by
writing a MarshalledObject instance to a file, for example.

But, you could also have all the "classes" "known" in your application and just
have the client ready to instantiate an instance, and just have "data"
transported back and forth with XML, or JSON or something else.

There are choices for using services, but not a lot of choices if you want to
use a ServiceRegistrar instance for your lookup service.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T10:55:09Z

Niclas Hedhman wrote:

> Because downloading class files via http is so much more effecient,
> and hosting those via http left the RMI team to focus on more
> important stuff.
> Personally, I employed one out of two strategies to deal with
> dynamically loaded classes (I'm sure there are others);
>
> 1. Either embed a tiny http server in each service, and all classes
> are picked up from the originating host. Requires a little bit of
> trickery, since it is (or at least was) not possible to specify http:
> URLs in the classpath on the command-line. And basically, the
> bootstrap code would launch the http server, and then create a new
> classloader with the real application's classes pointed out via a
> http:// to the current running machine.

The RMIClassLoaderSPI is meant to take care of this issue by allowing you to
specify a classloader that will provide the appropriate annotations.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T03:39:13Z

Thanks a lot...
Your advices and tips were vary valuable for me.

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T03:12:56Z

On Mon, Jun 22, 2009 at 5:24 PM, Alex Co<alexe100@...> wrote:

> I just have one idea that is operate on LUS default implementation. May be the
> LUS could start accept ALSO other form of things which are not serializable
> objects .

Since Jini implementation is now sitting in Apache River project, you
could of course add your own extensions to it, and totally
disregarding what the spec mandates. The upside is that you can
control everything, and the downside is no interoperability and
possibly long term maintenace problems.

So, for instance, as part of the Discovery/Join phase, you could for
instance use UPnP (or a home brewed mechanism) to discover the LUS,
and modify Reggie to support other protocols than RMI. I am not sure
how resource contrained you are, but perhaps xstream or some json
system would be possible to handle the serialization. You could also
check out an old alternative RMI implementation (AltRMI, sitting in
Apache Incubator as a project failing to create a community) for ideas
on how to do the method dispatch system and perhaps use AltRMI as a
base, then swap out the serialization with a json one and manage to
squeeze that into your device.
You could for instance opt to disallow support for some Lookup Service
features, such as Entries and Events, and perhaps try to reach a
'primitives only' solution at service interface levels.

Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T03:02:51Z

Another problem is that the reggie is based on RMI and to interact with it the
client must speak rmi too.

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T02:24:29Z

>> So, this means that the default LUS server needs to receive at least a
>> serializable object to maintain the Jini system as it was specified (very
dynamic
>> and agnostic in location matters)...

>There is no "default" LUS. All LUSes in the same group are registering
>all services in parallel to provide for redundancy, scalability and
>robustness to intermittent network problems. Otherwise correct.^

When I refer default LUS I mean the default LUS implementation algorithm
(reggie) not a particular LUS running on the federation. Sorry it was my
mistake.
I already studied UpnP, SLP etc but Jini is my target. Why? I dont know?
because the Java world that is fashinating. I have a tiny JVM for that device
(made at my home) with tcp/IP sockets but no serialization (no room for that
:-( ). I am looking for ways to enter in the jini federation with that device (for
consume and for supply jini services, obviously tiny services).

I just have one idea that is operate on LUS default implementation. May be the
LUS could start accept ALSO other form of things which are not serializable
objects .

Please, could you comment this solution?

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T01:46:32Z

On Mon, Jun 22, 2009 at 4:32 PM, Alex Co<alexe100@...> wrote:
> Yes, you are right. Interface is needed to "shape" the service and to be a
> mean to identify it on LUS and it is the proxy that must implements serializable.
> Ok, now i start to understand why smart proxy class file is not enough on the
> client side. With just the class file the system would be more static, that is
> that class file was writeen and then the client would use always the same ip,
> port etc etc. by introducing also the deserialized proxy object (data) each
> server could "tune" that smart object at the moment of register it with the lus
> and the whole system would be more "dynamic" because the smart proxy
> object is not static and bot bound with a static source.

Yes, that is one way to express it...

> So, this means that the default LUS server needs to receive at least a
> serializable object to maintain the Jini system as it was specified (very dynamic
> and agnostic in location matters)...

There is no "default" LUS. All LUSes in the same group are registering
all services in parallel to provide for redundancy, scalability and
robustness to intermittent network problems. Otherwise correct.

> If my client device do not suports even (de)serialization, is there any way to
> integrate that device in the jini federation (without using surrogate) in order to
> give the chance to it to expose and consume Jini services, even sacrificing (a
> little) the whole jini federation?

As I mentioned just now, I think you will be in for a tough ride. Even
surrogate won't help you, since Jini basically requires a full JVM on
the client, whereas you are much more free to do what you like on the
server. I think that you may have better luck with either UPnP or
perhaps SLP. If you are into OSGi, check out r-OSGi which may (I have
not looked at the details) suit your needs, as I know Jan Rallermeier
is biased heavily towards the embedded space.

Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T01:40:50Z

On Mon, Jun 22, 2009 at 6:33 AM, Alex Co<alexe100@...> wrote:

> The question is:
> Can this class or an object of this class (smart proxy) be registered in LUS?

An object of a class is registered in the LUS together with the
service interface, a Unique Identitfier and other attributes (called
Entry).

> As far as i know that class must implements serializable, to be possible to
> register it on LUS, right?

Yes, one of the two possible options (serializable or externalizable).

> As far as i know serialization is to transfer live objects over wire. "Download via
> http is a way to transfer class files over wire".

Well, try to avoid mixing classes and objects in the same sentence.
RMI allows for dynamic classloading, i.e. that the classes needed on
the 'opposite side' of the transfer that is not already present, can
be downloaded from a known location. The location URL of where those
classes are to be downloaded are located;
1. If the Classloader have loaded the classes at the originating host
via a globally accessible protocol (i.e. http, ftp), then the
destination JVM's classloader will use that URL to find the classes
needed.
2. If the above fails, then the client will try to download it from
the location specified by java.rmi.server.codebase property.

Note that dynamic classloading is optional. You could possibly have a
situation where no classes are needed to be transported over the wire.

The service proxy will need to be uploaded to the LUS (not necessarily
by the service itself) in a serialized format, and the client need to
be able to retrieve that object instance via the LUS interface.

Now, the Jini Discovery/Join/Lookup specs defines how the client will
join the federation, find one or more LUSes, and how to lookup a
service. Now, considering your questions on RMI-USERS, I suspect that
you are after to bypass the LUS to get to your service, since the RMI
level conversation between the client and the LUS is fairly 'chatty'.
If that is the case, then you are effectively disabling everything
that Jini provides, and perhaps you should be looking at UPnP instead.

> To the best of my knowledge the client needs LUS to abstract localization of
> the server, but why server must instantiate a serializable class in order to add
> it to the LUS?

The typical scenario is that the server will instantiate the service
proxy, together with its own location information, and then upload the
service proxy to the LUS via the LUS' interface. That is technically
not a requirement. Search for "Surrogate Architecture" for more info
what is needed to have a service not capable of RMI or even Java
itself.

> Why LUS do not store class files instead of objects and then
> clientes discover LUS and dowload class files instead of serializable objects?

Because downloading class files via http is so much more effecient,
and hosting those via http left the RMI team to focus on more
important stuff.
Personally, I employed one out of two strategies to deal with
dynamically loaded classes (I'm sure there are others);

1. Either embed a tiny http server in each service, and all classes
are picked up from the originating host. Requires a little bit of
trickery, since it is (or at least was) not possible to specify http:
URLs in the classpath on the command-line. And basically, the
bootstrap code would launch the http server, and then create a new
classloader with the real application's classes pointed out via a
http:// to the current running machine.

2. Have a central repository of all classes, and have all
java.rmi.server.codebase properties set to it.

> In this case, client needs only the class file not the live object stored in the
> LUS by server, right?
> Once getting the class file, client instantiates it and call the method.
> So, why serialization is obligatory on Jini?

I think because your exception to the 'rule', that you can have
successfully use a class without any instance data, is too rare, and
the chosen path handles that simple case, but the opposite isn't true.

Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-22T01:32:05Z

Yes, you are right. Interface is needed to "shape" the service and to be a
mean to identify it on LUS and it is the proxy that must implements serializable.
Ok, now i start to understand why smart proxy class file is not enough on the
client side. With just the class file the system would be more static, that is
that class file was writeen and then the client would use always the same ip,
port etc etc. by introducing also the deserialized proxy object (data) each
server could "tune" that smart object at the moment of register it with the lus
and the whole system would be more "dynamic" because the smart proxy
object is not static and bot bound with a static source.

So, this means that the default LUS server needs to receive at least a
serializable object to maintain the Jini system as it was specified (very dynamic
and agnostic in location matters)...

If my client device do not suports even (de)serialization, is there any way to
integrate that device in the jini federation (without using surrogate) in order to
give the chance to it to expose and consume Jini services, even sacrificing (a
little) the whole jini federation?

Thanks a lot

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-21T23:41:45Z

On Jun 21, 2009, at 10:22 AM, Niclas Hedhman wrote:
> Jini's mission is built around the concept of location-independence,
> configuration-free and self-healing networked systems.
>
> So, to answer 'serialization'; No it is up to the service and proxy
> to agree to any private protocol they like. It can be RMI, or it
> could be a home-brewed protocol over UDP, SPX or what not. The
> service contract is only between the client and the proxy running in
> the client.
>
Yes, but I think that the question is about the requirements for one
service's proxy to be passed to another (the primary example being a
lookup service), for which there needs to be some agreement for how
the second service can transfer the first's proxy-- and the
expectation there is that the proxy supports RMI marshalling semantics
(and thus serialization) even if second service doesn't actually use
RMI to do such a transfer.

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-21T23:38:56Z

On Jun 20, 2009, at 9:20 AM, Alex Co wrote:
> Jini does not mandate the use of rmi as the communication protocol
> between
> client and server, right?

Right.

> So, for those that do not want to use rmi, the service interface
> must at least
> implements serializable, right?

Not the service interface in particular (in general interfaces should
not extend java.io.Serializable), but the service proxy's class should
be serializable.

> Then, on client side, if client needs to use a jini service it
> downloads service
> classes definitions by http (for example) and the jini service
> object comes by
> wire by using serialization on server side and deserialization on
> client side. Then
> the proxy is constructed on the client side by "joining" the
> downloaded classes
> definitions and the proxy object that arrives to client by
> deserialization.
>
> My question is: why it is necessary downloaded class definitions and
> deserialized proxy object to invoke jini service?
>
> Why not just get the class definitions, instantiate them and call
> its methods?
> What is the role of the proxy object there?

In general, objects are code + data. In particular, service proxy
objects typically have instance data identifying the network location
(like host and port, and object ID in the RMI case, etc.) of the
service's back end-- you wouldn't want to need a separate service
proxy class and definition for each possible deployment of the service
implementation.

-- Peter

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...

Re: Why, at least, serialization?

2009-06-21T15:33:58Z

Thank you Niclas.

Well, I think I understood the jini concept already. May be i did not explain me
good in the question i made.

I know that the smart proxy, stub or local proxy abstract client from all. It just
have to call the method. The language spoken between server and
proxys/stubs is private and jini do not cares about that.

My question is in other direction! The LUS!

Jini is basically clients, servers and LUS(s), right?

Supose I what to develop a service and an smart proxy in Java. The service
has the method void helloworld(void). Nio need a smart procy in this case, but
consider that a smart proxy is then developed that opens a socket to the
server on its constructor and provides a method called InvokeHello that
invokes helloworld on the server.

The smart proxy do not have to be developed using RMI, I know that (and that
is very good!). In this case the smart proxy is just a class file that do not
implements nor extends nothing.in the lus
The question is:
Can this class or an object of this class (smart proxy) be registered in LUS?
As far as i know that class must implements serializable, to be possible to
register it on LUS, right?

As far as i know serialization is to transfer live objects over wire. "Download via
http is a way to transfer class files over wire".

To the best of my knowledge the client needs LUS to abstract localization of
the server, but why server must instantiate a serializable class in order to add
it to the LUS? Why LUS do not store class files instead of objects and then
clientes discover LUS and dowload class files instead of serializable objects?

In this case, client needs only the class file not the live object stored in the
LUS by server, right?

Once getting the class file, client instantiates it and call the method.

So, why serialization is obligatory on Jini?

Thanks a lot

Alex

--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...