Is there any additional configuration that needs to be done in order to enable CDI JTA Transactions using #Transactional annotation under CDI beans with Weblogic 12.1.3 server?
I have tried to just add the annotation into a service method, but EntityManager didn't recognize to be running under a transaction.
Is there any interceptor or something else that needs to be registered?
#JoshAment is right.
WebLogic 12.1.3 only partially supports Java EE 7 (it supports its four pieces: JPA 2.1, JAX-RS 2.0, JSON-P 1.0, WebSockets 1.0). But #Transactional is a part of JTA 1.2.
Right now only Liberty Profile is fully certified against Java EE 7.
The planned year-end WebLogic 12.1.4 is going to support it also.
Anyway, answering your question: just configured persistence.xml should be enough to use the #javax.transaction.Transactional annotation in your code.
// You may also consider to move away from Java EE 7 ;) then you would be able to freely choose whatever lib you want. I strongly believe that server itself should not provide anything except servlets.
Related
I want to use scheduling in jboss7 (and in wildfly) but I don't want to use any EJB. I know the EJB #Schedule can be used but I have a web application and the same WAR should be used in Tomcat too so EJB is out of the question.
What can I use for scheduling?
Thanks,
V.
I'm trying to deploy a Mule application which uses Hazelcast to cache the result of some methods that are frequently used. However, while deploying the application I got the following error:
java.lang.ClassCastException: Cannot cast com.hazelcast.client.txn.ClientTxnPortableHook to com.hazelcast.nio.serialization.PortableHook
at java.lang.Class.cast(Class.java:3176) ~[?:1.7.0_79]
at com.hazelcast.util.ServiceLoader$1.next(ServiceLoader.java:97) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.load(PortableHookLoader.java:48) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.(PortableHookLoader.java:41) ~[hazelcast-3.1.6.jar:3.1.6]
I've tried to use the loader override function by placing the next setting in mule-deploy.properties:
loader.override=-com.hazelcast
The Mule application uses Hazelcast 3.5, and Mule 3.6.2 EE uses Hazelcast 3.1.6. Can you tell me a possible solution?
I have reviewed the link provided by Enrique (ClassCastException when casting to the same class) and it was useful because there were two different classpaths, but there were other aspects to be considered in the solution of the problem:
The Hazelcast versions were different. The Mule application used Hazelcast 3.5, and Mule 3.6.2 EE used Hazelcast 3.1.6.
There was not log configuration for Hazelcast in the mule server.
Because I really need to use the Hazelcast 3.5, it was not a choice to downgrade the Hazelcast to 3.1.6. So, I had to replace the version of the Hazelcast in the mule server to 3.5 and remove this library from the Mule application. And then I had to made a lot of tests to discard possible incompatibility issues. The tests were successful.
For the log configuration for Hazelcast in the mule server, I had to add the next JVM parameter to the mule server wrapper:
wrapper.java.additional.44=-Dhazelcast.logging.type=log4j
I used "log4j" because I was using Log4j2. You can see more information about this configuration in the next link:
http://docs.hazelcast.org/docs/3.5/manual/html/logging.html
I need to port a JPA application which uses Hibernate as JPA Provider to Oracle WLS which uses EclipseLink JPA provider. As for the Hibernate, I needed some special configuration in persistence.xml to activate the second level cache. Is it activated by default with Eclipse Link ? I've found some outdated (2009) resources on the net which confirms it's on by default. Can anybody confirm it ?
Thanks
Yes, it is on by default. See
http://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching
For details
I am using OSGI with Glassfish 3.0.1.We use Jersey REST as the resource layer. We have lots of osgi services. we are planning to decouple them & deploy it in a cloud. One way we do this is by doing a http REST call. But we would like to do service to service call at the api level. One way to do this is by using DOSGI. But Glassfish 3.0.1 doesn't seem to support DOSGI. Any other suggestions?
I believe that Glassfish contains Apache Felix, which is a fully compliant OSGi Framework. Therefore you do not need explicit support from Glassfish in order to use a set of bundles that provide Remote Services (the name "DOSGI" is now deprecated). Indeed, this is kind of the point of OSGi!
Anyway the next obvious question is which Remote Services implementation to choose. I would advise you NOT to use CXF since it is too buggy and unmaintained. That leaves Eclipse ECF or Paremus RSA.
(Disclaimer: the Paremus implementation is commercial and I work for Paremus).
I haven't used Apache Axis since my 1.x days so I am little rusty here. My question is this.... How do I go about using the #Autowired annotation in my Apache Axis2 service endpoint class? Is this possible? I did some google searching and have yet to find anything conclusive. I am using Apache Axis2 version 1.5.1 and Spring 3.0.3. I just want to autowire up a simple DAO into my Web Service endpoint. I wouldn't think that would be so hard. I have already configured my applicationContext.xml and tested my DAO in a simple DBunit JUnit test case so it works fine. I can also Autowire up my Spring bean in my JUnit test. In my WAR I have configured my web.xml to use the org.springframework.web.context.ContextLoaderListener. This works fine and I can see when I deploy the war that the applicationCOntext is loaded up. Now how do I wire this up so I can use #Autowired in my Apache Axis2 service endpoint class?
Thanks for any help in advance!
Kyle
Resolved my own issue. Jsst needed to have my Service Endpoint class simply extend the SpringBeanAutowiringSupport class.