We Keep Coding

elasticsearch 6 ESIntegTestCase "codebase property already set"

I'm attempting an upgrade to ES 6.2 from 2.3.4.
Previously, we'd integration-tested code by using NodeBuilder and running up a local ES node. I'd rather swap this out for the ESIntegTestCase usage if possible.
However, when I try to run an integration test I get the following error:
at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:164)
at org.elasticsearch.test.ESTestCase.<clinit>(ESTestCase.java:190)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:592)
Caused by: java.lang.IllegalStateException: codebase property already set: codebase.metrics-core -> file:/Users/me/.m2/repository/io/dropwizard/metrics/metrics-core/3.1.0/metrics-core-3.1.0.jar, cannot set to file:/Users/me/.m2/repository/com/yammer/metrics/metrics-core/2.2.0/metrics-core-2.2.0.jar
at org.elasticsearch.bootstrap.Security.readPolicy(Security.java:236)
at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:139)
... 4 more
What does this mean, and how I can I fix it?
My test class is annotated with: #RunWith(com.carrotsearch.randomizedtesting.RandomizedRunner.class) and extends ESIntegTestCase if that helps at all.
Thank you for any help anyone can offer!

If developing a plugin so still needing embedded ES, then perhaps setting system property -Dtests.gradle=false can work around the issue.
since BootstrapForTesting.java L175 contains:
if (System.getProperty("tests.gradle") == null) {
addClassCodebase(codebases, "plugin-classloader", "org.elasticsearch.plugins.ExtendedPluginsClassLoader");
addClassCodebase(codebases, "elasticsearch-secure-sm", "org.elasticsearch.secure_sm.SecureSM");
}

As per this issue: https://github.com/elastic/elasticsearch/issues/21544 ESIntegTestCase should also no longer really be used unless you're testing a plugin or something like that (see reply posting here: https://discuss.elastic.co/t/how-do-i-deal-with-this-particular-jar-hell-issue/135662/4).
See here for more: https://discuss.elastic.co/t/codebase-property-already-set-when-running-esintegtestcase/135659/2
The best best methodology for integration testing with elasticsearch that I have found now is mentioned in that discuss posting: use testcontainers-elasticsearch (https://github.com/dadoonet/testcontainers-java-module-elasticsearch)
You need docker installed on the machine running the tests, but it will automatically pull the required docker image, start up the container and tear it down again at the end.

Quartz Scheduler Job run once, then gives an error

I have a strange behavior from Quartz. The job was able to run after I clear the quartz database tables and tomcat restart. And after a few times of full run, the following error occur. I ran out of clue, anyone had this problem below?
Update:
If I changed the TRIGGER_STATE status from "ERROR" to "WAITING", that job will run again and after a few full cycle, it changed to "ERROR" with the same error stack trace.
[scheduler_QuartzSchedulerThread] 00:07:01,007 ERROR org.quartz.impl.jdbcjobstore.JobStoreSupport.triggerFired(JobStoreSupport.java:2908) - Error retrieving job, setting trigger state to ERROR.
org.quartz.JobPersistenceException: Couldn't retrieve job because a required class was not found: com.mbww.scgid.social.facebook.RunFbPageHourlyJob [See nested exception: java.lang.ClassNotFoundException: com.social.facebook.RunFbPageHourlyJob]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob(JobStoreSupport.java:1416)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggerFired(JobStoreSupport.java:2903)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$38.execute(JobStoreSupport.java:2871)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3788)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggerFired(JobStoreSupport.java:2865)
at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:319)
Caused by: java.lang.ClassNotFoundException: com.mbww.scgid.social.facebook.RunFbPageHourlyJob
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1483)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
at org.springframework.scheduling.quartz.ResourceLoaderClassLoadHelper.loadClass(ResourceLoaderClassLoadHelper.java:75)
at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.java:894)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob(JobStoreSupport.java:1404)
... 5 more

This is probably a classpath error where you missed to define your classpath. As there's something wrong with your classpath, your app can't find the necessary jar and thus the class it needs.

Surprisingly, there are many reasons for this to happen base on Mr Google.
For my case, it is because someone else in the team has deployed another same application (with different name), and this actually cause a confusion to Quartz. When it tries to load the class, it sometimes trying to load the class from the old application, where the class is not there. then the error make sense:
Couldn't retrieve job because a required class was not found:
com.mbww.scgid.social.facebook.RunFbPageHourlyJob
After removing the old application from the tomcat, it all runs smooth and well now.

Debugging JDO error

My application is throwing this error:
Error : An error occurred trying to instantiate an instance of the API adapter "org.datanucleus.api.jdo.JDOAdapter"
(perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?) :
{1}
org.datanucleus.exceptions.NucleusUserException: Error :
An error occurred trying to instantiate an instance of the API adapter "org.datanucleus.api.jdo.JDOAdapter" (perhaps you dont have the requisite datanucleus-api-XXX jar in the CLASSPATH?) :
{1}
...
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Although my application do have datanucleus-api-jdo-3.0.0-release.jar
What could be the reason if not missing jars?
EDIT:
This is what have been suggested to fix this issue:
This is a sporadic error that happens from time to time on any
persistable class, but moreso on ones that are used a lot in parallel.
It happens in JDO and JPA, and it seems as though the local datastore
locks a particular table / entity group and forgets to release it;
thus causing all subsequent calls to ds operations to fail. I
generally don't have to restart eclipse; just stopping then starting
the server tends to fix the problem, if not, a full refresh/clean
build will do the trick.
However, I have already restarted my GAE server and re-run my application still getting the same error.
Here is the complete POM.xml
Here is the complete stack trace.

Use latest versions. Include all dependencies (jdo-api, datanucleus-api-jdo). Read docs for what needs to be in the CLASSPATH (enhanced versions of your classes, for example).

Exception when using #SchemaValidation annotation on JAX-WS endpoint in Weblogic

I am trying to get schema validation working for a JAX-WS Web Service deployed on Weblogic 10.3.3.
According to the documentation, this should be as simple as adding the annotation
"#SchemaValidation" to the endpoint class. However when I try this the following exception is thrown when the application is deployed:
Caused by: javax.xml.ws.WebServiceException:
Annotation#com.sun.xml.internal.ws.developer.SchemaValidation
(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler)
is not recognizable,
atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature
should be marked with #FeatureConstructor
at com.sun.xml.ws.binding.WebServiceFeatureList.getWebServiceFeatureBean(WebServiceFeatureList.java:169)
at com.sun.xml.ws.binding.WebServiceFeatureList.parseAnnotations(WebServiceFeatureList.java:141)
The error message is complaining that "com.sun.xml.internal.ws.developer.SchemaValidationFeature" does not have a constructor annotated with #FeatureConstructor. When I look at that class, it sure seems to have one:
#com.sun.xml.internal.ws.api.FeatureConstructor(value={"handler"})
public SchemaValidationFeature(java.lang.Class arg0);
I have googled around but cannot find any reference to this more than this fellow unfortunate soul who did not get any answers. It would be great if someone could point me in the right direction because at this moment I am stuck.

SchemaValidation annotation is working, but make sure you're importing correct class.
com.sun.xml.ws.developer.SchemaValidation
instead of
com.sun.xml.internal.ws.developer.SchemaValidation
The second class is bundled with JDK by default. The first one (used by weblogic) comes from glassfish.jaxws.rt_XXX.jar, so you may need to add this jar to your classpath explicitly.

I have faced the same problem recently.
To overcome this, I added the tag
<validation-request>true</validation-request>
to the file weblogic-webservices.xml
This enabled SOAP request validation on the app-server.
XML Structure of weblogic-webservices.xml
Note : I have not been able to use the #SchemaValidation tag successfully, but the above way - works as expected.

Provider oracle.j2ee.ws.client.ServiceFactoryImpl not found

I am writing an application that invokes an Oracle web service. The web service client code was provided me.
This application uses a custom subclass of URLClassLoader to load jars at run-time. Running the unit tests from my local machine works fine, however when I deploy the application on the server and run it, I get the following error. Other classes/jars are loading fine through the custom ClassLoader.
Not sure why this is happening? Maybe FactoryFinder is using a separate ClassLoader instance? Any help is appreciated. Thanks!
javax.xml.rpc.ServiceException: Provider oracle.j2ee.ws.client.ServiceFactoryImpl not found
at javax.xml.rpc.FactoryFinder.newInstance(FactoryFinder.java:44)
at javax.xml.rpc.FactoryFinder.find(FactoryFinder.java:137)
at javax.xml.rpc.ServiceFactory.newInstance(ServiceFactory.java:69)
at com.mycomp.myapp.oracle.client.TSClient.<init>(TSClient.java:34)
at com.mycomp.myapp.oracle.LaborHours.update(LaborHours.java:92)
at com.mycomp.myapp.oracle.OracleConnection.updateMetrics(OracleConnection.java:73)
at com.mycomp.myapp.Project.crawl(Project.java:150)
at com.mycomp.myapp.Main.main(Main.java:302)

This is the conclusion I came up with.
ServiceFactory uses it's own class loading mechanism (which apparently is a different instance than my custom class loader).
I had to use this hack http://forums.sun.com/thread.jspa?threadID=300557 to add the jars to the system class loader's class path.