[
https://issues.apache.org/jira/browse/CASSANDRA-18877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-18877:
-----------------------------------
Attachment: signature.asc
I genuinely think that even if we just wired it to build/test/lib/jars nobody
would notice that. Even they did it would not matter.
How many people are using byteman scripts in CCM? Three? It has to be called
from the code from Python, I do not think there is a relevant CCM command to do
that on the command line.
So ... yeah. We are trying to keep it like it was for a user group which does
not exist.
That being said the PR for CCM is still looking into the old directory too.
Also, I consider CCM to be testing / evaluation tool. It is not like CCM would
be used for running production clusters. Under what circumstances a user would
try to inject a byteman script to a running node if it was not for testing
purposes?
If we are fair, I would say that the current way of loading it is wrong too. A
user should be able to point it to whatever dir to find these byteman
libraries. I do not get why it ia pointing to a build dir of Cassandra in the
first place. So we just change it from the wrong locatio to one which is
equally bad.
Sent from ProtonMail mobile
\
> remove bytebuddy / byteman from production classpath and remove compress-lzf
> dependency from build deps
> -------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18877
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18877
> Project: Cassandra
> Issue Type: Task
> Components: Build
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was digging in the project deps and if you compare all libs in "libs" dir
> and all libs in "build/lib/jars", there are indeed some differences which are
> OK however in build/lib/jars there are also libraries for byteman and
> byte-buddy. This is clearly wrong as these dependecies should not be
> accessible from the production code, only from tests.
> The reason they are accessible in prod code is that there is the class
> TestRateLimiter (1). I do not have a clue why that class is in the prod code
> in the first place. The only place it is referenced in is here (2) but that
> byteman script is not loaded anywhere in tests. I was also checking Python
> dtests.
> I think this is some leftover or something like "I will keep it here when I
> need it", but as nobody seems to do, I strongly advocate for removing it and
> making bytebuddy and byteman only test scoped dependencies as it should be.
> A reader who pays attention notices that these dependencies are of provided
> scope which is a trick to have it compilable but not among the libraries in
> the production runtime and it does not do any harm as it is never invoked
> from the production code (if it was, it would fail on missing imports)
> neverthless this is still an issue which should be addressed. We were doing
> something similar with assertj dependency recently.
> The second issue is that there is a dependency on compress-lzf in build
> dependencies. This is not necessary either as that library was removed from
> the repository in (3) but it still somehow leaked to the build process again.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/TestRateLimiter.java
> (2)
> https://github.com/apache/cassandra/blob/trunk/test/resources/byteman/mutation_limiter.btm
> (3)
> https://github.com/apache/cassandra/commit/fc92db2b9b56c143516026ba29cecdec37e286bb
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
