I meant RMIClassLoaderSPI below. And note that this mechanism is currently a VM Wide implementation detail, instead of being a service proxy specific mechanism. That’s where we need to be able to allow for something specific to plugin for a specific service to use a specific platform for resolving proxy and serviceUI components.
Gregg > On Feb 3, 2017, at 9:52 AM, Gregg Wonderly <ge...@cox.net> wrote: > > I was merely speaking of a ClassLoader which might composite several > ClassLoaders using something like the codebase annotation. If we want to > make it possible to load service proxies and serviceUI codebases from > “anywhere” in Jini, we should be prepared to utilize whatever “compositing” > technique that platform provides/uses, while still trying to provide a > concrete view of ClassLoader passed around as TCCL so that specific isolation > that will occur, is maintained in code that is shared across all of these > codesource types. > > There may need to be some kind of factory involved at some level that is > parameterized by platform type, as is implied by the RMIClassLoaderAPI > mechanisms use of the codebase annotation. > > Gregg > >> On Feb 3, 2017, at 12:52 AM, Peter <j...@zeus.net.au> wrote: >> >> Just in case I've misunderstood. Was your reference to composite ClassLoader >> is a reference to Bharath's earlier posted link? >> >> http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html?m=1 >> >> Regards, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> ---- Original message ---- >> From: Peter <j...@zeus.net.au> >> Sent: 03/02/2017 02:23:25 pm >> To: dev@river.apache.org <d...@riverapache.org> >> Subject: Re: OSGi >> >> Thanks Gregg, >> >> I realise that Jini may have been a lot more successful had your experiences >> with desktop applications been given greater consideration. >> >> Any thoughts on JavaFX, fxml for serviceui? >> >> Criticism had also in the past, been levelled at the lookup service's >> inability to perform boolean logic comparisons of Entry fields. Delayed >> unmarshalling allows local Entry comparisons, improved security and a more >> responsive ui. >> >> I understand why you wouldn't want to "download the internet" (which really >> means download transitive dependencies at startup) when a user first opens >> their desktop application, quick start up is important on the desktop. Less >> so on the server where run time performance is more important. >> >> I get that you're not prepared to take a backwards step with desktop start >> up performance. >> >> OSGi support is targeted towards Iot and growing our developer base, it's a >> convenient time for me to work on that now, as I'm working on a modular >> maven build, but it's still my understanding that we (River) also intend to >> continue supporting other developers who don't utilise OSGi or Maven (Rio >> users). >> >> Maven pulls in a lot of unnecessary transitive dependencies (which isn't a >> problem for a server or build env), OSGi reduces them by using package >> dependencies at runtime. Classdep can reduce the number further to only the >> class files necessary, but it doesn't support versioning. >> >> Jigsaw is a modular framework that doesn't use ClassLoaders to manage module >> visibility but it has no versioning support either >> >> Containers and modularity are developer concerns, but we need to ensure this >> is as easy as possible for developers to implement their chosen design and >> environment. Right now OSGi is difficult because no one has written >> serialization that takes its ClassLoader visibility into account. >> >> OSGi and Maven provide some good tools for automating and simplifying the >> build process. Bnd generates manifests automatically with package imports >> and exports for OSGi and also reads annotations. Modules certainly make the >> code easier to read and understand for the maintainer and allows components >> that don't change to be released on different timeframes. The qa test suite >> is still an ant build, which I'm currently working on running with the new >> jar names on the class path (affects test policy file grants). Clearly >> tests will need to be written for OSGi. >> >> The TCCL classloader will continue to work as it always has, when an OSGi >> framework is not detected. >> >> At the end of the day though, no framework is mandatory and developers can >> use classdepandjar to package only the classes needed for a client app or >> proxy into a single jar. >> >> The classdepend library (rewritten internals of classdep that uses asm) >> could be utilised to create a runtime dependency graph as you suggest (which >> could be serialized) and Jigsaw may yet have a role to play (and I've done >> some work already to support java 9). The risk with Classdep is, it may not >> pick up all dependencies in modern bytecode, its only written with >> consideration for java 6 class files. Jdk 1.9 provides a new tool, jdeps to >> discover dependencies and this might be utilised to replace Classdep or its >> internal implementation in the long term, if someone steps up and takes that >> on. Classdep has developed a bug in recent times that affects the build >> (occassionally drops deps) and there has been little maintenance on it >> recently. >> >> OSGi could also determine dependency graphs, however would be OSGi specific >> (package deps) and I'm not yet certain it's necessary. I also think that >> dependency graphs will tend to be a framework concern, whether they are >> class, package or module based dependencies they are specific. >> >> At this time, choosing a specific container or framework for developers to >> utilise is a non goal, we're just working on better support for >> deserialization in an OSGi framework, because there are visibility problems >> that the TCCL can't completely solve for OSGi. >> >> No serialization or Remote method invocation framework currently supports >> OSGi very well, one that works well and can provide security might gain a >> lot of new interest from that user base. >> >> A modular River also reduces the api users need to learn to get started, >> which makes River easier to learn for Maven or OSGi developers. In this >> case they already understand their build tools and probably want to continue >> using them. >> >> It's a non goal to chose any particular modular ity framework for developers >> to use at this time. >> >> Regards, >> >> Peter. >> >> Sent from my Samsung device . >> >> Include original message >> ---- Original message ---- >> From: Gregg Wonderly <ge...@cox.net> >> Sent: 03/02/2017 01:25:35 am >> To: dev@river.apache.org >> Subject: Re: OSGi >> >> I am a fan of “one jar” because I get real tired of spending time >> “packaging” when the class loading mechanisms already provide “segregation”. >> I understand how “pretty” packaging is and how everyone can be completely >> excited about a clean view of dependencies. However, when I package >> something that works, I don’t want to hand someone 5 things. The “jar” file >> has been “click to run” file type for a long time. That, for me means that >> you should be able to get everything you need from that jar. The problem >> that clickable jar files suffer from, is that lack of use of Java for >> desktop apps. Instead, the server mentality of 10s of jars from 10s of >> places, integration, versioning, etc., have created the “lots of pieces is >> fine” viewpoint and tooling around that has made it pretty much impossible >> to easily create one jar, without “custom” packaging. >> >> I like to solve problems once, not over and over again. We need to make >> sure and think about “tools” that make whatever packaging is decided on, >> trivial to create. Think about using annotations to segregate pieces into >> the packages that you want them to be in. Think about runtime dependency >> graphs being expressible in annotations as well, so that we might be able to >> utilize a composite class loader to “get” dependent jars from an appropriate >> source. This would allow great, dynamic binding to occur in the class >> loader, and still provide a single class loader view of the context so that >> TCCL and other parts of the Java runtime will still work in non-jini >> packages. >> >> Gregg >> >>> On Feb 1, 2017, at 7:44 PM, Peter <j...@zeus.net.au> wrote: >>> >>> Thanks Gregg, >>> >>> I think it's necessary to continue supporting preferred class loading for >>> those who don't use osgi or maven. Rio already has a maven class resolver >>> RMIClassLoaderSPI implementation. But we also need to ensure we can still >>> solve the same problems that preferred class loading addresses in modular >>> environments. >>> >>> We also need to consider how existing implementations can transition to a >>> modular framework, should developers want to. >>> >>> River / Jini's classdepandjar duplicates classes in jar files. Maven or >>> OSGi modules usually don't. >>> >>> In a modular version of Gregg's use case scenario, the shared Entries >>> wouldn't be included in the proxy codebase but instead be imported from >>> another module / bundle / package. >>> >>> The Entry's would be imported by the client and proxy modules / bundles, >>> avoiding unnecessary downloads and ensuring shared visibility. The client >>> and proxy will need to have an overlapping import package version range and >>> the currently utilised package at the client will need to be within the >>> proxy's imported version range, so it will be wired / resolved correctly. >>> >>> We should look at implementing a modular test case of what your doing, to >>> test our OSGiClassProvider. >>> >>> Supporting OSGi is likely to require delayed unmarshalling. Logical >>> comparisons of Package version Entry's will be required before proxy's can >>> be downloaded/ unmarshalled. >>> >>> The lookup service only provides exact matching. However it would be >>> possible to perform a limited range of version matching with wild cards >>> without delayed unmarshalling. >>> >>> Modular frameworks reduce downloads by utilising already downloaded code >>> when compatible. >>> >>> Regards, >>> >>> Peter >>> >>> Sent from my Samsung device. >>> >>> Include original message >>> ---- Original message ---- >>> From: Gregg Wonderly <ge...@cox.net> >>> Sent: 02/02/2017 06:56:43 am >>> To: dev@river.apache.org >>> Subject: Re: OSGi >>> >>> Part of the “preferred” is to keep downloads from happening. But the other >>> is the fact that the UI is already using/linked to specific sources of the >>> Entry classes that it uses for finding the name of the service, the icon >>> and other details. There are serviceUI classes which are also already >>> bound at the time of service discovery and the serviceUI for that service >>> needs to resolve to those classes, not any in the codebase jars for the >>> service. >>> >>> Gregg >>> >>>> On Feb 1, 2017, at 5:52 AM, Peter <j...@zeus.net.au> wrote: >>>> >>>> Gregg, >>>> >>>> Have you got some more detail on your Entry classes that need to be >>>> preferred? >>>> >>>> Thanks, >>>> >>>> Peter. >>>> >>>> Sent from my Samsung device. >>>> >>>> Include original message >>>> ---- Original message ---- >>>> From: Gregg Wonderly <ge...@cox.net> >>>> Sent: 31/01/2017 12:56:56 am >>>> To: dev@river.apache.org >>>> Subject: Re: OSGi >>>> >>>> Maybe you can help me out here by explaining how it is that execution >>>> context and class visibility are both handled by OSGi bundles. For >>>> example, one of my client applications is a desktop environment. It does >>>> service look up for all services registrations providing a “serviceUI”. >>>> It then integrates all of those services into a desktop view where the UIs >>>> are running at the same time with each one imbedded in a JDesktopPane or a >>>> JTabbedPane or a JFrame or JDialog. There are callbacks from parts of >>>> that environment into my application which in turn is interacting with the >>>> ServiceUI component. You have AWT event threads which are calling out, >>>> into the ServiceUIs and lots of other threads of execution which all, >>>> ultimately, must have different class loading environments so that the >>>> ServiceUI components can know where to load code from. >>>> >>>> It’s exactly TCCL that allows them to know that based on all the other >>>> class loading standards. The ClassLoader is exactly the thing that all of >>>> them have in common if you include OSGi bundles as well. The important >>>> detail, is that if the TCCL is not used as new ClassLoaders are created, >>>> then there is no context for those new ClassLoaders to reference, >>>> universally. >>>> >>>> The important details are: >>>> >>>> 1) The desktop application has to be able to prefer certain Entry >>>> classes which define details that are presented to the user. >>>> 2) When the user double clicks on a services icon, or right clicks >>>> and selects “Open in new Frame”, an async worker thread needs a TCCL >>>> pointing at the correct parent class loader for the service’s >>>> URLClassLoader to reference so that the preferred classes work. >>>> 3) Anytime that the AWT Event thread might be active inside of the >>>> services UI implementation, it also needs to indicate the correct parent >>>> class loader if that UI component causes other class loading to occur. >>>> 4) I am speaking specifically in the context of deferred class >>>> loading which is controlled outside of the service discovery moment. >>>> >>>> >>>>> On Jan 30, 2017, at 4:04 AM, Michał Kłeczek (XPro Sp. z o. o.) >>>>> <michal.klec...@xpro.biz> wrote: >>>>> >>>>> What I think Jini designers did not realize is that class loading can >>>>> be treated exactly as any other capability provided by a (possibly >>>>> remote) service. >>>>> Once you realize that - it is possible to provide a kind of a >>>>> "universal container infrastructure" where different class loading >>>>> implementations may co-exist in a single JVM. >>>> >>>> That’s precisely what ClassLoader is for. TCCL is precisely to allow >>>> “some class” to know what context to associate newly loaded classes with, >>>> so that in such an environment, any code can load classes on behalf of >>>> some other code/context. It doesn’t matter if it is TCCL or some other >>>> class management scheme such as OSGi bundles. We are talking about the >>>> same detail, just implemented in a different way. >>>> >>>>> What's more - these class loading implementations may be dynamic >>>>> themselves - ie. it is a service that provides the client with a way to >>>>> load its own (proxy) classes. >>>>> >>>>> In other words: "there not enough Jini in Jini itself”. >>>> >>>> I am not sure I understand where the short coming is at then. Maybe you >>>> can illustrate with an example where TCCL fails to allow some piece of >>>> code to load classes on behalf of another piece of code? >>>> >>>> In my desktop application environment, there is a abstract class which is >>>> used by each serviceUI to allow the desktop to know if it provides the >>>> ability to open into one of the above mentioned JComponent subclasses.. >>>> That class is preferred and provided and resolved using the codebase of >>>> the desktop client. That class loading environment is then the place >>>> where the service is finally resolved and classes created so that the >>>> proxy can be handed to the serviceUI component which ultimately only >>>> partially resolves from the services codebase. >>>> >>>> It’s this class compatibility which needs to be lightweight. >>>> >>>>> >>>>> We have _all_ the required pieces in place: >>>>> - dynamic code loading and execution (ClassLoaders), >>>>> - security model and implementation that allows restricting rights of >>>>> the downloaded code, >>>>> - and a serialization/deserialization which allows sending arbitrary >>>>> data (and yes - code too) over the wire. >>>>> >>>>> It is just the matter of glueing the pieces together. >>>> >>>> Correct, but it’s a matter of class compatibility where a client >>>> environment has to interact with a service and the serviceUI components >>>> where TCCL excels and providing the ability to create class loaders with >>>> the correct parent context, for Java based code. OSGi introduces the >>>> opportunity for some extra bells and whistles. But I don’t see that it >>>> can completely eliminate the nature of TCCL and how it was intended to be >>>> used. >>>> >>>>> >>>>> Thanks, >>>>> Michal >>>>> >>>>> >>>>> Gregg Wonderly wrote: >>>>>> <snip> >>>>>> I am not an OSGi user. I am not trying to be an OSGi opponent. What >>>>>> I am trying to say is that I consider all the commentary in those >>>>>> articles about TCCL not working to be just inexperience and argument to >>>>>> try and justify a different position or interpretation of what the real >>>>>> problem is. >>>>>> >>>>>> The real problem is that there is not one “module” concept in Java >>>>>> (another one is almost here in JDK 9/Jigsaw). No one is working >>>>>> together on this, and OSGi is solving problems in a small part of the >>>>>> world of software. It works well for embedded, static systems. I >>>>>> think OSGi misses the mark on dynamic systems because of the piecemeal >>>>>> loading and resolving of classes. I am not sure that OSGi developers >>>>>> really understand everything that Jini can do because of the choices >>>>>> made (and not made) in the design. The people who put Jini together had >>>>>> a great deal of years of experience piecing together systems which >>>>>> needed to work well with a faster degree of variability and adaptation >>>>>> to the environment then what most people seem to experience in their >>>>>> classes and work environments which are locked down by extremely >>>>>> controlled distribution strategies which end up slowing development in >>>>>> an attempt to control everything that doesn’t actually cause quality to >>>>>> suffer. >>>>>> >>>>>> Gregg >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> >> >
