Also maven has been used as part of this solution too. Maven lookup by package instead of interface seems like adding another layer or a redirection in lookup mechanisms.
Gregg Sent from my iPhone > On Jul 26, 2016, at 8:41 AM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > I am well aware of StartNow since that is the first Jini "support library" I > have used. Indeed - it is really easy to use. > But it is only one side of the issue - the API and some support support code > that is supposed to be linked statically with the service implementation. > > What I am talking about is actually "externalizing" most aspects of a service > implementation so that: > - you do not have to package any (for some meaning of "any" :) ) libraries > statically (since all code can be downloaded dynamically) > - you do not have to provide any (for some meaning of "any" :) ) static > configuration (ie. configuration files) - a service should simply use other > services and "reconfigure" itself when those change > It would go towards some kind of an "agent architecture", with movable > objects (ie "services") being "hosted" by well... other movable objects :). > The idea is less appealing today when we have all the cloud infrastructure, > virtualization, software defined networking etc. Nevertheless still > interesting IMHO. > > Thanks, > Michal >> Gregg Wonderly July 26, 2016 at 1:28 PM >> My StartNow project on Java.net aimed directly at this mode of operation a >> decade ago. I wanted conventions that provided use of configuration with >> defaults. >> >> You just extend PersistantJiniService and call start(serviceName). >> Subclasses could override default implementation for how the conventions in >> the APIs created implementation objects through code or configuration. >> >> The intent was to create THE API to provide the conventions of service >> creation. >> >> We have a Window/JWindow class and don't have to do all the decorating >> ourselves. >> >> Jini service construction should work the same way! >> >> Gregg >> >> Sent from my iPhone >> >> >> Tom Hobbs July 26, 2016 at 11:50 AM >> I would say the comment on that blog sums everything about Jini up. >> >> It’s just too hard to set up and get working. >> >> That’s why I think simplifying reggie is possibly a first step. Make a >> /small/ and simple reggie jar that just handled service registration and not >> proxy downloading etc. Make it really easy to register your services without >> needing class loaders etc, preferably via some convention rather than >> configuration. (This is what I’m trying to find the time to work on.) >> >> I’d really like to be able to type; >> >> $ java -jar reggie.jar >> >> And have a reggie running with all the defaults ready to register my >> services with. Or perhaps, as an option; >> >> $ java -jar reggie.jar —ipv6 >> >> Security, class loading, proxy downloading and all the rest of it could then >> be put back in by specifying more advanced configuration options. >> >> My Scala service would be great if I could define it just as; >> >> object MyCoolService extends LazyLogging with ReggieRegistration with >> ReggieLookup >> >> Or in Java with default interface methods; >> >> class MyCoolService implements ReggieRegistration, ReggieLookup >> >> And that would be it, congratulations you’ve started a reggie and registered >> your service and have methods available to help you find other services. >> >> This would satisfy use cases where the network was private and/or trusted. >> And security on top would, ideally, be up to configuration again or perhaps >> injecting some alternative implementation of some bean somewhere. But the >> core premise is, make it easy to startup, demo and see if it fits what you >> want it for. >> >> >> >> >> Peter July 26, 2016 at 3:58 AM >> Note the comment about security on the blog? >> >> Steps I've taken to simplify security (that could also be adopted by river): >> 1. Deprecate proxy trust, replace with authenticate service prior to >> obtaining proxy. >> 2. proxy codebase jars contain a list of requested permissions to be granted >> to the jar signer and url (client need not know in advance). >> 3. Policy file generation, least privilege principles (need to set up >> command line based output for admin verification of each permission during >> policy generation). >> 4 Input validation for serialization. >> 5. DownloadPermission automatically granted to authenticated registrars (to >> signer and url, very specific) during multicast discovery. >> >> Need to more work around simplification of certificate management. >> >> Regards, >> >> Peter. >> Sent from my Samsung device. >> >> Include original message >> ---- Original message ---- >> From: Peter <j...@zeus.net.au> >> Sent: 26/07/2016 10:27:59 am >> To: dev@river.apache.org <dev@river.apache.org> >> Subject: another interesting link >> >> https://blogs.oracle.com/hinkmond/entry/jini_iot_edition_connecting_the >> >> >> Sent from my Samsung device. >
