Problem in converting an application from BMT to CMT - ejb-3.0

I have an application which is using weblogic server 10.3 and ejb 3.0 and also Toplink for ORM. Currently the transactions are using UnitOfWork.commit() for committing a particular action stated in the EJB remote component interface such as createXX(),deleteXX(),etc.
Now when I am trying to comment the uow.commit(); in my code, and declaritively change the ejb-jar.xml so that the particular EJB module in question has Container and I have used #TransactionAttribute(value=REQUIRES_NEW) for my createXX() method, ideally the container should auto commit as part of the CMT.But it is not committing. There is no error, and just for info, I the checkbox in the weblogic server console remains unchecked for "Support Global Transactions".
Please help me with this as the prompt says record created successfully (as per my business msg), but while checking in the logs actual commit is not happening after the uow.uow.registerNewObject(EntityObject); is executed.

Ensure you have integrated TopLink with WebLogic JTA, (have set the server platform to weblogic, have set a weblogic jta data-source).
You also should be using Session.getActiveUnitOfWork() or acquireUnitOfWork(), and should not call uow.commit().

Related

LinkageError on WebSphere 9 for javax.transaction.* classes

I have a web application that used to run fine on many web servers (tomcat, jboss, weblogic and websphere). Now, however, it has an error when deploying on WebSphere 9.
The app contains the jar javax.transaction-api-1.2. Some of its classes, e.g., javax.transaction.xa.XAResource, are also included in Java SE, but not all of them. Some are specific to Java EE and are required by some 3rd-party libraries in my app. The app is always deploying with child-first (parent-last) classloader.
WebSphere 9 throws this error during startup when the app tries to load the Oracle JDBC driver:
java.lang.LinkageError: loading constraint violation: loader "com/ibm/ws/classloader/CompoundClassLoader#7157be44" previously initiated loading for a different type with name
"javax/transaction/xa/XAResource" defined by loader "com/ibm/oti/vm/BootstrapClassLoader#422c7b1b"
Note that we aren't actually using XA transactions in the app, we are using regular transactions.
On other servers, and previous versions of WebSphere, it was never a problem. The server didn't care that we load XAResource from inside the war, even if it was previously loaded somewhere in the server. Now WebSphere 9 is different, it says that the app classloader already loaded this class from the server, but I don't know why or when did this happen.
Any idea how to solve this?
Remove the transaction API from your application. JTA 1.2 is already included in the server and provides no value in your applications. It's always risky to bring Java EE/SE APIs in a parent-last class loader unless you are 100% certain that they are technically necessary, because they can lead to issues like this one.
I can't say how this worked in previous server versions (there have been some Java-level changes in enforcing linkage issues like this), but the solution is reasonably straightforward.
At the end we did two things to solve this problem.
1) We upgraded the jta jar to version 1.3 (link here). This jar solves the problem by avoiding duplicate classes - it contains only J2EE classes and omits the J2SE classes that are already included in the JVM.
2) We upgraded WebSphere server from 9.0.0.7 to 9.0.0.11.
At the time, I suspected just upgrading the jar should suffice, but our QA had some issues with it and they also upgraded the server. Due to lack of time, we didn't investigate it further and just decided to do both.

evaluating JBPM version 6.2 and problems

I am new to JBPM (evaluating version 6.2), I already worked almost 4 year in activiti bpm, Can someone explain me following things
I already created a process and domain entity with kie workbench and deployed it into my application (tested both way with copy past kjar and integrate with maven repo), my application and kie workbench is pointing to same database and currently deployed to same tomcat, is it correct?
I have already been able to start the process from kie workbench as well as from my application, but the process which I deployed/started from my own application is visible in kie workbench and vice versa,but i am unable to take any action like completing the task from kie workbench, what could be the possible reason ? (possible session related issue)
what will happened if i update already running process and deployed the update version (off course i have to set -Dorg.kie.override.deploy.enabled=true, and same olde version), what will be the impact on already running process? I am getting following error with my demo app
"Unexpected error encountered : java.lang.RuntimeException:Could not find process demoWorkflow.shipmentProcess when restoring process instance 1"
what will happened if i have more then one instance of my application (cluster) pointing to same JBPM database, and what kind strategy should I used to deploy the updated process on all instances with kie workbench. We don't want to restart our servers.
if I modify the module (update the bpmn as well as data model) and deploy it again, what will be the impact on existing process.
kie guvnor is replaced kie-scanner, its mean that every time we are changing the drool rules we have to rely on kie-scanner to update the rule inside my process.
Thanks in advance.

How to specify JDBC setting in a struts project?

I am trying to setup a struts project locally. One way I know to set up JDBC settings as to go to administrative console of websphere and create JDBC provider and JNDI and all. But is there any other way to do in the code itself?
There is some resource reference in web.xml. I am totally new to struts.Please help.
DataSourceAlias
javaxsql.Data...... etc etc
If you configured for WAS 6.1and configuration is good you need to stop and start nodeAgents for the changes to get propagated and test the jdbc connection after restarting.....if it was WAS 8 they will be propagated automatically that means you configured improperly

glassfish 3.1.2 monitoring EJB container, bean-methods

the glassfish application server provides a nice monitoring REST interface.
To use it u can enable several monitorable items in the admin console, for example the EJB container. The documentation says, you can retreive EJB-statistics for every deployed application.
If you request a URL like localhost:4848/monitoring/domain1/server/applications/APPNAME/EJBNAME you will get statistics for a given EJB of the application.
Further, there is a possibility to look more deeply into each bean-method of the ejb, for example the executiontime, about which the documentation says:
"Time, in milliseconds, spent executing the method for the last successful/unsuccessful attempt to run the operation. This is collected for stateless and stateful session beans and entity beans if monitoring is enabled on the EJB container."
The problem now is, monitoring is enabled on the EJB-container (Level set to HIGH), but nothing is sampled in any bean-method in any EJB in any deployed application.
Is there something special to do in the bean and/or the glassfish ?
Thanks in advance for help,
Chris
EDIT:
Ok, I noticed something more about that behaviour:
In the server log you get a log message for each deployed EJB like that:
INFO: EJB5181:Portable JNDI names for EJB DataFetcher // ...
If I set the ejb-container monitoring level to HIGH (which is what I want to do), I get the following warning for each deployed EJB, regardless which app I deploy:
WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later
I googled the warning but none of the resulst really help me enabling EJB monitoring...
This seems to be a Bug in Glassfish.
EJB Monitoring is currently not working in 3.1.2.
JIRA issue is already raised: http://java.net/jira/browse/GLASSFISH-19677
There is nothing "special" to do.
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html
For me it seems as if you probably enabled the monitoring option on the wrong configuration. Please double check.
To get rid of this message you can disable the monitoring on ejb container option below in the image
From Monitor Data--->Configure monitoring--->make ejb container log off

WebLogic 10.5.3 + Seam 2.2.1: Application does not start

we have a WAR packaged web application which works on a development machine. It consists of Java EE 5 + Seam 2.2.1 + Hibernate 3.3.1. It uses an Oracle 10g XE database and runs on the latest Tomcat 6 using JDK 1.6.0_24. The system is a 64bit Windows 7 Pro and uses Firefox 6.
Now, we tried to migrate the application to Oracle WebLogic 10.3.5. We followed the Seam manual for specifying the datasource, deploying the JSF lib and configuring the necessary xml-Files. In parallel to that, we verified that a newly seam-gen generated application using the same datasource and having the xml files configured as stated works fine.
But if we try our own application on WebLogic, allthough the deployment works fine, when trying to open the web application in the browser, it shows that endless redirection occured. We don't see any stacktrace or log error, even when configuring log4j in WebLogic. When analyzing the request with Firebug, we see the get request to "login.seam" and then 20 times a get request for "error.seam" (or "debug.seam when setting debug mode) with the response "302 Moved Temporarily".
I worked on that all week now, trying to compare all configurations and couldn't solve it - so I hope to get any ideas what could cause that problem and how to solve it!
I could pin down the problem to starting a transaction on the JTA persistence context.
I still don't understand why I didn't see any log message or stacktrace and why this also happens on the debug/error page (that's why the endless redirect occured).
I ended up using RESOURCE_LOCAL so far, but I'm not sure if this is the right thing to do.
The alternative is disabling the seam transaction setting, but then it didn't work together with the development build which still runs on Tomcat.

Resources