Is Liferay 7.0 EE compatible with Weblogic 10.3.6? - deployment

I am trying to deploy Liferay 7 locally on my Weblogic server, but receiving Forbidden 403 error when accessing URL at http://localhost:7004/liferay_7
Error 403--Forbidden
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
I have tried Liferay 6.1 CE on my weblogic server by following the guide below, and everything worked fine.
https://dev.liferay.com/discover/portal/-/knowledge_base/6-1/installing-liferay-on-oracle-weblogic-10-3?notice=1
But I could only find a guide on Liferay 7 with weblogic 12c in which the instructions are very different. I suspect it is a configuration issue, but I'm at the end of my wits to figure out what is exactly wrong.
I appreciate all your suggestions. Thank you in advance.

According to the Compatibility Matrix, Liferay DXP (there is no 7 EE) is limited to Weblogic 12 indeed. This is a good assumption for Liferay 7 CE as well.

Related

WSO2 IWA with Kerberos – unable to decrypt kerberos token exception

We are using WSO2 5.4.1 version and trying to setup IWA using Kerberos. We have done all the configurations as mentioned in the following post.
https://medium.com/#farasath/integrated-windows-authentication-with-kerberos-and-wso2-identity-server-ffcd8263a0f1
When we try to access the application we are getting following exception.
We have checked all the configurations multiple times but not able to figure out the root cause. Can someone help us to find out what could be missing in this setup? Are we missing any additional step?
We have also tried with WSO2 IS version 5.5.0 but still getting same error.
How can we enable additional logging to see what is going wrong with kerberos token decryption?
It was indeed a JDK issue. For some reason we were using Oracle jdk1.8.0_45 and we were facing this issue. We had upgraded the version to jdk1.8.0_162 and we were able to proceed but then we encounter another problem. After authentication we were not getting remote claims in the response from WSO2 IS. As per this post (stackoverflow.com/questions/49997900/…) we upgraded to latest patch of WSO2 IS 5.5.0 and now it is working.
We are able to authenticate user using IWA-Kerberose.

My REST API calls to Salesforce work through RunScope (an API debugging site) but not directly to Salesforce

So right now I'm trying to make a bunch of REST API calls to Salesforce from my WebSphere server, but every time I make a request, I get a "500 Server Error" error message in my logs. I then tried to run my API calls through RunScope to try and debug what was going wrong. As soon as I sent my API calls through RunScope to Salesforce, the 500 Error went away and everything worked. I instantly thought it was some kind of SSL Protocol issue since Salesforce apparently doesn't support SSL3.0. So I checked my WebSphere configuration and noticed that it supports both SSL and TLS protocols (I'm not 100% sure which protocol it's using though, if anyone knows of a way to test that, that would be helpful). Now I'm pretty stumped. I know it's not a certificate issue because i installed the needed certificates on my WebSphere server. Anyone else have any ideas why the API calls work through RunScope to Salesforce but not directly to Salesforce? Any help is appreciated.
I figured it out. My issue was that my WebSphere server was running TLS1.0 which isn't supported anymore by Salesforce. If you're running into the same issues as me, make sure your server is running TLS 1.1 or higher.

Liberty App runs fine on local machine and throws 415 Unsupported Media Type on Bluemix

I am developing an app with JAX-RS. The app is running fine on my local Liberty 8.5 Server. It fails when I package and push the server to bluemix. When I try to access my method I get the error:
"NetworkError: 415 Unsupported Media Type"
The system cannot find any method in the class that consumes null media type.
My web.xml looks like the following:
<!-- Enable features -->
<featureManager>
<feature>jsp-2.2</feature>
<feature>localConnector-1.0</feature>
<feature>jdbc-4.0</feature>
<feature>cdi-1.0</feature>
<feature>json-1.0</feature>
<feature>jaxrs-1.1</feature>
<feature>jpa-2.0</feature>
</featureManager>
I searched a lot. Somebody had the same question said it's problem about jaxrs-1.1 which should be updated to jaxrs-2.0, but I don't know how to update it. It's default in Liberty 8.5 Server.
Can anybody help me? It's the first time I ask in stackover
Sorry, I'm not good at English.
Somebody had the same question said it's problem about jaxrs-1.1 which should be updated to jaxrs-2.0, but I don't know how to update it. It's default in Liberty 8.5 Server.
I hope this will be useful for you.
Using JAX-RS 2 Client API in Liberty and Bluemix
Removing JAX-RS feature from Websphere Application Server 8.5

Websphere 8.5 JAX-WS WSDL redirect

I got a SOAP web service with code first approach running with the built in JAX-WS implementation in Websphere 6.1.
The service was migrated from Websphere version 6.1 to version 8.5.
Formerly (version 6.1) the WSDL was available directly at the URL
[...]/services/SomeService?wsdl
Since migrating to version 8.5 the WSDL is still available via aforesaid URL, but a redirect is being made to
[...]/services/Services_002f_SomeService.wsdl
A client needs to access the WSDL before each request that is being made to the web service and is not getting on with the redirect (i.e. with the [...]?wsdl-URL), so he needs the redirected URL. (This is something I'm having no bearing on, unfortunately... )
Problem is that the '002f' part in the redirected URL is dynamic and might be changed by Websphere. (It did already in our testing environment.)
Does anybody know an option that prevents Websphere from the aforementioned redirect?
I finally found the reason for the weird '002f' characters in the redirect URL.
It is due to the given serviceName services/SomeService
#WebService (targetNamespace="http://example.net/", serviceName="services/SomeService")
\u002f is the '/' character in UTF8
So redirect goes to [...]/services/SomeService/Services_002fSomeService.wsdl and is reasonable.
The info of a possibly changing redirect URL to ...003f..., ...004f..., etc. which I got is obviously wrong.
Though not redirecting would not have caused any troubles at all and I don't know why the new JAX-WS implementation in WAS 8.5 really has to do that, I' coming to terms with just giving the (as I know know) static '002f' WSDL URL to the client.

Server sent unexpected return value (502 Bad Gateway) in response to COPY request

I'm using Spring Tool Suite 3.1.0 with the latest Subclipse installed over it.
Committing and updating worked just fine, until I received the following message while trying to commit:
Server sent unexpected return value (502 Bad Gateway) in response to COPY request for 'some filename'
The url of my repository is: https://megiforge.pl/svn/zpi2012
Now I tried to google the answer to my problem, but all the solutions seem to mention changing Apache server configuration, and I can't wrap my head around finding the corresponding files in Subclipse config.
The only thing that could cause this was me moving a file from one folder to another, because that's the only difference between this and my previous commits. Ideas?
If the solution is to fix your Apache server configuration, and all of the archived discussion on this problem says that it is, then there is nothing you can do in your client configuration. This is a change that needs to be made on the server. It sounds like it happens when the server has a reverse proxy or SSL accelerator configured in front of the Apache server.
One example here: http://svn.haxx.se/users/archive-2006-03/0549.shtml