Community
Participate
Working Groups
Created attachment 288356 [details] Tomcat 8.5 Server launch and Spring 5 (no spring boot) Hello, When debugging code for Maven based project, I've got a lot of errors - especially since latest version of Eclipse (2022-03) - of Eclipse debug failing to: - Resolve breadcrumb - Resolve local variables - Evaluate conditional breakpoint I do think this is a blocker given that it render the Eclipse debugger pretty much useless. I think all comes from Eclipse Debug UI failing to get a so called (and annoying) *Java project context* (1): the screenshot below provides 4 examples of problem with the debug mode, from which I fail to understand why it fails while it was not: | Screenshot | Description | | ---- | ---- | | eclipse_no_debug_context_01 | Tomcat 8.5 Server launch and Spring 5 (no spring boot) | | eclipse_no_debug_context_02 | JUnit 3 unit test with Spring 3 (sic) | | eclipse_no_debug_context_03 | JUnit 4 unit test for issue HHH-15142; we can see the breadcumb and local variables being lost | | eclipse_no_debug_context_04 | same project as eclipse_no_debug_context_03.png; unlike before, the local variables are resolved; | In all these screenshot, we can see the breadcumb not displaying the enclosing type/file: this is strange because the editor title is properly set, and the window title also references the JAR from which the source file comes (but I don't know if it should read junit-4.13.2-sources.jar and not junit-4.13.2.jar. The first two screenshot were taken from a work related project which I can't attach here. The last two screenshots were taken using the sample project for Hibernate issue HHH-15142: - Clone the GIT repository https://github.com/schauder/issue-HHH-15142 or https://github.com/glhez/issue-HHH-15142 in case it get deleted. - In Eclipse, go to File > Import > Import Maven project - Browse to where GIT repository was cloned - Go to type org.hibernate.query.spi.QueryParameterBindingValidator - Put a breakpoint at line 53 where the "Parameter value [%s] did not match expected type [%s (%s)]" should be. - Go to JPAUnitTestCase - Run it as JUnit 4 test (the default F11 may try to use JUnit Jupiter and find nothing) - Wait for Eclipse to switch/ask to use Debug perspective - Navigate the stacktrace The table below shows when it fails: some JAR are from Maven, while other are from Eclipse bundle. | breadcumb | local variables | source | Type / Method / Line | | --------- | --------------- | -------------- | ------------------------------------------------------------------------------------------------------------------- | | Ok | Ok | JAR: Hibernate | `QueryParameterBindingValidator.validate(Type, Object, TemporalType) line: 53` | | Ok | Ok | JAR: Hibernate | `QueryParameterBindingValidator.validate(Type, Object) line: 27` | | Ok | Ok | JAR: Hibernate | `QueryParameterBindingImpl<T>.validate(T) line: 90` | | Ok | Ok | JAR: Hibernate | `QueryParameterBindingImpl<T>.setBindValue(T) line: 55` | | Ok | Ok | JAR: Hibernate | `QueryImpl<R>(AbstractProducedQuery<R>).setParameter(String, Object) line: 501` | | Ok | Ok | JAR: Hibernate | `QueryImpl<R>(AbstractProducedQuery<R>).setParameter(String, Object) line: 122` | | Ok | Ok | JAR: Hibernate | `CriteriaCompiler$1$1.bind(TypedQuery) line: 141` | | Ok | Ok | JAR: Hibernate | `CriteriaQueryImpl$1.buildCompiledQuery(SharedSessionContractImplementor, InterpretedParameterMetadata) line: 364` | | Ok | Ok | JAR: Hibernate | `CriteriaCompiler.compile(CompilableCriteria) line: 171` | | Ok | Ok | JAR: Hibernate | `SessionImpl(AbstractSharedSessionContract).createQuery(CriteriaQuery<T>) line: 774` | | Ok | Ok | JAR: Hibernate | `SessionImpl(AbstractSessionImpl).createQuery(CriteriaQuery) line: 23` | | Ok | Ok | Project | `JPAUnitTestCase.hhh123Test() line: 65` | | Ok | Ok | JDK | `NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]` | | Ok | Ok | JDK | `NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62` | | Ok | Ok | JDK | `DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43` | | Ok | Ok | JDK | `Method.invoke(Object, Object...) line: 498` | | Fail | Fail | JAR: JUnit | `FrameworkMethod$1.runReflectiveCall() line: 59` | | Fail | (none) | JAR: JUnit | `FrameworkMethod$1(ReflectiveCallable).run() line: 12` | | Fail | Ok | JAR: JUnit | `FrameworkMethod.invokeExplosively(Object, Object...) line: 56` | | Fail | (none) | JAR: JUnit | `InvokeMethod.evaluate() line: 17` | | Fail | (none) | JAR: JUnit | `RunBefores.evaluate() line: 26` | | Fail | Ok | JAR: JUnit | `RunAfters.evaluate() line: 27` | | Fail | Fail | JAR: JUnit | `ParentRunner$3.evaluate() line: 306` | | Fail | Fail | JAR: JUnit | `BlockJUnit4ClassRunner$1.evaluate() line: 100` | | Fail | Ok | JAR: JUnit | `JUnit4(ParentRunner<T>).runLeaf(Statement, Description, RunNotifier) line: 366` | | Fail | Ok | JAR: JUnit | `JUnit4(BlockJUnit4ClassRunner).runChild(FrameworkMethod, RunNotifier) line: 103` | | Fail | Ok | JAR: JUnit | `JUnit4(BlockJUnit4ClassRunner).runChild(Object, RunNotifier) line: 63` | | Fail | Fail | JAR: JUnit | `ParentRunner$4.run() line: 331` | | Fail | Ok | JAR: JUnit | `ParentRunner$1.schedule(Runnable) line: 79` | | Fail | Ok | JAR: JUnit | `JUnit4(ParentRunner<T>).runChildren(RunNotifier) line: 329` | | Fail | Ok | JAR: JUnit | `ParentRunner<T>.access$100(ParentRunner, RunNotifier) line: 66` | | Fail | Fail | JAR: JUnit | `ParentRunner$2.evaluate() line: 293` | | Fail | Fail | JAR: JUnit | `ParentRunner$3.evaluate() line: 306` | | Fail | Ok | JAR: JUnit | `JUnit4(ParentRunner<T>).run(RunNotifier) line: 413` | | No source | No source | Eclipse Bundle | `JUnit4TestReference.run(TestExecution) line: 93` | | No source | No source | Eclipse Bundle | `TestExecution.run(ITestReference[]) line: 40` | | No source | No source | Eclipse Bundle | `RemoteTestRunner.runTests(String[], String, TestExecution) line: 529` | | No source | No source | Eclipse Bundle | `RemoteTestRunner.runTests(TestExecution) line: 756` | | No source | No source | Eclipse Bundle | `RemoteTestRunner.run() line: 452` | | No source | No source | Eclipse Bundle | `RemoteTestRunner.main(String[]) line: 210` | The *Source lookup info* (contributed by https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.sourcelookup.ui/src/org/eclipse/m2e/sourcelookup/ui/internal/OpenSourceLookupInfoDialogCommandHandler.java ?) shows there are 3 kind of source containers: Location: E:\apps\data\maven\local\org\hibernate\hibernate-core\5.6.6.Final\hibernate-core-5.6.6.Final.jar GAV: [org.hibernate:hibernate-core:5.6.6.Final] Java project: <not-implemented> Source container: PackageFragmentRootSourceContainer hibernate-core-5.6.6.Final.jar P/test-case-template-hibernate-orm5 Location: E:\git\external\github\issue-HHH-15142\target\test-classes GAV: [] Java project: <not-implemented> Source container: JavaProjectSourceContainer test-case-template-hibernate-orm5 Location: E:\apps\data\maven\local\junit\junit\4.13.2\junit-4.13.2.jar GAV: [junit:junit:4.13.2] Java project: <not-implemented> Source container: ExternalArchiveSourceContainer E:\apps\data\maven\local\junit\junit\4.13.2\junit-4.13.2-sources.jar I don't understand the rational that explain why the first one is a PackageFragmentRootSourceContainer, which works, and the last one is a ExternalArchiveSourceContainer. I don't know the differences between the two, apart that the later is when it fails. Versions: Java 17 + Eclipse 2022-03 M2E - Maven Integration for Eclipse (includes Incubating components) 1.20.1.20220227-1319 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e M2E - POM Editor using LemMinX language server (includes Incubating components) 1.18.4.20220127-1634 org.eclipse.m2e.lemminx.feature.feature.group Eclipse.org - m2e M2E - SLF4J over Logback Logging (optional) 1.17.2.20211002-1029 org.eclipse.m2e.logback.feature.feature.group Eclipse.org - m2e (1): I think the Debug fails to properly resolve breadcumb, local variables and conditional breakpoint because the editor lacks a Java project for it to work. That said, Eclipse Debug could probably be intelligent here since the JUnit launch references a project. [1]: https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.sourcelookup.ui/src/org/eclipse/m2e/sourcelookup/ui/internal/OpenSourceLookupInfoDialogCommandHandler.java [2]: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT [3]: https://github.com/schauder/issue-HHH-15142 [4]: https://github.com/glhez/issue-HHH-15142
Created attachment 288357 [details] JUnit 3 unit test with Spring 3 (sic)
Created attachment 288358 [details] JUnit 4 unit test for issue HHH-15142; we can see the breadcumb and local variables being lost
Created attachment 288359 [details] same project as eclipse_no_debug_context_03.png; unlike before, the local variables are resolved;
In case you need something "more readable" (eg: with proper table) you can view my gist here: https://gist.github.com/glhez/edb5cb1daec2c848e0bc390c0540241f
I also tried a "simple" Java project: - Clone the referenced project: git clone https://github.com/glhez/issue-HHH-15142.git (I don't know if I can ZIP it here) - In a terminal, go the directory The repository contains a Eclipse .project/.classpath which references files in the repository: the file being JAR, they are __NOT__ in the repository and must be downloaded from central because it takes up to 44M: ./mvnw dependency:copy-dependencies -Dclassifier=sources -DoutputDirectory=lib/sources ./mvnw dependency:copy-dependencies -DoutputDirectory=lib/binaries Once done, the project and its launch (JPAUnitTestCase.launch) can be imported in Eclipse using "Import Java Project" (not "Maven Project"). Note that I did create the issue as blocker because it render the debugger completely useless because you can't navigate and you can't see variables.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Bug is still present, and moved to https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/86
