You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <to...@sucfin.com> on 2009/07/13 13:53:04 UTC
OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
"I know you guys are very busy, but it would be nice if the most
experienced Jini/River software engineers were able to dissect the
[OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
for Jini/River. I know it's tough to allocate time to do that though."
Well, in the absence of the most experienced you're left with me. :-)
For added confusion, I don't know a whole heap about OSGi either, so the
follow is a likely mix of over simplification and misunderstanding.
If that sounds useful, continue reading...
This is the complete document, I skipped down to RFC 119 only;
http://www.osgi.org/download/osgi-4.2-early-draft.pdf
The RFC discusses the concept of a "Service Registry" which looks an
awful lot like a River ServiceRegistrar. Delving further into the RFC
it seems to me that we if we can translate from the specified interfaces
that describe an "OSGi Service" to that which describes a "River
Service" then River could slot in quite nicely as a response to this
RFC.
Much of the work feels like translating from what OSGi say service
descriptions and lookups *should* look like and what River says service
descriptions and lookups *do* look like.
The only tricky part, I think, would be how an OSGi component (which
likely extends something else) can be made into a River service such
that it is discoverable in the usual way. This would be an interesting
problem and raises the circumstance where an OSGi service might publish
itself as an OSGi service, but because it's River underneath, would be
discoverable by pure River clients on the same network also.
Looking at how the RFC specifies what a service description is and what
it looks like, I think that there is mileage in River adopting something
similar. It would be nice, in my opinion, to move away from the
quasi-java config files River uses in favour of something else.
XML makes sense because that's what most of the rest of the world uses -
although I personally don't care for it much.
Someone on the Jini-Users (or similar, I can't quite remember) a while
ago was talking about using Groovy classes to describe service
configuration. Something like this sounds pretty neat, but anything
that needs to be recompiled for changes can take affect is likely to be
unworkable for obvious reasons.
Also, building in a mechanism to provide a similar version-sensitive
lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
feature for River all other considerations not-withstanding.
Anyway, that's this layman's interpretation of this OSGi RFC; if only
for a few days or weeks of spare time to spend putting it together.
Tom
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <gr...@wonderly.org>.
Gregg Wonderly wrote:
> Exposing those details in a
> way that doesn't cause "downloading" or "unmarshalling" (which can lead
> to codebase contamination because of local class uses) is what is left
> to do.
There are updates visible at http://reef.dev.java.net which change the
MarshalledDataAccess interface to include
public Map<String,Object> getFieldValues();
There is also work that happens in MarshalledInstance (for the service) and
EntryRep (for attributes) to make them create this map as the objects are
"Marshalled".
Thus if you wrote code such as
public void discovered( ServiceRegistrar regs[] ) {
for( ServiceRegistar reg: regs ) {
if( reg instanceof ServiceLookup ) {
doLookup( (ServiceLookup)reg );
} else {
... normal ServiceRegistrar
}
}
}
private void doLookup( ServiceLookup lu ) {
RemoteIterator<ServiceEntry> it =
lu.lookup( template, Integer.MAX_VALUE );
...
}
you could look at both ServiceDataAccess for the service proxy and each of the
Entry objects to see the public, native valued fields names and values via
ServiceDataAccess.getFieldValues.
If you've never looked at reef, go to the 'Documents and files' link on
http://reef.dev.java.net and download the api docs and look at them. The
reef.jar and reef-dl.jar files are there too, and you can swap out reggie.jar
and reggie-dl.jar in our jini deployment to make use of this lookup server.
Again, it is backward compatible with any existing use of reggie (to the best of
my ability to determine that compatibility) because it provides a
ServiceRegistrar implementation. But, it adds to the proxy, the implementation
of the ServiceLookup interface so that you can look for that to be implemented
by ServiceRegistrar, and take advantage of the extra features.
I started on a ServiceDiscoveryManager like replacement that would hide the
differences of the two lookup services and provide new features that only
ServiceLookup would provide the "fast, no downloads" capabilities, but existing
ServiceRegistrars would cause downloads and not be as scaleable.
Still haven't found time to finish that, but if there is real interest in this,
than I might be more motivated.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 29, 2009 at 2:05 AM, Gregg Wonderly<ge...@cox.net> wrote:
> Supporting RFC-119 means we need a new lookup mechanism that doesn't cause
> unmarshalling. I have in mind one way to implement that on top of reggie so
> that existing service registrations don't have to change what the do, only
> what version of reggie they register with.
>
> The use of type based lookups and supporting a new API for string based
> lookups with expressions etc doesn't mesh well with marshalled data unless
> you segregate what should be used from what is not interesting. Jini Entry
> objects can have very complex values in them, and unmarshalling is the "most
> robust" way to see those types for "user code". For the Reggie internals,
> the details are more visible because of how the "MarshalledInstance" is
> created. Exposing those details in a way that doesn't cause "downloading"
> or "unmarshalling" (which can lead to codebase contamination because of
> local class uses) is what is left to do.
I really liked this whole mail, and agree with all things I
understand, and trust your technical know-how in those things I don't.
As I said, I am not in a position to drive such effort, nor have a
strong opinion of whether RFC119 should be attempted here or not, or
whether an extension/complement to current lookup semantics should be
done... Apache is a lot about "scratch your own itch", and not about
pushing others into action for which they have no vested interest.
I simply don't have River in my current work portfolio.
So, by that, I leave the discussion to those who have a vested interest.
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
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
Niclas Hedhman wrote:
> On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<ge...@cox.net> wrote:
>
>> It comes down to whether that logic really must live in the lookup, or in
>> the client. And, as many people have said before, you can write a new
>> lookup "service" that uses these features and have your application lookup
>> that lookup server by interface, and then call methods on it to find the
>> matches.
>
> Ok, let's examine such "Named Service Properties Lookup";
>
> 1. It defines that each service can have N key-value pairs; No problems.
> 2. It will have a service interface that allow the lookup in OSGi
> syntax. No problems.
> 3. It will either require;
> a. That the service explicitly register itself at it.
> b. That the NSPL lookup all other services on the federation and
> extract the key-value pairs somehow, and possibly allow annotation of
> it independently.
>
> 3a is to me equal -> Will not be promoted, therefor not used.
> 3b is possible but seems like a big hack, compared to complementing
> the API with key-value mapped attributes and an expression language
> not executed by unmarshalling any service proxies.
>
>> Let me restate one thing, which I really don't think people appreciate.
>> Unmarshalling services in a client is EXPENSIVE. If you are picking 1, from
>> 100 instances by executing some code that the service proxy provides, there
>> will be problems.
>
> Isn't the above a strong argument against "let the client do it"?
> First do a general lookup, which provides 20 services, transport and
> unmarshall those service proxies to the client, and then inspect
> further. That can't be the way to do it, and I don't think you promote
> that either with your "It comes down to whether that logic really must
> live in the lookup, or in the client." statement, but it is how I
> initially read it.
I said a lot of different things in different ways that didn't help me make the
point, sorry for that.
1. You can't take the existing LUS mechanism and extend the API for
registration without making something visible in lookup.
2. You can't take the existing, marshalled values, and unmarshall them to look
at "strings" or other "data" for matching, so the new registration data has to
be represented as a "special" case and not part of what already happens.
3. Specialization can happen by using method signature changes, special Entry
types, or by layering lookup into something that uses the existing mechanisms in
ServiceRegistrar, but does something with the registration data.
For example, what if we created maps for each Entry that were
"com.my.company.package.EntryClass.fieldName" ==> "The string value"
for all fields that were native types? If we then transported that data
inside of the existing MarshalledInstance as separate data that was made
available on (my reef impl's) ServiceLookup interface, then a new RFC-119 lookup
could be implemented by looking for ServiceLookup on the ServiceRegistrar proxy,
and then getting the map of values and doing string comparisons.
> I am not here anymore to try and get OSGi and Jini communities to
> converge. That battle is long ago over, and both sides (IMHO) lost,
> since they didn't get a single inch closer.
I believe that neither side really had any productive conversations other than
"why don't you do XXXX it's what we need to integrate these technologies".
We needed to have the "why did you do it that way" conversations to help
everyone appreciate each others perspectives.
Supporting RFC-119 means we need a new lookup mechanism that doesn't cause
unmarshalling. I have in mind one way to implement that on top of reggie so
that existing service registrations don't have to change what the do, only what
version of reggie they register with.
The use of type based lookups and supporting a new API for string based lookups
with expressions etc doesn't mesh well with marshalled data unless you segregate
what should be used from what is not interesting. Jini Entry objects can have
very complex values in them, and unmarshalling is the "most robust" way to see
those types for "user code". For the Reggie internals, the details are more
visible because of how the "MarshalledInstance" is created. Exposing those
details in a way that doesn't cause "downloading" or "unmarshalling" (which can
lead to codebase contamination because of local class uses) is what is left to do.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Jul 28, 2009 at 3:19 AM, Gregg Wonderly<ge...@cox.net> wrote:
> It comes down to whether that logic really must live in the lookup, or in
> the client. And, as many people have said before, you can write a new
> lookup "service" that uses these features and have your application lookup
> that lookup server by interface, and then call methods on it to find the
> matches.
Ok, let's examine such "Named Service Properties Lookup";
1. It defines that each service can have N key-value pairs; No problems.
2. It will have a service interface that allow the lookup in OSGi
syntax. No problems.
3. It will either require;
a. That the service explicitly register itself at it.
b. That the NSPL lookup all other services on the federation and
extract the key-value pairs somehow, and possibly allow annotation of
it independently.
3a is to me equal -> Will not be promoted, therefor not used.
3b is possible but seems like a big hack, compared to complementing
the API with key-value mapped attributes and an expression language
not executed by unmarshalling any service proxies.
> Let me restate one thing, which I really don't think people appreciate.
> Unmarshalling services in a client is EXPENSIVE. If you are picking 1, from
> 100 instances by executing some code that the service proxy provides, there
> will be problems.
Isn't the above a strong argument against "let the client do it"?
First do a general lookup, which provides 20 services, transport and
unmarshall those service proxies to the client, and then inspect
further. That can't be the way to do it, and I don't think you promote
that either with your "It comes down to whether that logic really must
live in the lookup, or in the client." statement, but it is how I
initially read it.
> The basic issue from my perspective is that if people don't talk about
> specifics, but only generalize about the issues, resolution doesn't happen
> very fast. I try to talk about specifics,
Well, I agree that "actual usecases" are superior in discussions.
But there are psychological problems as well. Once you say "My
solution is superior because...", then the recipient will stop listen
and go into defense mode to find cracks in the armor (your argument),
and will counter (in this case), "Ha, rubbish. You can't even do
arithmetic lookup.". From then on the discussion is over and it
becomes a religious/political game of 'mine is longer than yours'...
I am not here anymore to try and get OSGi and Jini communities to
converge. That battle is long ago over, and both sides (IMHO) lost,
since they didn't get a single inch closer. OSGi has the "we can do it
all"-attitude at the moment, and the distributed solution (at API/SPI
level) has been formulated and solutions worked out. Jini community
can no longer become a 'contributing participant', and that is a
shame. River *could* choose to be 'conformist', i.e. take the RFC-119
spec and implement it with Jini technology, and in that process see
what 'new things' (detailed as you call it) would surface for Jini.
Organizationally, OSGi allows the public to write so called RFPs.
Those are "Requirement" docs which outlines the need, but don't touch
on the solution. The RFPs are expected to be extremely
usecase-oriented with hypothetical (or real) walk-thrus of what is
needed. Feel free to contribute the need for type hierarchies in
service lookups.
Personally, I like both Jini and OSGi, but regretfully I am currently
not working actively on either one of them (offers welcome ;-) )...
And I should be the last one to say what the communities should do to
move forward.
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
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
Niclas Hedhman wrote:
> On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<gr...@wonderly.org> wrote:
>
>> The issue which I think is never fully considered is that lookup is based on
>> the Java type system, including complex types, and not based on string
>> matching. If it was just string matching, we'd have RE support now. But
>> there is no defined RE syntax for "derived from" or "implements X" etc. The
>> Java type system provides that.
>
> Yes, that is the view of "Jini Zealot" ;-) and their argument is that
> Jini Lookup can't do algorithms and arithmetic. And as long as either
> side don't want to look for the converged solution, this status quo
> will remain, just like when I first brought this up 2-3 years ago. And
> Kriens & Co at OSGi will have the same 'we are so much better'
> attitude as well...
As just another perspective point, I consider this the "everything useful must
be part of the platform" confusion. Everything useful needs to be possible with
a platform in the space the platform is "used". But everything that everyone
finds useful just can't be part of the platform.
When I rant about programming languages reinventing the wheel and only syntax
being used to do something different that can be expressed in other languages, I
think of the same narrow minded view. Anything that is not provided "natively"
in a language or platform, either can't be done, or requires that you right some
code to do it. We are still at such low coding levels with such powerful
languages, that "can't be done" just doesn't come out as the point of contention.
And as I said in my other long winded response, in this case, someone can write
a service that provides such a lookup mechanism and encapsulate such logic
there. It would make most sense for such a service to use the ServiceRegistrar
Entry data to perform the searches.
My changes to Reggie (http://reef.dev.java.net) for "delayed unmarshalling"
would make it possible to then send the "unmarshalled" service data to the
caller as the results so that the codebase would remain uncontaminated etc.
I will conceded that a multi-layer service lookup is not really possible without
having access to the unmarshalled service data to be forwarded to the calling party.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
Niclas Hedhman wrote:
> On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<gr...@wonderly.org> wrote:
>
>> The issue which I think is never fully considered is that lookup is based on
>> the Java type system, including complex types, and not based on string
>> matching. If it was just string matching, we'd have RE support now. But
>> there is no defined RE syntax for "derived from" or "implements X" etc. The
>> Java type system provides that.
>
> Yes, that is the view of "Jini Zealot" ;-)
It's view that takes versioning into account and some other issues that I think
are under appreciated. Sure, strings are simple and easy, right up to the point
that you have to keep finding new ways to specify that you want to do something
that a hierarchical type system lets you do with one name, and strings make you
do with 10 values, 4 expressions and an extra "if" or two. Then, strings seem
kind of fragile and not so "cute".
> and their argument is that Jini Lookup can't do algorithms and arithmetic.
It comes down to whether that logic really must live in the lookup, or in the
client. And, as many people have said before, you can write a new lookup
"service" that uses these features and have your application lookup that lookup
server by interface, and then call methods on it to find the matches.
Whether that "mechanism" should be the primary service or not has always been
the sticking point for the Sun team. They always suggested (and I concurred)
that "Jini" doesn't keep you from doing that if you need it, so from a
"platform" perspective, it doesn't seem like something "Jini" should specify.
Instead, someone can write such a thing, make it available for others to use,
and the community could take advantage of it as needed.
I consider RIO an example of such a thing. The QOS facilities of RIO, some
could argue, could be part of the lookup. You could say:
o I want a service that's been up for a week at least
o I want a processor that is at least at 2.5ghz
o I want a service instance that has 1TB of work space on disk
and other things. But, this is such a specialized view of lookup, that it
doesn't seem like it should be in the "API". Some of that could be done in
Entry objects, but it might be better to do it with a "service" that can do the
analysis and make things happen that need to happen.
Let me restate one thing, which I really don't think people appreciate.
Unmarshalling services in a client is EXPENSIVE. If you are picking 1, from 100
instances by executing some code that the service proxy provides, there will be
problems.
> And as long as either
> side don't want to look for the converged solution, this status quo
> will remain, just like when I first brought this up 2-3 years ago. And
> Kriens & Co at OSGi will have the same 'we are so much better'
> attitude as well...
The basic issue from my perspective is that if people don't talk about
specifics, but only generalize about the issues, resolution doesn't happen very
fast. I try to talk about specifics, always, but there are people who just
don't want specifics, they just want to hear "yes", "no", "that sucks", "won't
do it", or "not invented here" kinds of things so they can ride the coattail of
arguments instead becoming educated in the reasoning and history in a way that
allows them to help the other party understand the differences they think are
important.
Detailed vs Concise are at opposite ends of the spectrum in most cases. Many
people are hard against one of these two terms without much desire to float
between them as needed. Detailed and Concise is usually only possible if all
the "details" have already been explained.
>> I will concede that the mechanics of matching in reggie are a
>> reimplementation of the type system semantics, because code is not
>> unmarshalled (as a versioning, code corruption, and security measure, at the
>> least).
>
> This is just a result of the initial decision to have Entry and
> inheritance as the basis for service attributes. Another decision
> could have been made that we only allow named properties, where the
> name is a String and the Value is any one of the following immutable
> types... In retrospect, can you really claim that the way Jini chose
> is superior an alternate route? I am not so sure...
A type like system is needed for type hierarchies. You can't match a type
hierarchy out of a single string without all of the hierarchy present in some
form, in that string.
It's interesting to talk about "values" and "named properties". Types, in Java,
are generally used to put groups of these pairs together.
It's the power of expanding a group, by amending it's contents that most
application history revolves around. Versioning in our brains and in practice
cause us to use Types to "constrain" groups of things into logical sets with the
type system providing a simple name/moniker for that group of items (and
functions in the OO world).
Practically, "maps" are another way to do this grouping. Maps don't have
mechanisms which allow you to assert that a given set of properties are present
at "compile time" without some specific qualities that are normally expressed in
code that lives somewhere. A name for those "semantics" has to exist to
properly represent "everything" that is detailed.
With just a map and no name/moniker, you have to look for, or request, or
enumerate all of them. This means that simple names in a type system must be
represented by a complex collection or list of "things".
Things like "corn flakes" are maps because every manufacturer has a specific
recipe and quality part of the product. "General Mills" or "Quaker" and other
brand names are like "class names" or types. They tell you a lot of specifics
about the corn flakes. To say everything about them without the brand name, you
have a lot of enumerated parts to keep up with, understand and process, everywhere.
There are reasons, beyond the "initial implementation did it this way" that make
the type system interesting from my perspective.
>> I'm more than willing to put together a new lookup service that does provide
>> "string only" lookup of Entry.toString() values. It would be possible to
>> include new data, taken from the Entry values before they are marshalled for
>> transport.
>>
>> My changes to reggie to support deferred downloading, include the packaging
>> of all class and interface names as part of the MarshalledInstance so that
>> you can ask if an Entry (or the service itself) "is a" without having to
>> unmarshall it.
>
> This proposal sounds like a hack. You are trying to work around
> marshalling, since you have made the choice that it should be
> marshalled. Be more bold and drop Entry, go with named attributes and
> see where it takes you.
I feel the type system matching that exists today needs to continue to be the
primary service lookup for Jini. It is what service lookup means when talking
to "Jini" services.
If we wanted to provide lookup for another set of service types, and we want the
ServiceRegistrar mechanisms to be used there so that non-jini clients do not
care what the source of the service is, than it seems to me that there can be
some duplicity of information made available in multiple formats in service
registration so that each user can access the data which they need and find to
be the most valuable for them.
I haven't really seen any other proposals (other than properties only), I'm just
sharing what I've currently considered in my thoughts.
>> There are lots of things that I suspect the OSGi camp is only now
>> discovering to be necessary "evils".
>
> Perhaps... or not. I think the current stock of solutions are mostly
> WS-* related, and they just inherit the problems under the hood.
I'm not plugged into those conversations, so you are right, they may not be
discovering anything new, or might not be after the same level of issues that
I'm looking for solutions to be available for.
Did I shed any light on how I am thinking about things that might make you see
something different about the two mechanisms?
Thanks for the continued conversation on these issues.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Jul 23, 2009 at 1:29 AM, Gregg Wonderly<gr...@wonderly.org> wrote:
> The issue which I think is never fully considered is that lookup is based on
> the Java type system, including complex types, and not based on string
> matching. If it was just string matching, we'd have RE support now. But
> there is no defined RE syntax for "derived from" or "implements X" etc. The
> Java type system provides that.
Yes, that is the view of "Jini Zealot" ;-) and their argument is that
Jini Lookup can't do algorithms and arithmetic. And as long as either
side don't want to look for the converged solution, this status quo
will remain, just like when I first brought this up 2-3 years ago. And
Kriens & Co at OSGi will have the same 'we are so much better'
attitude as well...
> I will concede that the mechanics of matching in reggie are a
> reimplementation of the type system semantics, because code is not
> unmarshalled (as a versioning, code corruption, and security measure, at the
> least).
This is just a result of the initial decision to have Entry and
inheritance as the basis for service attributes. Another decision
could have been made that we only allow named properties, where the
name is a String and the Value is any one of the following immutable
types... In retrospect, can you really claim that the way Jini chose
is superior an alternate route? I am not so sure...
> I'm more than willing to put together a new lookup service that does provide
> "string only" lookup of Entry.toString() values. It would be possible to
> include new data, taken from the Entry values before they are marshalled for
> transport.
>
> My changes to reggie to support deferred downloading, include the packaging
> of all class and interface names as part of the MarshalledInstance so that
> you can ask if an Entry (or the service itself) "is a" without having to
> unmarshall it.
This proposal sounds like a hack. You are trying to work around
marshalling, since you have made the choice that it should be
marshalled. Be more bold and drop Entry, go with named attributes and
see where it takes you.
> There are lots of things that I suspect the OSGi camp is only now
> discovering to be necessary "evils".
Perhaps... or not. I think the current stock of solutions are mostly
WS-* related, and they just inherit the problems under the hood.
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
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Sam Chance <sg...@gmail.com>.
Gregg,
That's more than reasonable! I wish I could go down to the details you
require, but I just can't. Partly because I don't get that detailed in my
work, and partly due to sensitivities of my customer space.
The net-net of it in my mind is that it provides the basis for (re-)using
pre-built, pre-tested and *pre-approved* software modules. From a software
acquisition point of view, I (really, my client space) can purchase only the
software required and not pay for the same things repeatedly and
unwittingly. The standardized modularization allows me, as a systems
integrator, to better streamline the different levels of testing. Similar
to auto parts, software "parts" become more commodotized and
interchangeable.
>From a architecture perspective, OSGi provides a dynamic and *in-VM* SOA.
Instead of only exposing [XML Web] services around the periphery, entire
systems can (are) be(ing) built as a collection of [OSGi] services. One can
also modularize bindings/protocols and use something like SCA to "wire them
into the system" [read: Paremus]. The dynamicity of OSGi allows for the idea
of "hot swapping". In fact, it seems Oracle has gone to excess discussing
the ability to "hot swap" components.
A "practical reality" benefit is the wide-scale buy-in. Major companies
who've committed to it include Oracle/Sun, IBM, SAP, Red Hat, SpringSource,
TIBCO, Sprint, Progress, and on and on. Apache ServiceMix, Jetty, JonAS (I
think) and others are built on OSGi. Many vendors with whom I deal most are
OSGi powered or in the process. Apache Felix, Eclipse Equinox, Knoplerfish
are OSGi runtimes. Paremus implements the *granddaddy* of them all though,
a distributed OSGi runtime. See
http://www.infoq.com/news/2008/02/infiniflow-12 for a "lightweight" intro.
Another benefit is the simplicity. The gist of it is a small amount of
metadata in the manifest file and a small state space for "deployed" bundles
(Started, Stopped, Active... a few more).
I learned today that a major "program" is migrating an entire, large system
to the OSGi technology platform.
All this isn't necessarily "technical", but I don't dwell exclusively in the
technical domain. I have to span from electrons to executives. It's just
the nature of my job. I will say my developers love me for introducing it.
Paremus is the company that saw the vision. They are the ones who made
[disributed OSGi] a reality. I'm simply spreading the flame inasmuch as I am
able.
My purpose for bringing OSGi up in the context of River is because I feel
OSGi is a "local JVM" version of Jini. And it seems reasonable to believe
they are even better paired together. At least one company, Paremus,
agrees.
So, if one decides they like the idea, what should they build? I don't
know. Maybe they could build a distribution framework that makes OSGi
bundles "visible" and "accessible" across the planet in one large repository
of functionality!
Next, they could extend the LookUp / query capability to semantic (i.e.
logical/contextual) lookup/discovery. See the Semantic Web Technology space
for more info at http://www.w3.org/2001/sw/, http://linkeddata.org.
Thank you!
Sam
On Thu, Jul 16, 2009 at 3:59 PM, Gregg Wonderly <ge...@cox.net> wrote:
> Sam, I am at a loss for words...
>
> It's clear that I am not able to ask for help in understanding the benefits
> that you see, or perhaps you can't relate them to me. I'm just looking for
> your experiences and the values you see. I know what OSGi says it is. I
> know how to read the documentation (again and again) to see what it
> currently supports in each new release.
>
> That's not what I am looking for. I'm trying to get first hand reports and
> recommendations on what is valuable to those who have used it and deployed
> things using it. I want to see which of the possible set of features that
> Jini could provide for OSGi inter-working would allow someone to get some
> benefits.
>
> For example, preferred class loading solves some class loading issues.
> But, if some parts of OSGi have removed those benefits from your view and
> you don't need them any longer, I'd like to know more about that.
>
> Do you just like OSGi because it's a container that you drop things into
> and they work?
>
> I want to know the details of your experiences please.
>
> Gregg Wonderly
>
>
> Sam Chance wrote:
>
>> Gregg,
>>
>> It is not my desire or intention to try to play "technology ping-pong."
>> I'm
>> only introducing another viewpoint. Frankly, I don't have time to read
>> long, verbose emails. I've touted enough OSGi technology attributes to
>> intrigue those who might be interested in learning more. The answers to
>> your questions can be found on the OSGi Alliance's web site - and I
>> promise
>> you there are solid answers. Additionally, a number of books that provide
>> ample OSGi coverage are either recently published or nearing publication.
>>
>> Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and
>> others
>> offer a lot of informative OSGi literature as well. Neal Bartlett also
>> provides a lot of OSGi resources. Eclipse [Equinox] and Apache Felix are
>> great places as well.
>>
>> Happy Learning! :-)
>>
>> Sam
>>
>> On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <gr...@wonderly.org>
>> wrote:
>>
>> Sam Chance wrote:
>>>
>>> In fact, OSGi does help a lot with "Classpath Hell".
>>>>
>>>> I didn't see a reply from my earlier request for more information on
>>> the
>>> issues that the OSGi experienced think OSGi helps the most with regarding
>>> this issue. I'd really like to see what issues you all have had and that
>>> OSGi has addressed.
>>>
>>> Is it just that packaging encloses the set of things you need to make
>>> things work and you don't have to worry about that, or is it something
>>> else?
>>> Many containers use ClassLoader hierarchies of various shapes to isolate
>>> and "interrelate" different types of package structures. I'm just
>>> interested in knowing more about the issues and benefits you all
>>> recognize
>>> from your experiences.
>>>
>>> OSGi also adds another layer of security above the standard Java.
>>>>
>>> What do you feel is important about this? Authentication vs
>>> Authorization
>>> issues would be great to have your opinions and experience on.
>>>
>>> Versioning is a "first-class function" in OSGi.
>>>>
>>> This is a big deal for separating old and new. I think we have a good
>>> bit
>>> of this in the PreferredClass mechanisms in Jini 2.x so that
>>> implementations
>>> can be forced into use for bug fixing and interfacing with different
>>> versions of difference services. Is there anything else beside
>>> classloader
>>> based separation that you all find important in what OSGi provides?
>>>
>>> Gregg Wonderly
>>>
>>>
>>
>>
>>
>
--
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Michael,
That would be very much appreciated.
Best Regards,
Peter.
Michal Kleczek wrote:
> On Thursday, 23 of July 2009 06:11:01 Peter Firmstone wrote:
>
>> HTTP codebase's are part of the problem, the URLClassLoader is fixed in the
>> object's Type (class identity), which may change over time. Michael Warres
>> addressed this problem by creating a dynamic codebase service where the URL
>> was a cryptographic hash of the jar file (stored data) identity.
>>
>> Michael made a presentation on Service based codebases, apparently not
>> much code was required to implement it. We cannot directly copy the
>> code (interfaces etc) from the presentation due to copyright, although
>> we can produce functionally equivalent code.
>>
>> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>>
>>
>
> We have implemented a similar solution in XPro.
> The main difference is that in our implementation there is no "put" operation
> in a ContentAddressedStore interface. In other words:
> 1. Each service publishes a separate ContentAddressStore and becomes its own
> codebase server.
> 2. You can run specialized services that cache resources from other
> ContentAddressStores to achieve HA
> 3. Optionally you can configure the services to act in a P2P fashion - the
> resources downloaded by a service are also published.
>
> The main motivation behind this was to be able to run services with minimal
> dependencies on other services being available on the network.
>
> After resolving some licencing problems (which should not be very complicated
> I think) we could contribute this code to River.
>
> Thanks,
> Michal
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Michal,
That would be very much appreciated, p2p sounds like a good idea too.
Best Regards,
Peter Firmstone.
Michal Kleczek wrote:
> On Thursday, 23 of July 2009 06:11:01 Peter Firmstone wrote:
>
>> HTTP codebase's are part of the problem, the URLClassLoader is fixed in the
>> object's Type (class identity), which may change over time. Michael Warres
>> addressed this problem by creating a dynamic codebase service where the URL
>> was a cryptographic hash of the jar file (stored data) identity.
>>
>> Michael made a presentation on Service based codebases, apparently not
>> much code was required to implement it. We cannot directly copy the
>> code (interfaces etc) from the presentation due to copyright, although
>> we can produce functionally equivalent code.
>>
>> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>>
>>
>
> We have implemented a similar solution in XPro.
> The main difference is that in our implementation there is no "put" operation
> in a ContentAddressedStore interface. In other words:
> 1. Each service publishes a separate ContentAddressStore and becomes its own
> codebase server.
> 2. You can run specialized services that cache resources from other
> ContentAddressStores to achieve HA
> 3. Optionally you can configure the services to act in a P2P fashion - the
> resources downloaded by a service are also published.
>
> The main motivation behind this was to be able to run services with minimal
> dependencies on other services being available on the network.
>
> After resolving some licencing problems (which should not be very complicated
> I think) we could contribute this code to River.
>
> Thanks,
> Michal
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Michal Kleczek <mi...@xpro.biz>.
On Thursday, 23 of July 2009 06:11:01 Peter Firmstone wrote:
> HTTP codebase's are part of the problem, the URLClassLoader is fixed in the
> object's Type (class identity), which may change over time. Michael Warres
> addressed this problem by creating a dynamic codebase service where the URL
> was a cryptographic hash of the jar file (stored data) identity.
>
> Michael made a presentation on Service based codebases, apparently not
> much code was required to implement it. We cannot directly copy the
> code (interfaces etc) from the presentation due to copyright, although
> we can produce functionally equivalent code.
>
> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>
We have implemented a similar solution in XPro.
The main difference is that in our implementation there is no "put" operation
in a ContentAddressedStore interface. In other words:
1. Each service publishes a separate ContentAddressStore and becomes its own
codebase server.
2. You can run specialized services that cache resources from other
ContentAddressStores to achieve HA
3. Optionally you can configure the services to act in a P2P fashion - the
resources downloaded by a service are also published.
The main motivation behind this was to be able to run services with minimal
dependencies on other services being available on the network.
After resolving some licencing problems (which should not be very complicated
I think) we could contribute this code to River.
Thanks,
Michal
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Gregg,
Comments inline.
Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> Hi Gregg,
>>
>> I hear what your saying.
>> Can I share some thoughts?
>>
>> An Object's Class Type is the fully qualified class name + the
>> originating ClassLoader.
>
> Once it is live in the VM, it is, but until that time, it's the source
> "jar" that represents the "type" because versioning is expressed
> there. Michael Warres' paper indicates this, and I think you grasp
> that concept. The classloader is just a software representation of
> the contents of the Jar file.
I'd like to make versioning finer grained than that, at least for
applications, I'd like to segregate at the Package level, many class
files don't change once applications mature, for Library's it makes
better sense to have a coarse grained versioning mechanism.
>
>> HTTP codebase's are part of the problem, the URLClassLoader is fixed
>> in the object's Type (class identity), which may change over time.
>> Michael Warres addressed this problem by creating a dynamic codebase
>> service where the URL was a cryptographic hash of the jar file
>> (stored data) identity.
>
> The codebase, if not designed with versioning as part of the
> expression of it, is the root cause of missing "version" information.
> It's still possible to create multiple class loaders using the same
> URL at different times, and have those classloaders do things like
> store the Jar locally, be long lived and be resurrectable across
> processes etc.
>
> The Hash is a good solution, but does require some tooling for service
> deployment and perhaps a container mechanism to make easy use of, but
> it's still possible to use it manually with just a few tools.
>
>> Michael made a presentation on Service based codebases, apparently
>> not much code was required to implement it. We cannot directly copy
>> the code (interfaces etc) from the presentation due to copyright,
>> although we can produce functionally equivalent code.
>>
>> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>>
>>
>> See also River-316
>>
>> So the dynamic service based codebase could move around, and be
>> offered redundantly.
>
> I wrote a protocol handler which would be used as
>
> -Djava.protocol.handler.pkgs="codebase:service-dl.jar
> codebase:jsk-dl.jar"
>
> which would do service lookup, and then ask services "do you provide
> service-dl.jar" and "do you provide jsk-dl.jar". It would then get
> the jars from one of the services that answered yes, and return the
> URLConnection to the downloaded jar as a "file:" URL.
>
> I didn't ever deploy anything using this, because I really don't run
> into problems of services working but the codebase provider not
> working, very often, if at all in production. It happens occasionally
> in development.
I'm really keen to see Michal's code that may be on offer from XPro, as
it supports a P2P mechanism. However please upload.
>
>> In addition, we could update/upgrade/replace the Hierarchical based
>> PreferredClassLoader relationship with a more flexible
>> DynamicClassLoader based on ClassWorlds to segregate incompatible
>> class packages while granting compatible classes the ability to
>> communicate. There is BSD licensed code that we could build on:
>>
>> http://classworlds.codehaus.org/ ClassWorlds has some very elegant
>> simple models (easy to code & use) that may help us.
>
> I'll try and look at ClassWorlds. The PreferredClassLoader provides
> one mechanism that allows the "implementation" vs "contract" aspect of
> a class/interface to be specified and thus where it is loaded from,
> controlled. The fact that it defers to its "parent" when "not
> preferred" just means that we could do anything with the rest of the
> loading process which should really just leave 2 types of classes, the
> "JVM classes" and the "contract classes". Both might have version
> related details. The "JVM classes" would imply something a bit harder
> to "solve" at runtime. But, the "contract classes" versioning could
> be specified by some additional information in the PREFERRED.LIST
> perhaps.
>
> Understand when I said "parent" above that I'm not suggesting that
> there should be a linear hierarchy of ClassLoaders. Just that the
> parent is the next place to defer to.
>
>>> From the above website: "The |classworlds| model does away with the
>>> hierarchy normally associated with ClassLoaders. Instead, there is
>>> a pool of ClassRealms
>>> <http://classworlds.codehaus.org/apidocs/com/codehaus/classworlds/ClassRealm.html>
>>> which can import arbitrary packages from other ClassRealms.
>>> Effectively, |classworlds| turns the old-style hierarchy into a
>>> directed graph."
>>
>> One might give a library its own ClassLoader in each JVM for
>> instance, then we could make that library available to the
>> applications / services that depended upon it. A later version of
>> that library would have a separate ClassLoader so that "Jar hell" or
>> "Classpath Hell" (standalone JVM talk) or its distributed equivalent
>> "Class Type Hell" or "ClassLoader Hell" are avoided (unfair:
>> ClassLoaders are a blessing in disguise, they add another dimension
>> to namespaces).
>
> One thing that I think makes sense is to put together some trial
> version management bits of code. The mechanics are the important part
> to "get right" first, and then we can survey what works and think
> about how to access it and put together automatic mechanisms where
> possible (the invocation layer would allow this to happen seamlessly
> for version "upgrades", not so sure about downgrades). Factory style
> methods could be used in iterative services where things are "loaded",
> "processed" and "stored".
Have a look at River-316, I've uploaded, code with plenty of comments &
Javadoc.
>
> I think this "space" already has had a lot of different things
> evaluated and things like "classworlds" show that some "code" has
> gelled in many places that provides solutions to various parts of the
> problem space.
I'm interested in ClassWorlds, to me, its a poor man's Subprocess API
(shame that never eventuated maybe it will in Harmony?), it would allow
isolation between packages, and libraries, limiting classpath scope to
only that which is requried.
>
> Gregg Wonderly
>
Cheers,
Peter.
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
Peter Firmstone wrote:
> Hi Gregg,
>
> I hear what your saying.
> Can I share some thoughts?
>
> An Object's Class Type is the fully qualified class name + the
> originating ClassLoader.
Once it is live in the VM, it is, but until that time, it's the source "jar"
that represents the "type" because versioning is expressed there. Michael
Warres' paper indicates this, and I think you grasp that concept. The
classloader is just a software representation of the contents of the Jar file.
> HTTP codebase's are part of the problem, the URLClassLoader is fixed in
> the object's Type (class identity), which may change over time. Michael
> Warres addressed this problem by creating a dynamic codebase service
> where the URL was a cryptographic hash of the jar file (stored data)
> identity.
The codebase, if not designed with versioning as part of the expression of it,
is the root cause of missing "version" information. It's still possible to
create multiple class loaders using the same URL at different times, and have
those classloaders do things like store the Jar locally, be long lived and be
resurrectable across processes etc.
The Hash is a good solution, but does require some tooling for service
deployment and perhaps a container mechanism to make easy use of, but it's still
possible to use it manually with just a few tools.
> Michael made a presentation on Service based codebases, apparently not
> much code was required to implement it. We cannot directly copy the
> code (interfaces etc) from the presentation due to copyright, although
> we can produce functionally equivalent code.
>
> http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
>
> See also River-316
>
> So the dynamic service based codebase could move around, and be offered
> redundantly.
I wrote a protocol handler which would be used as
-Djava.protocol.handler.pkgs="codebase:service-dl.jar codebase:jsk-dl.jar"
which would do service lookup, and then ask services "do you provide
service-dl.jar" and "do you provide jsk-dl.jar". It would then get the jars
from one of the services that answered yes, and return the URLConnection to the
downloaded jar as a "file:" URL.
I didn't ever deploy anything using this, because I really don't run into
problems of services working but the codebase provider not working, very often,
if at all in production. It happens occasionally in development.
> In addition, we could update/upgrade/replace the Hierarchical based
> PreferredClassLoader relationship with a more flexible
> DynamicClassLoader based on ClassWorlds to segregate incompatible class
> packages while granting compatible classes the ability to communicate.
> There is BSD licensed code that we could build on:
>
> http://classworlds.codehaus.org/ ClassWorlds has some very elegant
> simple models (easy to code & use) that may help us.
I'll try and look at ClassWorlds. The PreferredClassLoader provides one
mechanism that allows the "implementation" vs "contract" aspect of a
class/interface to be specified and thus where it is loaded from, controlled.
The fact that it defers to its "parent" when "not preferred" just means that we
could do anything with the rest of the loading process which should really just
leave 2 types of classes, the "JVM classes" and the "contract classes". Both
might have version related details. The "JVM classes" would imply something a
bit harder to "solve" at runtime. But, the "contract classes" versioning could
be specified by some additional information in the PREFERRED.LIST perhaps.
Understand when I said "parent" above that I'm not suggesting that there should
be a linear hierarchy of ClassLoaders. Just that the parent is the next place
to defer to.
>> From the above website: "The |classworlds| model does away with the
>> hierarchy normally associated with ClassLoaders. Instead, there is a
>> pool of ClassRealms
>> <http://classworlds.codehaus.org/apidocs/com/codehaus/classworlds/ClassRealm.html>
>> which can import arbitrary packages from other ClassRealms.
>> Effectively, |classworlds| turns the old-style hierarchy into a
>> directed graph."
>
> One might give a library its own ClassLoader in each JVM for instance,
> then we could make that library available to the applications / services
> that depended upon it. A later version of that library would have a
> separate ClassLoader so that "Jar hell" or "Classpath Hell" (standalone
> JVM talk) or its distributed equivalent "Class Type Hell" or
> "ClassLoader Hell" are avoided (unfair: ClassLoaders are a blessing in
> disguise, they add another dimension to namespaces).
One thing that I think makes sense is to put together some trial version
management bits of code. The mechanics are the important part to "get right"
first, and then we can survey what works and think about how to access it and
put together automatic mechanisms where possible (the invocation layer would
allow this to happen seamlessly for version "upgrades", not so sure about
downgrades). Factory style methods could be used in iterative services where
things are "loaded", "processed" and "stored".
I think this "space" already has had a lot of different things evaluated and
things like "classworlds" show that some "code" has gelled in many places that
provides solutions to various parts of the problem space.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Gregg,
I hear what your saying.
Can I share some thoughts?
An Object's Class Type is the fully qualified class name + the originating ClassLoader.
HTTP codebase's are part of the problem, the URLClassLoader is fixed in the object's Type (class identity), which may change over time. Michael Warres addressed this problem by creating a dynamic codebase service where the URL was a cryptographic hash of the jar file (stored data) identity.
Michael made a presentation on Service based codebases, apparently not
much code was required to implement it. We cannot directly copy the
code (interfaces etc) from the presentation due to copyright, although
we can produce functionally equivalent code.
http://www.jini.org/files/meetings/eighth/presentations/Warres/Warres.pdf
See also River-316
So the dynamic service based codebase could move around, and be offered redundantly.
In addition, we could update/upgrade/replace the Hierarchical based PreferredClassLoader relationship with a more flexible DynamicClassLoader based on ClassWorlds to segregate incompatible class packages while granting compatible classes the ability to communicate. There is BSD licensed code that we could build on:
http://classworlds.codehaus.org/ ClassWorlds has some very elegant simple models (easy to code & use) that may help us.
>From the above website: "The |classworlds| model does away with the hierarchy normally associated with ClassLoaders. Instead, there is a pool of ClassRealms <http://classworlds.codehaus.org/apidocs/com/codehaus/classworlds/ClassRealm.html> which can import arbitrary packages from other ClassRealms. Effectively, |classworlds| turns the old-style hierarchy into a directed graph."
One might give a library its own ClassLoader in each JVM for instance,
then we could make that library available to the applications / services
that depended upon it. A later version of that library would have a
separate ClassLoader so that "Jar hell" or "Classpath Hell" (standalone
JVM talk) or its distributed equivalent "Class Type Hell" or
"ClassLoader Hell" are avoided (unfair: ClassLoaders are a blessing in
disguise, they add another dimension to namespaces).
The new com.sun.jini.tool.classdepend package has functionality to
record class dependency relationships in an array, this could be
modified to also store each classes unique sha-1 or md5 hash, as well as
serialVersionUID's, if they implement Serialisable or Externalizable,
this dependency array or a similar string hash (similar to your
suggestion on namespaces) could be returned on request as part of the
codebase service.
I purchased a copy of the following paper online (Thank's Jim for the
tip), I found a freely available copy you can all read. Its called
Modular Software Upgrades for Distributed Sytems by Sameer Ajmant,
Barbara Liskov and Liuba Shrira. It discusses updating services in
distributed systems. It is a course grained versioning system.
http://www.pmg.csail.mit.edu/~ajmani/papers/ecoop06-upgrades.pdf
So I'm currently trying to get my head around a new ClassLoader
framework for classes where a developer knows which objects need to be
preserved over time, while their underlaying class implementations may
change, this would be a fine grained versioning system, at the Class
Level. The new package com.sun.jini.tools.classdepend can return a
dependency tree stored in an array, this could be extended to record
each classes unique sha-1 or md5 hash, as well as serialVersionUID's, if
they implement Serialisable or Externalizable, it already stores the
fully qualified class name. The sha-1 or md5 hash would also form part
of Security of downloaded code as this could be checked before loading
the Class file.
Versioning, Identity and preservation of object state / contents over
time is much harder and is unsolved. Jim Waldo recommends Classes
implement interfaces, where only the interfaces are used. This allows
objects from different ClassLoaders that implement the same interface to
interact and be interchanged. For instance if you have a Class called
Money.class (version 1) and you reimplement its methods and add
additional methods in Money.class(version 2), the only way the objects
can be used in the same array etc is if they share a common Interface or
ancestor class. If you inherit Money.class (version 1) and call it
MoneyTree.class you can override all replaced methods and add additional
methods and it can be used as a money object, however you can't use the
new additional methods when in company with the original class Money's
objects, only those that existed prior.
To overcome this problem, I'm thinking about a ClassLoader Versioning
Framework for Objects we want to distribute and preserve over time,
preserving their state and contents while retaining the ability to
upgrade their class files or bytecodes and also changing their type,
using Interfaces to enable interoperability between objects with
different types. Serialization can be used to upgrade objects class file
bytecodes (marshall, unmarshall into a replacement ClassLoader) with
required visibility granted by what we can build on using ClassWorlds.
Any objects linking to the VersionedObjects could be strongly linked via
a reference object that was updated with the VersionedObject's new hard
reference location, all other objects could be strongly linked to the
ReferenceObject and retrieve a weak link from the reference object to
the VersionedObject. The ClassLoader Versioning Framework would keep a
weak reference to each ReferenceObject with a Lease, after the Lease
expires, the ClassLoader would check if that object still existed
(weakly referenced, may have been garbage collected) and if so, check if
its Class file has been updated via an Update Service, which returns the
hash code for the update Class file. Alternately this could be
requested via a ClassLoader method, each time a weak reference is
requested through the ReferenceObject. The VersioningClassLoader would
then, with the hashcode, request a codebaseURL from the Codebase Service
and create the new version in another ClassLoader, the new
VersionedObject would be strongly referenced by the existing
ReferenceObject, leaving the old VersionedObject with no strong
reference, to be Garbage Collected.
All VersionedObject's must implement Serializable.
A Mutable object would require a Transaction Manager.
Identity is more difficult, for objects who's identity is sufficiently
determined by the equals() and hashCode() methods this should be
sufficient. However objects that require a unique identity can be
broken down again into two types:
1. Immutable objects where Object.equals() doesn't determine object
Identity.
2. Mutable objects where Object.equals() doesn't determine object Identity.
I think #1 could be handled by an ObjectUniqueID service that provides
three unique numbers; The time in milliseconds at the time of request
and two random numbers. The object would receive this service at
instantiation time if required. The likelihood that two random numbers
and the time in milliseconds would produce a match for the same fully
quallified class name would be vary rare indeed.
Well #2 would be more complex, this object would need a Transaction
Manager, and also require the ObjectUniqueID service at the time of
instantiation.
With this in mind, I have no idea how to instantiate or construct a
VersionedObject, I haven't yet figured this part out, perhaps it could
be implemented by:
Interface VersioningClassLoader {
public ReferenceObject instantiate(Builder builderObject, String
fullyQualifiedClassName){};
}
Calling methods on the VersionedObject could be done by:
ReferenceObject ob = versionedClassLoaderInstance.instantiate(builder,
"my.package.classname");
ACommonInterface foo = ob.getWeakRef(); // The ReferenceObject checks
the lease is valid first.
or to execute some method:
ob.getWeakRef().someMethod();
When all strong links to the ReferenceObject and the VersionedObject it
points to, go out of scope, the ReferenceObject and the VersionedObject
can be garbage collected.
Each ClassLoader would be garbage collected after all VersionedObjects
it manages go out of scope (no strong references left) objects whose
leases have expired would be migrated to new ClassLoaders, each
classloader might have a maximum age determined by maximum Lease time +
a time window during which it can be given new VersionedObjects.
All objects that the VersionedObjects depend upon, would be considered
supporting objects and would go out of scope once the VersionedObjects
do, for example a new class file upgrade might dictate another version
of an external library, new objects required by the VersionedObject
would have to be created during unmarshalling and the new class files
for the library downloaded via the codebase Service, the codebase
service would also advertise via the service, the dependency tree it
contains, so the VersioningClassLoader Framework would determine the
Libraries suitability and make it available via a LibraryClassLoader if
it isn't already available.
All objects upon unmarshalling would be checked to see if they currently
exist in memory based on Lease Validity, identity or equality and if so
the in memory object used.
What I'm talking about is conceptual and experimental, I'm hoping others
will be able to provide some thoughts / input, assist and see if we
can't produce something useful along with the changes you've made and
lessons learned. Or alternatively tell me I'm totally nuts ;)
Cheers,
Peter.
Gregg Wonderly wrote:
> Niclas Hedhman wrote:
>> OSGi zealots don't like Jini for many reasons, probably in reality
>> driven by politics more than technology. One key technology that has
>> repeatedly been mentioned to me as a show-stopper for even considering
>> Jini in a more central role, is the differences in "service
>> attributes/properties". Jini's 'exact-match' Entry matching is
>> considered inferior of the LDAP expressions of OSGi. Somehow it feels
>> like a weak argument, and I think River today would consider
>> convergence on this point.
>
> The issue which I think is never fully considered is that lookup is
> based on the Java type system, including complex types, and not based
> on string matching. If it was just string matching, we'd have RE
> support now. But there is no defined RE syntax for "derived from" or
> "implements X" etc. The Java type system provides that.
>
> I will concede that the mechanics of matching in reggie are a
> reimplementation of the type system semantics, because code is not
> unmarshalled (as a versioning, code corruption, and security measure,
> at the least).
>
> I'm more than willing to put together a new lookup service that does
> provide "string only" lookup of Entry.toString() values. It would be
> possible to include new data, taken from the Entry values before they
> are marshalled for transport.
>
> My changes to reggie to support deferred downloading, include the
> packaging of all class and interface names as part of the
> MarshalledInstance so that you can ask if an Entry (or the service
> itself) "is a" without having to unmarshall it.
>
> Mobile code is non-trivial. Many of us have experience now, and River
> has some additional tools that were not in place before
> (PreferredClassLoader for one) which can "help" manage class
> dependency trees so that unmarshalled object can avoid being corrupted.
>
> My http://griddle.dev.java.net project illustrates that you can have a
> "Javaspace" like thing with live code, including matching using code.
> I separated the keys from the data though so that you can use native
> types for keys and unmarshalling them doesn't "load" any code.
>
> There are lots of things that I suspect the OSGi camp is only now
> discovering to be necessary "evils". Some will be things we can work
> around or do differently.
>
> Designing a completely new lookup, and getting it into the "Jini
> world" might be a useful task, but we will only be able to do that one
> time, I'm guessing.
>
> OSGi was aimed at "everyone you want, can participate" in this VM.
> Jini was aimed at "everyone who wants to, can run code" in this VM.
> There are different considerations for each.
>
> Participation in OSGi is selected participation because the container
> is loaded with what you want to run. Jini is open participation,
> because the network is full of things that want to run. It's the
> subtle, but important difference in who initiates the installation of
> the software that makes all the difference.
>
> Gregg Wonderly
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <gr...@wonderly.org>.
Niclas Hedhman wrote:
> OSGi zealots don't like Jini for many reasons, probably in reality
> driven by politics more than technology. One key technology that has
> repeatedly been mentioned to me as a show-stopper for even considering
> Jini in a more central role, is the differences in "service
> attributes/properties". Jini's 'exact-match' Entry matching is
> considered inferior of the LDAP expressions of OSGi. Somehow it feels
> like a weak argument, and I think River today would consider
> convergence on this point.
The issue which I think is never fully considered is that lookup is based on the
Java type system, including complex types, and not based on string matching. If
it was just string matching, we'd have RE support now. But there is no defined
RE syntax for "derived from" or "implements X" etc. The Java type system
provides that.
I will concede that the mechanics of matching in reggie are a reimplementation
of the type system semantics, because code is not unmarshalled (as a versioning,
code corruption, and security measure, at the least).
I'm more than willing to put together a new lookup service that does provide
"string only" lookup of Entry.toString() values. It would be possible to
include new data, taken from the Entry values before they are marshalled for
transport.
My changes to reggie to support deferred downloading, include the packaging of
all class and interface names as part of the MarshalledInstance so that you can
ask if an Entry (or the service itself) "is a" without having to unmarshall it.
Mobile code is non-trivial. Many of us have experience now, and River has some
additional tools that were not in place before (PreferredClassLoader for one)
which can "help" manage class dependency trees so that unmarshalled object can
avoid being corrupted.
My http://griddle.dev.java.net project illustrates that you can have a
"Javaspace" like thing with live code, including matching using code. I
separated the keys from the data though so that you can use native types for
keys and unmarshalling them doesn't "load" any code.
There are lots of things that I suspect the OSGi camp is only now discovering to
be necessary "evils". Some will be things we can work around or do differently.
Designing a completely new lookup, and getting it into the "Jini world" might be
a useful task, but we will only be able to do that one time, I'm guessing.
OSGi was aimed at "everyone you want, can participate" in this VM. Jini was
aimed at "everyone who wants to, can run code" in this VM. There are different
considerations for each.
Participation in OSGi is selected participation because the container is loaded
with what you want to run. Jini is open participation, because the network is
full of things that want to run. It's the subtle, but important difference in
who initiates the installation of the software that makes all the difference.
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Jul 17, 2009 at 3:59 AM, Gregg Wonderly<ge...@cox.net> wrote:
> I'm trying to get first hand reports and
> recommendations on what is valuable to those who have used it and deployed
> things using it.
Here is my take;
When I put Jini (1.x) to work in a commercial application back in
2000/2001, I had quite a lot of problems related to classloading. And
just as Jini is built on a solid foundation of Network Understanding
(8 fall... and so on), OSGi has tackled (in Release 4) the
classloading problem straight on. A R4 container will build class
spaces, where compatible versions of classes are clustered together,
and where multiple versions are allowed to co-exist. It also provides
well-defined lifecycle for classloading, for instance; If a bundle is
unloaded, the classes will remain in memory until a "refresh" is made,
when the container will drop the class space affected and rebuild it,
and meanwhile stopping the bundles affected.
Compare that to the RMI/Jini classloader model where "I have no clue
what is going on, and when it goes wrong..." state of mind is the norm
rather than the exception. Hierarchical classloader are primitive at
best, and the JDK implementation is "naive". Or in other words, I
think OSGi is to classloading what Jini is to networking --> The
better solution.
OSGi *also* defines a Service mechanism as well as a bunch of standard
services. Until the current D-OSGi spec (soon out in OSGi Release 4.2
spec), all the service stuff was in-JVM only, *although* in OSGi
Release 3, there was a specification for Jini integration, but lack of
Jini expertise in OSGi combined with 'not easily resolvable issues'
(i.e. spec might not have been properly implementable) led to it being
dropped from Release 4.0 (which ironically contained the advanced
classloading mechanisms that Jini could benefit from).
D-OSGi is a specification of *how* to hook in a resolution mechanism
for remote access, either in-coming or out-going. From an OSGi PoV it
is fairly simple stuff. Basically, you can register resolvers in the
Service Registry, that are involved in the "register service" and
"lookup service" method calls. Making a Jini implementation is
probably easier than some of the other that are being attempted.
OSGi zealots don't like Jini for many reasons, probably in reality
driven by politics more than technology. One key technology that has
repeatedly been mentioned to me as a show-stopper for even considering
Jini in a more central role, is the differences in "service
attributes/properties". Jini's 'exact-match' Entry matching is
considered inferior of the LDAP expressions of OSGi. Somehow it feels
like a weak argument, and I think River today would consider
convergence on this point.
Personally, I don't think there is any point trying to convince the
River community that they should bet on OSGi. The interests here are
too diverse for reaching consensus and would probably lead to another
round of 'paralysis'. Instead, I would encourage a subproject in River
that makes an OSGi RFC-119 implementation with the knowledge and
source code available here (if only I had more time/money). If the
work is well done, it becomes plug-n-play for OSGi developers and
possibly quick fresh breath of air in River. I would also recommend
that such effort is not stopping the people who want to push River
forward.
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
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sure Freeman, feel free to post any thoughts. What are your thoughts
Dennis?
Cheers,
Peter.
Freeman Jackson wrote:
> Is it possible to conduct a thought experiment using OSGi &
> JavaSpaces. Peter I am not saying that OSGi is a JavaSpaces issue but
> I think that most of I have seen with OSGi is more JavaSpaces related.
>
> On Thu, Feb 4, 2010 at 6:20 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Hi Tom,
>>
>> I thought I'd grab this thread again, as it still appears to be an issue and
>> I'm now in a better position to answer.
>>
>> Both Jini and OSGi use their implementation of the Publish, Find, Bind
>> pattern as an abstraction or façade to enable the implementation behind it
>> to be hot plugged, they both use the term service.
>>
>> I've realised that there is no need to map a Jini service to an OSGi
>> service, nor worry about the different semantics between them. Why? You
>> only need one abstraction, why have an abstraction on an abstraction? And
>> if you want to get technical each solves a different problem, so one is not
>> better than the other or in a competitive relationship:
>>
>> * You use your OSGi service to change out, swap between, iterate
>> over or group your modules (bundles). It heavily utilises
>> ClassLoaders for limiting visibility to avoid classpath hell.
>> * You use your Jini service to abstract away the communication
>> protocol between two nodes, so they can exchange objects easily.
>> When the protocol changes, the client doesn't need to worry about
>> it. It also enables the construction of a distributed system from
>> the sum of its components and it enables the abstraction of
>> hardware and software components.
>>
>> Here's how to take advantage of OSGi from Jini, it is slightly different
>> from standard OSGi modularity practises, if you don't like it, use Preferred
>> Classloader instead, or use the existing http URL mechanism, you are not
>> committed to utilising OSGi, but those the are planning to use Jini Services
>> over the web will probably want to.
>>
>> 1. Create a bundle containing your service interfaces. The
>> interfaces will then be in their own ClassLoader, this is
>> important, so that others can implement the same service interface
>> without being dependant on and having to download your
>> implementation bundles.
>> 2. Create your Smart Proxy Implementation, it belongs within its own
>> bundle, it depends on one or more of the Interface bundle
>> packages. If the interface bundle extends interfaces from
>> external packages, (imports other bundle packages containing
>> interfaces) then you must import those interface packages also
>> otherwise the you will get a runtime exception. Software on the
>> client utilising your proxy will need to import the interface
>> packages and any additional packages that these interfaces
>> extend.. You also need to specify any permissions your proxy needs.
>> 3. For simple reflective proxies, the proxy will be loaded into the
>> interface bundle Classloader at the client.
>> 4. Create your Server Service Implementation, it must import the
>> packages from the Interface and the Smart Client Package bundles
>> and any other packages that the interface bundle extends.
>>
>> When a client utilises your service, it's bundle must lookup your service
>> from the Jini Lookup Service it might do this during bundle activation or it
>> might do so, at some other time. When that same client deactivates its
>> bundle that depends on your service (proxy), it also stops using your
>> service.
>>
>> Our bundles need to register with the Jini service registrar when activated
>> and de-register when deactivated. They don't need to be registered to the
>> OSGi service registry. Notice at no point here have I required any mapping
>> OSGi service. That would be a distraction abstraction ;) If I want to,
>> there's nothing stopping me from using an OSGi service from within my Jini
>> bundles, it's purely up to the implementer.
>>
>> At no time should we attempt to directly map an OSGi service to a Jini
>> Service or visa versa, they do not map well due to different lookup
>> semantics and the 8 fallacy's of distributed computing, instead create a
>> bundle that utilises a Jini Service, your bundle can register some other
>> service with the OSGi service registry so that you can plug in an
>> implementation that does work for an existing local software component,
>> which doesn't need to be aware that the Jini service even exists. Your
>> bundle will handle the 8 fallacy's of distributed computing and deactivate
>> itself if the you cannot rescue your service so that local components
>> depending on you are deactivated properly also.
>>
>> Cheers,
>>
>> Peter.
>>
>> Tom Hobbs wrote:
>>
>>> "I know you guys are very busy, but it would be nice if the most
>>> experienced Jini/River software engineers were able to dissect the
>>> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
>>> for Jini/River. I know it's tough to allocate time to do that though."
>>>
>>> Well, in the absence of the most experienced you're left with me. :-)
>>> For added confusion, I don't know a whole heap about OSGi either, so the
>>> follow is a likely mix of over simplification and misunderstanding.
>>>
>>> If that sounds useful, continue reading...
>>>
>>> This is the complete document, I skipped down to RFC 119 only;
>>> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>>>
>>> The RFC discusses the concept of a "Service Registry" which looks an
>>> awful lot like a River ServiceRegistrar. Delving further into the RFC
>>> it seems to me that we if we can translate from the specified interfaces
>>> that describe an "OSGi Service" to that which describes a "River
>>> Service" then River could slot in quite nicely as a response to this
>>> RFC.
>>>
>>> Much of the work feels like translating from what OSGi say service
>>> descriptions and lookups *should* look like and what River says service
>>> descriptions and lookups *do* look like.
>>>
>>> The only tricky part, I think, would be how an OSGi component (which
>>> likely extends something else) can be made into a River service such
>>> that it is discoverable in the usual way. This would be an interesting
>>> problem and raises the circumstance where an OSGi service might publish
>>> itself as an OSGi service, but because it's River underneath, would be
>>> discoverable by pure River clients on the same network also.
>>>
>>> Looking at how the RFC specifies what a service description is and what
>>> it looks like, I think that there is mileage in River adopting something
>>> similar. It would be nice, in my opinion, to move away from the
>>> quasi-java config files River uses in favour of something else.
>>> XML makes sense because that's what most of the rest of the world uses -
>>> although I personally don't care for it much.
>>>
>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>> ago was talking about using Groovy classes to describe service
>>> configuration. Something like this sounds pretty neat, but anything
>>> that needs to be recompiled for changes can take affect is likely to be
>>> unworkable for obvious reasons.
>>>
>>> Also, building in a mechanism to provide a similar version-sensitive
>>> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
>>> feature for River all other considerations not-withstanding.
>>>
>>> Anyway, that's this layman's interpretation of this OSGi RFC; if only
>>> for a few days or weeks of spare time to spend putting it together.
>>>
>>> Tom
>>>
>>> www.sucdenfinancial.com
>>>
>>> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
>>> London EC3R 5AZ
>>> Telephone +44 203 207 5000
>>>
>>> Registered in England no. 1095841
>>> VAT registration no. GB 446 9061 33
>>>
>>> Authorised and Regulated by the Financial Services Authority (FSA) and
>>> entered in the FSA register under no. 114239
>>>
>>> This email, including any files transmitted with it, is confidential and
>>> may be privileged. It may be read, copied and used only by the intended
>>> recipient. If you are not the intended recipient of this message, please
>>> notify postmaster@sucfin.com immediately and delete it from your computer
>>> system.
>>>
>>> We believe, but do not warrant, that this email and its attachments are
>>> virus-free, but you should check.
>>>
>>> Sucden Financial Limited may monitor traffic data of both business and
>>> personal emails. By replying to this email, you consent to Sucden Financial
>>> 's monitoring the content of any emails you send to or receive from Sucden
>>> Financial . Sucden Financial is not liable for any opinions expressed by the
>>> sender where this is a non-business email.
>>>
>>> The contents of this e-mail do not constitute advice and should not be
>>> regarded as a recommendation to buy, sell or otherwise deal with any
>>> particular investment.
>>>
>>> This message has been scanned for viruses by Mimecast.
>>>
>>>
>>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Freeman Jackson <sy...@gmail.com>.
Is it possible to conduct a thought experiment using OSGi &
JavaSpaces. Peter I am not saying that OSGi is a JavaSpaces issue but
I think that most of I have seen with OSGi is more JavaSpaces related.
On Thu, Feb 4, 2010 at 6:20 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Hi Tom,
>
> I thought I'd grab this thread again, as it still appears to be an issue and
> I'm now in a better position to answer.
>
> Both Jini and OSGi use their implementation of the Publish, Find, Bind
> pattern as an abstraction or façade to enable the implementation behind it
> to be hot plugged, they both use the term service.
>
> I've realised that there is no need to map a Jini service to an OSGi
> service, nor worry about the different semantics between them. Why? You
> only need one abstraction, why have an abstraction on an abstraction? And
> if you want to get technical each solves a different problem, so one is not
> better than the other or in a competitive relationship:
>
> * You use your OSGi service to change out, swap between, iterate
> over or group your modules (bundles). It heavily utilises
> ClassLoaders for limiting visibility to avoid classpath hell.
> * You use your Jini service to abstract away the communication
> protocol between two nodes, so they can exchange objects easily.
> When the protocol changes, the client doesn't need to worry about
> it. It also enables the construction of a distributed system from
> the sum of its components and it enables the abstraction of
> hardware and software components.
>
> Here's how to take advantage of OSGi from Jini, it is slightly different
> from standard OSGi modularity practises, if you don't like it, use Preferred
> Classloader instead, or use the existing http URL mechanism, you are not
> committed to utilising OSGi, but those the are planning to use Jini Services
> over the web will probably want to.
>
> 1. Create a bundle containing your service interfaces. The
> interfaces will then be in their own ClassLoader, this is
> important, so that others can implement the same service interface
> without being dependant on and having to download your
> implementation bundles.
> 2. Create your Smart Proxy Implementation, it belongs within its own
> bundle, it depends on one or more of the Interface bundle
> packages. If the interface bundle extends interfaces from
> external packages, (imports other bundle packages containing
> interfaces) then you must import those interface packages also
> otherwise the you will get a runtime exception. Software on the
> client utilising your proxy will need to import the interface
> packages and any additional packages that these interfaces
> extend.. You also need to specify any permissions your proxy needs.
> 3. For simple reflective proxies, the proxy will be loaded into the
> interface bundle Classloader at the client.
> 4. Create your Server Service Implementation, it must import the
> packages from the Interface and the Smart Client Package bundles
> and any other packages that the interface bundle extends.
>
> When a client utilises your service, it's bundle must lookup your service
> from the Jini Lookup Service it might do this during bundle activation or it
> might do so, at some other time. When that same client deactivates its
> bundle that depends on your service (proxy), it also stops using your
> service.
>
> Our bundles need to register with the Jini service registrar when activated
> and de-register when deactivated. They don't need to be registered to the
> OSGi service registry. Notice at no point here have I required any mapping
> OSGi service. That would be a distraction abstraction ;) If I want to,
> there's nothing stopping me from using an OSGi service from within my Jini
> bundles, it's purely up to the implementer.
>
> At no time should we attempt to directly map an OSGi service to a Jini
> Service or visa versa, they do not map well due to different lookup
> semantics and the 8 fallacy's of distributed computing, instead create a
> bundle that utilises a Jini Service, your bundle can register some other
> service with the OSGi service registry so that you can plug in an
> implementation that does work for an existing local software component,
> which doesn't need to be aware that the Jini service even exists. Your
> bundle will handle the 8 fallacy's of distributed computing and deactivate
> itself if the you cannot rescue your service so that local components
> depending on you are deactivated properly also.
>
> Cheers,
>
> Peter.
>
> Tom Hobbs wrote:
>>
>> "I know you guys are very busy, but it would be nice if the most
>> experienced Jini/River software engineers were able to dissect the
>> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
>> for Jini/River. I know it's tough to allocate time to do that though."
>>
>> Well, in the absence of the most experienced you're left with me. :-)
>> For added confusion, I don't know a whole heap about OSGi either, so the
>> follow is a likely mix of over simplification and misunderstanding.
>>
>> If that sounds useful, continue reading...
>>
>> This is the complete document, I skipped down to RFC 119 only;
>> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>>
>> The RFC discusses the concept of a "Service Registry" which looks an
>> awful lot like a River ServiceRegistrar. Delving further into the RFC
>> it seems to me that we if we can translate from the specified interfaces
>> that describe an "OSGi Service" to that which describes a "River
>> Service" then River could slot in quite nicely as a response to this
>> RFC.
>>
>> Much of the work feels like translating from what OSGi say service
>> descriptions and lookups *should* look like and what River says service
>> descriptions and lookups *do* look like.
>>
>> The only tricky part, I think, would be how an OSGi component (which
>> likely extends something else) can be made into a River service such
>> that it is discoverable in the usual way. This would be an interesting
>> problem and raises the circumstance where an OSGi service might publish
>> itself as an OSGi service, but because it's River underneath, would be
>> discoverable by pure River clients on the same network also.
>>
>> Looking at how the RFC specifies what a service description is and what
>> it looks like, I think that there is mileage in River adopting something
>> similar. It would be nice, in my opinion, to move away from the
>> quasi-java config files River uses in favour of something else.
>> XML makes sense because that's what most of the rest of the world uses -
>> although I personally don't care for it much.
>>
>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>> ago was talking about using Groovy classes to describe service
>> configuration. Something like this sounds pretty neat, but anything
>> that needs to be recompiled for changes can take affect is likely to be
>> unworkable for obvious reasons.
>>
>> Also, building in a mechanism to provide a similar version-sensitive
>> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
>> feature for River all other considerations not-withstanding.
>>
>> Anyway, that's this layman's interpretation of this OSGi RFC; if only
>> for a few days or weeks of spare time to spend putting it together.
>>
>> Tom
>>
>> www.sucdenfinancial.com
>>
>> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
>> London EC3R 5AZ
>> Telephone +44 203 207 5000
>>
>> Registered in England no. 1095841
>> VAT registration no. GB 446 9061 33
>>
>> Authorised and Regulated by the Financial Services Authority (FSA) and
>> entered in the FSA register under no. 114239
>>
>> This email, including any files transmitted with it, is confidential and
>> may be privileged. It may be read, copied and used only by the intended
>> recipient. If you are not the intended recipient of this message, please
>> notify postmaster@sucfin.com immediately and delete it from your computer
>> system.
>>
>> We believe, but do not warrant, that this email and its attachments are
>> virus-free, but you should check.
>>
>> Sucden Financial Limited may monitor traffic data of both business and
>> personal emails. By replying to this email, you consent to Sucden Financial
>> 's monitoring the content of any emails you send to or receive from Sucden
>> Financial . Sucden Financial is not liable for any opinions expressed by the
>> sender where this is a non-business email.
>>
>> The contents of this e-mail do not constitute advice and should not be
>> regarded as a recommendation to buy, sell or otherwise deal with any
>> particular investment.
>>
>> This message has been scanned for viruses by Mimecast.
>>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by James Grahn <jg...@simulexinc.com>.
Lest I ruffle any feathers, the last sentence was meant to be neutral,
not a thumbs-down to OSGi. Poor phrasing.
jamesG
James Grahn wrote:
> I'm utterly unfamiliar with OSGi (hadn't heard of it until it shambled
> into this mailing list), but I will say this about using Groovy for
> configuration:
>
> The existing Jini configuration is the ultimate "one-off"; it's a DSL
> that is a narrow subset of Java that's not used anywhere else other than
> configuration, even within Jini (AFAIK).
>
> Groovy is a generalization of the existing Jini configuration that also
> grants developers access to better abstractions. Groovy is quite
> similar to Java, so there's little to explain to developers as they get
> started, and the resources to explain it are much larger (the Groovy
> community).
>
> So it's a marked improvement over the status quo in my book.
>
> I can't comment on how well this fits in with OSGi, nor am I certain
> that OSGi integration is desirable.
>
> jamesG
>
> Sam Chance wrote:
>> Tom,
>>
>> I think you are "tracking" in the direction I was suggesting. Peter's
>> email
>> is similarly aligned. I'm not meaning to imply that I am "right"; I'm
>> just
>> saying your and Peter's thoughts are congruent with my own. In fact,
>> OSGi
>> does help a lot with "Classpath Hell". OSGi also adds another layer of
>> security above the standard Java. Versioning is a "first-class
>> function" in
>> OSGi.
>>
>> Distributed OSGi, in my view, is almost an indirect reference to Jini!
>> Minimally, D-OSGi is well aligned with Jini/River and the opportunity to
>> implement it using River is clearly present.
>>
>> As for Jigsaw, Groovy, and Java 7 modules, I would steer clear. Decisions
>> about technology adoption are clearly not the result of superior
>> technology.
>> (Look no further than Jini!) OSGi is already enjoying wide adoption and
>> acceptance. Frankly, I attribute much of it to the *simplicity* of OSGi,
>> coupled with its elegance. Jigsaw is obscure at best; Groovy IMHO is
>> "one-off", and Java 7 is - well, who knows?
>>
>> The broad adoption of OSGi in automotive, mobile and enterprise
>> sectors is
>> clearly the enabler for "mass convergence". The press releases and other
>> public literature are pervasive and reflect a strong consensus.
>>
>> Having said all that, I also know that "computer science" can sometimes
>> appear to be an oxymoron! For all we know, Groovy and Jigsaw could be all
>> the rage next week! Still, it is logical and probable that OSGi will
>> become
>> the ubiquitous module system for Java. And convergence across heretofore
>> separate networks will usher in an enormous need for distributed services
>> and their requisite management.
>>
>> Just some thoughts.
>>
>> Sam
>>
>> On Mon, Jul 13, 2009 at 7:53 AM, Tom Hobbs <to...@sucfin.com> wrote:
>>
>>> "I know you guys are very busy, but it would be nice if the most
>>> experienced Jini/River software engineers were able to dissect the
>>> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
>>> for Jini/River. I know it's tough to allocate time to do that though."
>>>
>>> Well, in the absence of the most experienced you're left with me. :-)
>>> For added confusion, I don't know a whole heap about OSGi either, so the
>>> follow is a likely mix of over simplification and misunderstanding.
>>>
>>> If that sounds useful, continue reading...
>>>
>>> This is the complete document, I skipped down to RFC 119 only;
>>> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>>>
>>> The RFC discusses the concept of a "Service Registry" which looks an
>>> awful lot like a River ServiceRegistrar. Delving further into the RFC
>>> it seems to me that we if we can translate from the specified interfaces
>>> that describe an "OSGi Service" to that which describes a "River
>>> Service" then River could slot in quite nicely as a response to this
>>> RFC.
>>>
>>> Much of the work feels like translating from what OSGi say service
>>> descriptions and lookups *should* look like and what River says service
>>> descriptions and lookups *do* look like.
>>>
>>> The only tricky part, I think, would be how an OSGi component (which
>>> likely extends something else) can be made into a River service such
>>> that it is discoverable in the usual way. This would be an interesting
>>> problem and raises the circumstance where an OSGi service might publish
>>> itself as an OSGi service, but because it's River underneath, would be
>>> discoverable by pure River clients on the same network also.
>>>
>>> Looking at how the RFC specifies what a service description is and what
>>> it looks like, I think that there is mileage in River adopting something
>>> similar. It would be nice, in my opinion, to move away from the
>>> quasi-java config files River uses in favour of something else.
>>>
>>> XML makes sense because that's what most of the rest of the world uses -
>>> although I personally don't care for it much.
>>>
>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>> ago was talking about using Groovy classes to describe service
>>> configuration. Something like this sounds pretty neat, but anything
>>> that needs to be recompiled for changes can take affect is likely to be
>>> unworkable for obvious reasons.
>>>
>>> Also, building in a mechanism to provide a similar version-sensitive
>>> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
>>> feature for River all other considerations not-withstanding.
>>>
>>> Anyway, that's this layman's interpretation of this OSGi RFC; if only
>>> for a few days or weeks of spare time to spend putting it together.
>>>
>>> Tom
>>>
>>> www.sucdenfinancial.com
>>>
>>> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
>>> London EC3R 5AZ
>>> Telephone +44 203 207 5000
>>>
>>> Registered in England no. 1095841
>>> VAT registration no. GB 446 9061 33
>>>
>>> Authorised and Regulated by the Financial Services Authority (FSA) and
>>> entered in the FSA register under no. 114239
>>>
>>> This email, including any files transmitted with it, is confidential and
>>> may be privileged. It may be read, copied and used only by the intended
>>> recipient. If you are not the intended recipient of this message, please
>>> notify postmaster@sucfin.com immediately and delete it from your
>>> computer
>>> system.
>>>
>>> We believe, but do not warrant, that this email and its attachments are
>>> virus-free, but you should check.
>>>
>>> Sucden Financial Limited may monitor traffic data of both business and
>>> personal emails. By replying to this email, you consent to Sucden
>>> Financial
>>> 's monitoring the content of any emails you send to or receive from
>>> Sucden
>>> Financial . Sucden Financial is not liable for any opinions expressed
>>> by the
>>> sender where this is a non-business email.
>>>
>>> The contents of this e-mail do not constitute advice and should not be
>>> regarded as a recommendation to buy, sell or otherwise deal with any
>>> particular investment.
>>>
>>> This message has been scanned for viruses by Mimecast.
>>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by James Grahn <jg...@simulexinc.com>.
I'm utterly unfamiliar with OSGi (hadn't heard of it until it shambled
into this mailing list), but I will say this about using Groovy for
configuration:
The existing Jini configuration is the ultimate "one-off"; it's a DSL
that is a narrow subset of Java that's not used anywhere else other than
configuration, even within Jini (AFAIK).
Groovy is a generalization of the existing Jini configuration that also
grants developers access to better abstractions. Groovy is quite
similar to Java, so there's little to explain to developers as they get
started, and the resources to explain it are much larger (the Groovy
community).
So it's a marked improvement over the status quo in my book.
I can't comment on how well this fits in with OSGi, nor am I certain
that OSGi integration is desirable.
jamesG
Sam Chance wrote:
> Tom,
>
> I think you are "tracking" in the direction I was suggesting. Peter's email
> is similarly aligned. I'm not meaning to imply that I am "right"; I'm just
> saying your and Peter's thoughts are congruent with my own. In fact, OSGi
> does help a lot with "Classpath Hell". OSGi also adds another layer of
> security above the standard Java. Versioning is a "first-class function" in
> OSGi.
>
> Distributed OSGi, in my view, is almost an indirect reference to Jini!
> Minimally, D-OSGi is well aligned with Jini/River and the opportunity to
> implement it using River is clearly present.
>
> As for Jigsaw, Groovy, and Java 7 modules, I would steer clear. Decisions
> about technology adoption are clearly not the result of superior technology.
> (Look no further than Jini!) OSGi is already enjoying wide adoption and
> acceptance. Frankly, I attribute much of it to the *simplicity* of OSGi,
> coupled with its elegance. Jigsaw is obscure at best; Groovy IMHO is
> "one-off", and Java 7 is - well, who knows?
>
> The broad adoption of OSGi in automotive, mobile and enterprise sectors is
> clearly the enabler for "mass convergence". The press releases and other
> public literature are pervasive and reflect a strong consensus.
>
> Having said all that, I also know that "computer science" can sometimes
> appear to be an oxymoron! For all we know, Groovy and Jigsaw could be all
> the rage next week! Still, it is logical and probable that OSGi will become
> the ubiquitous module system for Java. And convergence across heretofore
> separate networks will usher in an enormous need for distributed services
> and their requisite management.
>
> Just some thoughts.
>
> Sam
>
> On Mon, Jul 13, 2009 at 7:53 AM, Tom Hobbs <to...@sucfin.com> wrote:
>
>> "I know you guys are very busy, but it would be nice if the most
>> experienced Jini/River software engineers were able to dissect the
>> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
>> for Jini/River. I know it's tough to allocate time to do that though."
>>
>> Well, in the absence of the most experienced you're left with me. :-)
>> For added confusion, I don't know a whole heap about OSGi either, so the
>> follow is a likely mix of over simplification and misunderstanding.
>>
>> If that sounds useful, continue reading...
>>
>> This is the complete document, I skipped down to RFC 119 only;
>> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>>
>> The RFC discusses the concept of a "Service Registry" which looks an
>> awful lot like a River ServiceRegistrar. Delving further into the RFC
>> it seems to me that we if we can translate from the specified interfaces
>> that describe an "OSGi Service" to that which describes a "River
>> Service" then River could slot in quite nicely as a response to this
>> RFC.
>>
>> Much of the work feels like translating from what OSGi say service
>> descriptions and lookups *should* look like and what River says service
>> descriptions and lookups *do* look like.
>>
>> The only tricky part, I think, would be how an OSGi component (which
>> likely extends something else) can be made into a River service such
>> that it is discoverable in the usual way. This would be an interesting
>> problem and raises the circumstance where an OSGi service might publish
>> itself as an OSGi service, but because it's River underneath, would be
>> discoverable by pure River clients on the same network also.
>>
>> Looking at how the RFC specifies what a service description is and what
>> it looks like, I think that there is mileage in River adopting something
>> similar. It would be nice, in my opinion, to move away from the
>> quasi-java config files River uses in favour of something else.
>>
>> XML makes sense because that's what most of the rest of the world uses -
>> although I personally don't care for it much.
>>
>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>> ago was talking about using Groovy classes to describe service
>> configuration. Something like this sounds pretty neat, but anything
>> that needs to be recompiled for changes can take affect is likely to be
>> unworkable for obvious reasons.
>>
>> Also, building in a mechanism to provide a similar version-sensitive
>> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
>> feature for River all other considerations not-withstanding.
>>
>> Anyway, that's this layman's interpretation of this OSGi RFC; if only
>> for a few days or weeks of spare time to spend putting it together.
>>
>> Tom
>>
>> www.sucdenfinancial.com
>>
>> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
>> London EC3R 5AZ
>> Telephone +44 203 207 5000
>>
>> Registered in England no. 1095841
>> VAT registration no. GB 446 9061 33
>>
>> Authorised and Regulated by the Financial Services Authority (FSA) and
>> entered in the FSA register under no. 114239
>>
>> This email, including any files transmitted with it, is confidential and
>> may be privileged. It may be read, copied and used only by the intended
>> recipient. If you are not the intended recipient of this message, please
>> notify postmaster@sucfin.com immediately and delete it from your computer
>> system.
>>
>> We believe, but do not warrant, that this email and its attachments are
>> virus-free, but you should check.
>>
>> Sucden Financial Limited may monitor traffic data of both business and
>> personal emails. By replying to this email, you consent to Sucden Financial
>> 's monitoring the content of any emails you send to or receive from Sucden
>> Financial . Sucden Financial is not liable for any opinions expressed by the
>> sender where this is a non-business email.
>>
>> The contents of this e-mail do not constitute advice and should not be
>> regarded as a recommendation to buy, sell or otherwise deal with any
>> particular investment.
>>
>> This message has been scanned for viruses by Mimecast.
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
Sam, I am at a loss for words...
It's clear that I am not able to ask for help in understanding the benefits that
you see, or perhaps you can't relate them to me. I'm just looking for your
experiences and the values you see. I know what OSGi says it is. I know how to
read the documentation (again and again) to see what it currently supports in
each new release.
That's not what I am looking for. I'm trying to get first hand reports and
recommendations on what is valuable to those who have used it and deployed
things using it. I want to see which of the possible set of features that Jini
could provide for OSGi inter-working would allow someone to get some benefits.
For example, preferred class loading solves some class loading issues. But, if
some parts of OSGi have removed those benefits from your view and you don't need
them any longer, I'd like to know more about that.
Do you just like OSGi because it's a container that you drop things into and
they work?
I want to know the details of your experiences please.
Gregg Wonderly
Sam Chance wrote:
> Gregg,
>
> It is not my desire or intention to try to play "technology ping-pong." I'm
> only introducing another viewpoint. Frankly, I don't have time to read
> long, verbose emails. I've touted enough OSGi technology attributes to
> intrigue those who might be interested in learning more. The answers to
> your questions can be found on the OSGi Alliance's web site - and I promise
> you there are solid answers. Additionally, a number of books that provide
> ample OSGi coverage are either recently published or nearing publication.
>
> Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and others
> offer a lot of informative OSGi literature as well. Neal Bartlett also
> provides a lot of OSGi resources. Eclipse [Equinox] and Apache Felix are
> great places as well.
>
> Happy Learning! :-)
>
> Sam
>
> On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
>
>> Sam Chance wrote:
>>
>>> In fact, OSGi does help a lot with "Classpath Hell".
>>>
>> I didn't see a reply from my earlier request for more information on the
>> issues that the OSGi experienced think OSGi helps the most with regarding
>> this issue. I'd really like to see what issues you all have had and that
>> OSGi has addressed.
>>
>> Is it just that packaging encloses the set of things you need to make
>> things work and you don't have to worry about that, or is it something else?
>> Many containers use ClassLoader hierarchies of various shapes to isolate
>> and "interrelate" different types of package structures. I'm just
>> interested in knowing more about the issues and benefits you all recognize
>> from your experiences.
>>
>>> OSGi also adds another layer of security above the standard Java.
>> What do you feel is important about this? Authentication vs Authorization
>> issues would be great to have your opinions and experience on.
>>
>>> Versioning is a "first-class function" in OSGi.
>> This is a big deal for separating old and new. I think we have a good bit
>> of this in the PreferredClass mechanisms in Jini 2.x so that implementations
>> can be forced into use for bug fixing and interfacing with different
>> versions of difference services. Is there anything else beside classloader
>> based separation that you all find important in what OSGi provides?
>>
>> Gregg Wonderly
>>
>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sam Chance wrote:
> Gregg,
>
> It is not my desire or intention to try to play "technology ping-pong." I'm
> only introducing another viewpoint. Frankly, I don't have time to read
> long, verbose emails. I've touted enough OSGi technology attributes to
> intrigue those who might be interested in learning more. The answers to
> your questions can be found on the OSGi Alliance's web site - and I promise
> you there are solid answers. Additionally, a number of books that provide
> ample OSGi coverage are either recently published or nearing publication.
>
> Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and others
> offer a lot of informative OSGi literature as well. Neal Bartlett also
> provides a lot of OSGi resources. Eclipse [Equinox] and Apache Felix are
> great places as well.
>
> Happy Learning! :-)
>
> Sam
>
> On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
>
>
>> Sam Chance wrote:
>>
>>
>>> In fact, OSGi does help a lot with "Classpath Hell".
>>>
>>>
>> I didn't see a reply from my earlier request for more information on the
>> issues that the OSGi experienced think OSGi helps the most with regarding
>> this issue. I'd really like to see what issues you all have had and that
>> OSGi has addressed.
>>
>> Is it just that packaging encloses the set of things you need to make
>> things work and you don't have to worry about that, or is it something else?
>> Many containers use ClassLoader hierarchies of various shapes to isolate
>> and "interrelate" different types of package structures. I'm just
>> interested in knowing more about the issues and benefits you all recognize
>> from your experiences.
>>
>>
>>> OSGi also adds another layer of security above the standard Java.
>>>
>> What do you feel is important about this? Authentication vs Authorization
>> issues would be great to have your opinions and experience on.
>>
>>
>>> Versioning is a "first-class function" in OSGi.
>>>
>> This is a big deal for separating old and new. I think we have a good bit
>> of this in the PreferredClass mechanisms in Jini 2.x so that implementations
>> can be forced into use for bug fixing and interfacing with different
>> versions of difference services. Is there anything else beside classloader
>> based separation that you all find important in what OSGi provides?
>>
There seems to be two or three topics here getting confused?
Firstly, the classloader is the source of many problems isn't it?
Thanks Gregg, for the info on the PreferredClass mechanisms in Jini, it
gave me something with some meat to follow up, I wasn't aware of it
until now.
I'm reading Gregg's email as well as yours Sam and following up on the
links, please be considerate/respectful of others viewpoints.
When I mentioned class versioning support changes in the JRE required to
support project Jigsaw, I hadn't realised that the Module versioning
information of Jigsaw didn't extend all the way down to bytecode and
class files, my misunderstanding, I had hoped that class file versioning
could provide an answer to problems with new codebases and old objects
and vica versa.
Thanks to the tip from Gregg, I've found a good research paper (Michael
Warres) that describes the issues with Classloading and their relevance
to Jini at: http://research.sun.com/techrep/2006/smli_tr-2006-149.pdf
PS are we authorised to upload this onto the River site? Are there other
similar papers?
My original thought process was along the lines of being able to discern
between different versions of classes loaded from codebases with the
same fully qualified class names.
Could we create a tool that added codebaseVersionID final variables to
class files for exteral sourced libraries, perhaps using ASM? This
along with the serialVersionUID could be used to determine the
compatibility and dependency tree of the codebases for individual
classes. We could use Annotations as suggested by Michael Warres in our
own code then to manage inter class and package dependencies? Then
perhaps we could cache available codebases in clients in case http
codebase servers go down or maybe make the codebase servers more dynamic
so codebases don't go missing when some codebase servers fail?
How hard would it be to create a tool that parses the source code for
new developers to do this for them, you know all javadoc comments must
have a @version number at the top of the class? After they compile
their code and confirm its working, the tool could create the
codebaseVersionID variables for them, based on a configuration file for
external libs? You said that code mobility is difficult how can we make
it easier? classdep?
How can we fix the above problem based on reccommendations by Michael
Warres?
Secondly:
OSGi - uses a services model to solve single VM packaging problems,
doesn't it? That is; export services that can be used by other OSGi
modules (independant applications / libraries of services) to build
applications from.
River - uses a services model for distributed computing.
Was there proposal to create an OSGi compatible module that acts as a
Facade to host River distributed services to OSGi applications that
otherwise wouldn't be capable of taking advantage of network aware (the
8 fallacies of distribute computing) redundancy capabilities? What is
the use case for this? Is this for a service that is critical to a
particular application (from performance or redundancy perspective) that
may be subject to failure and the abilities of River to run multiple
services. An OSGi based application that has outgrown it's roots so to
speak, parts of it can be rewritten based on River? What issues would
arrise due to remote objects?
So this OSGi module could then act as a Facade, that used the Lookup
Service to make redundant services available to OSGi to improve the QOS,
service reliability, performance to OSGi based applications?
Is this what the debate is about or have I missed something? I doesn't
require changes to River, just a new OSGi module that can be downloaded
by the OSGi application developer who can start writing some River
services for his/her existing OSGi based application?
Going in the other direction, someone could write an OSGi based
application that provides services to a distributed River network for
the export of value objects (simple data objects) over a River service
yes? In which case the distributed applications running on River don't
need to be OSGi aware? The http codebase server would need to have
class file copies of the value objects however.
Cheers,
Peter.
>> Gregg Wonderly
>>
>>
>
>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Sam Chance <sg...@gmail.com>.
Gregg,
It is not my desire or intention to try to play "technology ping-pong." I'm
only introducing another viewpoint. Frankly, I don't have time to read
long, verbose emails. I've touted enough OSGi technology attributes to
intrigue those who might be interested in learning more. The answers to
your questions can be found on the OSGi Alliance's web site - and I promise
you there are solid answers. Additionally, a number of books that provide
ample OSGi coverage are either recently published or nearing publication.
Oracle, Sun, IBM, SpringSource, JBoss, Progress, Paremus, ProSyst and others
offer a lot of informative OSGi literature as well. Neal Bartlett also
provides a lot of OSGi resources. Eclipse [Equinox] and Apache Felix are
great places as well.
Happy Learning! :-)
Sam
On Tue, Jul 14, 2009 at 6:49 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
> Sam Chance wrote:
>
>> In fact, OSGi does help a lot with "Classpath Hell".
>>
>
> I didn't see a reply from my earlier request for more information on the
> issues that the OSGi experienced think OSGi helps the most with regarding
> this issue. I'd really like to see what issues you all have had and that
> OSGi has addressed.
>
> Is it just that packaging encloses the set of things you need to make
> things work and you don't have to worry about that, or is it something else?
> Many containers use ClassLoader hierarchies of various shapes to isolate
> and "interrelate" different types of package structures. I'm just
> interested in knowing more about the issues and benefits you all recognize
> from your experiences.
>
> > OSGi also adds another layer of security above the standard Java.
>
> What do you feel is important about this? Authentication vs Authorization
> issues would be great to have your opinions and experience on.
>
> > Versioning is a "first-class function" in OSGi.
>
> This is a big deal for separating old and new. I think we have a good bit
> of this in the PreferredClass mechanisms in Jini 2.x so that implementations
> can be forced into use for bug fixing and interfacing with different
> versions of difference services. Is there anything else beside classloader
> based separation that you all find important in what OSGi provides?
>
> Gregg Wonderly
>
--
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <gr...@wonderly.org>.
Sam Chance wrote:
> In fact, OSGi does help a lot with "Classpath Hell".
I didn't see a reply from my earlier request for more information on the issues
that the OSGi experienced think OSGi helps the most with regarding this issue.
I'd really like to see what issues you all have had and that OSGi has addressed.
Is it just that packaging encloses the set of things you need to make things
work and you don't have to worry about that, or is it something else? Many
containers use ClassLoader hierarchies of various shapes to isolate and
"interrelate" different types of package structures. I'm just interested in
knowing more about the issues and benefits you all recognize from your experiences.
> OSGi also adds another layer of security above the standard Java.
What do you feel is important about this? Authentication vs Authorization
issues would be great to have your opinions and experience on.
> Versioning is a "first-class function" in OSGi.
This is a big deal for separating old and new. I think we have a good bit of
this in the PreferredClass mechanisms in Jini 2.x so that implementations can be
forced into use for bug fixing and interfacing with different versions of
difference services. Is there anything else beside classloader based separation
that you all find important in what OSGi provides?
Gregg Wonderly
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Sam Chance <sg...@gmail.com>.
Tom,
I think you are "tracking" in the direction I was suggesting. Peter's email
is similarly aligned. I'm not meaning to imply that I am "right"; I'm just
saying your and Peter's thoughts are congruent with my own. In fact, OSGi
does help a lot with "Classpath Hell". OSGi also adds another layer of
security above the standard Java. Versioning is a "first-class function" in
OSGi.
Distributed OSGi, in my view, is almost an indirect reference to Jini!
Minimally, D-OSGi is well aligned with Jini/River and the opportunity to
implement it using River is clearly present.
As for Jigsaw, Groovy, and Java 7 modules, I would steer clear. Decisions
about technology adoption are clearly not the result of superior technology.
(Look no further than Jini!) OSGi is already enjoying wide adoption and
acceptance. Frankly, I attribute much of it to the *simplicity* of OSGi,
coupled with its elegance. Jigsaw is obscure at best; Groovy IMHO is
"one-off", and Java 7 is - well, who knows?
The broad adoption of OSGi in automotive, mobile and enterprise sectors is
clearly the enabler for "mass convergence". The press releases and other
public literature are pervasive and reflect a strong consensus.
Having said all that, I also know that "computer science" can sometimes
appear to be an oxymoron! For all we know, Groovy and Jigsaw could be all
the rage next week! Still, it is logical and probable that OSGi will become
the ubiquitous module system for Java. And convergence across heretofore
separate networks will usher in an enormous need for distributed services
and their requisite management.
Just some thoughts.
Sam
On Mon, Jul 13, 2009 at 7:53 AM, Tom Hobbs <to...@sucfin.com> wrote:
> "I know you guys are very busy, but it would be nice if the most
> experienced Jini/River software engineers were able to dissect the
> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
> for Jini/River. I know it's tough to allocate time to do that though."
>
> Well, in the absence of the most experienced you're left with me. :-)
> For added confusion, I don't know a whole heap about OSGi either, so the
> follow is a likely mix of over simplification and misunderstanding.
>
> If that sounds useful, continue reading...
>
> This is the complete document, I skipped down to RFC 119 only;
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>
> The RFC discusses the concept of a "Service Registry" which looks an
> awful lot like a River ServiceRegistrar. Delving further into the RFC
> it seems to me that we if we can translate from the specified interfaces
> that describe an "OSGi Service" to that which describes a "River
> Service" then River could slot in quite nicely as a response to this
> RFC.
>
> Much of the work feels like translating from what OSGi say service
> descriptions and lookups *should* look like and what River says service
> descriptions and lookups *do* look like.
>
> The only tricky part, I think, would be how an OSGi component (which
> likely extends something else) can be made into a River service such
> that it is discoverable in the usual way. This would be an interesting
> problem and raises the circumstance where an OSGi service might publish
> itself as an OSGi service, but because it's River underneath, would be
> discoverable by pure River clients on the same network also.
>
> Looking at how the RFC specifies what a service description is and what
> it looks like, I think that there is mileage in River adopting something
> similar. It would be nice, in my opinion, to move away from the
> quasi-java config files River uses in favour of something else.
>
> XML makes sense because that's what most of the rest of the world uses -
> although I personally don't care for it much.
>
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration. Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to be
> unworkable for obvious reasons.
>
> Also, building in a mechanism to provide a similar version-sensitive
> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
> feature for River all other considerations not-withstanding.
>
> Anyway, that's this layman's interpretation of this OSGi RFC; if only
> for a few days or weeks of spare time to spend putting it together.
>
> Tom
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
> London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and
> entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and
> may be privileged. It may be read, copied and used only by the intended
> recipient. If you are not the intended recipient of this message, please
> notify postmaster@sucfin.com immediately and delete it from your computer
> system.
>
> We believe, but do not warrant, that this email and its attachments are
> virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and
> personal emails. By replying to this email, you consent to Sucden Financial
> 's monitoring the content of any emails you send to or receive from Sucden
> Financial . Sucden Financial is not liable for any opinions expressed by the
> sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be
> regarded as a recommendation to buy, sell or otherwise deal with any
> particular investment.
>
> This message has been scanned for viruses by Mimecast.
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini]) - revised
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Tom,
I thought I'd grab this thread again, as it still appears to be an issue
and I'm now in a better position to answer.
Both Jini and OSGi use their implementation of the Publish, Find, Bind
pattern as an abstraction or façade to enable the implementation behind
it to be hot plugged, they both use the term service.
I've realised that there is no need to map a Jini service to an OSGi
service, nor worry about the different semantics between them. Why?
You only need one abstraction, why have an abstraction on an
abstraction? And if you want to get technical each solves a different
problem, so one is not better than the other or in a competitive
relationship:
* You use your OSGi service to change out, swap between, iterate
over or group your modules (bundles) and their functionality. OSGi
heavily utilises ClassLoaders to limiting visibility, avoiding
classpath hell.
* You use your Jini service to abstract away the communication
protocol between two nodes, so they can exchange objects easily.
When the protocol changes, the client software doesn't need to be
concerned.
It also enables the construction of a distributed system from
the sum of its components and it enables the abstraction of
hardware and software components.
Here's how to take advantage of OSGi from Jini, it is slightly different
from standard OSGi modularity practises, if you don't like it, use
Preferred Classloader instead, or use the existing http URL mechanism,
you are not committed to utilising OSGi, but those who are planning to
use Jini Services over the web will probably want to.
1. Create a bundle containing your service interfaces. The
interfaces will then be in their own ClassLoader, this is
important, so that others can implement the same service interface
without being dependant on and having to download your
implementation bundles.
2. Create your Smart Proxy Implementation, it belongs within its own
bundle, it depends on one or more of the Interface bundle
packages. If the interface bundle extends interfaces from
external packages, (imports other bundle packages containing
interfaces) then you must import those interface packages also
otherwise the you will get a runtime exception. Software on the
client utilising your proxy will need to import the interface
packages and any additional packages that these interfaces
extend.. You also need to specify any permissions your proxy
needs.
3. For simple reflective proxies, the proxy will be loaded into the
interface bundle Classloader at the client.
4. Create your Server Service Implementation, it must import the
packages from the Interface and the Smart Client Package bundles
and any other packages that the interface bundle extends.
When a client from within an OSGI bundle utilises your jini service
remotely, it must lookup your service from the Jini Lookup Service, it
might do this during bundle activation, or it might do so during
execution. When a client deactivates its bundle, it also stops using
your service (It doesn't actually depend on packages from your proxy
bundle, only packages from the interface bundle/s).
Bundles containing Jini services, should register with a Jini service
registrar during bundle activation and de-register when deactivated.
They don't need to be registered with the OSGi service registry. Notice
at no point here have I required any mappings to OSGi services. That
would be a distraction abstraction ;) If I want to, there's nothing
stopping me from using an OSGi service from within my bundles, it's
purely up to the implementer.
At no time should we attempt to directly map an OSGi service to a Jini
Service or visa versa, they do not map well due to different lookup
semantics and the 8 fallacy's of distributed computing. If you must
provide a Jini service to a local software component that utilises an
OSGi service, create an adapter bundle that looks up and utilises a Jini
Service. Your adapter bundle can register an OSGi service with the OSGi
service registry. Other OSGi bundles using your OSGi service don't need
to be aware that the Jini service even exists, however you do need to
take the network fallacies / latencies into account.
There isn't a requirement to create an OSGi service. Your local bundle
utilising Jini Services can be made to handle the 8 fallacy's of
distributed computing and deactivate itself if suitable Jini Service are
no longer available. This way, local components that are directly
dependant on your functionality are deactivated properly also and don't
hang waiting, you'll want to write to the local service log before doing
so, try to clean up gracefully.
If you have created an OSGi Service and registered it with the OSGi
Registry, other OSGi bundles won't depend on your bundle. Instead of
shutting down your bundle, you might choose to look for another jini
service, while doing this you de register your OSGi service, until you
find another suitable Jini service.
I wouldn't recommend that Smart proxy's register an OSGi service
directly, I suppose that someone might find a reason to do it, however
there is nothing stopping a Jini Smart proxy from utilising the local
OSGi services.
Simple Reflective Proxy's will never directly cause any other bundle to
become deactivated by the OSGi framework. Bundles that utilise Jini
services must be designed with the 8 network fallacies in mind.
Cheers,
Peter.
Tom Hobbs wrote:
> "I know you guys are very busy, but it would be nice if the most
> experienced Jini/River software engineers were able to dissect the
> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
> for Jini/River. I know it's tough to allocate time to do that though."
>
> Well, in the absence of the most experienced you're left with me. :-)
> For added confusion, I don't know a whole heap about OSGi either, so the
> follow is a likely mix of over simplification and misunderstanding.
>
> If that sounds useful, continue reading...
>
> This is the complete document, I skipped down to RFC 119 only;
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>
> The RFC discusses the concept of a "Service Registry" which looks an
> awful lot like a River ServiceRegistrar. Delving further into the RFC
> it seems to me that we if we can translate from the specified interfaces
> that describe an "OSGi Service" to that which describes a "River
> Service" then River could slot in quite nicely as a response to this
> RFC.
>
> Much of the work feels like translating from what OSGi say service
> descriptions and lookups *should* look like and what River says service
> descriptions and lookups *do* look like.
>
> The only tricky part, I think, would be how an OSGi component (which
> likely extends something else) can be made into a River service such
> that it is discoverable in the usual way. This would be an interesting
> problem and raises the circumstance where an OSGi service might publish
> itself as an OSGi service, but because it's River underneath, would be
> discoverable by pure River clients on the same network also.
>
> Looking at how the RFC specifies what a service description is and what
> it looks like, I think that there is mileage in River adopting something
> similar. It would be nice, in my opinion, to move away from the
> quasi-java config files River uses in favour of something else.
>
> XML makes sense because that's what most of the rest of the world uses -
> although I personally don't care for it much.
>
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration. Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to be
> unworkable for obvious reasons.
>
> Also, building in a mechanism to provide a similar version-sensitive
> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
> feature for River all other considerations not-withstanding.
>
> Anyway, that's this layman's interpretation of this OSGi RFC; if only
> for a few days or weeks of spare time to spend putting it together.
>
> Tom
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
>
> This message has been scanned for viruses by Mimecast.
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Tom,
I thought I'd grab this thread again, as it still appears to be an issue
and I'm now in a better position to answer.
Both Jini and OSGi use their implementation of the Publish, Find, Bind
pattern as an abstraction or façade to enable the implementation behind
it to be hot plugged, they both use the term service.
I've realised that there is no need to map a Jini service to an OSGi
service, nor worry about the different semantics between them. Why?
You only need one abstraction, why have an abstraction on an
abstraction? And if you want to get technical each solves a different
problem, so one is not better than the other or in a competitive
relationship:
* You use your OSGi service to change out, swap between, iterate
over or group your modules (bundles). It heavily utilises
ClassLoaders for limiting visibility to avoid classpath hell.
* You use your Jini service to abstract away the communication
protocol between two nodes, so they can exchange objects easily.
When the protocol changes, the client doesn't need to worry about
it. It also enables the construction of a distributed system from
the sum of its components and it enables the abstraction of
hardware and software components.
Here's how to take advantage of OSGi from Jini, it is slightly different
from standard OSGi modularity practises, if you don't like it, use
Preferred Classloader instead, or use the existing http URL mechanism,
you are not committed to utilising OSGi, but those the are planning to
use Jini Services over the web will probably want to.
1. Create a bundle containing your service interfaces. The
interfaces will then be in their own ClassLoader, this is
important, so that others can implement the same service interface
without being dependant on and having to download your
implementation bundles.
2. Create your Smart Proxy Implementation, it belongs within its own
bundle, it depends on one or more of the Interface bundle
packages. If the interface bundle extends interfaces from
external packages, (imports other bundle packages containing
interfaces) then you must import those interface packages also
otherwise the you will get a runtime exception. Software on the
client utilising your proxy will need to import the interface
packages and any additional packages that these interfaces
extend.. You also need to specify any permissions your proxy needs.
3. For simple reflective proxies, the proxy will be loaded into the
interface bundle Classloader at the client.
4. Create your Server Service Implementation, it must import the
packages from the Interface and the Smart Client Package bundles
and any other packages that the interface bundle extends.
When a client utilises your service, it's bundle must lookup your
service from the Jini Lookup Service it might do this during bundle
activation or it might do so, at some other time. When that same client
deactivates its bundle that depends on your service (proxy), it also
stops using your service.
Our bundles need to register with the Jini service registrar when
activated and de-register when deactivated. They don't need to be
registered to the OSGi service registry. Notice at no point here have I
required any mapping OSGi service. That would be a distraction
abstraction ;) If I want to, there's nothing stopping me from using an
OSGi service from within my Jini bundles, it's purely up to the implementer.
At no time should we attempt to directly map an OSGi service to a Jini
Service or visa versa, they do not map well due to different lookup
semantics and the 8 fallacy's of distributed computing, instead create a
bundle that utilises a Jini Service, your bundle can register some other
service with the OSGi service registry so that you can plug in an
implementation that does work for an existing local software component,
which doesn't need to be aware that the Jini service even exists. Your
bundle will handle the 8 fallacy's of distributed computing and
deactivate itself if the you cannot rescue your service so that local
components depending on you are deactivated properly also.
Cheers,
Peter.
Tom Hobbs wrote:
> "I know you guys are very busy, but it would be nice if the most
> experienced Jini/River software engineers were able to dissect the
> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
> for Jini/River. I know it's tough to allocate time to do that though."
>
> Well, in the absence of the most experienced you're left with me. :-)
> For added confusion, I don't know a whole heap about OSGi either, so the
> follow is a likely mix of over simplification and misunderstanding.
>
> If that sounds useful, continue reading...
>
> This is the complete document, I skipped down to RFC 119 only;
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>
> The RFC discusses the concept of a "Service Registry" which looks an
> awful lot like a River ServiceRegistrar. Delving further into the RFC
> it seems to me that we if we can translate from the specified interfaces
> that describe an "OSGi Service" to that which describes a "River
> Service" then River could slot in quite nicely as a response to this
> RFC.
>
> Much of the work feels like translating from what OSGi say service
> descriptions and lookups *should* look like and what River says service
> descriptions and lookups *do* look like.
>
> The only tricky part, I think, would be how an OSGi component (which
> likely extends something else) can be made into a River service such
> that it is discoverable in the usual way. This would be an interesting
> problem and raises the circumstance where an OSGi service might publish
> itself as an OSGi service, but because it's River underneath, would be
> discoverable by pure River clients on the same network also.
>
> Looking at how the RFC specifies what a service description is and what
> it looks like, I think that there is mileage in River adopting something
> similar. It would be nice, in my opinion, to move away from the
> quasi-java config files River uses in favour of something else.
>
> XML makes sense because that's what most of the rest of the world uses -
> although I personally don't care for it much.
>
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration. Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to be
> unworkable for obvious reasons.
>
> Also, building in a mechanism to provide a similar version-sensitive
> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
> feature for River all other considerations not-withstanding.
>
> Anyway, that's this layman's interpretation of this OSGi RFC; if only
> for a few days or weeks of spare time to spend putting it together.
>
> Tom
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
>
> This message has been scanned for viruses by Mimecast.
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Tom,
Can't say I'm one of the experts.
I've been trying to determine the differences and similarities between
OSGi and Project Jigsaw and the changes to Java 7 to support modular
systems.
This article is interesting: http://www.infoq.com/news/2009/06/jigsaw
It reports that OSGi has a dependency concept similar to Jigsaw called
fragments, however that fragments don't themselves express dependencies,
to form a dependency tree as such. If you've ever played around with
Debian's dpkg package manager, you'll know what I'm talking about.
I'd personally like to see what direction Oracle takes with the merger,
perhaps there may be a convergence, cross pollination, competition or
something similar, before we commit to OSGi or Jigsaw, perhaps
dependency trees might assist with solving the fragmented container
conundrum, I don't think we'll need to wait too long, we can get AR2
rolled in the mean time.
One component that does have my interest is the possibility of class
file versioning, (not Java bytecode versioning) so two incompatible
versions of a class can coexist in the same classpath or runtime. I was
thinking that this would be useful for migration of live River djinn's,
where incompatible class files could exist with dependency or class file
versioning while one was phased out or trialled.
I'm also thinking that if we add support of compression to the http
codebase (and serialization), we can download individual class files
over the network individually instead of entire jar files (repeatedly
compressed class files would be cached, to reduce CPU overhead). This
might make performance a bit snappier when only requiring a few classes
from a large library that would normally be stored in a jar for instance.
I'd like to do something about packaging a Kerberos KDC Server (thinking
TripleSec) with River, with support for RBAC, so that it runs out of the
box to speak.
Translation of remote interfaces with OSGi sound interesting, River
might become a migration path for those that needing something more
powerful.
Cheers,
Peter.
Tom Hobbs wrote:
> "I know you guys are very busy, but it would be nice if the most
> experienced Jini/River software engineers were able to dissect the
> [OSGi] RFC 119 and provide an assessment as to how or if it is "suited"
> for Jini/River. I know it's tough to allocate time to do that though."
>
> Well, in the absence of the most experienced you're left with me. :-)
> For added confusion, I don't know a whole heap about OSGi either, so the
> follow is a likely mix of over simplification and misunderstanding.
>
> If that sounds useful, continue reading...
>
> This is the complete document, I skipped down to RFC 119 only;
> http://www.osgi.org/download/osgi-4.2-early-draft.pdf
>
> The RFC discusses the concept of a "Service Registry" which looks an
> awful lot like a River ServiceRegistrar. Delving further into the RFC
> it seems to me that we if we can translate from the specified interfaces
> that describe an "OSGi Service" to that which describes a "River
> Service" then River could slot in quite nicely as a response to this
> RFC.
>
> Much of the work feels like translating from what OSGi say service
> descriptions and lookups *should* look like and what River says service
> descriptions and lookups *do* look like.
>
> The only tricky part, I think, would be how an OSGi component (which
> likely extends something else) can be made into a River service such
> that it is discoverable in the usual way. This would be an interesting
> problem and raises the circumstance where an OSGi service might publish
> itself as an OSGi service, but because it's River underneath, would be
> discoverable by pure River clients on the same network also.
>
> Looking at how the RFC specifies what a service description is and what
> it looks like, I think that there is mileage in River adopting something
> similar. It would be nice, in my opinion, to move away from the
> quasi-java config files River uses in favour of something else.
>
> XML makes sense because that's what most of the rest of the world uses -
> although I personally don't care for it much.
>
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration. Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to be
> unworkable for obvious reasons.
>
> Also, building in a mechanism to provide a similar version-sensitive
> lookup mechanism would 1) fit with OSGi nicely and 2) be a useful
> feature for River all other considerations not-withstanding.
>
> Anyway, that's this layman's interpretation of this OSGi RFC; if only
> for a few days or weeks of spare time to spend putting it together.
>
> Tom
>
> www.sucdenfinancial.com
>
> Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
> Telephone +44 203 207 5000
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
>
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
>
> This message has been scanned for viruses by Mimecast.
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Wade Chandler <hw...@yahoo.com>.
How large are the required libraries for groovy which would have to be deployed to every machine running services? That could be a draw back if we're talking fairly good sized MBs and deployment models. I know just the main groovy JAR file itself is almost 4MB now days. Just something to think about with the conversation. More and more dependencies means larger and larger distribution sizes which in the end result of an application means longer download times etc depending on the use cases and network limitations.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
> From: Gregg Wonderly <ge...@cox.net>
> To: river-dev@incubator.apache.org
> Sent: Thursday, July 16, 2009 2:47:58 PM
> Subject: Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
>
> I am not concerned about any performance issues regarding Groovy based
> configuration either. It may be that you spend 30ms loading config values
> instead of 3ms for example. Not a big issue for me.
>
> Gregg Wonderly
>
> James Grahn wrote:
> > Do recall that we're discussing Groovy as a replacement to the reduced-java
> DSL that Jini uses as configuration. So I don't really see where efficiency
> concerns enter into this (very limited use, one time cost).
> >
> > (That said, Groovy is likely as fast or faster than whatever interpreter we
> run now.)
> >
> > jamesG
> >
> > Elijah Menifee wrote:
> >> Some of the nice features of groovy is because it is a dynamic language,
> >> that can be compiled down to the JVM by the parser when it it
> >> reread/reloaded/redefined. According to my understanding however that
> >> capability comes at a price: The dynamic code that it generates relies on a
> >> lot of reflection to do some of its magic, so the code is not optimized the
> >> way the standard javac does with static class/method lookup at compile time,
> >> thus it runs slower. JDK 7 is slated to include JSR
> >> 292
> >> which is supposed to add new JVM Bytecode Ops specifically for dynamically
> >> invoking and redefining class/method structures, which extend beyond just
> >> groovy to being able to efficently target lots of different dynamic
> >> languages to the JVM efficently, you can read more about this at Dynamic
> >> Language
> Support
> >> .
> >>
> >> NOTE, I am not saying we should not use Groovy, I am just pointing out the
> >> potential inefficiency until JDK 7 is available.
> >>
> >> In fact one of the things I am looking at is using these type of features
> >> (Groovy or another dynamic scripting language that can be run in java such
> >> as Ruby) in the prototype to replace our server. Note that our current
> >> server is written in PERL, and in some ways using a dynamic scripting
> >> language with simplified DBI style of untyped SQL access would greatly
> >> simplify the porting of much of our buisness logic.
> >>
> >> The problems we have had with the PERL include low-level bugs in the
> >> Net::SSLeay code when a Socket is disconnect during packet writes. Because
> >> of this low-level library bug processes sometimes hang around, consuming cpu
> >> and memory trying to write and renegotiate the link instead of propogating
> >> this disconnect error condition up. In fact one of the tasks on my plate
> >> during business hours is to determine a way to fix this, and submit the
> >> patch to CPAN. Another problem (which we believe was fixed sometine ago,
> >> but have not rewritten our server to take advantage of) is that at one time
> >> the PERL thread model was broken when run on SMP (bug on early Perl 5 and
> >> 2.2 linux kernels...) machines, so our server was changed to use process
> >> forks, which is not nearly as scalable as the threaded server we started out
> >> with.
> >>
> >> We have had no problems with the SSL layer on our client side in java,and
> >> the java SSL implementation is much more heavily utilized and maintained in
> >> this world of JavaEE servers, so the entire reason for prototyping the new
> >> server on java using some the more recent technology is to move to a much
> >> more scalable infrastructure as we add clients, using a common code base on
> >> both the server and client, and limiting the number of concurrent
> >> transactions on the DB via worker threads in a que to optimize server load,
> >> and support asynchronous messaging back to the client for push style updates
> >> on data changes from other clients, which can not be cleanly/easily done
> >> with our PERL forked server.
> >>
> >> SO my two cents worth is we use Groovy knowing that it will eventually
> >> become much more efficent on the JVM.
> >>
> >> On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone wrote:
> >>
> >>> Gee, that looks easy Dennis,
> >>>
> >>> We could also support using java source too in JDK 1.6 or later as the
> >>> compiler API is included, but groovy looks so much like java (less
> >>> semicolon) it's not funny!
> >>>
> >>> I can't see any reason why we can't use Groovy? Users can choose with
> >>> their feet.
> >>>
> >>> What was the objection?
> >>>
> >>> +1 Peter.
> >>>
> >>>
> >>>
> >>>
> >>> Dennis Reedy wrote:
> >>>
> >>>> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
> >>>>
> >>>>>
> >>>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
> >>>>> ago was talking about using Groovy classes to describe service
> >>>>> configuration. Something like this sounds pretty neat, but anything
> >>>>> that needs to be recompiled for changes can take affect is likely to be
> >>>>> unworkable for obvious reasons.
> >>>>>
> >>>> I brought up the Groovy config support. Rio has switched over from the
> >>>> Jini configuration file approach to now use Groovy classes. No compilation
> >>>> is required, the Groovy classes are parsed when loaded by the
> >>>> GroovyConfiguration utility. A simple example of a Groovy configuration for
> >>>> Reggie follows:
> >>>>
> >>>> @Component('com.sun.jini.reggie')
> >>>> class ReggieConfig {
> >>>>
> >>>> String[] getInitialMemberGroups() {
> >>>> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
> >>>> 'rio')]
> >>>> return (String[])groups
> >>>> }
> >>>>
> >>>> String getUnicastDiscoveryHost() {
> >>>> return java.net.InetAddress.getLocalHost().getHostAddress()
> >>>> }
> >>>>
> >>>> }
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <ge...@cox.net>.
I am not concerned about any performance issues regarding Groovy based
configuration either. It may be that you spend 30ms loading config values
instead of 3ms for example. Not a big issue for me.
Gregg Wonderly
James Grahn wrote:
> Do recall that we're discussing Groovy as a replacement to the
> reduced-java DSL that Jini uses as configuration. So I don't really
> see where efficiency concerns enter into this (very limited use, one
> time cost).
>
> (That said, Groovy is likely as fast or faster than whatever interpreter
> we run now.)
>
> jamesG
>
> Elijah Menifee wrote:
>> Some of the nice features of groovy is because it is a dynamic language,
>> that can be compiled down to the JVM by the parser when it it
>> reread/reloaded/redefined. According to my understanding however that
>> capability comes at a price: The dynamic code that it generates relies
>> on a
>> lot of reflection to do some of its magic, so the code is not
>> optimized the
>> way the standard javac does with static class/method lookup at compile
>> time,
>> thus it runs slower. JDK 7 is slated to include JSR
>> 292<http://jcp.org/en/jsr/detail?id=292>
>> which is supposed to add new JVM Bytecode Ops specifically for
>> dynamically
>> invoking and redefining class/method structures, which extend beyond just
>> groovy to being able to efficently target lots of different dynamic
>> languages to the JVM efficently, you can read more about this at Dynamic
>> Language
>> Support<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>
>>
>> .
>>
>> NOTE, I am not saying we should not use Groovy, I am just pointing out
>> the
>> potential inefficiency until JDK 7 is available.
>>
>> In fact one of the things I am looking at is using these type of features
>> (Groovy or another dynamic scripting language that can be run in java
>> such
>> as Ruby) in the prototype to replace our server. Note that our current
>> server is written in PERL, and in some ways using a dynamic scripting
>> language with simplified DBI style of untyped SQL access would greatly
>> simplify the porting of much of our buisness logic.
>>
>> The problems we have had with the PERL include low-level bugs in the
>> Net::SSLeay code when a Socket is disconnect during packet writes.
>> Because
>> of this low-level library bug processes sometimes hang around,
>> consuming cpu
>> and memory trying to write and renegotiate the link instead of
>> propogating
>> this disconnect error condition up. In fact one of the tasks on my plate
>> during business hours is to determine a way to fix this, and submit the
>> patch to CPAN. Another problem (which we believe was fixed sometine ago,
>> but have not rewritten our server to take advantage of) is that at one
>> time
>> the PERL thread model was broken when run on SMP (bug on early Perl 5 and
>> 2.2 linux kernels...) machines, so our server was changed to use process
>> forks, which is not nearly as scalable as the threaded server we
>> started out
>> with.
>>
>> We have had no problems with the SSL layer on our client side in java,and
>> the java SSL implementation is much more heavily utilized and
>> maintained in
>> this world of JavaEE servers, so the entire reason for prototyping the
>> new
>> server on java using some the more recent technology is to move to a much
>> more scalable infrastructure as we add clients, using a common code
>> base on
>> both the server and client, and limiting the number of concurrent
>> transactions on the DB via worker threads in a que to optimize server
>> load,
>> and support asynchronous messaging back to the client for push style
>> updates
>> on data changes from other clients, which can not be cleanly/easily done
>> with our PERL forked server.
>>
>> SO my two cents worth is we use Groovy knowing that it will eventually
>> become much more efficent on the JVM.
>>
>> On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone <ji...@zeus.net.au>
>> wrote:
>>
>>> Gee, that looks easy Dennis,
>>>
>>> We could also support using java source too in JDK 1.6 or later as the
>>> compiler API is included, but groovy looks so much like java (less
>>> semicolon) it's not funny!
>>>
>>> I can't see any reason why we can't use Groovy? Users can choose with
>>> their feet.
>>>
>>> What was the objection?
>>>
>>> +1 Peter.
>>>
>>>
>>>
>>>
>>> Dennis Reedy wrote:
>>>
>>>> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>>>
>>>>>
>>>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>>>> ago was talking about using Groovy classes to describe service
>>>>> configuration. Something like this sounds pretty neat, but anything
>>>>> that needs to be recompiled for changes can take affect is likely
>>>>> to be
>>>>> unworkable for obvious reasons.
>>>>>
>>>> I brought up the Groovy config support. Rio has switched over from the
>>>> Jini configuration file approach to now use Groovy classes. No
>>>> compilation
>>>> is required, the Groovy classes are parsed when loaded by the
>>>> GroovyConfiguration utility. A simple example of a Groovy
>>>> configuration for
>>>> Reggie follows:
>>>>
>>>> @Component('com.sun.jini.reggie')
>>>> class ReggieConfig {
>>>>
>>>> String[] getInitialMemberGroups() {
>>>> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>>>> 'rio')]
>>>> return (String[])groups
>>>> }
>>>>
>>>> String getUnicastDiscoveryHost() {
>>>> return java.net.InetAddress.getLocalHost().getHostAddress()
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by James Grahn <jg...@simulexinc.com>.
Do recall that we're discussing Groovy as a replacement to the
reduced-java DSL that Jini uses as configuration. So I don't really
see where efficiency concerns enter into this (very limited use, one
time cost).
(That said, Groovy is likely as fast or faster than whatever interpreter
we run now.)
jamesG
Elijah Menifee wrote:
> Some of the nice features of groovy is because it is a dynamic language,
> that can be compiled down to the JVM by the parser when it it
> reread/reloaded/redefined. According to my understanding however that
> capability comes at a price: The dynamic code that it generates relies on a
> lot of reflection to do some of its magic, so the code is not optimized the
> way the standard javac does with static class/method lookup at compile time,
> thus it runs slower. JDK 7 is slated to include JSR
> 292<http://jcp.org/en/jsr/detail?id=292>
> which is supposed to add new JVM Bytecode Ops specifically for dynamically
> invoking and redefining class/method structures, which extend beyond just
> groovy to being able to efficently target lots of different dynamic
> languages to the JVM efficently, you can read more about this at Dynamic
> Language Support<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>
> .
>
> NOTE, I am not saying we should not use Groovy, I am just pointing out the
> potential inefficiency until JDK 7 is available.
>
> In fact one of the things I am looking at is using these type of features
> (Groovy or another dynamic scripting language that can be run in java such
> as Ruby) in the prototype to replace our server. Note that our current
> server is written in PERL, and in some ways using a dynamic scripting
> language with simplified DBI style of untyped SQL access would greatly
> simplify the porting of much of our buisness logic.
>
> The problems we have had with the PERL include low-level bugs in the
> Net::SSLeay code when a Socket is disconnect during packet writes. Because
> of this low-level library bug processes sometimes hang around, consuming cpu
> and memory trying to write and renegotiate the link instead of propogating
> this disconnect error condition up. In fact one of the tasks on my plate
> during business hours is to determine a way to fix this, and submit the
> patch to CPAN. Another problem (which we believe was fixed sometine ago,
> but have not rewritten our server to take advantage of) is that at one time
> the PERL thread model was broken when run on SMP (bug on early Perl 5 and
> 2.2 linux kernels...) machines, so our server was changed to use process
> forks, which is not nearly as scalable as the threaded server we started out
> with.
>
> We have had no problems with the SSL layer on our client side in java,and
> the java SSL implementation is much more heavily utilized and maintained in
> this world of JavaEE servers, so the entire reason for prototyping the new
> server on java using some the more recent technology is to move to a much
> more scalable infrastructure as we add clients, using a common code base on
> both the server and client, and limiting the number of concurrent
> transactions on the DB via worker threads in a que to optimize server load,
> and support asynchronous messaging back to the client for push style updates
> on data changes from other clients, which can not be cleanly/easily done
> with our PERL forked server.
>
> SO my two cents worth is we use Groovy knowing that it will eventually
> become much more efficent on the JVM.
>
> On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Gee, that looks easy Dennis,
>>
>> We could also support using java source too in JDK 1.6 or later as the
>> compiler API is included, but groovy looks so much like java (less
>> semicolon) it's not funny!
>>
>> I can't see any reason why we can't use Groovy? Users can choose with
>> their feet.
>>
>> What was the objection?
>>
>> +1 Peter.
>>
>>
>>
>>
>> Dennis Reedy wrote:
>>
>>> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>>
>>>>
>>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>>> ago was talking about using Groovy classes to describe service
>>>> configuration. Something like this sounds pretty neat, but anything
>>>> that needs to be recompiled for changes can take affect is likely to be
>>>> unworkable for obvious reasons.
>>>>
>>> I brought up the Groovy config support. Rio has switched over from the
>>> Jini configuration file approach to now use Groovy classes. No compilation
>>> is required, the Groovy classes are parsed when loaded by the
>>> GroovyConfiguration utility. A simple example of a Groovy configuration for
>>> Reggie follows:
>>>
>>> @Component('com.sun.jini.reggie')
>>> class ReggieConfig {
>>>
>>> String[] getInitialMemberGroups() {
>>> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>>> 'rio')]
>>> return (String[])groups
>>> }
>>>
>>> String getUnicastDiscoveryHost() {
>>> return java.net.InetAddress.getLocalHost().getHostAddress()
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Elijah Menifee <el...@gmail.com>.
Some of the nice features of groovy is because it is a dynamic language,
that can be compiled down to the JVM by the parser when it it
reread/reloaded/redefined. According to my understanding however that
capability comes at a price: The dynamic code that it generates relies on a
lot of reflection to do some of its magic, so the code is not optimized the
way the standard javac does with static class/method lookup at compile time,
thus it runs slower. JDK 7 is slated to include JSR
292<http://jcp.org/en/jsr/detail?id=292>
which is supposed to add new JVM Bytecode Ops specifically for dynamically
invoking and redefining class/method structures, which extend beyond just
groovy to being able to efficently target lots of different dynamic
languages to the JVM efficently, you can read more about this at Dynamic
Language Support<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>
.
NOTE, I am not saying we should not use Groovy, I am just pointing out the
potential inefficiency until JDK 7 is available.
In fact one of the things I am looking at is using these type of features
(Groovy or another dynamic scripting language that can be run in java such
as Ruby) in the prototype to replace our server. Note that our current
server is written in PERL, and in some ways using a dynamic scripting
language with simplified DBI style of untyped SQL access would greatly
simplify the porting of much of our buisness logic.
The problems we have had with the PERL include low-level bugs in the
Net::SSLeay code when a Socket is disconnect during packet writes. Because
of this low-level library bug processes sometimes hang around, consuming cpu
and memory trying to write and renegotiate the link instead of propogating
this disconnect error condition up. In fact one of the tasks on my plate
during business hours is to determine a way to fix this, and submit the
patch to CPAN. Another problem (which we believe was fixed sometine ago,
but have not rewritten our server to take advantage of) is that at one time
the PERL thread model was broken when run on SMP (bug on early Perl 5 and
2.2 linux kernels...) machines, so our server was changed to use process
forks, which is not nearly as scalable as the threaded server we started out
with.
We have had no problems with the SSL layer on our client side in java,and
the java SSL implementation is much more heavily utilized and maintained in
this world of JavaEE servers, so the entire reason for prototyping the new
server on java using some the more recent technology is to move to a much
more scalable infrastructure as we add clients, using a common code base on
both the server and client, and limiting the number of concurrent
transactions on the DB via worker threads in a que to optimize server load,
and support asynchronous messaging back to the client for push style updates
on data changes from other clients, which can not be cleanly/easily done
with our PERL forked server.
SO my two cents worth is we use Groovy knowing that it will eventually
become much more efficent on the JVM.
On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Gee, that looks easy Dennis,
>
> We could also support using java source too in JDK 1.6 or later as the
> compiler API is included, but groovy looks so much like java (less
> semicolon) it's not funny!
>
> I can't see any reason why we can't use Groovy? Users can choose with
> their feet.
>
> What was the objection?
>
> +1 Peter.
>
>
>
>
> Dennis Reedy wrote:
>
>>
>> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>
>>>
>>>
>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>> ago was talking about using Groovy classes to describe service
>>> configuration. Something like this sounds pretty neat, but anything
>>> that needs to be recompiled for changes can take affect is likely to be
>>> unworkable for obvious reasons.
>>>
>>
>> I brought up the Groovy config support. Rio has switched over from the
>> Jini configuration file approach to now use Groovy classes. No compilation
>> is required, the Groovy classes are parsed when loaded by the
>> GroovyConfiguration utility. A simple example of a Groovy configuration for
>> Reggie follows:
>>
>> @Component('com.sun.jini.reggie')
>> class ReggieConfig {
>>
>> String[] getInitialMemberGroups() {
>> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>> 'rio')]
>> return (String[])groups
>> }
>>
>> String getUnicastDiscoveryHost() {
>> return java.net.InetAddress.getLocalHost().getHostAddress()
>> }
>>
>> }
>>
>>
>>
>>
>>
>>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Dennis Reedy <de...@gmail.com>.
On Jul 14, 2009, at 500PM, Gregg Wonderly wrote:
> Dennis, can you add any additional information about how
> configurations of multiple things are put together in either single
> files, or how multiple files are integrated together? I do like the
> simplicity and the power of this.
The approach is similar to the traditional Jini configuration, where
you can provide multiple components per file. The difference with the
Groovy approach is you provide the @Component annotation to indicate
what configuration component the Groovy class s for.
I've attached the Rio Cybernode starter and service configs as an
example. Let me know if this doesnt address your questions.
Overrides are also supported, but the override is not passed in as a
string (as in the traditional configuration), the override is also a
Groovy class the extends the configuration it is overriding and
overrides the property that it is changing.
As you would expect inheritance is also supported, if you take a look
at Rio, you'll see a good example for the activatable groovy configs.
>
> It might also be interesting to see if a Scala version would be
> interesting or have any different capabilities since there are
> additional language features there too.
Yep, that could be interesting as well
Dennis
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis, can you add any additional information about how configurations of
multiple things are put together in either single files, or how multiple files
are integrated together? I do like the simplicity and the power of this.
It might also be interesting to see if a Scala version would be interesting or
have any different capabilities since there are additional language features
there too.
Gregg Wonderly
Dennis Reedy wrote:
>
> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>
>>
>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>> ago was talking about using Groovy classes to describe service
>> configuration. Something like this sounds pretty neat, but anything
>> that needs to be recompiled for changes can take affect is likely to be
>> unworkable for obvious reasons.
>
> I brought up the Groovy config support. Rio has switched over from the
> Jini configuration file approach to now use Groovy classes. No
> compilation is required, the Groovy classes are parsed when loaded by
> the GroovyConfiguration utility. A simple example of a Groovy
> configuration for Reggie follows:
>
> @Component('com.sun.jini.reggie')
> class ReggieConfig {
>
> String[] getInitialMemberGroups() {
> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
> 'rio')]
> return (String[])groups
> }
>
> String getUnicastDiscoveryHost() {
> return java.net.InetAddress.getLocalHost().getHostAddress()
> }
>
> }
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gee, that looks easy Dennis,
We could also support using java source too in JDK 1.6 or later as the
compiler API is included, but groovy looks so much like java (less
semicolon) it's not funny!
I can't see any reason why we can't use Groovy? Users can choose with
their feet.
What was the objection?
+1 Peter.
Dennis Reedy wrote:
>
> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>
>>
>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>> ago was talking about using Groovy classes to describe service
>> configuration. Something like this sounds pretty neat, but anything
>> that needs to be recompiled for changes can take affect is likely to be
>> unworkable for obvious reasons.
>
> I brought up the Groovy config support. Rio has switched over from the
> Jini configuration file approach to now use Groovy classes. No
> compilation is required, the Groovy classes are parsed when loaded by
> the GroovyConfiguration utility. A simple example of a Groovy
> configuration for Reggie follows:
>
> @Component('com.sun.jini.reggie')
> class ReggieConfig {
>
> String[] getInitialMemberGroups() {
> def groups =
> [System.getProperty(Constants.GROUPS_PROPERTY_NAME, 'rio')]
> return (String[])groups
> }
>
> String getUnicastDiscoveryHost() {
> return java.net.InetAddress.getLocalHost().getHostAddress()
> }
>
> }
>
>
>
>
>
Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Posted by Dennis Reedy <de...@gmail.com>.
On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>
>
> Someone on the Jini-Users (or similar, I can't quite remember) a while
> ago was talking about using Groovy classes to describe service
> configuration. Something like this sounds pretty neat, but anything
> that needs to be recompiled for changes can take affect is likely to
> be
> unworkable for obvious reasons.
I brought up the Groovy config support. Rio has switched over from the
Jini configuration file approach to now use Groovy classes. No
compilation is required, the Groovy classes are parsed when loaded by
the GroovyConfiguration utility. A simple example of a Groovy
configuration for Reggie follows:
@Component('com.sun.jini.reggie')
class ReggieConfig {
String[] getInitialMemberGroups() {
def groups =
[System.getProperty(Constants.GROUPS_PROPERTY_NAME, 'rio')]
return (String[])groups
}
String getUnicastDiscoveryHost() {
return java.net.InetAddress.getLocalHost().getHostAddress()
}
}