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
SampleHandler is in the org.apache.geode.internal.statistics package.
The SampleHandler interface was originally introduced to allow multiple
handlers to receive notification of a statistics sample. Before this
interface, the StatSampler used a StatArchiveWriter directly to write to
the .gfs
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
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
@Galen - If a method is added to a Java interface (e.g. CacheListener),
then classes implementing the interface must define the method, or a
compile error will occur. This is true in the case where 1) the class
implements CacheListener directly rather than extending CacheListenerAdapter
and 2)
The following unit test will pass repeatedly in both your IDE (ex: run
until failure) or in stressNewTest:
public class SystemOutRuleTest {
@Rule
public SystemOutRule systemOutRule = new SystemOutRule().enableLog();
@Test
public void passesRepeatedly() {
System.out.println("hello");
Log4J and Logback both capture a reference to System.out and/or System.err
and then use that reference thereafter. This means that any manipulation of
System.out or System.err -- using System.setOut(PrintStream) or
System.setErr(PrintStream) -- probably isn't going to play nicely with
logging in
Before we get to far off the intention of this discussion, let's refocus. The
purpose of the this discussion isn’t to find the “best” modules solution but
rather to find one that is “good enough” to allow Geode 1.x to work in a Java
11 world with a reasonable user experience. While we can run
>
> If you want to
> maintain an API as internal, then you should properly protect that API with
> the appropriate *Java* access modifiers (private, package-private and
> protected).
>
Hopefully modules will allow us to do this better, by restricting which
*classes* are visible outside the
Key indexes tell the query engine that the field is the same as the key
that was used to put into the underlying region. So let's say your field
is "ID". Creating a key index tells the query engine that a "select * from
/region theRegion where ID = 1" is the same as doing : theRegion.get(1).
In
Hi,
Have you thought about using the built-in Lucene functionality for this?
Fuzzy text search is exactly what it's made for.
On Mon, Nov 26, 2018 at 12:15 PM anjana_nair
wrote:
>
> Hi,
>
> I would like to add an index to key (keyindex) and the query executed is
> going to be like
>
>
I believe that the unable to access file: corrupted zip file indicates
some transient failure in GCP? I remember seeing it in the past, but I
don't think we ever got to the bottom of it.
To respond to your other email, yeah, I think bumping your PR to re-fire
might be the best way to
That’s really odd because that jar is baked into the build image. If it was
truly corrupt then all builds should be failing.
Hmmm
> On Nov 26, 2018, at 12:19 PM, Kirk Lund wrote:
>
> Just the first few compilation failures are listed below. Is the image
> for AcceptanceTestOpenJDK11
The unit test target has geode-core/src/main/resources in the classpath
which means that Log4J finds our log4j2.xml file and creates/registers our
custom appenders. We might want to have a unit test log4j2.xml that gets
placed earlier on the classpath but only for the unit test target. The
Thanks, Mark - Welcome Karen!
On Mon, Nov 26, 2018 at 12:17 PM Dan Smith wrote:
> Congratulations Karen! And thanks for all of your hard work, Mark!
>
> -Dan
>
> On Mon, Nov 26, 2018 at 11:56 AM Mark Bretl wrote:
>
> > Hello Geode Community,
> >
> > After two years, the Project Management
Just the first few compilation failures are listed below. Is the image
for AcceptanceTestOpenJDK11 precheckin broken in some way?
/home/geode/geode/geode-core/src/main/java/org/apache/geode/internal/InternalInstantiator.java:20:
error: cannot access Constructor
import
Congratulations Karen! And thanks for all of your hard work, Mark!
-Dan
On Mon, Nov 26, 2018 at 11:56 AM Mark Bretl wrote:
> Hello Geode Community,
>
> After two years, the Project Management Committee (PMC) agreed to
> transition the role of PMC chair from me to another PMC member. I would
>
*> Most of these are in internal packages, which means we can change the
package of these classes without breaking users.*
I don't agree with this.
Some functionality in Geode required by an application, or framework, is
only available in an "internal" package, unfortunately. This has to do
I need more time to think about this clearly (currently juggling multiple
things), but I would say this...
I don't think there should be "internal" APIs, as in o.a.g.*.internal.
There are only APIs/SPIs and implementations, period. If you want to
maintain an API as internal, then you should
Typo fix: If you need to use CleanupDUnitVMsRule along with other dunit
rules, then you will need to* use RuleChain*.
If you don't need to use CleanupDUnitVMsRule then you don't need to use
RuleChain.
On Mon, Nov 26, 2018 at 11:57 AM Kirk Lund wrote:
> Actually the only problem with this is
Actually the only problem with this is specific to bouncing of dunit VMs. I
filed "GEODE-6033: DistributedTest rules should support VM bounce" earlier
this month and I have a branch with preliminary changes that seem to be
working fine.
Aside from bouncing of dunit VMs, the dunit rules you listed
Hello Geode Community,
After two years, the Project Management Committee (PMC) agreed to
transition the role of PMC chair from me to another PMC member. I would
like to announce, at last week's Apache Board Meeting, the Board approved
the Geode PMC's recommendation of Karen Miller to the office
Hi,
I would like to add an index to key (keyindex) and the query executed is
going to be like
"constantstring%" where constant string is going to be the constant
prefix in a lile query. In this case can we just go ahead with key index or
should we use a function index ? key indexes are
Thanks for the correction Bruce!
> On Nov 26, 2018, at 10:04 AM, Bruce Schuchardt wrote:
>
> While it's common to use VM.getVM(int) to get a VM you still must use
> Host.getHost() to get a VM running an older version of Geode. Until someone
> adds a VM.getVM(version, vmNumber) we can't frown
Done!
-Dan
On Mon, Nov 26, 2018 at 11:15 AM Sean Goller wrote:
> Hi, In order to start dealing with some JIRA tickets could I get assign and
> resolve access?
> My apache username is smgoller.
>
> Thanks!
>
> -Sean.
>
On Mon, Nov 26, 2018 at 11:23 AM Udo Kohlmeyer
wrote:
> Imo, no module should export "internal". Maybe a stretch goal, but
> something we should keep in mind.
>
Yes, agreed, but outside the scope of this current discussion.
Imo, no module should export "internal". Maybe a stretch goal, but
something we should keep in mind.
On 11/26/18 10:50, Jacob Barrett wrote:
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and
Hi, In order to start dealing with some JIRA tickets could I get assign and
resolve access?
My apache username is smgoller.
Thanks!
-Sean.
If Dan's assertions are correct, and we can in fact refactor all these
packages without API changes, then I am all for giving it a shot. Worst
case we have done a little of the work we will have to do for a 2.0 api
change anyway and have to revert to the idea of an uber jar.
On Mon, Nov 19, 2018
One lingering question I have around jigsaw is the split package issue
recursive? In that I mean if a module exports "org.apache.geode.internal"
and another module exports "org.apache.geode.internal.foo" is this legal?
On Mon, Nov 19, 2018 at 5:21 PM Dan Smith wrote:
> I think we can actually
For test failures that do not have a ticket for that particular stack
trace, you should re-trigger your pre-checkin. If the test fails again,
your change probably caused it to start failing, even if it doesn't seem
related (like the unit test ordering issue we had Friday before last), and
you
The DistributedTestOpenJDK11 precheckin job for PR #2878 failed with what I
think is a Concourse error: https://github.com/apache/geode/pull/2878
I believe the expected process from me is to just poke my PR to repeat
precheckin. If that's wrong, please let me know. Thanks!
I just saw SizingFlagDUnitTest fail in a precheckin but it passes on my
branch when I run directly. I cannot find a Jira ticket for it. What's the
new process for handling these flickering tests?
See:
https://concourse.apachegeode-ci.info/builds/17745
Test failure stack:
While it's common to use VM.getVM(int) to get a VM you still must use
Host.getHost() to get a VM running an older version of Geode. Until
someone adds a VM.getVM(version, vmNumber) we can't frown upon
Host.getHost(0).getVM(startingVersion, 0).
On 11/21/18 4:09 PM, Mark Hanson wrote:
It is
Is there a preferred ordering of the above list of rules? Or is the
preferred ordering whichever passes?
On Wed, Nov 21, 2018 at 4:36 PM Mark Hanson wrote:
> It is frowned upon. VM.getVM(0) is now the accepted way to get VM 0.
>
> Thanks,
> Mark
>
>
> > On Nov 21, 2018, at 10:41 AM, Nabarun
35 matches
Mail list logo
