Geode-core provides suitable public alternatives, I'm sure Spring Data
Geode would be able to adapt and use the certified public API's.
--Udo
On 11/26/18 15:48, Dan Smith wrote:
Our wire format and disk format generally does *not* depend on class names
or packages. Internal classes implement DataSerializableFixedID and are
sent using a fixed integer ID. So we should be able to move these classes
around without affecting the on the wire format.
I don't think we should shy away from changing *internal* packages. Worst
case is that we break someone's code and encourage them to ask for a public
API, which is a conversation we should be having anyway.
But to allay some concerns I took a look at what internal classes spring
data geode is using (on the master branch). I think all of these are in
geode-core. So if we leave the packages in geode-core alone, SDG will be
fine.
import org.apache.geode.cache.query.internal.ResultsBag;
import org.apache.geode.distributed.internal.DistributionConfig;
import org.apache.geode.distributed.internal.InternalDistributedSystem;
import org.apache.geode.distributed.internal.InternalLocator;
import org.apache.geode.internal.DistributionLocator;
import org.apache.geode.internal.GemFireVersion;
import org.apache.geode.internal.InternalDataSerializer;
import org.apache.geode.internal.cache.GemFireCacheImpl;
import org.apache.geode.internal.cache.LocalRegion;
import org.apache.geode.internal.cache.PartitionedRegion;
import org.apache.geode.internal.cache.PoolManagerImpl;
import org.apache.geode.internal.cache.UserSpecifiedRegionAttributes;
import org.apache.geode.internal.concurrent.ConcurrentHashSet;
import org.apache.geode.internal.datasource.ConfigProperty;
import org.apache.geode.internal.datasource.GemFireBasicDataSource;
import org.apache.geode.internal.jndi.JNDIInvoker;
import org.apache.geode.internal.security.shiro.GeodePermissionResolver;
import org.apache.geode.management.internal.cli.domain.RegionInformation;
import
org.apache.geode.management.internal.cli.functions.GetRegionsFunction;
import org.apache.geode.management.internal.security.ResourcePermissions;
import org.apache.geode.pdx.internal.PdxInstanceEnum;
import org.apache.geode.pdx.internal.PdxInstanceFactoryImpl;
On Mon, Nov 26, 2018 at 3:24 PM Kirk Lund <kl...@pivotal.io> wrote:
One problem about moving around internal classes is that Geode uses
(proprietary and Java-based) serialization on the wire instead of defining
a wire-format that isn't dependent on class names/structures/packages.
I for one would love to move to a real wire-format with a well-defined
protocol but that's probably a separate project in its own right.
Are you really convinced that we could move internal classes around without
breaking rolling upgrades, client-server backwards compatibility and
diskstore contents?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith <dsm...@pivotal.io> wrote:
I think we can actually fix most of these issues without geode-2.0. Most
of
these are in internal packages, which means we can change the package of
these classes without breaking users. The only concerning one is
org.apache.geode.cache.util, which is a public package. However, the
AutoBalancer is actually still marked @Experimental, so we could
technically move that as well. Or maybe deprecate the old one and it's
associated jar, and create a new jar with a reasonable package. JDK11
users
could just avoid the old jar.
I have been wondering for a while if we should just fold geode-cq and
geode-wan back into geode-core. These are not really properly separated
out, they are very tangled with core. The above package overlap kinda
shows
that as well. But maybe going through the effort of renaming the packages
to make them java 11 modules would help improve the code anyway!
-Dan
On Mon, Nov 19, 2018 at 5:03 PM Owen Nichols <onich...@pivotal.io>
wrote:
To package Geode as Java 11 Jigsaw module(s), a major hurdle is the
requirement that packages cannot be split across modules.
If we simply map existing Geode jars to Modules, we have about 10 split
packages (see table below). Any restructuring would potentially have
to
wait until Geode 2.0.
A workaround would be to map existing packages into a small number of
new
modules (e.g. geode-api and geode-internal). Existing jars would
remain
as-is. Users making the transition to Java 11 /w Jigsaw already need
to
switch from CLASSPATH to MODULEPATH so the inconvenience of a
different
naming scheme for Geode-as-modules might be acceptable (however, once
module naming and organization is established, we may be stuck with it
for
a long time).
Thoughts?
Is it even possible to rearrange all classes in each package below
into a
single jar? Is doing so desirable enough to defer Java 11 support
until
a
yet-unplanned Geode 2.0, or perhaps to drive such a release?
Or, is it satisfactory to fatten Geode releases to include one set of
jars
for CLASSPATH use, plus a different set of jars for MODULEPATH use?
Package
Jar
org.apache.geode.cache.client.internal
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.cache.client.internal.locator.wan
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.cache.query.internal.cq
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
org.apache.geode.cache.util
geode-core-1.8.0.jar
geode-rebalancer-1.8.0.jar
org.apache.geode.internal
geode-connectors-1.8.0.jar
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
geode-lucene-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.tier.sockets.command
geode-core-1.8.0.jar
geode-cq-1.8.0.jar
org.apache.geode.internal.cache.wan
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.wan.parallel
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.cache.wan.serial
geode-core-1.8.0.jar
geode-wan-1.8.0.jar
org.apache.geode.internal.protocol.protobuf.v1
geode-protobuf-1.8.0.jar
geode-protobuf-messages-1.8.0.jar
