You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org> on 2010/05/27 01:33:38 UTC
[jira] Created: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Remove Java client dependency on commons-collection.jar
-------------------------------------------------------
Key: QPID-2629
URL: https://issues.apache.org/jira/browse/QPID-2629
Project: Qpid
Issue Type: Improvement
Components: C++ Client
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
The JMS client has only a single dependency on the commons-collection.jar.
It is using the RefereneMap in the message delegates to store the destination cache.
It would be nice if we could use an alternative instead of having yet another dependency.
For a client application it's really a big plus point to have as less dependencies as possible
(Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
But for runtime we could definitely get rid of it to keep the size small.
Possible strategies.
1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
We currently use the ref map with hard refs for keys and soft refs for values.
2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-2629:
-----------------------------------
Component/s: Java Client
(was: C++ Client)
Changed the component to "java client" - Thx Emmanuel for spotting it.
I would assume it's probably ok to rename the package name from "commons" to "qpid".
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
> Attachments: QPID-2629.patch
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-2629:
-----------------------------------
Fix Version/s: 0.7
Priority: Minor (was: Major)
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872032#action_12872032 ]
Robbie Gemmell commented on QPID-2629:
--------------------------------------
I would copy (with package change as noted above) the files across from a release tag in the Commons section of the repo to maintain commit/version tracking, rather than just applying the patch.
Not really an issue, but I assume the build.deps addition for slf4j-jdk14-1.4.0.jar actually relates to some other work rather than this JIRA?
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
> Attachments: QPID-2629.patch
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-2629:
-----------------------------------
Attachment: QPID-2629.patch
Attached is patch where I have included the required source files into the client module.
If there are no disagreements, I intend to check in the patch by friday.
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
> Attachments: QPID-2629.patch
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Resolved: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu resolved QPID-2629.
------------------------------------
Resolution: Fixed
Patch committed.
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
> Attachments: QPID-2629.patch
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2629) Remove Java client dependency on
commons-collection.jar
Posted by "Emmanuel Bourg (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872015#action_12872015 ]
Emmanuel Bourg commented on QPID-2629:
--------------------------------------
That's fine to copy the classes from Commons Collections, but you may want to change the package to avoid any conflict if Commons Collections is on the classpath.
Also this issue is for the Java client instead of the C++ client.
> Remove Java client dependency on commons-collection.jar
> -------------------------------------------------------
>
> Key: QPID-2629
> URL: https://issues.apache.org/jira/browse/QPID-2629
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Priority: Minor
> Fix For: 0.7
>
> Attachments: QPID-2629.patch
>
>
> The JMS client has only a single dependency on the commons-collection.jar.
> It is using the RefereneMap in the message delegates to store the destination cache.
> It would be nice if we could use an alternative instead of having yet another dependency.
> For a client application it's really a big plus point to have as less dependencies as possible
> (Pls note that for the broker module, commons-collection is a transitive dependency, so we can't just remove it from our lib folder).
> But that is fine as it's only a compile time dependency should anybody wish to build the client from source.
> But for runtime we could definitely get rid of it to keep the size small.
> Possible strategies.
> 1. Replace the ReferenceMap with a suitable implementation. I don't think WeakHashMap as suggested on a thread is the right solution either.
> We currently use the ref map with hard refs for keys and soft refs for values.
> 2. We could just include the necessary files (just 4 actually) in the clients source dir. - This is perfectly legal as per the ASF license this is allowed.
> This also seems like a very good short term solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org