AbstractMethodError for abstract Widget class - since migration to byte-buddy
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 50/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- mobile-dev, testing-qa
Hướng nghiên cứu
Bắt đầu với ví dụ Widget trừu tượng trong Page-objects.md và theo dõi cách OverrideWidget, WidgetInterceptor và field.getType() chọn lớp widget. Tái hiện các trường hợp Android và iOS từ issue, sau đó xác minh rằng các lời gọi đến các triển khai nền tảng không còn gây ra AbstractMethodError khi sử dụng Byte Buddy.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is there an existing issue for this?
- I have searched the existing issues
Appium Version
2.0.1
Appium Host Type
Command Line
Are you using Appium components not maintained by the Appium team?
No response
Is this issue reproducible using the latest components?
- I confirm the issue is still reproducible with the latest component versions
Current Behavior
Currently my repo(Android & iOS combined) is using java-client version: 8.3.0
I did not update my version since I got issues with the new byte buddy library. I tried to update to the latest java client version(10.0.0) and still, I get the same issue.
The issue:
I am working according to this docs: PO - abstract Widget class.
When I run my tests using a java client with byte buddy I get AbstractMethodError.
Expected Behavior
To work as it did with cglib.
Appium Log
No response
Environment Details
- Debug details (
appium --show-debug-info): - Last component version(s) which did not exhibit the problem: appium 2.0.1, java-client 10.0.0
- Platform and version of device under test: android
- Real device or emulator/simulator: emulator
Minimal Reproducible Example
Reproduction:
Consider the following setup in your PO:
public class MyPO {
@OverrideWidget(androidUIAutomator = CustomWidget.AndroidCustomWidget.class, iOSXCUITAutomation = CustomWidget.IOSCustomWidget.class)
private CustomWidget myCustomWidget;
}
Your Widget class:
public abstract class CustomWidget extends Widget {
public abstract void abstractTest();
public static class AndroidCustomWidget extends CustomWidget {
@Override
public void abstractTest() {
//android implementation
}
}
public static class IOSCustomWidget extends CustomWidget {
@Override
public void abstractTest() {
//iOS implementation
}
}
}
Then in the test class just call:
myPO.getCustomWidget().abstractTest();
You'll get AbstractMethodError since byte buddy tries to call the original abstract method signature
Further Information
I also managed to find the issue and fix it locally. I will detail my steps here.
First, acording to this Callable implements no-abstract methods by default ByteBuddy's proxies(which are essentially just subclasses) subclass the Widget class and passing calls to the Interceptor(in our case Appium's WidgetInterceptor) for non-abstract methods. The issue is that it subclasses the original CustomWidget and thus it cannot call myWidget.abstractTest() and throwing AbstractMethodError. Instead, it needs to subclass AndroidCustomWidget or IOSCustomWidget according to the platform we are currently using. Since the abstractTest method is non-abstract in AndroidCustomWidget and IOSCustomWidget, byte buddy will override and intercept those methods as well - resulting in the desired behavior.
Fix example:
I was just testing and found out that the java client passes widgetType = (Class<? extends Widget>) field.getType(); which in our case is the abstract class CustomWidget, I added a check for android OverrideWidget and it worked perfectly(since the widgetType is now of type AndroidCustomWidget). In cglib it used to work but I guess byte buddy implements things differently so the the code needs to take into consideration the current platform and the Widget class that overrides it.
- Ngôn ngữ chính
- Java
- Star
- 1.3k
- Fork
- 752
- Merge trung bình
- 5 ngày 14 giờ
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của appium/java-client
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
appium/java-client#2426 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
appium/java-client#2368 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 30/100
appium/java-client#2341 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
appium/java-client#2323 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
java-client 启动报错Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
appium/java-client#2288 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của appium/java-client
Issue tương tự
-
and-bugs and-ui gpx-track
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 2 ngày
-
TerminalRow.mSpaceUsed (short) overflows on terminals wider than 1023 columns, crashing setCharĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
termux/termux-app#5340 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
OpenAICompatibleToolDescriptorSchemaGenerator drops requiredProperties of nested object parametersĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
apache/rocketmq-dashboard#5110 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
frontend
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
No-Country-simulation/S08-26-equipo04#210 ·
Maintainer thường phản hồi trong vòng 1 ngày