Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw
by Rory O'Donnell
Hi Galder,
Early-access builds of JDK 9 with Project Jigsaw are available for
download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.
The EA builds contain the latest prototype implementation of JSR 376
<http://openjdk.java.net/projects/jigsaw/spec>, the Java Platform Module
System,
as well as that of the JDK-specific APIs and tools described in JEP 261
<http://openjdk.java.net/jeps/261>.
If you'd like to try out the EA builds, by far the most helpful things
you can do are:
*
Try to run existing applications, without change, on these builds to
see whether the module system, or the modularization of the
platform, breaks your code or identifies code that depends upon
JDK-internal APIs or other unspecified aspects of the platform.
*
Experiment with the module system itself, perhaps by following the
quick start guide
<http://openjdk.java.net/projects/jigsaw/quick-start>, and start
thinking about how to migrate existing libraries and application
components to modules. We hope to publish some specific migration
tips shortly.
Please send usage questions and experience reports to the jigsaw-dev
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> list.
Specific suggestions about the design of the module system should be
sent to the JSR 376 Expert Group's comments list
<mailto:jpms-spec-comments@openjdk.java.net>.
For more information please seen Mark Reinhold's mail [1]
Rgds,Rory
[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 9 months
Hidden failures in the testsuite
by Sanne Grinovero
Hi all,
I just updated my local master fork and started the testsuite, as I
sometimes do.
It's great to see that the build was successful, and no tests
*appeared* to have failed.
But! lazily scrolling up in the console, I see lots of exceptions
which don't look like intentional (I'm aware that some tests
intentionally create error conditions). Also some tests are extremely
verbose, which might be the reason for nobody noticing these.
Some examples:
- org.infinispan.it.compatibility.EmbeddedRestHotRodTest seems to log
TRACE to the console (and probably the whole module)
- CDI tests such as org.infinispan.cdi.InfinispanExtensionRemote seem
to fail in great number because of some ClassNotFoundException(s)
and/or ResourceLoadingException(s)
- OSGi integration tests seem to be all broken by some invalid
integration with Aries / Geronimo
- OSGi integration tests dump a lot of unnecessary information to the
build console
- the Infinispan Query tests log lots of WARN too, around missing
configuration properties and in some cases concerning exceptions; I'm
pretty sure that I had resolved those in the past, seems some
refactorings were done w/o considering the log outputs.
Please don't ignore the output; if it's too verbose to watch, that
needs to be resolved too.
I also monitor the "expected execution time" of some modules I'm
interested in, that's been useful in some cases to figure out that
there was some regression.
One big question: why is it that so many tests "appear to be good" but
are actually broken? I would like to understand that.
Thanks,
Sanne
8 years, 9 months
Metrics and interceptors
by Tristan Tarrant
A recent issue with some refactoring of the PassivationInterceptor
affecting code using it directly (EAP's Infinispan subsystem), has got
me thinking about the fact that we have somewhat treated interceptors as
a form of API since we do not provide another way of retrieving metrics
collected by the interceptors, aside from the basic cache stats.
With the plan to eventually drop interceptors, these kind of metrics
should be exposed through a more stable API (aside from maintaining
stability of the MBean side of things).
The org.infinispan.stats.Stats interface already partially covers that
for basic stats (see org.infinispan.cache.AdvancedCache.getStats()), and
I think it should be extended or at least complemented to do this.
WDYT ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
8 years, 9 months
HotRod C++ client build
by Dan Berindei
Hi Tristan
I installed cmake, valgrind, and swig on the RHEL CI agents, and the
C++ client build seems to work.
Cheers
Dan
8 years, 9 months
Redis infinispan cache store
by Simon Paulger
Hi,
I'm interested in developing inifinispan integration with Redis for use in
JBoss. Before working on JBoss, I first need to add the capability to
Infinispan itself.
Is this an enhancement that the infinispan community would be interested in?
Regards,
Simon
8 years, 9 months
Blue-Green deployment scenario
by Christian Beikov
Hello,
I have been reading the rolling upgrade chapter[1] from the
documentation and I have some questions.
1. The documentation states that in the target cluster, every cache
that should be migrated, should use a CLI cache loader pointing to
the source cluster. I suppose that this can only be configured via
XML but not via the CLI or JMX? That would be bad because after a
node restart the cache loader would be enabled again.
2. How would the JMX URL look like if I wanted to connect to a secured
Wildfly over HTTP? I was thinking of
jmx:http-remoting-jmx://USER:PASSWORD@HOST:PORT/CACHEMANAGER/CACHE
3. What do I need to do to rollback to the source cluster after
switching a few nodes to the target cluster?
Thanks in advance!
Regards,
Christian
[1]
http://infinispan.org/docs/7.2.x/user_guide/user_guide.html#_rolling_upgr...
8 years, 9 months
