Hi Peter, I was hoping to take a step back for a second, perhaps its just me that seems to have my head spinning of late on this list. I may have missed some things, but we've discussed many issues over the past week:
- How to advertise the DL jar(s) a service vends, allowing a client to download requisite jars that allow the jars to be loaded from a local (trusted) location - Given the capability above, the need for a codebase service may not be required - Conventions on how to develop River services, as it relates to jar naming, packaging and what dependencies are between the various artifacts - How to possibly move forward with utilizing Maven repositories and the implied capabilities of published artifacts - The development of a maven archetype to allow a developer to easily create a working project in seconds Your attention to detail and the documentation of how class loader interactions with regards to security is great. I'd like to understand the requirements of what you have documented below, the urge to refactor MarshalledInstance, and why the new class loader hierarchy needs to be added to River. Perhaps I'm just missing some fundamental issues, but maybe we need to take some time and determine the whys before the hows? Is this direction fundamental to the OSGi direction that you're taking? If so, how does this impact non-OSGi based systems? Thanks Dennis On May 24, 2010, at 1034PM, Peter Firmstone wrote: > Thanks Chris, > > Sound like it's time for some MarshalledInstance Refactoring? > > Perhaps a Maven (generic if possible) URL schema (with message digest > support), we need an annotation (or name convention) that indicates whether > proxy's can share ClassLoader & ProtectionDomain space, dictated by static > variables and common Principals. > > A new constructor for MarshalledInstance that accepts an alternate URL too. > > ... and two new methods in MarshalledInstance: > Object get(ClassLoader cl, CodeSource[] cs, boolean verifyCodeBaseIntegrity); > URL[] getCodeSourceAnnotation(); > > Then MarshalledServiceItem could include new methods: > > public URL[] getCodeSourceAnnotation(); > public Object getService( CodeSource[] cs ); > //If cs == null || cs missing a CodeSource use default URL. > > Note here that while unmarshalling has been delayed, I haven't relinquished > control of ClassLoaders or ProtectionDomains, eg the client can use OSGi, > without dictating the Service must also, none of the serialized instances > from method returns will need to be deserialized by OSGi, avoiding altogether > the OSGi deserialization issue. > The client application doesn't have to deal with these concerns directly, we > could write multiple ResultStreamFilters that can be chained, the filter that > matches the URL schema will unmarshall the service, the filter sequence will > dictate the preferred unmarshalling. The filter responsible for successful > unmarshalling would construct a new ServiceItem, that isn't unmarshalled, the > next unmarshalling filter would ignore it, allowing it to pass through. > After it is unmarshalled another filter will check method constraints. > > Method Parameters that originate from client ClassLoaders will be > unmarshalled in the Application ClassLoader space on the Service > implementation node, this is where things get hairy if the Service API method > parameters are non final, abstract or interfaces. Any class that belongs to > a Service API jar will be safely loaded into the Jini Platform ClassLoader > space in it's own ProtectionDomain. Client returned parameter classes > however will need their own ClassLoader's > > If the Service API is loaded into a Parent ClassLoader (Jini Platform > ClassLoader) at the Service implementation node and API parameters are > extended, the client classes will need their own ClassLoader space at the > Service Implementation end, Since a service may serve many clients, these > ClassLoaders must be shared, based on identical CodeSource and Principals. > The client classes will only be accessible via the Service API interfaces or > classes (they are abstracted). > > ANY CLIENT THAT IMPLEMENTS AN API Interface or extends an API parameter, will > need to make it's implementation package jar publicly available. Like the > proxy implementation, it is free to change, however it should be versioned > appropriately, like the proxy and have it's own jar. ( This is where the > Java Package Version Spec comes in handy, we can annotate classes with > Package version and local CodeSource). The CodeSource might contain a file > URL, however it will contain the jar archive name (which is why Dennis want's > to name packages with their versions, which can't hurt!) and given the > Package Version Spec, it will work for OSGi bundles as well as Maven. A > client using an OSGi bundle must remember that all of the implementing > classes should be in the same bundle and the Service node and may not be > utilising OSGi, so shouldn't attempt to use any OSGi services in Service API > parameter implementations. > > The version spec will identify compatiblity of classes, the closed compatible > local CodeSource may be used, otherwise a new ClassLoader will be used. Each > client will either share all compatible CodeSource and Principals or have > their own ClassLoader space. > > Greg, do you think we could use your service-client.jar for client parameter > implementations or would this cause confusion? > > Perhaps we should use: > > service-param.jar > > So to really round if off: > > Service Implementers must produce versioned manifest jar archives of: > > Smart Proxy: > > Implementation jar: service.jar (depends on service-api.jar) > API jar: service-api.jar > Smart proxy jar: service-proxy.jar (depends on service-api.jar) > Selfish Smart proxy jar: service-iproxy.jar (depends on > service-api.jar) > > Dumb Proxy: > > Implementation jar: service.jar (depends on service-api.jar) > API jar: service-api.jar > > > Client Implementers must produce version manifest jar archives of: > > Client Parameter extensions: service-param.jar > > If you didn't guess correctly the Selfish Smart proxy jar is the one that > proxy's cannot share in the same ClassLoader and ProtectionDomain. > > > ClassLoader Structure (In addition to all your helpful comments on river-dev, > thanks also to Jim, Tim & Mike, planting the seed): > > System ClassLoader > | > Extension ClassLoader (incl jsk-policy.jar) > | > Jini Platform ClassLoader (incl jsk-platform.jar, *-api.jar) > | > _______________|__________________________________ > | | | > Application ClassLoader Proxy ClassLoader's Parameter Impl ClassLoader's > (Apps & Service Impl) (Smart Proxy's) (Remote client parameter > classes) > > > Advise History: > > Jim: Use common Interfaces and classes in Parent ClassLoaders > Tim: Thanks for research on Dependency Tree and ClassLoader Tree's and > guidance. > Mike: Research paper on ClassLoader issues. > > Thanks & Praise worth mentioning: > > Bob Scheifler and others for Jini's strong Security foundation. > Bill Venners for the ServiceUI, it is truly innovative > > (hint: come back) > > > Christopher Dolan wrote: >> Isn't List<URL> already present in the MarshalledInstance? Why repeat >> this as an Entry? Wouldn't it be easier to just add a public accessor >> to deserialize the list of URLs from MarshalledInstance.locBytes? >> >> I apologize if this was already explained, but there's been a LOT of >> email to read on this list lately. >> >> Chris >> >> -----Original Message----- >> From: Dennis Reedy [mailto:[email protected]] Sent: Saturday, May 22, >> 2010 9:29 AM >> To: [email protected] >> Subject: Re: Maven repository Entry was Re: Codebase service? >> >> [CJD] ... <snip> ... >> >> I would just go with a >> List<String> dlJars; >> >> With this you could provide support for retrieving the DL jar(s) for >> non-maven systems as well. If the dlJars property contains 1 element and >> is of the form groupId:artifactId:version:classifier, then maven >> resolution gets used. Otherwise the DL jars can be obtained using the >> codebase of the advertising service. >> >> For maven resolution, I think you'll also want to either provide support >> for parsing your maven settings.xml or include the repositories to go >> find the artifact if it's not present. If the artifact is retrieved from >> the repository it will have a message digest along side of it (with >> either a .sha1 or .md5 extension). That can be used to compare a locally >> computed digest HttpmdUtil.computeDigest() for updates. But that >> comparison really only needs to take place for snapshots, since by >> definition releases are considered immutable. >> >> IMO supporting transitive deps is a must have, without that we really >> dont get that far. A DL artifact may depend on another DL artifact, and >> that DL artifact may have deps as well. >> >> >> >> >
