Develop Reference

No suitable Deployment Server is defined for the project or globally

I have tried to resolve the problem by this questions: Netbeans 11.2: No suitable Deployment Server is defined for the project or globally, but my nb-configuration.xml file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project-shared-configuration>
<!--
This file contains additional configuration written by modules in the NetBeans IDE.
The configuration is intended to be shared among all the users of project and
therefore it is assumed to be part of version control checkout.
Without this configuration present, some functionality in the IDE may be limited or fail altogether.
-->
<properties xmlns="http://www.netbeans.org/ns/maven-properties-data/1">
<!--
Properties that influence various parts of the IDE, especially code formatting and the like.
You can copy and paste the single properties, into the pom.xml file and the IDE will pick them up.
That way multiple projects can share the same settings (useful for formatting rules for example).
Any value defined here will override the pom.xml file value but is only applicable to the current project.
-->
<org-netbeans-modules-maven-j2ee.netbeans_2e_hint_2e_j2eeVersion>1.8-web</org-netbeans-modules-maven-j2ee.netbeans_2e_hint_2e_j2eeVersion>
<org-netbeans-modules-maven-j2ee.netbeans_2e_hint_2e_deploy_2e_server>gfv5ee8</org-netbeans-modules-maven-j2ee.netbeans_2e_hint_2e_deploy_2e_server>
<netbeans.hint.jdkPlatform>JDK 1.8</netbeans.hint.jdkPlatform>
<org-netbeans-modules-maven-jaxws.rest_2e_config_2e_type>ide</org-netbeans-modules-maven-jaxws.rest_2e_config_2e_type>
</properties>
</project-shared-configuration>
So I have netbeans_2e_hint_2e_j2eeVersion set to 1.8-web and
netbeans_2e_hint_2e_deploy_2e_server set to gfv5ee8 as is in the answer. But still error of no suitable server deployment. How to resolve this?

Try this:
Right click project -> Properties -> Run.
Change Server to the one you want to use.

NoSuchMethodError - Calling Class/Method from Class in Same Package

We are integrating an internal framework into our weblogic application and we are running into deployment problems.
Technologies Used
Weblogic 10.3.6 application
Spring 3.0
Maven 2
Eclipse J2EE
The Problem
On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the org.joda.time (2.0) jar.
Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
. . . excluded . . .
Things We Have Tried
After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.
Googling "NoSuchMethodError" usually gave JAR hell solutions.
Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.
.war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files
One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.
Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.
Questions:
Can anyone explain why the method could not be found?
Are there more places to check for existing or conflicting jars?
Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?

Here's some interesting reading:
prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a
element (a sub-element of the
element). By default, this element is set to
False. Setting this element to True subverts the classloader
delegation model so that class definitions from the Web application
are loaded in preference to class definitions in higher-level
classloaders. This allows a Web application to use its own version of
a third-party class, which might also be part of WebLogic Server. See
“weblogic.xml Deployment Descriptor Elements.”
taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html
Other troubleshooting tips:
You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.
An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.
--whereis.jsp --
<%# page import="java.security.*" %>
<%# page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>
You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial

A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.
Weblogic is pulling the org.joda jar.
Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.
The below is from my application, you can have a look what all we have to removed for our application.
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.slf4j.helpers.*</wls:package-name>
<wls:package-name>org.slf4j.impl.*</wls:package-name>
<wls:package-name>org.slf4j.spi.*</wls:package-name>
<wls:package-name>org.hibernate.*</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.xmlbeans.*</wls:package-name>
<wls:package-name>javassist.*</wls:package-name>
<wls:package-name>org.joda.*</wls:package-name>
<wls:package-name>javax.xml.bind.*</wls:package-name>
<wls:package-name>com.sun.xml.bind.*</wls:package-name>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
</wls:prefer-application-packages>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>

Using Coda Hale Yammer Metrics library in Websphere Application Server 7

I am trying to add metrics library to existing webservice on WAS 7. I am getting below error
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [AdminServlet]: com.yammer.metrics.reporting.AdminServlet was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime class path SRVE0234I
What are the other run-time dependencies required for metrics-servlet-2.2.0?
I have metrics-core-2.2.0.jar and metrics-servlet-2.2.0.jar in my WEB-INF\lib folder.
Threads, ping and healthcheck servlets work fine.

I think your missing some more required jars, are you not using maven or gradle for dependency management
Please refer here to know all required jars that metrics-servlet-2.2.0.jar depends on. http://mvnrepository.com/artifact/com.yammer.metrics/metrics-servlets/3.0.0-BETA1
My suggestion is, it is always difficult to maintain dependencies without Maven/Gradle or any other build tools :).

Howto reach logback.xml in an Eclipse RCP plugin?

I created an Eclipse RCP "Hello World"-Plugin, it's running and showing me the main window, then I created a second plugin called "logging" with the logback libraries and added this logging-plugin as a dependency to the main plugin.
The main plugin now knows the logger-classes, and I can use them, but how do I reach the "logback.xml"-file from the main plugin? This file is stored in the "resources"-folder in the logging-plugin.
-mainplugin <---knows logging classes, but not reaching logback.xml
-logging
|-libs
|-resources
|-logback.xml

logback.xml is a configuration file for your logging, the one where you set log level ect. ... right? In this case it belongs to the mainplugin, not to the logging plugin (which would only expose the methods of the jar file in the libs folder).
Like this:
-mainplugin
|-resources
|-logback.xml
-logging
|-libs
In order to work you would have to set buddy policies in your plugins and lockback.xml have to be in the classpath (!). This is required to allow the logging plugin to find the lockback.xml inside your plugin without to have a direct dependency.
in the MANIFEST.MF of the logging plugin you would have to add:
Eclipse-BuddyPolicy: registered
In the MANIFEST.MF of your mainplugin you would have to add:
Eclipse-RegisterBuddy: org.logplugin.id
with org.logplugin.id being the id of your logging plugin.
For more information: http://www.eclipsezone.com/articles/eclipse-vms/

A more introductory, including another two approaches, is described at http://devblog.virtage.com/2012/07/logback-and-eclipse-attaching-logback-xml/.

Adding classpath to jetty running in maven integration-test

I'm trying to set up integration tests for a Maven project that produces a war file. (As seen here http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin/.) However I the war file requires a bunch of .properties files on the classpath, that I don't want to bundle in the war.
Is there a way (preferably through plugin configuration) to add a folder to the classpath used by jetty?
I Googled this and found http://markmail.org/message/awtqrgxxttra3uxx but this, as far as I can tell, does not actually work at all. The .properties files are not found.

This should be possible using the webAppConfig configuration element (sample below taken from this thread):
<webAppConfig>
<contextPath>/nportal</contextPath>
<!-- All I want to do here is add in the /etc/jetty/classes for runtime files. For some reason I have to also add back in the /target/classes directory -->
<extraClasspath>${basedir}/target/classes/;${basedir}/etc/jetty/classes/</extraClasspath>
</webAppConfig>

If you find that the above solution doesn't work for you, consider including the test classpath into your Jetty configuration.
<configuration>
<useTestClasspath>true</useTestClasspath>
...
</configuration>
This will then allow you to place all manner of resources/classes on the test classpath and have them visible to the Jetty server without them creeping into the production code.

You can place your additional configuration files under /src/test/resources and set a property <useTestScope>true</useTestScope> in the plugin configuration as specified here:
useTestScope
If true, the classes from testClassesDirectory and dependencies of scope "test" are placed first on the classpath. By default this is false.