How to attach different versions of same source file - java

Eclipse Mars Release (4.5.0)
I have a few projects in the same namespace and two of them use different versions of the same library (percisely, spring 4.0.x and spring 4.2.x, update is not finished yet.)
Now when debugging a project that uses Spring 4.2.1 eclipse erronously navigates me to sources of Spring 4.0.x (as in the picture below)
There is no instruction at the 629 line in Spring 4.0.x, but here is one in Spring 4.2.1.
Question: How to tell eclise that I want to debug a project with the particular version of sources?

Related

Problem while creating a new spring boot project

In the help.md file it's telling me that JVM was changed from 11 to 17
this is what the help.md file looks like
The following was discovered as part of building this project:
* The JVM level was changed from '11' to '17', review the [JDK Version Range](https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions#jdk-version-range) on the wiki for more details.
and here is an example of later problems
And even if i change the project structure manually to java 11 sdk
i have issues with versions next .
This problem is occurring in the newer version of Spring Boot. So when creating project using Spring Initializr or Spring Starter Project select the older version of Spring Boot (like 3.0.1 or 2.7.7).
This should solve the problem.

Unable to create Enterprise application in NetBeans IDE 12.6

When I try to create an Enterprise application using the wizard (Ant project) I get the following error
java.lang.NullPointerException: Cannot invoke "org.netbeans.modules.j2ee.dd.api.application.Application.setDisplayName(String)" because "this.application" is null
at org.netbeans.modules.j2ee.earproject.ProjectEar.setupDDFromVirtual(ProjectEar.java:290)
at org.netbeans.modules.j2ee.earproject.ProjectEar.getApplication(ProjectEar.java:255)
at org.netbeans.modules.j2ee.earproject.ui.wizards.NewEarProjectWizardIterator.testableInstantiate(NewEarProjectWizardIterator.java:160)
at org.netbeans.modules.j2ee.earproject.ui.wizards.NewEarProjectWizardIterator.instantiate(NewEarProjectWizardIterator.java:139)
at org.openide.loaders.TemplateWizard$InstantiatingIteratorBridge.instantiate(TemplateWizard.java:1048)
at org.openide.loaders.TemplateWizard.handleInstantiate(TemplateWizard.java:602)
at org.netbeans.modules.project.ui.NewProjectWizard.handleInstantiate(NewProjectWizard.java:51)
at org.openide.loaders.TemplateWizard.instantiateNewObjects(TemplateWizard.java:436)
at org.openide.loaders.TemplateWizardIterImpl.instantiate(TemplateWizardIterImpl.java:228)
at org.openide.loaders.TemplateWizardIteratorWrapper$ProgressInstantiatingIterator.instantiate(TemplateWizardIteratorWrapper.java:155)
at org.openide.WizardDescriptor.callInstantiateOpen(WizardDescriptor.java:1602)
at org.openide.WizardDescriptor.callInstantiate(WizardDescriptor.java:1546)
at org.openide.WizardDescriptor.access$2300(WizardDescriptor.java:67)
[catch] at org.openide.WizardDescriptor$Listener$2$1.run(WizardDescriptor.java:2233)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
Of course, all the fields in the wizard are filled. However, there are no errors when creating WAR and EJB separately. The error occurs only when an EAR is created, even if it is empty.
use
NetBeans 12.6
Windows 10 OS
GlassFish Server 6.2.1
Java 17
All paths are spelled out correctly, read / write permissions to directories are set
Screen
I can reproduce your problem, and NetBeans Bug Report 5953 "Creating a new Enterprise Application (Java with Ant) impossible (only when selecting JakartaEE9) - NPEs thrown" has already been raised.
The bug report is unresolved, but the problem only occurs when creating a Jakarta EE 9 Enterprise Application. I successfully created a Jakarta EE 8 Enterprise Application simply by selecting Jakarta EE8 from the Java EE Version drop list within the wizard.
You have several options available to resolve this, but none of them are good:
Wait for NetBeans to fix the problem. Definitely not recommended!
Create a Jakarta EE8 Enterprise Application with the Ant wizard instead, if you don't require EE 9 functionality.
Create a Jakarta EE8 Enterprise Application with the Ant wizard, then "hack" the generated projects to use EE 9.
Use another IDE which properly supports this functionality.
Create the EE 9 Enterprise Application in another IDE, then import the projects into NetBeans.
Using Maven or Gradle isnstead of Ant as the build tool doesn't help either:
I couldn't create a Maven Enterprise Application when using Jakarta EE8 or Jakarta EE9, though I didn't research why.
The project wizard doesn't even offer "Enterprise Application" as an option when using Gradle.
Notes:
NetBeans 13 will be released next month, but I don't think this issue will be fixed.
Also see the (ominous) bug report "NETBEANS-2871 Resolve Enterprise Application support" from 2019 which remains unresolved:
Need to figure out whether maybe Web Applications (in Ant, Maven, and
Gradle) might not be enough in terms of Java EE support, i.e., do we
need Enterprise Applications and EJB-specific project types, if not,
let's remove them.
It works with jakarta EE9 provided you do the following:
Plugin versions in all pom.xml files:
maven-compiler-plugin 3.9.0
maven-war-plugin 3.3.2
maven-dependency-plugin 3.2.0
In the pom.xml file of -ejb- change packaging war to jar.
Then:
Clean and build in the following order:
top, ejb, web and ear.
That's all.

What JARs are needed for Spring 4.2.6 version to create a CRUD project using Eclipse Mars

I'm creating Spring MVC CRUD Operations for a sample project. But I'm
confused what JARs should I need to build. when I look at some tutorials they
were using Spring 3.0.1 version. When I add the same JARs the project is not
able to run. I have created the same copy of the tutorial for code. But I'm
unable to run. Please help me with this task.
Use maven plugin to create the project. Mars has inbuilt maven plugin.
Go through this link.
Link

ApacheCXF 3.1.4 and Spring 4.2.4 compatability

I am trying to upgrade my libraries: ApacheCXF 2.7.7 --> 3.1.4. Spring 2.5.5 --> 4.2.4.
My Hudson build keeps failing because it cannot find packages/classes, org.springframework.context.ApplicationContext, for example. The classpath in cxf-manifest.jar, as part of ApacheCXF, refers specifically to Spring 4.1.7 jars.
I've tried loading both Spring 4.1.7 and 4.2.4 versions, but no joy. (Is loading multiple lib versions even possible?).
I've tried removing cxf-manifest.jar from the classpath/buildpath. Eclipse is happy with that and it finds the desired classes in the Spring 4.2.4 jars, but Hudson is still not happy.
I've considered moving to Spring 4.1.7, but I don't see the point of upgrading partially.
Is ApacheCXF 3.1.4 specifically incompatible with Spring 4.2.4? And how would I get Hudson to be happy with the upgraded libraries?
Turns out that I forgot to add the specific directory containing the Spring jars to my build.xml script.
ApacheCXF 3.1.4 IS compatible with Spring 4.2.4
Edit: Apparently I was wrong.

Atlassian FishEye plugin and Spring LDAP classes

My plugin for FishEye should have a possibility to accessing the our Active Directory and implement some more features for FishEye. The plugin should make the synchronization with directory every X minutes, so it is based on SAL Scheduler.
When I tried to use com.sun.jndi.ldap.LdapCtxFactory, I found that is works only with REST plugin, but using with SAL does not load this classes even when I re-defined the classloader.
Anyway, I re-implemented my functionality with the Spring LDAP and when I tried to deploy my plugin to the FishEye I got:
2014-12-03 23:12:03,010 ERROR [ThreadPoolAsyncTaskExecutor::Thread 9 ] org.springframework.osgi.extender.internal.activator.ContextLoaderListener DefaultOsgiBundleApplicationContextListener-onOsgiApplicationEvent - Application context refresh failed (NonValidatingOsgiBundleXmlApplicationContext(bundle=com.mycompany.fisheye.ldap-restriction-plugin, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/osgi]
Offending resource: URL [bundle://84.0:0/META-INF/spring/atlassian-plugins-component-imports.xml]
Ok. I googled and found https://developer.atlassian.com/docs/faq/troubleshooting/dependency-issues-during-plugin-initialisation
There is written that I have to change the scope of dependency to provided for avoiding the conflicts. Ok, I made that. But now I have another exception:
Exception in thread "PluginSchedulerTask-com.mycompany.fisheye.LdapRestrictio nComponentImpl:job" java.lang.NoClassDefFoundError: org/springframework/ldap/core/support/LdapContextSource
I tried to put the spring-ldap-core-1.3.2.RELEASE.jar to $fisheyeDir/lib and nothing happens - the bootloader does not pick up this JAR.
Does anybody know what can be done in this situation? Should I use another LDAP framework or it is possible to shove these ldap client implementation to the classpath?
FishEye version 3.6.1 (latest), spring jars into classpath version 3.0.5.RELEASE. My spring-security-ldap dependency is also 3.0.5.RELEASE.
Thanks in advance.
The Spring version FishEye uses internally (3.0.5 in 3.6.1, 3.1.4 as of 3.7), is not exposed to plugins.
Instead they get a spring runtime from the Atlassian plugin system (https://bitbucket.org/atlassian/atlassian-plugins). FishEye uses plugins 3.0.x, so the Spring version that's available to plugins is 2.5.6.
Neither FishEye, the plugin system nor any of the bundled plugins include spring-ldap, so you can't set the dependency scope to (as this causes the library not to be included in the plugin jar, instead expecting it be available via an OSGI import).
So what I believe you should try is to bundle a version of spring-ldap that's compatible with Spring 2.5.6. To solve the BeanDefinitionParsingException, you might need to exclude some transitive dependencies that are provided by the plugin system (use mvn dependency:tree to find those).
Disclosure: I'm a dev working on FishEye/Crucible

Categories

Resources