We are having a REST API inside weblogic that internally connects to Corba Server. API response object comes with '0X00' in Datatypes java.lang.String and java.lang.String.Character. Remaining all datatypes are fine with correct data.
This is happening only in Weblogic 12C. Tomcat and Standalone Java class working fine as expected
Some thing related to Weblogic that client delegates not able to convert "String and Character" datatype.
Weblogic Version - 12.2.1.4
JDK version - JDk 1.8_251
We have found the root cause. Its because of "Corba delegate implementation". Need to explicitly specify JDK specific corba implementation class in corba init.
System.getProperties().put("org.omg.CORBA.ORBClass", "com.sun.corba.se.impl.orb.ORBImpl");
Otherwise Vendor specific delegates. In our case weblogic specific delegates(JDK 8) are implemented and is conflicting with server JDK 11 response.
Related
We have a java client (mule app) which is using hornetq client (v2.3.25.SP20) for connecting to the HornetQ remote server via the JNDI naming server (port 1099).
The connection is secured with SSL. The driver is requiring the javax.net.ssl.trustStore property to be set explicitly. Otherwise, it does not find the trust store.
We would like to specify a custom truststore for the session.
But setting a global property javax.net.ssl.trustStore may affect other applications. So, we are looking for the alternative.
I've coded a custom trust manager (X509TrustManager) which points to the custom truststore. But the issue is that it's used only for establishing connectivity with the JNDI server. Then, the actual connection object is taking the trust store location from the remote server (in case, of course, if javax.net.ssl.trustStore is not set).
The error HQ212007 is produced:
connector.create or connectorFactory.createConnector should never
throw an exception, implementation is badly behaved, but we will deal
with it anyway.
Unable to create NettyConnector for myserver:4447
Failed to find a store at remote server keystore location
Googling the error code, I've found very similar issue described with not solution provided here.
So, is there another way of specifying a path to a truststore for hornetq client when connectivng via JNDI, so, that it would not affect other applications running on the same VM system? Or, may be there is a way to disable the SSL certificate validation on the client side completely - this would work for us as well?
There are HornetQ-specific system properties to set SSL configuration parameters. Check out the documentation for HornetQ 2.4.0.
These properties were added after 2.3.0.Final but backported to the 2.3.x branch which is why they're available in 2.3.25.SP20 but aren't documented in the 2.3.0.Final docs.
In short, you can use these system properties instead of the global ones:
org.hornetq.ssl.keyStore
org.hornetq.ssl.keyStorePassword
org.hornetq.ssl.trustStore
org.hornetq.ssl.trustStorePassword
I am using IBM MobileFirst Platform Foundation 8.0.0. I have a Java Adapter that is deployed on the mobilefirst server that is calling an external service. After creating a resource on the external system, I return the created id on “location” response header. It gives me the complete url of the created resource of the external system like http://example.com:1234/resource_name/1234
I don’t want to expose the external system’s url to the caller / client of my adapter. I want to return something like this - http://mobilefirstserver.com:6789/mfp/api/adapters/MyAdapter/resource_name/1234
where "mobilefirstserver" is the server on which MyAdapter is running. I am unable to find any method from mfp libraries where it can retrieve “mobilefirstserver” and “6789”. I can retrieve the adapter’s target URI, which is “example” and “1234” from adapter.xml, but not the host and port details of the mobilefirst server.
Some options:
Use the configuration API to obtain it: ConfigurationAPI.getServerJNDIProperty("mfpadmin/mfp.admin.authorization.server.url") - this will be something like this: http://localhost:9080/mfp/api. You will need to extract the host and port from it.
You could use, on the client-side, the WL.App.getServerUrl API and use it as a parameter in your call to the adapter. But that little sense for your scenario (although I didn't fully 'get' what is the scenario).
Since the server is yours, you can simply hard-code these values in your adapter implementation.
Having trouble with chrome v 4x.xx and WebLogic not automatically handshaking via tls 1.0 minimum. While calling a RESTful service from JavaScript front end I keep getting net::ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION since Google have dropped support for SSL V3.0. I have tried adding the flag forcing this to JAVA_OPTIONS and on another occasion to the starting arguments for WebLogic, despite knowing these only become suported in 10.3.6. Is there another way?
So it turns out WebLogic 10.3.2.0 has a bug in it. When the client makes contact with the server for the first time it tells the server which SSL/TLS certificate version it supports - UP TO. The latest Chrome I believe supports TLS v1.2, so this is the only information sent to WebLogic. WebLogic has problems recognising that 1.2 is greater than 1.0, (which is the highest version available on WebLogic 10.3.2.0 (AFAIK, it is on ours) and should therefore be trusted, so terminates the connection.
source - https://productforums.google.com/forum/#!topic/chrome/iwX2PbNGk8E
I have implemented a Push Notification adpater and would like backend system to call the procedure in order to submit notification.
With reference to this post, http://server:port/dev/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used but it works in development environment only.
At the end of the post it is mentioned that http://server:port/context/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used to invoke the adapter.
(1) May I know whether it is supported in production environment only? Because it returned HTTP method GET is not supported by this URL in development environment.
(2) Noted that we might need to define securityTest="wl_unprotected" for the adapter and thus the adapter is not protected. What will be the best way to achieve the goal for backend sytem to call the adapter with security control?
In Worklight 5, Worklight Studio uses Jetty within and the usage of a context root is not required. Only once moving your project to an application server such as Tomcat, WebSphere, Liberty, you have to specify it (in worklight.properties and application-descriptor.xml).
So,
in development - no.
in production - yes.
In Worklight 6 where Jetty has been replaced with Liberty, context root is now part of your project whether you are in development or production.
You will have to add the "wl_unprotected" securityTest to your procedure in the adapter XML.
As for protecting the requests, my guess is that your IT department can isolate and protect specific URLs and not allow using them in certain scenarios. You already have the URL structure for them to use.
I have seen some questions about dynamic adapter configuration at run-time
how to pass domain,port number,username and password from user input to worklight http adapter
With a Worklight Adapter can I change the domain and port for a procedure at runtime?
but my question is about adapter configuration after deploy on WL server 5.0.6 from external - not at runtime from code.
Our scenario is that in our enterprise development and testing process requires the QA and Testing team to change the destination host and port for the adapters from mockup-backend to testing-backend to production-backend regularly during testing.
of course, this should happen through configuration and not re-compile and re-deploy.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6?
Can this be changed in the WL database tables?
Can this be changed in the WL server filesystem somewhere?
since we did not find any solution to that yet, the developer team is already thinking about using the Adapter only as dumb facade and implement all connection to the backend-services in Adapter-side Java using the Java URL and Connection classes.
Then it would be easy to read a configuration file from the file system in Java to change the backend destination URL and ports in this file.
It would even be easy to read the URL and port from a property in the worklight.properties file in JavaScript and pass it to Java to connect.
I would like to avoid having developing all backend connection code in Java. I would rather see the project use the actual Adapter connectivity features, but I am also not sure how to convince the team since it is quite easy with just 4 lines of code in Java. The advantage of using the Adapter connectivity that can not be configured is hard to see over a own Java implementation in Adapter-Java code.
Thank you.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6? Can this be changed in the WL database tables? Can this be changed in the WL server filesystem somewhere?
In Worklight 5.0.6, as written in the questions you've linked to in the question, an adapter's connectivity settings cannot be altered. They are stored in the packaged adapter and cannot be read from anywhere else during runtime nor after deployment.