I used to send emails with javamail and Java 8.
Now that I upgraded to Java 12 I get the java.lang.NoClassDefFoundError: javax/activation/DataHandler.
I added the javax.activation-api-1.2.0.jar and now I get java.lang.NoClassDefFoundError: com/sun/activation/registries/LogSupport.
This is because javax.activation-api-1.2.0.jar doesn't have the com.sun... package that previous versions had.
What jars should I put on my project to properly send and email with java 12? And where to find them?
There are a lot of confusing sources like:
https://repo1.maven.org/maven2/javax/activation/javax.activation-api/1.2.0/
https://eclipse-ee4j.github.io/jaf/
https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#jaf-1.1.1-fcs-oth-JPR
You need the implementation jar file, not the API jar file. Use this.
Related
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
What jar is Base64 in?
com.google.api.client.repackaged.org.apache.commons.codec.binary.Base64.class is contained in google-http-client-1.13.1-beta.jar, but adding that to the claspath doesn't resolve it.
I just can't figure out what jar has com/google/appengine/repackaged/...
Grrrr... using Appengine.1.9.25 works but switching in 1.9.37 fails....
Exception in thread "main" java.lang.NoClassDefFoundError: com/google/appengine/repackaged/com/google/api/client/repackaged/org/apache/commons/codec/binary/Base64
at com.google.appengine.repackaged.com.google.api.client.util.Base64.encodeBase64URLSafeString(Base64.java:79)
at com.google.appengine.repackaged.com.google.api.client.json.webtoken.JsonWebSignature.signUsingRsaSha256(JsonWebSignature.java:634)
at com.google.appengine.repackaged.com.google.api.client.googleapis.auth.oauth2.GoogleCredential.executeRefreshToken(GoogleCredential.java:378)
at com.google.appengine.repackaged.com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:489)
at com.google.appengine.repackaged.com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:217)
at com.google.appengine.repackaged.com.google.api.client.http.HttpRequest.execute(HttpRequest.java:868)
at com.google.appengine.tools.remoteapi.OAuthClient.get(OAuthClient.java:64)
at com.google.appengine.tools.remoteapi.RemoteApiInstaller.getAppIdFromServer(RemoteApiInstaller.java:413)
at com.google.appengine.tools.remoteapi.RemoteApiInstaller.loginImpl(RemoteApiInstaller.java:376)
at com.google.appengine.tools.remoteapi.RemoteApiInstaller.login(RemoteApiInstaller.java:337)
at com.google.appengine.tools.remoteapi.RemoteApiInstaller.install(RemoteApiInstaller.java:173)
Try to use 1.9.26 version. Seems Google missed to package commons-codec into 1.9.37.
I try to use this command to deploy my application to
appspot.google.com:
c:\a\appeng\bin\appcfg.cmd --use_java7 update c:\a\u3e
Generates the error messsage.
C:\a>c:\a\appeng\bin\appcfg.cmd --use_java7 update c:\a\u3e
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I tried setting the path to use the Java 1.6 SDK we downloaded
but that did not help or change any thing.
The web resources talk about what version of Java is used
by the application once it appears on Google's servers; I
did not see anything about the Java version for the upload
process including developers.google.com/appengine/docs/java/gettingstarted/uploading and developers.google.com/appengine/docs/java/tools/uploadinganapp#Command_Line_Arguments as well as searching this site specifically and checking google.
Can I deploy
an application from the computer in my house without
deinstalling the Java 1.7 I use for other purposes?
Thank you for looking at this question. I resolved the problem. It was not related to Google Application Development
Server. It was a difficult-to-resolve path problem to the directory where the Java executables were kept.
I am getting an exception trying to use update/extract with PDF files
My Set up is:-
Ubuntu Server 11.10
Tomcat 6
Solr 3.5.0.2011.11.22.15.54.38
I can browse to solr/admin OK
I have put all the contrib/extract and apache-solr-cell3.5.0.jar libraries into the tomcat folder webapps/solr/WEB-INF/lib
I am calling extract using:-
curl "http://localhost:8080/solr/update/extract?uprefix=attr_&fmap.content=attr_content&commit=true" -F "file=/path/to/my.pdf"
error is
java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:383)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:461)
at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.getWrappedHandler(RequestHandlers.java:248)
at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:239)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
Would appreciate any pointers - the only time this error seems to come up elsewhere is with Nutch and cached results.
I have tried sending the mimetype in the querystring and also a *.doc file but got the same error.
According to the error message it is not a MimeTypeException exception you get: The problem is a NoClassDefFoundError, because Solr cannot load the class MimeTypeException.
Normally this class is present in tika-core.jar.
Make sure you actually have that file and also check if you have a lib statement in your solrconfig.xml pointing to the right directory.
This was due to the basic error of copying the necessary tika libraries (to tomcat6/webapps/solr/WEB-INF/lib) but leaving ownership of the jar files as ROOT instead of chown-ing them to TOMCAT6. After setting the right permission and restarting Tomcat it started working OK
Found the solution of this problem, I was using SolrJ to update my pdf indexing.
after deploy solr to tomcat, I didn't include the following libraries into the tomcat/webapp
and I get all the lazy loading problem, etc etc
I even try to get apache tika...
until I do this...
shutdown tomcat
\apache-solr-3.5.0\contrib\extraction
copy the libraries above to below
\apache-tomcat-7.0.26\webapps\solr\WEB-INF\lib
startup tomcat
cheers
We get the following error when we use WSDL2Java tool to generate stubs. The webservice is up and running.
WSDLToJava Error: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsd
l definition from : http://scheduler.heartbeatsoftware.com/scheduler/WebServices
/SampleSNMWebService?wsdl
Caused by : WSDLException: faultCode=PARSER_ERROR: java.lang.IllegalArgumentExce
ption: InputSource must have a ByteStream or CharacterStream
If we donwload the wsdl and generate stubs from that wsdl, they are generated. But the java client using those stubs throws the same exception as above
Strangely when we deploy the same webservice on our LAN such a problem is not encountered stubs are generated sucessfully and the subsequent java client works well.
The webservice is created using apache cxf version 2.2.5 and hosted on tomcat 6
Any pointers would be appreciated
regards
Sameer
Found solution. Just need to modify the wsdl.java.bat to include proxy settings
-Dhttp.proxyHost= -Dhttp.proxyPort=8080