I am migrating my java enterprise application from WAS8.5 full profile
to liberty server. My application code has soap client and required
stubs generated from WSDL. I am able to receive response when using
WAS8.5 but getting below exceptions while running liberty server.
I have already added jaxws-2.2 .
Recreated the stubs again pointing to liberty server, IBM-WS from eclipse. I
couldn't find relevant answers online.
Console logs
[WARNING ] Could not unwrap Operation {http://services.abc.com/gb/getsomepoint/v1}getSomeInfoByParam to match method "public abstract void com.abc.services.gb.getsomepoint.v1.GBGetSomePointV1.getSomeInfoByParam(javax.xml.ws.Holder,java.lang.String,java.lang.String,javax.xml.ws.Holder,javax.xml.ws.Holder)"
javax.xml.ws.soap.SOAPFaultException: BIP3113E: Exception detected in message flow GB_GetSomePoint_V1.SOAP Input (integration node NMD4BRK)
[err] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156)
[err] at [internal classes]
[err] ... 51 more
[err] Caused by:
[err] org.apache.cxf.binding.soap.SoapFault: BIP3113E: Exception detected in message flow GB_GetSomePoint_V1.SOAP Input (integration node NMD9BRK)
[err] at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84)
[err] at [internal classes]
[err] ... 53 more
There isn't much information to go on from the console but one thing to check is if the request/response messages to and from the client look the same on Liberty as they do on WAS 8.5. That'd be a simple way to verify if the expected behavior is the same. Another thing to consider is if your WSDL contract matches the request generated by the client (i.e. all the bindings are there).
The Web Services configuration (WS-Policy/WS-Security) can be substantially different on Liberty vs WAS 8.5 and this Knowledge Center document has some good info on how to properly configure your app if you need it.
Deploying JAX-WS applications to Liberty:
https://www.ibm.com/support/knowledgecenter/SSD28V_9.0.0/com.ibm.websphere.wlp.core.doc/ae/twlp_dep_jaxws.html
The last thing I’d suggest is turning on Liberty’s Web Services trace. There isn’t a lot of info about root cause from the console messages, but by turning on the trace the specific problem might make itself known. You can turn trace on by following these directions.
Enabling trace on WebSphere Liberty:
https://www.ibm.com/support/knowledgecenter/SSD28V_9.0.0/com.ibm.websphere.wlp.core.doc/ae/rwlp_logging.html
The specific trace specification you’ll want to enable for Web Services is as follows:
traceSpecification="*=audit:com.ibm.ws.jaxws.*=finest:org.apache.cxf.*=finest”
If it works after commenting out jaxws-2.2 feature, you must be using a different jax-ws implementation packaged with your application. You can try adding back the jaxws-2.2 feature and set this JVM property for liberty server: -Dcom.ibm.xml.xlxp.jaxb.opti.level=0
Related
We have the following scenario:
Current working setup
Web API project using a single DockerFile
A release pipe line with an 'Azure App Service deploy' task.
Proposed new setup
Web API project using multi container Docker Compose file
A release pipe line with an 'Azure Web App for Containers' task.
Upon deploying the new setup we receive the below error message:
ERROR - multi-container unit was not started successfully
Unhandled exception. System.AggregateException: One or more errors occurred.
(Parameters: Connection String: XXX, Resource: https://vault.azure.net, Authority:
https://login.windows.net/xxxxx. Exception Message:
Tried to get token using Managed Service Identity.
Access token could not be acquired. Connection refused)
The exception thrown is because it can't connect to Azure MSI (Managed Service Identity). It does this to obtain a token before connecting to key vault.
I have tried the following based upon some research and solutions others have found:
Connecting with "RunAs=App" (this seems to be the default parameter-less constructor anyway)
Building up the connection string myself manually by pulling the "MSI_SECRET" environment variable from the machine. This is always blank.
Restarting MSI.
Upgrading and downgrading AppAuthentication package
MSI appears to be configured correctly as it works perfectly with our current working setup so we can rule that out.
It's worth noting that this is System assigned identity not a user assigned one.
The documentation that states which services support managed identites only mentions 'Azure Container Instances' not 'Azure Managed Container Instances' and that is for Linux/Preview too so that it could be not supported.
Services that support managed identities for Azure resources
We've spent a considerable amount of time getting to this point with the configuration and deployment and it would be great if we could resolve this last issue.
Any help appreciated.
Unfortunately, there currently is no multi-container support for managed identities. The multi-container feature is in preview and so does not have all its functionality working yet.
However, the documentation you linked to is also not as clear about the supported scenarios, so I am working on getting this documentation updated to better clarify this. I can update this answer once that's done.
I am running apache beam java pipeline and for some reason getting lots of warning logs in GCP.
I tried changing log level of packages java.net,sun.rmi to SEVERE but still no success.
Logs are getting polluted with these warning messages. Any one else facing the same issue ?
jsonPayload: {
exception: "java.net.SocketTimeoutException: Accept timed out
at java.base/java.net.PlainSocketImpl.socketAccept(Native Method)
at java.base/java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:458)
at java.base/java.net.ServerSocket.implAccept(ServerSocket.java:551)
at java.base/java.net.ServerSocket.accept(ServerSocket.java:519)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:394)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:366)
at java.base/java.lang.Thread.run(Thread.java:834)
"
logger: "sun.rmi.transport.tcp"
message: "RMI TCP Accept-5555: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=5555] throws"
Pipeline is simple : Pubsub to Postgres. No additional third party connectivity.
Please refer to public documentation about troubleshooting.
Select the job to view more detailed information on errors and run results. When you select a job, you can view the execution graph as well as some information about the job. Then, click the Logs button to view log messages generated by your pipeline code and the Dataflow service.
Another thing, that you can use is debug option. When running the gcloud command, you can include the option --verbosity=debug to get debugging output.
This might be related to a JVM bug. Please check Java SDK version snd upgrade to a newer (2.17.0 or higher) version.
Additionally, check Encoding errors, IOExceptions, or unexpected behavior in user code error.
I hope you find the above pieces of information useful.
I couldn't figure out the actual issue but in the mean time since it was polluting the logs traces added flag in pipeline options:
--workerLogLevelOverrides={"sun.rmi.transport.tcp":"OFF"}
I'm trying to get most basic example for Spring Cloud Dataflow running on CloudFoundry.
I've followed the steps here: http://docs.spring.io/spring-cloud-dataflow-admin-cloudfoundry/docs/current-SNAPSHOT/reference/htmlsingle/#getting-started to make the admin app available in my org/space.
Then I tried to create the most basic example from http://cloud.spring.io/spring-cloud-dataflow/, namely to create the "ticktock" stream:
dataflow:>stream create ticktock --definition "time | log" --deploy
I can see that both apps ticktock-time and ticktock-log are created in the space, the needed service "redis" is bound to these apps and they try to start. Unfortunately they don't start completely, because they have problem to access "redis" service. In the log we find:
Exception encountered during context initialization - cancelling
refresh attempt:
org.springframework.context.ApplicationContextException: Failed to
start bean 'outputBindingLifecycle'; nested exception is
org.springframework.context.ApplicationContextException: Failed to
start bean 'inputBindingLifecycle'; nested exception is
org.springframework.data.redis.RedisConnectionFailureException: Cannot
get Jedis connection; nested exception is
redis.clients.jedis.exceptions.JedisConnectionException: Could not get
a resource from the pool
which eventually is caused by
Caused by: redis.clients.jedis.exceptions.JedisConnectionException:
java.net.ConnectException: Connection refused
Am I missing some configuration step in between?
Alexander
There seems to be an issue with our deployer using the master branch of the Java buildpack. Try these settings for the Dataflow Server:
cf set-env s-c-dataflow-server CLOUDFOUNDRY_BUILDPACK https://github.com/cloudfoundry/java-buildpack.git#v3.6
cf restage s-c-dataflow-server
Also, be aware that we currently launch apps using "streamname-module" as part of the URL so unless you use unique stream names you might collide with other users and get a "400 Bad Request" error.
I'm trying to deploy my Grails application to AppFog using CloudFoundry plugin (ver. 1.1) in Spring Source Suites (STS 2.9.2).
I'm using https://api.appfog.com as server address and MYAPPNAME.aws.af.cm for application address when deploying app.
Application is pushed and started, services are bounded but, after that, I recive error saying that:
Communication with server failed: I/O error: Server returned HTTP response code: 405 for URL: https://api.appfog.com/apps/MYAPPNAME/application
Also, when I try to create Caldecott tunnel toward database I recive response "The URIs: caldecott-85393a.appfog.com have already been taken or reserved. (404 Not Found)" which I also saw when (by mistake) treid to deploy application to MYAPPNAME.api.appfog.com (default AF name instead of particular infrastructure adress).
I suppose that CloudFoundry plugin uses default server address to reach application and also trying to create Caldecott tunnel on default server address (caldecott-85393a.appfog.com instead of caldecott-85393a.aws.af.cm)
Does anybody have idea how to circumvent this situation?
BR
Zoran
this doesn't sound like an issue with the plugin itself but the response coming back from AppFog's cloud. I would take this up as an issue with them and clarify you can use that plugin with their cloud.
AppFog had issues recently with their Java deployments that was specifically affecting Grails apps. This has been resolved and should be working seamlessly as expected now. You can always reach out for more information in the active google group as well: https://groups.google.com/forum/#!forum/appfog-users
This works locally. Set up: Grails 2.0.3. Debain Linux. I've deployed other applications successfully to Cloud Foundry.
Apparently this thing can happen as a consequence of the Spring Security Plugin not being happy with the resources plugin. Removing the resources plugin doesn't cure this.
This is the problem:
Class: java.lang.IllegalStateException
Message: No thread-bound request found: Are you referring to request attributes outside of
an actual web request, or processing a request outside of the originally receiving thread?
If you are actually operating within a web request and still receive this message, your
code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current request.
Adding the org.springframework.web.context.request.RequestContextListener and its loader to web.xml and importing them into the page doesn't help either.
There is much about this on the web, but in my case it only happens on Cloud Foundry.
Cloud Foundry runs on Java 1.6, like my machine. The logs say the same as the quote above, with stack traces identical to what I've found on the web.
Any ideas? I'm stuck. I've spent the best of two days on this.
Thanks.
Adding compile ":webxml:1.4.1" to the plugins section of BuildConfig.groovy should fix that. Credit to http://support.cloudfoundry.com/entries/21371626-grails-mongodb-deployment-fails