[ 
https://issues.apache.org/jira/browse/ARTEMIS-2557?focusedWorklogId=352579&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-352579
 ]

ASF GitHub Bot logged work on ARTEMIS-2557:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 03/Dec/19 12:04
            Start Date: 03/Dec/19 12:04
    Worklog Time Spent: 10m 
      Work Description: gemmellr commented on issue #2898: ARTEMIS-2557 doc 
caveat for OpenWire JMS 1.1 dep
URL: https://github.com/apache/activemq-artemis/pull/2898#issuecomment-561138132
 
 
   Personally I dont think this should really be documented, and would change 
the module config out such that the issue doesnt arise.
   
   The module has a transitive dep on the JMS 1.1 API via activemq-client, and 
has a transitive dep on the JMS 2.0 API via artemis-jms-client, and then 
further declares a non-transitive dep on JMS 1.1 itself. Various options likely 
exist to resolve the issue this doc update covers, stopping the 1.1 dep being 
passed to dependent componenents, while keeping things working for the 
module...e.g, excluding the transitive 1.1 dep from activemq-client, marking 
the fixed 1.1 dep as provided scope or optional, removing it entirely, 
declaring a fixed dep on JMS 2.0 spec, different combinations of these etc.
   
   I dont think using the JMS 2 API jar [,perhaps only at runtime,] for a 
server-side component of an otherwise JMS2-supporting broker really implies 
anything much about the spec level supported for clients, particularly as no 
client yet exists to follow through on any confusion that arises. Since the JMS 
2.0 API is still in the dep list here, if there is any scope for confusion it 
largely exists either way. Anyone that tries using JMS 2 APIs with a client 
that doesnt implement them will quickly find out it doesnt work, with it fairly 
simple to figure out why from the resulting errors. Anyone that really does 
want a 1.1 API + client used in something declaring a dep on 
artemis-openwire-protocol should already have their own dependency on them, in 
which case nothing would change by preventing the dep being passed on to them 
by artemis-openwire-protocol.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 352579)
    Time Spent: 2h 10m  (was: 2h)

> Document potential JMS spec dependency issue for embedded use-cases
> -------------------------------------------------------------------
>
>                 Key: ARTEMIS-2557
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2557
>             Project: ActiveMQ Artemis
>          Issue Type: Task
>          Components: Broker, OpenWire
>    Affects Versions: 2.10.1
>            Reporter: SL
>            Assignee: Justin Bertram
>            Priority: Minor
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> artemis-openwire-protocol has a dependency on geronimo-jms-1.1_spec
> {code:xml}
>        <dependency>
>          <groupId>org.apache.geronimo.specs</groupId>
>          <artifactId>geronimo-jms_1.1_spec</artifactId>
>          <version>1.1.1</version>
>       </dependency>
> {code}
> However other components such as artemis-jms-server have a dependency on 
> geronimo-jms_2.0_spec which carry a superset of the same interfaces, but with 
> subtle differences (such as the JMSContext in ConnectionFactory)
> If your have both components in a dependency hierarchy you may end up with a 
> classpath including both jar which can lead to a behavior that is
> a) inconsistent, since one or the other jar may have been loaded first to 
> resolve a given interface
> b) funny, if a component compiled against an interface from 2.0 try to use 
> one from 1.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to