[Logo] Enterprise Client Community
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Deployment on IBM WebSphere Application Server fails  XML
Forum Index -> Deployment
Author Message
dkment



Joined: 07/05/2015 05:45:41
Messages: 1
Offline

Hi,

the last few days we tried deploying a CC application on IBM WAS 8.5.5.0.
Currently the whole thing fails because we cannot get the owning dispatcher from our dispatcher. This ends up in DefaultDispatcher.getOwner, and always returns null.

Any ideas why this might happen? Did anyone succeed in deploying a CC application in IBM WAS?

Regards,
David
CaptainCasa

Power User
[Avatar]

Joined: 21/11/2007 12:23:06
Messages: 5521
Offline

Hi,

could you append the CC-server-log?
(by default located in the servlet-temp-directory, which is provided by the application server, in Tomcat this tomcat/work - with WAS I do not know where it is; the name of the files is "eclnt_jsfserver.txt.*" with * being a counter.

Thanks! Björn

Björn Müller, CaptainCasa GmbH
msailer

Power User

Joined: 22/06/2015 12:17:44
Messages: 112
Offline

Meine Frage hat sich erledigt.
msailer

Power User

Joined: 22/06/2015 12:17:44
Messages: 112
Offline

Ok now I have a question. I'm trying to get CC work on IBM Websphere 8.5. We have a strange behavior. When starting the RISC client everything works ok so far. The client sends a HTTP GET to /app/jsp.mainframe.risk?... and it it receives a 200 OK with header parameters:

Set-Cookie: jsessionId=0000Y....:-1
Set-Cookie: eclnt-id=ID_XXXX; Expires=Sat, 28-Jul-85 09:37:59 GMT

So it gets a valid session and that session is the same for every subsequent request.

When I do the same with the Java client, which we start with that .jnlp file, I get a lot of forth and back requests but when it comes to the point where the client does a POST /app/faces/jsp/mainframe.jsp the response only has a:

Set-Cookie: jsessionid=0000Y...:-1

When I then try to login the next POST request creates a new session and we're logged out again.

Do you have any idea why this happens? Is there any secret command we need to add to the application to prevent this?

msailer

Power User

Joined: 22/06/2015 12:17:44
Messages: 112
Offline

lol ok I think I just found the secret parameter via try n error:

sendcookies=true
msailer

Power User

Joined: 22/06/2015 12:17:44
Messages: 112
Offline

Another problem occurs now:

When we restart the Websphere application we have an issue in starting the risc client. It seems like there is a strange initialization issue because when we start the Java client 1 time, then the risc client is working. The initial exception on the server is that one:

[7/10/17 10:30:19:992 CEST] 00000142 SystemErr R com.ibm.ws.logging.WsLogger deliverOrBuffer Jul 10, 2017 10:30:19 AM com.ibm.ws.webcontainer.servlet.ServletWrapper service
SEVERE: Uncaught service() exception thrown by servlet RISCStarter: java.lang.Error: java.lang.Error: java.lang.Error: java.lang.NullPointerException
at org.eclnt.jsfserver.util.WebResourceReader.readUTF8FileIntoString(WebResourceReader.java:82)
at org.eclnt.jsfserver.starter.RISCStarter.buildIncludeList(RISCStarter.java:187)
at org.eclnt.jsfserver.starter.RISCStarter.doGet(RISCStarter.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:66
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1227)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:776)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:45
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:17
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at de.nexus.http.filter.SecurityHeaderFilter.doFilter(SecurityHeaderFilter.java:45)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:92
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1025)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:909)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:459)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:526)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:312)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:283)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
Caused by: java.lang.Error: java.lang.Error: java.lang.NullPointerException
at org.eclnt.jsfserver.util.WebResourceReader.readUTF8FileIntoString(WebResourceReader.java:45)
at org.eclnt.jsfserver.util.WebResourceReader.readUTF8FileIntoString(WebResourceReader.java:76)
... 37 more
Caused by: java.lang.Error: java.lang.NullPointerException
at org.eclnt.jsfserver.util.WebResourceReader.readFileIntoByteArray(WebResourceReader.java:132)
at org.eclnt.jsfserver.util.WebResourceReader.readFileIntoByteArray(WebResourceReader.java:93)
at org.eclnt.jsfserver.util.WebResourceReader.readUTF8FileIntoString(WebResourceReader.java:40)
... 38 more

I know there is a debug logging at that code which would tell me the file it tries to load but that logging won't be done. The cc server logfile isn't even created.

Do you have an idea?

Edit: I can confirm that the static ServletContext in WebResourceReader is not yet set when the application is started with RISC. Can that be forced somehow?
 
Forum Index -> Deployment
Go to:   
Powered by JForum 2.1.6 © JForum Team