Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
From: =?utf-8?Q?Michael_Andr=C3=A9_Pearce?= <michael.andre.pearce@me.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (1.0)
Date: Wed, 06 Dec 2017 16:44:53 +0000
Subject: Re: Artemis JMS Client All JAR
Message-id: <A21C5714-B763-41DA-8691-E8D0DF26E423@me.com>
References: <1512571188897-0.post@n4.nabble.com>
In-reply-to: <1512571188897-0.post@n4.nabble.com>
To: users@activemq.apache.org
archived-at: Wed, 06 Dec 2017 16:45:09 -0000

Hi Benjamin=20

I can understand a little as classloader if the class would be different in t=
wo different jars.=20

but if these are spec jars with the same class=E2=80=99s then it shouldn=E2=80=
=99t cause an issue as it shouldn=E2=80=99t matter which class gets loaded f=
rom which jar, because they should be the same.

If anything having all the implantation jars in the single jar may cause mor=
e issues if you have other vendors as Libs like guava etc are bundled in.=20=


We did do some shading to try avoid some of that, but the original intent of=
 the single jar was to package everything needed, for simple deployment case=
s where we don=E2=80=99t expect competing jars, not for complex dependencies=
 clashing handling.

from the sounds of it with having multiple other vendors libs also, if you h=
ave that really should be handling the dependencies manually without the all=
 jar , manually, via maven or other tooling.

I=E2=80=99m not saying it=E2=80=99s not causing you an issue but it be good i=
f you could expand with an exception this is causing. And the jars you have o=
n the cp.=20

I=E2=80=99m not 100% pulling libs out is the answer here as it sounds as you=
 have more a complex dependency deployment which as stated wasn=E2=80=99t th=
e original intent of the single jar client.=20


Cheers
Mike


Sent from my iPhone

> On 6 Dec 2017, at 14:39, beegee <benjamin.gentner@fntsoftware.com> wrote:
>=20
> Hi,
>=20
> the Artemis client all JAR contains all dependencies in a shadowed package=
,
> except of two dependencies:
> - JMS Spec 2.0
> - javax.json Spec (?)
>=20
> I would suggest to not include the Spec JARS in the client JAR as it could=

> cause trouble if those JARS are already included in the classpath. Also, i=
f
> an application supports several different JMS providers and has included
> client all JARS of those providers, then it's better to have the JMS spec
> JAR included just once.
>=20
> In our software product we cannot use Maven or some sort of library
> dependency management tool as of now, so we need to add those JARS manuall=
y
> to the classpath. The client all JAR helps a lot, but as we need to suppor=
t
> different JMS providers it would be better to have the JMS spec separatly.=
=20
>=20
> What do you think?
>=20
> Kind regards,
> Benjamin Gentner
>=20
>=20
>=20
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.ht=
ml