river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River & OSGi
Date Thu, 19 Nov 2009 21:35:02 GMT
Mike McGrady wrote:
> First, Peter, I wish you the best in your struggles with your health.  
> I know what you mean about letting work absorb you: it keeps us 
> present when we fall into it.
Thank you.
> Second, sometimes people take my questions as answers when they are 
> questions.  I meant the question about class genuinely and not in some 
> passive aggressive sense.  OSGi works with managing URL classloaders 
> so I wanted to get clear about what was meant about classpath.
Original Question: What is "the classpath" here?  You cannot mean the 
Java classpath.

Ok, I'll bite, what's wrong with using the classpath?  Please don't go 
on about classpath hell etc. I'm just trying to build a simple analysis 
tool to gather class and package API signatures.

> Third, people tend to identify personally with things that then become 
> sensitive to them.  I tend to try and stick to the subject .
> Obviously under those conditions it does not work.  I am too serious 
> about the topic many times to take the time to be careful about the 
> egos involved, including mine.  Often i have just have a minute.
> So these venues are probably not the best for me.
> Thank you for your assistance.
> Sent from my iPhone
> On Nov 19, 2009, at 2:35 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>> My last point was about not letting the little things get to you, 
>> don't argue the little things, just suggest another way if you don't 
>> like it.
>> For example, your last comment to me that I haven't gotten around to 
>> answering is :
>> What is "the classpath" here?  You cannot mean the Java classpath.
>> Could have been rephrased as:
>> I see your setting the classpath to load classes from for your 
>> dependency analysis, you know tool xyz can help you do this better.  
>> And let the programmer go off and investigate the rest, 9 times out 
>> of 10 they'll be grateful.
>> If it is a misunderstanding, it doesn't matter as it has the 
>> appearance of assistance and is non threatening.
>> I might have come off the wrong way with my last comment.  You may, 
>> or may not be aware,  I'm receiving treatment for a brain tumor and 
>> have had some bigger picture issues to deal with in recent months.
>> The reason I'm still putting in an effort on this project is:
>> 1.  I still believe Apache River and Jini to hold the key to 
>> pervasive computing and I'd like to see the project reinvigorated and 
>> succeed.
>> 2.  It occupies my mind so I can stay positive and not let life's 
>> difficulties get me down.
>> I had prepared an answer for your question earlier so I'll post that 
>> for you.
>> Peter.
>> Mike McGrady wrote:
>>> I'm probably not made for these lists.  Maybe I should just keep my 
>>> opinion to myself.  I consider myself an expert in the field on some 
>>> topics and don't have months to go through what I consider to be the 
>>> standard misconceptions.
>>> Sent from my iPhone
>>> On Nov 18, 2009, at 11:13 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>>>> Mike you need to stop sounding like your looking down from the top 
>>>> of the podium and adopt a little humility in your comments.  Do try 
>>>> to be a little more agreeable.  Otherwise it rubs people the wrong 
>>>> way, which just isn't productive.  If your on the run all the time, 
>>>> perhaps you might want to get a netbook instead of the iPhone, then 
>>>> you can open an ide too.  Much better for participating.
>>>> I think that what comes across as an attitude of I know better and 
>>>> your wrong (whether intended or not) on the dev list is what puts 
>>>> people off participating.  Nobody wants to argue the details, we 
>>>> want to feel like we're contributing something.  We need to 
>>>> encourage people to try, perhaps we can set up an experimental area 
>>>> for would be committers, if need be, so they gain confidence to 
>>>> participate, more knowledgeable people can have a look and make 
>>>> suggestions and assist.  Once you start to get to know the codebase 
>>>> it isn't that hard to work with, I've been creating jUnit tests 
>>>> from the integration test code when I make changes to a class, it's 
>>>> pretty easy to do in your ide and the test results are instant.  
>>>> Every now and then you can run the integration and jtreg tests.
>>>> I downloaded your code from svn on kharma, have had a brief look 
>>>> and plan to look into it further, while doing so I thought to 
>>>> myself, here is someone who can write code,  why are we having so 
>>>> much trouble communicating?
>>>> You know when I talk to the great coders, their attitude is never 
>>>> one of superiority, it's always one of generosity and assistance, 
>>>> they're just happy to help with whatever problem your 
>>>> experiencing.  I think that's what distinguishes the great 
>>>> programmers, communication, it is reflected in their code too, and 
>>>> I'm not talking about comments, I mean you read the code, the names 
>>>> of methods and classes, the intent is just obvious.  But then look 
>>>> on find bugs, even the best are still human.
>>>> One word of advise about life, once you realise your own mortality 
>>>> and stare death in the face, before your time, especially when you 
>>>> have children, you wont worry so much about the technicalities, the 
>>>> little things just don't bother you anymore.  Make the most of life 
>>>> while it lasts, it really is fleeting.  It's not what you have that 
>>>> matters, its who.  Everything we argue over today will be forgotten 
>>>> tomorrow.
>>>> Best Regards,
>>>> Peter.
>>>> Mike McGrady wrote:
>>>>> Sent from my iPhone
>>>>> On Nov 18, 2009, at 8:59 PM, Sam Chance <sgchance@gmail.com> wrote:
>>>>>> Mike,
>>>>>> The typos and comments in your "reply" suggest you may be tired or
>>>>>> little under "some" influence.
>>>>> I am using an iPhone and haven't taken a single intoxicant for 
>>>>> millenia.  iPhones make up there own spelling at times.
>>>>>> If your "SOA experience" is typical, I can almost guarantee that
>>>>>> consists of proliferating (SOAP-based) web services...so what?
>>>>>> Wrapping an interface in XML simply perpetuates the same brittle
>>>>>> point-to-point - architecture.
>>>>> This is not true for real systems.
>>>>>> As for SLA, you *must* be joking! SLA are one of the *missing* 
>>>>>> aspects
>>>>>> of "mainstream" SOA. In fact, only recently has SLA been elevated
>>>>>> the dialog. I'm quite confident the "weighty SOA mindset" you 
>>>>>> posit is
>>>>>> based on WS-*.
>>>>> You are clearly confident but mistaken.  Try to get SDN data for 
>>>>> the FAA SWIM program your way.  Knowing about the data has 
>>>>> virtually nothing to do with actually getting it.
>>>>>> I find it almost humorous that you seem to refute Jini and OSGi as
>>>>>> instances of SOA constructs. You may want to circle back and change
>>>>>> all the literature about these two SOA frameworks to reflect your
>>>>>> view. Good luck with that.
>>>>> SOA is not a framework.  SOA is an architecture in which the 
>>>>> atomic elements are business level services.  This is standard talk.
>>>>>> I live and work in the DC area. I sense you do as well; or at least
>>>>>> you work on DoD or Federal government systems. That would explain

>>>>>> your
>>>>>> view about "SOA". But I could be wrong.
>>>>> I dont live in DC.  I live in the Seattle area.
>>>>>> I'd welcome the chance to meet with you and hammer out these issues.
>>>>>> I'm sure I could learn a lot...and *maybe* teach you a thing or two.
>>>>>> :-)
>>>>> I am sure I could learn a lot from you.
>>>>>> If you want to see SLA implemented by the runtime in a policy and
>>>>>> model-driven way, look at the Paremus Service Fabric. (Seems like
>>>>>> groundhog day...again).
>>>>> Service level agreements are not implemented in code.  This is WHY 
>>>>> SOA works.
>>>>>> Sam
>>>>>> On 11/18/09, Mike McGrady <mmcgrady@topiatechnology.com> wrote:
>>>>>>> I have been involved with some fairly mature and well known SOA
>>>>>>> systems for years and I certainly would never consider either

>>>>>>> Jini or
>>>>>>> OSGi to be anything remotely like a SOA netwrk.  SOA services
>>>>>>> explicitly SLA based and defined by business rules outside any
>>>>>>> strictures.  That is the key to there success.
>>>>>>> Only in a general and inconsequential sense can OSGi be 
>>>>>>> considered to
>>>>>>> have a registry.  Keeping syst state is not a registry.
>>>>>>> I wish this conversation, since it diverges willy milky from
>>>>>>> established computer science terminology could stuck to the 
>>>>>>> particulars.
>>>>>>> Just my thing and I probably have nothing more to say.
>>>>>>> Sent from my iPhone
>>>>>>> On Nov 18, 2009, at 5:14 PM, Sam Chance <sgchance@gmail.com>
>>>>>>>> Peter,
>>>>>>>> I agree with the notion that Jini and OSGi both implement
>>>>>>>> publish,
>>>>>>>> find and bind interaction model/pattern/paradigm / whatever

>>>>>>>> additional
>>>>>>>> related words one prefers. I've always described this construct

>>>>>>>> as the
>>>>>>>> "operational model" of SOA. It is exceedingly obvious to
>>>>>>>> the most
>>>>>>>> casual observer that Jini and OSGi adhere to this. The essential
>>>>>>>> difference is - in general terms - OSGi implements 
>>>>>>>> "publish-find-bind"
>>>>>>>> in a local memory space (I.e. a JVM) and Jini implements
>>>>>>>> across
>>>>>>>> multiple memory spaces (I.e. distributed). In my view, it
>>>>>>>> precisely
>>>>>>>> this difference that yields the complimentary nature of the
>>>>>>>> [SOA]
>>>>>>>> frameworks.
>>>>>>>> Ironically, although contemporary mainstream SOA "deployments",

>>>>>>>> which
>>>>>>>> are arguably Just a Bunch Of Web Services (JBOWS), prescribe

>>>>>>>> 'publish,
>>>>>>>> find and bind', they rely little on a registry (e.g. UDDI)
for the
>>>>>>>> 'find' function. Instead, they achieve the 'find' function
via a
>>>>>>>> highly distributed and decentralized mechanism called "WoM"

>>>>>>>> (Word of
>>>>>>>> Mouth). :-)
>>>>>>>> Sam
>>>>>>>> On 11/18/09, Michael McGrady <mmcgrady@topiatechnology.com>
>>>>>>>>> Peter,
>>>>>>>>> Okay.  I see.  You are not using "pattern" in the sense
>>>>>>>>> pattern
>>>>>>>>> brought
>>>>>>>>> into computer science by the Gang of Four.  You are using
>>>>>>>>> term
>>>>>>>>> more in
>>>>>>>>> a plain English sense.  I think this is misleading in
this venue
>>>>>>>>> and would
>>>>>>>>> suggest that you use another word to avoid the possible
>>>>>>>>> misunderstanding
>>>>>>>>> that you meant "design pattern" as it is used in computer

>>>>>>>>> science.
>>>>>>>>> On a more substantial note, I don't think the "pattern"
>>>>>>>>> discuss
>>>>>>>>> is the
>>>>>>>>> same at all for Jini and OSGi.  The services for OSGi
are not 
>>>>>>>>> like
>>>>>>>>> the
>>>>>>>>> services for SOA.  SOA services may or may not be akin
to the
>>>>>>>>> services for
>>>>>>>>> Jini.  I am very careful about abstracting or generalizing

>>>>>>>>> because,
>>>>>>>>> although
>>>>>>>>> my first and last love in computer science is architecture,
>>>>>>>>> devil is in
>>>>>>>>> the detail.
>>>>>>>>> For my part, I think it would be worthwhile to determine
>>>>>>>>> level of
>>>>>>>>> Ossification you want.  For example, there would be no
harm at 
>>>>>>>>> all
>>>>>>>>> in seeing
>>>>>>>>> whether you can modularize the jar files into bundles.
 Once that
>>>>>>>>> is done,
>>>>>>>>> then you can begin seeing how the actual processes in
OSGi match
>>>>>>>>> those in
>>>>>>>>> Jini.  As yet, you do not even know, as I understand
it, what 
>>>>>>>>> OSGi
>>>>>>>>> services
>>>>>>>>> you want.  That would need to be determined, since you
will be
>>>>>>>>> customizing
>>>>>>>>> them.
>>>>>>>>> I hope this is helpful and thank you for stating what
you were
>>>>>>>>> thinking.
>>>>>>>>> Mike
>>>>>>>>> On Nov 17, 2009, at 8:33 PM, Peter Firmstone wrote:
>>>>>>>>>> Mike McGrady wrote:
>>>>>>>>>>> I am presently the author of a framework called
"Karma" (Kolona
>>>>>>>>>>> Automated
>>>>>>>>>>> Resource Management Architecture) that is open
source with a
>>>>>>>>>>> management
>>>>>>>>>>> app under another open source framework AUM (Automated

>>>>>>>>>>> Universal
>>>>>>>>>>> Middleware).
>>>>>>>>>>> UM  (Universal Middleware) is a more current
name for OSGi.
>>>>>>>>>>> We could have called it DUM (Distributed Universal
>>>>>>>>>>> instead of
>>>>>>>>>>> AUM but thought better.
>>>>>>>>>>> Too bad we did not get on better when I asked
you what you 
>>>>>>>>>>> meant by
>>>>>>>>>>> "Service Pattern".  (I still have no idea what
you mean.)
>>>>>>>>>> Here's a Clarification of what I meant by "Service
>>>>>>>>>> from
>>>>>>>>>> Richards
>>>>>>>>>> Book, page 12, this should clear up any remaining
>>>>>>>>>> "the service-oriented publish, find, and bind interaction

>>>>>>>>>> pattern:
>>>>>>>>>> service
>>>>>>>>>> providers publish their services into a service registry,
>>>>>>>>>> service
>>>>>>>>>> clients search the
>>>>>>>>>> registry to find available services to use (see Figure
>>>>>>>>>> So there you go it's the "Publish, find and bind
>>>>>>>>>> pattern"
>>>>>>>>>> The point I was attempting to make in the beginning
was that 
>>>>>>>>>> Jini,
>>>>>>>>>> OSGi,
>>>>>>>>>> ServiceLoader and Netbeans Modules all use the "Publish,
>>>>>>>>>> and
>>>>>>>>>> bind
>>>>>>>>>> interaction pattern" to solve different problems,
I was 
>>>>>>>>>> trying to
>>>>>>>>>> lay out
>>>>>>>>>> the understanding to avoid an argument and promote
a discussion
>>>>>>>>>> about how
>>>>>>>>>> to implement utilisation of OSGi within River and
>>>>>>>>>> applications.
>>>>>>>>>> I still haven't managed to achieve this discussion,
>>>>>>>>>> the
>>>>>>>>>> best way
>>>>>>>>>> forward will become more apparent during implementation.
>>>>>>>>>> Cheers,
>>>>>>>>>> Peter.
>>>>>>>>>>> Anyway, this does all you want to do and we have
a plan to have
>>>>>>>>>>> it set as
>>>>>>>>>>> a standard with IEEE, where I am a member of
the standards
>>>>>>>>>>> committee.  If
>>>>>>>>>>> you check there in a few months, you can see
what I was 
>>>>>>>>>>> hoping to
>>>>>>>>>>> talk to
>>>>>>>>>>> you about before your ego got in the way.
>>>>>>>>>>> Good luck with your endeavors.
>>>>>>>>>>> Mike
>>>>>>>>>>> On Nov 8, 2009, at 5:06 PM, Peter Firmstone wrote:
>>>>>>>>>>>> Yes that's the beauty of Services, they provide
>>>>>>>>>>>> for
>>>>>>>>>>>> pluggable replacement implementations.  That's
the "Service
>>>>>>>>>>>> Pattern"  As
>>>>>>>>>>>> we have seen it is possible to use the Service
Pattern to 
>>>>>>>>>>>> solve
>>>>>>>>>>>> a number
>>>>>>>>>>>> of different problems.  Eg Netbean Plugins,
SPI, OSGi, Jini.
>>>>>>>>>>>> I'm looking at OSGi to wire up services inside
the JVM as you
>>>>>>>>>>>> say.  When
>>>>>>>>>>>> I say package, I mean a java package residing
in the local JVM
>>>>>>>>>>>> it may or
>>>>>>>>>>>> may not be part of a Jini service, it may
be a purely local 
>>>>>>>>>>>> JVM
>>>>>>>>>>>> package,
>>>>>>>>>>>> eg a library dependency or local domain package.
>>>>>>>>>>>> example, I
>>>>>>>>>>>> have
>>>>>>>>>>>> package X, version 1 loaded in my local JVM,
I need to have
>>>>>>>>>>>> package X
>>>>>>>>>>>> version 2 loaded as version 1 isn't compatible
with the new
>>>>>>>>>>>> Objects
>>>>>>>>>>>> (domain data) I'm recieving in serialized
form.  I need to 
>>>>>>>>>>>> share
>>>>>>>>>>>> this
>>>>>>>>>>>> information locally with Package Y that currently
>>>>>>>>>>>> references
>>>>>>>>>>>> to
>>>>>>>>>>>> objects in Package X version 1.  The Objects
in Package X
>>>>>>>>>>>> version 1 that
>>>>>>>>>>>> Package Y references need to have their class
files upgraded.
>>>>>>>>>>>> Without
>>>>>>>>>>>> OSGi I can do this by persisting state, stopping
the JVM,
>>>>>>>>>>>> restarting and
>>>>>>>>>>>> loading package X version 2.
>>>>>>>>>>>> I'm not looking at distributed OSGi, but
I can see a use 
>>>>>>>>>>>> case for
>>>>>>>>>>>> utilising a Jini Service, when a local OSGi
bundle that 
>>>>>>>>>>>> performs
>>>>>>>>>>>> some
>>>>>>>>>>>> task that could be done optimally if the
processing can be 
>>>>>>>>>>>> moved
>>>>>>>>>>>> to
>>>>>>>>>>>> where the data resides, this is just an example
there are
>>>>>>>>>>>> probably 10
>>>>>>>>>>>> other ways of doing this:
>>>>>>>>>>>> A local application bundle that provides
an OSGi service 
>>>>>>>>>>>> locally
>>>>>>>>>>>> queries
>>>>>>>>>>>> a remote database using JDBC and performs
a considerable 
>>>>>>>>>>>> amount of
>>>>>>>>>>>> manipulation to that data prior to returning
a subset.  The
>>>>>>>>>>>> query and
>>>>>>>>>>>> its result are sent over the network using
a database JDBC
>>>>>>>>>>>> connection.
>>>>>>>>>>>> The processing for that data, if shifted
to the machine 
>>>>>>>>>>>> that has
>>>>>>>>>>>> the
>>>>>>>>>>>> database data, would consume significantly
less network
>>>>>>>>>>>> resources.  EG
>>>>>>>>>>>> the data transferred over the network is
reduced by a 
>>>>>>>>>>>> factor of
>>>>>>>>>>>> 100 by
>>>>>>>>>>>> processing the data on the database machine
after querying.  A
>>>>>>>>>>>> bundle
>>>>>>>>>>>> that provides a "local JVM application" an
"OSGi service" 
>>>>>>>>>>>> could
>>>>>>>>>>>> utilise
>>>>>>>>>>>> a "Jini Service" to request the data be processed
at the 
>>>>>>>>>>>> Database
>>>>>>>>>>>> machine in a particular manner before receiving
>>>>>>>>>>>> result.  This
>>>>>>>>>>>> function could be locally available as an
OSGi service to some
>>>>>>>>>>>> other
>>>>>>>>>>>> local application, that application doesn't
need to know about
>>>>>>>>>>>> Jini, it
>>>>>>>>>>>> is an implementation detail that is abstracted.
>>>>>>>>>>>> My objectives are all based around codebase
services (objects
>>>>>>>>>>>> aren't
>>>>>>>>>>>> locked to their http codebase origin), in
combination with 
>>>>>>>>>>>> OSGi or
>>>>>>>>>>>> something like it, to ensure compatible classes
>>>>>>>>>>>> packages are
>>>>>>>>>>>> loaded
>>>>>>>>>>>> among separate JVM instances.  Yes Newton
does something 
>>>>>>>>>>>> similar,
>>>>>>>>>>>> however it is AGPLv3 licensed.
>>>>>>>>>>>> I envision a distributed environment where
nodes can have the
>>>>>>>>>>>> majority
>>>>>>>>>>>> of their packages downloaded and upgraded
via codebase 
>>>>>>>>>>>> servcies.
>>>>>>>>>>>> Providing an evolving cluster, that upgrades
it's bundles
>>>>>>>>>>>> incrementally,
>>>>>>>>>>>> while maintaining the maximum level of class
and package
>>>>>>>>>>>> compatibility.
>>>>>>>>>>>> Think Agile Cluster Running System component
>>>>>>>>>>>> People, who are jumping in now because I've
mentioned OSGi, 
>>>>>>>>>>>> are
>>>>>>>>>>>> making
>>>>>>>>>>>> assumptions and haven't been following the
discussions I've 
>>>>>>>>>>>> posted
>>>>>>>>>>>> previously about Versioned Classes, Classloader
trees, Static
>>>>>>>>>>>> Analysis
>>>>>>>>>>>> and Codebase Services, this is frustrating
as I was hoping for
>>>>>>>>>>>> some
>>>>>>>>>>>> participation.  It seems I can only get attention
when I 
>>>>>>>>>>>> mention a
>>>>>>>>>>>> controversial subject.  What I want is attention
to solving 
>>>>>>>>>>>> the
>>>>>>>>>>>> problems
>>>>>>>>>>>> that will make River better.
>>>>>>>>>>>> In my note below when I'm referring to the
>>>>>>>>>>>> Pattern", I
>>>>>>>>>>>> mean the
>>>>>>>>>>>> service pattern that OSGi implements, enables
bundles to be
>>>>>>>>>>>> upgraded by
>>>>>>>>>>>> loading the replacement bundle in a new classloader,
>>>>>>>>>>>> service is a
>>>>>>>>>>>> common interface, the new upgraded service
is discovered after
>>>>>>>>>>>> it is
>>>>>>>>>>>> started.  The alternative is to use delegates
to update 
>>>>>>>>>>>> references
>>>>>>>>>>>> between objects when the Classloader changes
as per some of 
>>>>>>>>>>>> the
>>>>>>>>>>>> other
>>>>>>>>>>>> patches I've uploaded.
>>>>>>>>>>>> Jini also utilises a "Service Pattern", but
to solve a 
>>>>>>>>>>>> different
>>>>>>>>>>>> problem.
>>>>>>>>>>>> I knew this was going to be a difficult topic
to present.
>>>>>>>>>>>> What we need are separate lists, where people
who want to
>>>>>>>>>>>> participate in
>>>>>>>>>>>> constructive development to solve problems
can do so and 
>>>>>>>>>>>> another
>>>>>>>>>>>> list
>>>>>>>>>>>> where people can pontificate about software
ideals and have
>>>>>>>>>>>> disrespectful arguments with each other without
holding up
>>>>>>>>>>>> development.
>>>>>>>>>>>> While we're developing we can keep an eye
on the argument list
>>>>>>>>>>>> without
>>>>>>>>>>>> getting embroiled.
>>>>>>>>>>>> Anyway I've said enough, I'm going back to
doing the things I
>>>>>>>>>>>> need to
>>>>>>>>>>>> do, if someone who has been following my
posts to date has
>>>>>>>>>>>> implementation ideas, but are afraid to mention
it, please 
>>>>>>>>>>>> feel
>>>>>>>>>>>> free to
>>>>>>>>>>>> contact me directly to discuss, I do need
some input to gain
>>>>>>>>>>>> confidence
>>>>>>>>>>>> that I'm approaching these problems in the
right manner.
>>>>>>>>>>>> Peter.
>>>>>>>>>>>> Dennis Reedy wrote:
>>>>>>>>>>>>> On Nov 8, 2009, at 1251AM, Peter Firmstone
>>>>>>>>>>>>>> I had avoided OSGi purely due to
the controversy it 
>>>>>>>>>>>>>> generates
>>>>>>>>>>>>>> on this
>>>>>>>>>>>>>> list, however without the Service
Pattern one cannot 
>>>>>>>>>>>>>> upgrade a
>>>>>>>>>>>>>> package
>>>>>>>>>>>>>> without first persisting everything
and shutting down the
>>>>>>>>>>>>>> entire JVM,
>>>>>>>>>>>>>> then restarting.  At least OSGi allows
you to stop a bundle
>>>>>>>>>>>>>> and any
>>>>>>>>>>>>>> dependents, persist what you need
to then start with a later
>>>>>>>>>>>>>> bundle
>>>>>>>>>>>>>> version if desired, without having
to persist or shut 
>>>>>>>>>>>>>> down the
>>>>>>>>>>>>>> entire
>>>>>>>>>>>>>> JVM.
>>>>>>>>>>>>> If thats all you want you dont need OSGi.
>>>>>>>>>>>>> lifecycles are
>>>>>>>>>>>>> supported with a variety of container
approaches, from JEE,
>>>>>>>>>>>>> Spring to
>>>>>>>>>>>>> Rio. You also do not need to shutdown
the JVM to load new 
>>>>>>>>>>>>> service
>>>>>>>>>>>>> classes.
>>>>>>>>>>>>> Adopting OSGi as a micro-kernel architecture
for wiring up
>>>>>>>>>>>>> services
>>>>>>>>>>>>> inside the JVM is a different thing.
Looking at distributed
>>>>>>>>>>>>> OSGi is a
>>>>>>>>>>>>> totally different thing on top of that.
IMO, if you want to
>>>>>>>>>>>>> consider
>>>>>>>>>>>>> OSGi for River, you focus on the former,
not the latter.
>>>>>>>>>>> Mike McGrady
>>>>>>>>>>> Principal Investigator AF081-028 AFRL SBIR
>>>>>>>>>>> Senior Engineer
>>>>>>>>>>> Topia Technology, Inc.
>>>>>>>>>>> 1.253.720.3365
>>>>>>>>>>> mmcgrady@topiatechnology.com
>>>>>>>> -- 
>>>>>>>> Sent from my mobile device
>>>>>>>> Sam Chance
>>>>>>>> 443-694-5293 (m)
>>>>>>>> 410-694-0240 x108 (o)
>>>>>> -- 
>>>>>> Sent from my mobile device
>>>>>> Sam Chance
>>>>>> 443-694-5293 (m)
>>>>>> 410-694-0240 x108 (o)

View raw message