...
At runtime the Ignite user installs all required bundles (including ignite-core, any optional Ignite bundles as well as the application bundles) using either the standard mechanisms defined by the OSGi spec, or relying on the container's implementation-specific capabilities. For example, Apache Karaf (an OSGi implementation) offers a packaging/deloyment concept called "Feature" which roughly speaking is a list of bundles to automatically deploy when the OSGi Framework starts.
[raul.kripalani]: I've already modified the POMs to generate and package the MANIFEST.MF with the appropriate OSGi headers. The code is pushed to the ignite-1527 branch. Highlight
...
It's responsibility of the implementation to ensure that the encoded representation is sufficient to unambiguously identify the correct bundle during deserialization.
[raul.kripalani]: The naming is confusing. We are actually not transmitting classloaders. In fact, we cannot do so. What we'd like to do is transmit deserialisation "hints", that are used in whatever form the marshaller deems appropriate. So if anything, I would call this class a DeserialisationHintsCodec with methods: generateHints and computeClassLoaderFromHints. Highlight
[dmitriy setrakyan]: I am not sure I see the reason for removing the word classLoader on serialization part and keeping it on deserialization. I also think that the method names should be symmetric. With that in mind, "encodeClassLoader" and "decodeClassLoader" may not be the best names, but they are consistent with each other and symmetric. My vote would be to keep the naming.
The ClassLoaderCodec
should be called for every Object during serialization and deserialization and should be part of the IgniteConfiguraiton
:
Code Block |
---|
public interface ClassLoaderCodec { @Nullable public Object encodeClassLoader(Class<?> cls, ClassLoader clsLdr) throws IgniteException; public ClassLoader decodeClassLoader(String fqn, @Nullable Object encodedClsLdr) throws IgniteException; } |
[raul.kripalani]: See my comment above. Highlight
...
However, for the applications that can enforce one-to-one mapping of packages to bundles, a simplified (optimistic) approach can be used instead. With this approach, no encoding of the class loader is required (encodeClassLoader()
returns null
), and only the FQN is used for decoding of the class loader.highlight
[raul.kripalani]: I don't like transmitting bundle symbolic names over the wire, as it couples the serialising party with the deserialising party, forcing both to contain the class inside the same bundle. As I said in the mailing list, making this assumption would be a short-sighted strategy, as users may be sharing caches across applications across multiple containers, where classes live in different bundles in different containers.
I also don't think it's necessary. We just need the package name + package version. An OSGi container cannot expose the same package under the same version number twice, so the tuple (package name, package version) is enough to unambiguously locate the Bundle that exports our class.
Now, what we need to do is determine HOW we locate the Bundle. I have two ideas in mind:
With either of these approaches, I think we don't need pessimistic and/or optimistic strategies. Just a single strategy would be enough.
Here's how the pessimistic codec implementation might look like (in pseudo-code):
...