The "platform" - what is it, how do you use it?

[Rafał Krupiński]

Hi
What exactly is platform (config/platform files)?
I thought it was an another layer of ClassLoader, just below system classloader, common to all services, but the RioServiceDescriptor code suggests the opposite (I haven't study it thoroughly).
There is a copy of the platform for each service.

There also is a "common" flag, which I thought it would make the platform module a common singleton, but it just brings CNFEs (which may be a bug somewhere in our code).

Best regards
Rafał

[Dennis Reedy]

On Nov 8, 2013, at 813AM, Rafał Krupiński <r.kru...@gmail.com> wrote:

> Hi
> What exactly is platform (config/platform files)?
> I thought it was an another layer of ClassLoader, just below system classloader, common to all services,

As the readme.txt in the config/platform directory states:

Provides attributes for creating PlatformCapability classes and declaring what jars will be common across all service classloaders. If jars are common they are loaded by the CommonClassLoader, and are in the classpath of all child class loaders. By default Rio and River technology jars are common across all service classloaders.

This where the platform gets loaded.

System ClassLoader (rio-start, rio-resolver, jsk-platform, groovy, slf4j)
|
|
Common ClassLoader (rio-api, rio-lib, jsk-lib)
|
|
-----+---------------+
| |
Service-1 CL Service-n CL


If for some reason you need to have software loaded into the platform, making it available to all services, then add them into the platform.

I originally added this support to address some issues involved with loading JNI enabled objects. The issue was once JNI was loaded by one service it could not be loaded by another service. Pushing that into the Common ClassLoader (CCL) solved that, and it's been around since then.

I have seen similar things with Berkely DB as well. Pushing that into the CCL addresses having multiple services in the same JVM use Berkely DB. I generally think it's a bad idea to expand the platform and it should be used with care.

I'd like to eventually move to OSGi and make this all go away, but thats somewhere down the road a bit.

> but the RioServiceDescriptor code suggests the opposite (I haven't study it thoroughly).
> There is a copy of the platform for each service.

No, the RioServiceDescriptor states that multiple service objects can be placed in the same JVM, with each object maintaining a distinct codebase and policy. The RSD does load the platform, and for each platform capability that is common, it adds those jars into the CCL. The CCL is a singleton for the JVM.

>
> There also is a "common" flag, which I thought it would make the platform module a common singleton, but it just brings CNFEs (which may be a bug somewhere in our code).

The common property indicates that a PlatformCapability is to be loaded into the CCL. You can have a platform capability this is not common (not in the CCL), and declare that you want to be provisioned on a machine that has that capability available, and obtain matched platform capabilities through:

ServiceBeanContext.getComputeResourceManager().getMatchedPlatformCapabilities()

HTH

Dennis

[Rafał Krupiński]

PlatformCapabilityConfig[] caps =
platformLoader.getDefaultPlatform(rioHome);
for (PlatformCapabilityConfig cap : caps) {
URL[] urls = cap.getClasspathURLs();
urlList.addAll(Arrays.asList(urls));
}

...

caps = platformLoader.parsePlatform(platformDir);
for (PlatformCapabilityConfig cap : caps) {
if (cap.getCommon()) {
URL[] urls = cap.getClasspathURLs();
urlList.addAll(Arrays.asList(urls));
}
}

Does it mean that platform descriptors whth common=false are ignored?

[Dennis Reedy]

On Nov 8, 2013, at 1032AM, Rafał Krupiński <r.kru...@gmail.com> wrote:

> On 08.11.2013 15:41, Dennis Reedy wrote:
>>
>> On Nov 8, 2013, at 813AM, Rafał Krupiński <r.kru...@gmail.com> wrote:
>>
>>> There also is a "common" flag, which I thought it would make the platform module a common singleton, but it just brings CNFEs (which may be a bug somewhere in our code).
>>
>> The common property indicates that a PlatformCapability is to be loaded into the CCL. You can have a platform capability this is not common (not in the CCL), and declare that you want to be provisioned on a machine that has that capability available, and obtain matched platform capabilities through:
>>
>> ServiceBeanContext.getComputeResourceManager().getMatchedPlatformCapabilities()
>
>
> PlatformCapabilityConfig[] caps = platformLoader.getDefaultPlatform(rioHome);
> for (PlatformCapabilityConfig cap : caps) {
> URL[] urls = cap.getClasspathURLs();
> urlList.addAll(Arrays.asList(urls));
> }

The default platform that includes Rio and River...

>
> ...
>
> caps = platformLoader.parsePlatform(platformDir);
> for (PlatformCapabilityConfig cap : caps) {
> if (cap.getCommon()) {
> URL[] urls = cap.getClasspathURLs();
> urlList.addAll(Arrays.asList(urls));
> }
> }
>
> Does it mean that platform descriptors whth common=false are ignored?

They are ignored by the RSD when populating the CCL, but are later loaded as platform capabilities, and included as capabilities when the cybernode registers with provision monitors.

Dennis