Trying out some code to call a Watson Service I provisioned on Bluemix. I get the following error:
Unable to extract the trust manager on
okhttp3.internal.Platform#e19ef72e, sslSocketFactory is class
com.ibm.jsse2.SSLSocketFactoryImpl
Here is my code:
try {
DocumentConversion service = new DocumentConversion("2016-05-25");
service.setUsernameAndPassword("*****", "*****");
File doc = new File("C:/Sample1.pdf");
Answers htmlToAnswers = service.convertDocumentToAnswer(doc).execute();
System.out.println(htmlToAnswers);
} catch(Exception e) {
System.out.println("Error! -> " + e.getMessage());
}
Thoughts? Do I need to import a cert from Bluemix? Thanks.
Looks like it is a known problem in the okhttp library. Are you using Java SDK to use the IBM Watson version 3.0.0-RC1? If so, try with 2.10.0 as it has an older version of the okhttp library which may not suffer from this problem.
Related
I'm upgrading a project to Java 11. I realized that some of the internal packages such as sun.security.krb5.Config & sun.security.krb5.KrbException are no longer "visible" due to modules.
Few examples of how the codebase is consuming these packages are below:
Exception cause = ExceptionUtils.findCause(ne, KrbException.class);
LoginException le = (LoginException) ne.getCause();
if (le.getCause() instanceof KrbException) {
KrbException ke = (KrbException) le.getCause();
try {
sun.security.krb5.Config.refresh();
} catch (KrbException e) {
//log something
}
I read that these internal packages are supposed to be implemented using GSS APIs.
I have been going through the GSS classes and tutorials but couldn't find anything on replacing the internal packages mentioned above.
Take the LoginException as-is. JAAS is supposed to abstract from everything. You just have bad code.
I have a Spring Boot project, built using Maven, where I intend to use embedded mongo db. I am using Eclipse on Windows 7.
I am behind a proxy that uses automatic configuration script, as I have observed in the Connection tab of Internet Options.
I am getting the following exception when I try to run the application.
java.io.IOException: Could not open inputStream for https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip
at de.flapdoodle.embed.process.store.Downloader.downloadInputStream(Downloader.java:131) ~[de.flapdoodle.embed.process-2.0.1.jar:na]
at de.flapdoodle.embed.process.store.Downloader.download(Downloader.java:69) ~[de.flapdoodle.embed.process-2.0.1.jar:na]
....
MongoDB gets downloaded just fine, when I hit the following URL in my web browser:
https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip
This leads me to believe that probably I'm missing some configuration in my Eclipse or may be the maven project itself.
Please help me to find the right configuration.
What worked for me on a windows machine:
Download the zip file (https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip)
manually and put it (not unpack) into this folder:
C:\Users\<Username>\.embedmongo\win32\
Indeed the problem is about your proxy (a corporate one I guess).
If the proxy do not require authentication, you can solve your problem easily just by adding the appropriate -Dhttp.proxyHost=... and -Dhttp.proxyPort=... (or/and the same with "https.[...]") as JVM arguments in your eclipse junit Runner, as suggested here : https://github.com/learning-spring-boot/learning-spring-boot-2nd-edition-code/issues/2
One solution to your problem is to do the following.
Download MongoDB and place it on a ftp server which is inside your corporate network (for which you would not need proxy).
Then write a configuration in your project like this
#Bean
#ConditionalOnProperty("mongo.proxy")
public IRuntimeConfig embeddedMongoRuntimeConfig() {
final Command command = Command.MongoD;
final IRuntimeConfig runtimeConfig = new RuntimeConfigBuilder()
.defaults(command)
.artifactStore(new ExtractedArtifactStoreBuilder()
.defaults(command)
.download(new DownloadConfigBuilder()
.defaultsForCommand(command)
.downloadPath("your-ftp-path")
.build())
.build())
.build();
return runtimeConfig;
}
With the property mongo.proxy you can control whether Spring Boot downloads MongoDB from your ftp server or from outside. If it is set to true then it downloads from the ftp server. If not then it tries to download from the internet.
The easiest way seems to me to customize the default configuration:
#Bean
DownloadConfigBuilderCustomizer mongoProxyCustomizer() {
return configBuilder -> {
configBuilder.proxyFactory(new HttpProxyFactory(host, port));
};
}
Got the same issue (with Spring Boot 2.6.1 the spring.mongodb.embedded.version property is mandatory).
To configure the proxy, I've added the configuration bean by myself:
#Value("${spring.mongodb.embedded.proxy.domain}")
private String proxyDomain;
#Value("${spring.mongodb.embedded.proxy.port}")
private Integer proxyPort;
#Bean
RuntimeConfig embeddedMongoRuntimeConfig(ObjectProvider<DownloadConfigBuilderCustomizer> downloadConfigBuilderCustomizers) {
Logger logger = LoggerFactory.getLogger(this.getClass().getPackage().getName() + ".EmbeddedMongo");
ProcessOutput processOutput = new ProcessOutput(Processors.logTo(logger, Slf4jLevel.INFO), Processors.logTo(logger, Slf4jLevel.ERROR), Processors.named("[console>]", Processors.logTo(logger, Slf4jLevel.DEBUG)));
return Defaults.runtimeConfigFor(Command.MongoD, logger).processOutput(processOutput).artifactStore(this.getArtifactStore(logger, downloadConfigBuilderCustomizers.orderedStream())).isDaemonProcess(false).build();
}
private ExtractedArtifactStore getArtifactStore(Logger logger, Stream<DownloadConfigBuilderCustomizer> downloadConfigBuilderCustomizers) {
de.flapdoodle.embed.process.config.store.ImmutableDownloadConfig.Builder downloadConfigBuilder = Defaults.downloadConfigFor(Command.MongoD);
downloadConfigBuilder.progressListener(new Slf4jProgressListener(logger));
downloadConfigBuilderCustomizers.forEach((customizer) -> {
customizer.customize(downloadConfigBuilder);
});
DownloadConfig downloadConfig = downloadConfigBuilder
.proxyFactory(new HttpProxyFactory(proxyDomain, proxyPort)) // <--- HERE
.build();
return Defaults.extractedArtifactStoreFor(Command.MongoD).withDownloadConfig(downloadConfig);
}
In my case, I had to add the HTTPS corporate proxy to Intellij Run Configuration.
Https because it was trying to download:
https://downloads.mongodb.org/win32/mongodb-win32-x86_64-4.0.2.zip
application.properties:
spring.data.mongodb.database=test
spring.data.mongodb.port=27017
spring.mongodb.embedded.version=4.0.2
Please keep in mind this is a (DEV) setup.
I'm having real hassle getting a quartz job in an application server to call a REST service - totally puzzled (:
I have quartz (v 2.2.2) deployed & working on an IBM Liberty Application Server (v 8.5.5.8) with Java 1.8
It scans a directory for files and then calls my Dummy Task.
However, when I replace the Dummy Task with a REST WebClient call - I get a pretty odd stacktrace.
java.lang.NullPointerException
[err] at com.ibm.ws.jaxrs20.client.bus.LibertyJAXRSClientBusFactory.getClientScopeBus(LibertyJAXRSClientBusFactory.java:89)
[err] at com.ibm.ws.jaxrs20.client.JAXRSClientImpl.target(JAXRSClientImpl.java:109)
[err] at org.apache.cxf.jaxrs.client.spec.ClientImpl.target(ClientImpl.java:100)
[err] at notification.server.rest.MyIBMHandler.testClient4(MyIBMHandler.java:61)
the last line is mine and the code I wrote is simply based on this: https://www.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_jaxrs2.0_clientconfig.html
When I googled the exception above, I didn't see much except for one stacktrace related one:-
NullPointerException when running CXF JAX-RS 2.0 client "target" method in Liberty Profile under a Thread
Which leads me to believe there may be some form of a threading conflict here.
To prove my REST client code was ok on my Liberty app-server, I did put my REST methodinto a servlet and call it there and it did work fine.
i.e.
public void testClient4() {
javax.ws.rs.client.ClientBuilder cb = ClientBuilder.newBuilder();
javax.ws.rs.client.Client c = cb.build();
String res = null;
try {
String resourceURL = "http://localhost:9080/SampleRest/sample/";
res = c.target(resourceURL).path("Greeting").request().get(String.class);
System.out.println("res:" + res);
} catch (Exception e) {
res = "[Error]:" + e.toString();
System.err.println("error:" + e.getMessage());
e.printStackTrace();
} finally {
if (c != null)
c.close();
System.out.println("res:" + res);
}
}
My Quartz props are close to out of the box, here is the threadpool section:-
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 4
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
My job class uses the annotation - #DisallowConcurrentExecution
I'm using the jersey 2.17 libs & jackson libs
I've added lots of features to my Liberty profile - i.e.
<featureManager>
<feature>jsp-2.3</feature>
<feature>jaxrs-2.0</feature>
<feature>servlet-3.1</feature>
<feature>apiDiscovery-1.0</feature>
<feature>jaxrsClient-2.0</feature>
</featureManager>
For now, the REST service being called is a simple one.
When running quartz within an app-server, do I need to do anyconfig to be able to call a REST service? - anyone got this working?
It appears we fixed this NPE in the latest Liberty fixpack, looking here, the 8.5.5.9 fixpack is planned to be available on March 18. Once released, please test and determine if it fixes this problem, and if not let us know.
We are building a chat client in java and using smack 4.1.3. What I noticed is there is huge change in smack APIs after smack 4.0 and registrations examples available on the internet are not working for smack 4.1.3. I am not getting write APIs to register user. May anybody give sample codes.
Thanks in advance...
This connects ejabberd server with smack 4.1.3.
XMPPTCPConnectionConfiguration config = XMPPTCPConnectionConfiguration.builder()
.setUsernameAndPassword("testuser", "pass")
.setServiceName("example.com")
.setHost("example.com")
.setResource("test")
.setSecurityMode(XMPPTCPConnectionConfiguration.SecurityMode.disabled)
.setPort(5222)
.build();
SASLMechanism mechanism = new SASLDigestMD5Mechanism();
SASLAuthentication.registerSASLMechanism(mechanism);
SASLAuthentication.blacklistSASLMechanism("SCRAM-SHA-1");
SASLAuthentication.unBlacklistSASLMechanism("DIGEST-MD5");
AbstractXMPPConnection con = new XMPPTCPConnection(config);
try {
con.connect();
con.login();
} catch (Exception ex) {
System.out.println(ex.getCause() + " " + ex.getMessage());
Logger.getLogger(redcore.class.getName()).log(Level.SEVERE, null, ex);
}
Do you have any problem or restriction that you are not allowed to user simple REST api's, plugins provided by openfire for registering user's, retrieving, deleting etc.
Refer here for the official docs.
Heroku recently began supporting Java apps. Looking through the docs, it seems to resemble the Java Servlet Standard. Does anyone know of an instance where a GWT app has been successfully deployed on Heroku? If so, are there any limitations?
Yes, I've got a successful deployment using the getting started with Java instructions here:
http://devcenter.heroku.com/articles/java
I use the Maven project with appassembler plugin approach but added gwt-maven-plugin to compile a GWT app during the build.
When you push to heroku you see the GWT compile process running, on one thread only so quite slow but it works fine.
The embedded Jetty instance is configured to serve up static resources at /static from src/main/resources/static and I copy the compiled GWT app to this location during the build and then reference the .nocache.js as normal.
What else do you want to know?
You've got a choice, either build the Javascript representation of your GWT app locally into your Maven project, commit it and the read it from your app, or to generate it inside Heroku via the gwt-maven-plugin as I mentioned.
The code to serve up files from a static location inside your jar via embedded Jetty is something like this inside a Guice ServletModule:
(See my other answer below for a simpler and less Guice-driven way to do this.)
protected void configureServlets() {
bind(DefaultServlet.class).in(Singleton.class);
Map<String, String> initParams = new HashMap<String, String>();
initParams.put("pathInfoOnly", "true");
initParams.put("resourceBase", staticResourceBase());
serve("/static/*").with(DefaultServlet.class, initParams);
}
private String staticResourceBase() {
try {
return WebServletModule.class.getResource("/static").toURI().toString();
}
catch (URISyntaxException e) {
e.printStackTrace();
return "couldn't resolve real path to static/";
}
}
There's a few other tricks to getting embedded Jetty working with guice-servlet, let me know if this isn't enough.
My first answer to this turned out to have problems when GWT tried to read its serialization policy. In the end I went for a simpler approach that was less Guice-based. I had to step through the Jetty code to understand why setBaseResource() was the way to go - it's not immediately obvious from the Javadoc.
Here's my server class - the one with the main() method that you point Heroku at via your app-assembler plugin as per the Heroku docs.
public class MyServer {
public static void main(String[] args) throws Exception {
if (args.length > 0) {
new MyServer().start(Integer.valueOf(args[0]));
}
else {
new MyServer().start(Integer.valueOf(System.getenv("PORT")));
}
}
public void start(int port) throws Exception {
Server server = new Server(port);
ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
context.setBaseResource(createResourceForStatics());
context.setContextPath("/");
context.addEventListener(new AppConfig());
context.addFilter(GuiceFilter.class, "/*", null);
context.addServlet(DefaultServlet.class, "/");
server.setHandler(context);
server.start();
server.join();
}
private Resource createResourceForStatics() throws MalformedURLException, IOException {
String staticDir = getClass().getClassLoader().getResource("static/").toExternalForm();
Resource staticResource = Resource.newResource(staticDir);
return staticResource;
}
}
AppConfig.java is a GuiceServletContextListener.
You then put your static resources under src/main/resources/static/.
In theory, one should be able to run GWT using the embedded versions of Jetty or Tomcat, and bootstrap the server in main as described in the Heroku Java docs.