[
https://issues.jboss.org/browse/ISPN-5551?page=com.atlassian.jira.plugin....
]
Sanne Grinovero commented on ISPN-5551:
---------------------------------------
Thanks for explaining Horia! Looks like in this case this should be really included then,
but it's hard to make a general rule about these things if we want to try reuse
"most" of the existing modules.
One way would be to simply use the same versions of a target WildFly version, so we build
and test with that set of versions, but that would bind Infinispan to a specific WildFly
version, while we'll probably want some fleixibility.
Looks like the better way would be to re-bundle all modules in a private slot ?!
That's not what people expect from layered products.
Also it would be unclear on were to draw the line. Looks like libraries which are used
extensively by Infinispan like JBoss Marshalling and JGroups would better be bundled as
private slot, but what about the various other integrations, like JBoss Logger or
Narayana?
The line seems to be define just on a "more likely to create trouble" base.. we
should rather be more careful in tracking versions, when for example someone upgrades
jboss-marshalling-osgi to a version which is different from the target platform. The Maven
plugin "Enforcer" has a "dependency convergence" tool - I'm not
sure if it can track also dependencies from the container - but we might want to use
something like that to verify.
Infinispan AS modules artifact should include JBoss Marshalling
---------------------------------------------------------------
Key: ISPN-5551
URL:
https://issues.jboss.org/browse/ISPN-5551
Project: Infinispan
Issue Type: Bug
Affects Versions: 7.2.2.Final
Reporter: Horia Chiorean
Assignee: Tristan Tarrant
Fix For: 8.0.0.Beta1, 7.2.4.Final, 8.0.0.Final
Infinispan 7 provides the following Maven artifact:
{code:xml}
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-as-embedded-modules</artifactId>
<type>zip</type>
</dependency>
{code}
which can be used (and is used by ModeShape) when running in a JBoss AS instance.
However, this artifact does not contain the version of JBoss Marshalling that a
particular version of Infinspan requires but rather picks up the {{main}} version which is
available in the container:
{code:xml}
<module name="org.jboss.marshalling"/>
<module name="org.jboss.marshalling.river"
services="import"/>
{code}
Because of this, when deploying Infinispan 7.2.x in Wildfly 8.2.0, Infinispan will pick
up the version of marshalling delivered by Wildfly (1.4.9.Final instead of 1.4.10.Final)
causing class cast exceptions like:
{code:java}
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
org.jboss.marshalling.Externalizer
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1012)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1256)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at
org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
[infinispan-commons.jar:7.2.0.Final]
at
org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
[infinispan-core.jar:7.2.0.Final]
at
org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
[infinispan-commons.jar:7.2.0.Final]
at
org.infinispan.marshall.core.MarshalledEntryImpl.unmarshall(MarshalledEntryImpl.java:114)
[infinispan-core.jar:7.2.0.Final]
... 162 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)