We Keep Coding

How best to provide JAXB components in an RCP application

My RCP application makes calls to SOAP web services and has been using the built-in JAXB/JEE components in Java 1.8. I have set up the build process to force the use of Java 1.8 and this had been working well.
Recently, the build stopped working because the builder (Tycho) now has a component which only works with later Java versions. If I compile with the later version I get 100's of JEE-related errors such as JaxbElement not found or #WebMethod not found.
At some point we will have to move away from Java 1.8 and use a Java version which does not provide those JEE components, so forcing the use of 1.8 can only be a short-term solution.
Is there an eclipse plugin which already provides those missing components? (I have searched but not found anything) Or do I need to create my own helper plugin which contains the necessary libraries? Is there perhaps a JAXB alternative which I could use for the SOAP calls?

The JAXB plugins/bundles are available on Eclipse Orbit: the plugins/bundles starting with javax..
In the plugins/bundles where they are needed, add the dependency in the MANIFEST.MF file via Import-Package (using Require-Bundle would require that these plugins/bundles are available even when using Java 8).
See also this answer.

How to use Esapi 1.4.4 package in web application

I am currently working on a project that uses JDK 1.4. So its just turned out to be that we have to use ESAPI 1.4.4 which is the only version compatible with JDK 1.4 . I downloaded it from the following path https://github.com/esapi/esapi-java-legacy but it doesnt seem to be a jar file . I couldnt figure out how to include this in my eclipse project or how to bring it into my classpath. Is it possible to get the JAR ??? Someone please guide me how to use it or any sample project for reference is sufficient .Thanks in advance

Ditching JDK 1.4 is my top recommendation as well. But if that is not an option for some reason, then I would try pulling down the ESAPI code base from GitHub (https://github.com/ESAPI/esapi-java-legacy), changing the tag under the maven-compiler-plugin plugin from 1.7 to 1.4 and see if it compiles. Much of it probably will be fine, but you likely will have some huge 3rd party FOSS dependency issues so you will have to adjust those. So, before you go down that route, figure out what exactly it is that you need. If you only need ESAPI's output encoding, use the OWASP Java Encoder Project instead. Various other substitutes are described here: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F
Good luck.
-kevin

integrating org.apache.poi and the javax.xml.stream.* package (stax-api) in android - how to set the --core-library argument in Android Studio?

I'm using Android studio 1.5.1
I'd like to include the org.apache.poi-ooxml library in my android project. To include that library I needed to include some other library dependencies, among which the stax-api library.
The problem with stax api is that it has all the packages in javax.* which is a "core library". Java jdk has all these libraries included, so if I were to use it in Java SE, I wouldn't need that stax-api library. Android, on the other hand, has a "partial" stax-api library. For android I only need the javax.xml.stream.* package. That means that I need to extract the stax-api, remove everything except the javax.xml.stram package, and repackage it again.
So I guess it is safe to use this modified library in Android. But, it has the javax.* package, which, according to Android studio is a core library, so Android Studio (or whatever component in Android Studio) gives me a warning:
trouble processing "javax/xml/stream/EventFilter.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*) when
not building a core library.
This is often due to inadvertently including a core library file in
your application's project, when using an IDE (such as Eclipse). If
you are sure you're not intentionally defining a core class, then this
is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example, from a
non-Android virtual machine project. This will most assuredly not
work. At a minimum, it jeopardizes the compatibility of your app with
future versions of the platform. It is also often of questionable
legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine distribution,
as opposed to compiling an application -- then use the
"--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact building an
application, then be forewarned that your application will still fail
to build or run, at some point. Please be prepared for angry customers
who find, for example, that your application ceases to function once
they upgrade their operating system. You will be to blame for this
problem.
If you are legitimately using some code that happens to be in a core
package, then the easiest safe alternative you have is to repackage
that code. That is, move the classes in question into your own package
namespace. This means that they will never be in conflict with core
system classes. JarJar is a tool that may help you in this endeavor.
If you find that you cannot do this, then that is an indication that
the path you are on will ultimately lead to pain, suffering, grief,
and lamentation.
So, I'd like to use this --core-library option. But where to set it?
I already looked at Android Studio ignore --core-library flag which didn't help me. I think those answers are outdated, and that's why I'm asking a new question.
What I did try:
build.gradle:
dexOptions {
coreLibrary true;
}
build.gradle:
dexOptions {
preDexLibraries = false
}
project.tasks.withType(com.android.build.gradle.tasks.Dex) {
additionalParameters=['--core-library']
}
File --> Other Settings --> Default Settings --> Compilers --> Android Compilers
and check the 'Add --core-library flag'
None of these worked. Is there any way to set that option?
EDIT: Why do I need STAX:
I'm doing some stuff with Workbook, Sheet, Columns, Cells for .xlsx files.
When I include only poi-ooxml-3.14-beta1-20151223.jar I get an error in build time saying class file for org.apache.poi.ss.usermodel.Workbook not found.
Upon including poi-3.14-beta1-20151223.jar on runtime I get, among others, Could not find method org.openxmlformats.schemas.spreadsheetml.x2006.main.CTWorkbook.isSetBookViews, referenced from method org.apache.poi.xssf.usermodel.XSSFWorkbook.
Upon including poi-ooxml-schemas-3.14-beta1-20151223.jar during runtime I get , among others, Failed resolving Lorg/openxmlformats/schemas/spreadsheetml/x2006/main/CTWorkbook; interface 59 'Lorg/apache/xmlbeans/XmlObject; and java.lang.VerifyError: org/apache/poi/xssf/usermodel/XSSFWorkbook
Upon including xmlbeans-2.6.0.jar during runtime I get, among others, Could not find method javax.xml.stream.events.Namespace.getPrefix, referenced from method org.apache.poi.openxml4j.opc.internal.marshallers.PackagePropertiesMarshaller.getQName and java.lang.NoClassDefFoundError: javax.xml.stream.XMLEventFactory at org.apache.poi.openxml4j.opc.internal.marshallers.PackagePropertiesMarshaller.<clinit>(PackagePropertiesMarshaller.java:41)
UPDATE
So, from http://poi.apache.org/faq.html#faq-N1017E
18. Why do I get a java.lang.NoClassDefFoundError: javax/xml/stream/XMLEventFactory.newFactory()
This error indicates
that the class XMLEventFactory does not provide functionality which
POI is depending upon. There can be a number of different reasons for
this:
Outdated xml-apis.jar, stax-apis.jar or xercesImpl.jar:
These libraries were required with Java 5 and lower, but are not actually required with spec-compliant Java 6 implementations, so try
removing those libraries from your classpath. If this is not possible,
try upgrading to a newer version of those jar files.
Running IBM Java 6 (potentially as part of WebSphere Application Server): IBM Java 6 does not provide all the interfaces required by
the XML standards, only IBM Java 7 seems to provide the correct
interfaces, so try upgrading your JDK.
Sun/Oracle Java 6 with outdated patchlevel: Some of the interfaces were only included/fixed in some of the patchlevels for Java 6. Try
running with the latest available patchlevel or even better use Java
7/8 where this functionality should be available in all cases.
So, if I read this correctly, in Android, I do need a "truncated" STAX api.

There are a number of problems when you try to use Apache POI and it's depending libraries in an Android Application. Among others there are duplicate classes in xmlbeans.jar, the "javax.*" packages are prohibited by the Android compiler and a few others.
There are currently two projects which try to fix those issues:
https://github.com/andruhon/android5xlsx
https://github.com/centic9/poi-on-android/ (which I maintain)
android5xlsx provides ready-made jar-files to include in your application, but currently uses a somewhat outdated version of POI. poi-on-android is based on POI 3.15-beta1 and can be recompiled for newer versions of POI fairly easily.
Both projects are for Android 5+ and come with sample code and should allow basic usage of Apache POI on Android.

Add implementation 'javax.xml.stream:stax-api:1.0' in you app build.gradle, as some core class missed

Build web service with jax-ws reference implemetation bundled in JDK 6

I used to saw a tutorial about this topic. But when I try to make my example application by following the example. I can't find com.sun.xml.ws.transport.http.servlet.WSServletContextListener on my classpath.
but I found com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener
It confused me, why Oracle move those classes in com.sun.xml.xxx to com.sun.xml.internal? I am using JDK1.6.0_45. I saw some people said, form JDK6U4, jax-ws reference implementation is bundled in JDK, so we should be able to publish a web service by running a light weight http server just with JDK and no other dependencies needed, is that ture? You should notice that in the tutorial I mentioned above, additional dependencies is still needed, see step 5 "JAX-WS Dependencies".
And I also found that in IBM JDK, even com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener can't be found.

Yes, JAX-WS RI (same as JAX-B RI) is shipped with JDK since Jdk6. All the packages except for javax.xml.* are changed to .internal. in order to avoid conflicts between JDK's and standalone JAX-WS versions.
Using JDK's version, you can deploy web service using just JDK; if you want deploy WS in tomcat or in some AS, you still need JAX-WS standalone version.

If you check grepcode for (non-internal) WSServletContextListener, it shows you, the class is shipped with jaxws-rt/webservice-rt jar.
By looking for the internal WSServletContextListener, you can't find a jar shipping it. (but grepcode also contains the sources of openJDK)
Also, I tried to find WSServletContextListener in my local jdk7, but can't find it. But maybe some third-party jdk ship with the class.
Anyway, if you look into the tutorial again, you will find that jaxws-rt.jar is necessery for the application. Probably you should add it?

Glassfish and JodaTime

I am using Glassfish 3.1.2.2 to host several web applications, some of which use JodaTime. Recently, I've updated the version of JodaTime from 1.6.2 to 2.0. After doing this, I get problems with errors like this:
java.lang.NoSuchMethodError: org.joda.time.DateTime.compareTo(Lorg/joda/time/ReadableInstant;)I
Usually this indicates a dependency-crash on the classpath, but I couldn't find that my project had multiple versions of JodaTime, 2.0 was the only one. After some more digging, and debugging to find where the DateTime-class is loaded from, I found that it is loaded from [glassfish]\modules\joda-time-1.6.2.jar, which is of course not what I want.
Why does glassfish include a specific version of a library like JodaTime on the classpath of every application, and is it safe to remove it/replace it with version 2.0?

GlassFish doesn't include any version of JodaTime.
I guess you placed the jar file in [glassfish]\modules by yourself and forget that you did that. You can have a look at a fresh GlassFish installation to validate that.
It is safe to delete the old version from the modules folder.