Tried using DistributedObjectCache for sharing data between clusters in WAS liberty server.
I have configured things based on IBM Distributed Map
I used Method 5 from the link, my server version is 7 and web.xml version is 2.4
After the configurations on my "server.xml" and ibm-web-bnd.xmi, I have used the below code to get the map instance on the application start.
DistributedObjectCache dm1a =(DistributedObjectCache)ic.lookup("java:comp/env/dmap/LayoutCache");
the dm1a is always null
As the servlet cache is used for caching JSP pages. etc, I need to cache java object so I used DistributedObjectCache
I am not sure that the .xmi file is getting read by the server, because I have tested by changing the webapp reference in there which was different from web.xml, but no error was thrown on the server startup
Is there anything i am missing?
Related
We have a java web application which was hosted in tomcat 8. For session Management , we have been using the memcache which maintains non sticky based sessions. This has been working fine without any issues.
Now there is a requirement to upgrade the tomcat from 8 to tomcat 9 and the upgradation with the necessary jars for the tomcat 9 has been done. After the upgradation, we are facing an issue in the application where the session is becoming null. Some of the link in the app associated with the session are working fine and some of them when clicked gets me logged out of the session. Checking the logs, I see the session object null.
The memcached jars used as part of the tomcat 9 and copied under tomcat9/lib
memcache-session-manager-2.3.2
memcache-session-manager-tc9-2.3.2
jettison-1.1.jar
spymemcached-2.12.0
http-core-4.3
http-core-nio-4.3
we are using the 3rd party Serialization for this use case and they are also copied in the tomcat lib folder
kryo-3.0.3.jar
kryo-serializers-0.37.jar
minlog-1.3.0.jar
msm-kryo-serializer-1.9.3.jar
objenesis-2.1.jar
protobuf-java-2.6.1.jar
reflectasm-1.10.1.jar
With these jars , I am able to see the tomcat startup without any issues.
**<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:ip:port"
lockingMode="auto"
sticky="false"
requestUriIgnorePattern= ".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync= "false"
sessionBackupTimeout= "100"
copyCollectionsForSerialization="false"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>**
Followed the below link for setting up the memcache configuration in my application.
https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
Please help me if i am missing anything in the configuration.
Thanks
Pradeep
Have solved this issue by removing the param **requesturiignore pattern ** from the context.xml as this was creating different sessions.
I'm developing a custom application for IBM BPM that uses these libraries: Jace.jar, pe.jar, log4j.jar, stax-api.jar, xlxpScanner.jar and xlxpScannerUtils.jar that are used to call a web service.
When I create a java project and add those libraries, it works fine. It also works ok when I create a dynamic web project using tomcat 8 as server; but when using jboss I don't get the expected result when calling the web service. So, does anybody know how to disable the modules that use these libraries? Or where to find information about it?
I want my application to be server independent.
This is my code:
try {
VWSession vwSession = new VWSession("userName", "userPass", "connPt");
vwSession.isLoggedOn(); /* It's loaded with 'false' value in jboss.
In tomcat it's loaded with 'true' value */
} catch (Exception e) {
Logger.getLogger(getClass().getName()).log(Level.FATAL, "Details: ", e);
}
To create an application that is server agnostic, you need to strictly adhere to Java EE specification. Meaning, use only those jars that are bundled as part of the Java EE version you are using. Then too, there are certain deployment descriptors specific to a given application server that would need to be used in some cases. For example - jboss-deployment-structure.xml, ibm-application-bnd.xml, etc.
In your case, xlxpScanner.jar is not a part of the Java EE spec, so making the application server independent is not possible with the current settings. You could look for a replacement of the part of this jar you are using with something Java EE has. In short, get rid of this jar alongwith xlxpScannerUtils.jar.
Alternatively, if you want jboss to run the application properly, add all the jars in a module and give it to the EAR/WAR using jboss-deployment-structure.xml. Details can be found here.
Let me give a little background to give context to this question. Over the course of time, the application I have been assigned to work on lost the ability to be built and deployed as a full application. By that I mean the previous developer compiled the code in his local IDE, and dropped single class files, as opposed to building out proper JARs and WARs to be deployed out to tomcat. So I have been tasked to clean up the project so it is a standard deployable app again. So to sum up the important part, the application exists in a working format on a windows tomcat environment, that hasn't had a clean deploy in a long time, my goal is to make the app buildable and deployable via a jenkins CI server to a tomcat instance running on a Linux server. Now on to the problem. I get the following toplink exception in one application module.
Local Exception Stack:
Exception [TOPLINK-6007] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.QueryException
Exception Description: Missing descriptor for [class edu.cornell.finsys.datamodel.AccountDTO].
Query: ReadObjectQuery(edu.cornell.finsys.datamodel.AccountDTO)
I have verified that the toplink mapping file has been loaded by tomcat, and the AccountDTO is mapped in the file. To double check that, I have moved the mapping file out, and I get a completly different error at load time. I know the file mapping is correct, as it worked correctly on the old server. I don't know what else could be causing the toplink exception.
For more information, I am on tomcat version 6.0.37, Java version 1.6.0_45, toplink version 9.0.4.031126
Any ideas?
This may be it; right from Metalink:
Cause:
This is an issue with loading the sessions.xml file, once when the application was first deployed using that application's classloader and then not reloading the session when the application was redeployed and a new XMLContext was created. The caused us to attempt to use a session that had been loaded with a different classloader than the current application.
Possible solution:
The issue occurs when TopLink is part of the main classpath (Eg: Applib directory rather than stored in the ear file). When this happens, the static SessionManager has trouble finding descriptors the second and subsequent times an application is deployed. Basically the descriptors are indexed by class. When the application is redeployed, the classes used for the indexing are unloaded and new versions of those classes appear. This causes "Descriptor not found" exceptions.
Potential Workarounds
Put the toplink.jar file in the ear.
Write some code to manually clean up when the toplink application is torn down.
For certain architectures they may be able to use the version sessionManager.getSession() that allows the session to be refreshed.
Workaround 3 is best and very feasible. The session has to be lazily
obtained from the SessionManager and held in an application code
variable. When the application is restarted its handle on the TopLink
session will be null. The session can then be obtained from the
SesssionManager using the getSession(XMLLoader xmlLoader, String
sessionName, ClassLoader objectClassLoader, boolean
shouldLoginSession, boolean shouldRefreshSession) API with
shouldRefreshSession set to true. This will ensure that the old
session (if any) is logged out and removed from the SessionManager
before a new one is created.
Did any of the workarounds help?
When adding / updating a response header after the request has been processed I get the following warning:
com.ibm.ws.webcontainer.srt.SRTServletResponse setHeader SRVE8094W: WARNING: Cannot set header. Response already committed.
I am trying to manipulate the header by calling httpServletResponse.setHeader() or httpServletResponse.addHeader() from within a servlet filter after filterChain.doFilter() or by postHandle code spring interceptor.
I have encountered this problem while running my webapp using spring 3.x on websphere 8.5.
The problem is not reproduced on tomcat 7.0 therefore my guess is that it is Websphere related.
The problem is not reproduced in a pure servlet app therefore my guess is that it is Spring related.
I am familiar with
ShallowEtagHeaderFilter does not work under WAS8 app server
and with
Cannot set header in JSP. Response already committed
but I am looking for a "cleaner" solution.
Can anybody help me on this?
Websphere strictly follows the J2EE standard, hence whatever works in Tomcat need not necessarily work in Websphere. In my project, I got a lot of exception/errors which are particular for Websphere, but works as a charm in Tomcat. I suggest you to set the header in the controller. One other alternate is not to flush the output stream in the controller (if you have done it explicitly).
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml