Ignore persistence unit definitions that have PersistenceUnitTransactionType = RESOURCE_LOCAL - jpa

I have a Wildfly 8 container and an EAR with a persistence.xml inside. There are multiple persistence units defined.
Is there a way to ignore the process of the persistence unit definitions that have PersistenceUnitTransactionType = RESOURCE_LOCAL at the deployment of the EAR?

I was able to tell wildfly to ignore specific peristence-unit in peristence.xml by adding property
<properties>
<property name="jboss.as.jpa.managed" value="false" />
</properties>
So wildfly will not ignore all peristence-units with PersistenceUnitTransactionType=RESOURCE_LOCAL but all with the property set.

Related

JSF2 + Spring 4 + CDI + Spring Data, good match?

Let me tell you my story, and in between I will ask questions
I am working in a project I have to use JSF, there is not really other choice.
Coming from the wonderful Spring world in the last years, I really wanted to use some features like Spring Data, Spring singleton beans, Autowire beans into other beans, etc.
So I thought initially everything would be smooth, JSF (backing beans) will be managed by CDI container and #Service, #Respostory and database connection Entity manager by spring container. I want to make my application independent from a Java EE container, but just for information I am using Wildfly 9. In Wildfly, I create a datasource (connection to an oracle database) to bind later to my application.
So my first difficulty was, Some years ago, I code some JSF and I knew about #ManagedBean anotations and JSF scopes, all even though has not changed, there seems to be another aproach, and acording to what I read it is recommendable to use #Named and so on (CDI annotations) instead of the JSF annotations. So I wanted to follow those advices and somehow forces me to introduce CDI container into my application.
1st Question: Is that true ? Isn´t it recommendable to use old JSF annotations ?
My JSF beans look like this:
import java.io.Serializable;
import java.util.Locale;
import javax.annotation.PostConstruct;
import javax.enterprise.context.SessionScoped;
import javax.faces.context.FacesContext;
import javax.inject.Inject;
import javax.inject.Named;
import javax.validation.constraints.NotNull;
import co.com.psl.connectnetwork.service.AuthenticationService;
import lombok.Data;
#Named
#SessionScoped
#Data
public class LoginBean implements Serializable {
}
My first issue, is that as I mentioned before, I wanted to introduce Spring, so I had in my application context xml file
<context:annotation-config />
<context:component-scan base-package="co.com.package" />
That was causing me problems because it seemed that Spring scanned my JSF managed beans , and treated them as Spring beans, which I don´t have any issue with that, but in practice those beans were singleton !!! , so terrible for an application which manages some state among logged users.
So I solved it by excluding JSF beans from spring container, I did it by introducing this:
<context:component-scan base-package="co.com.scannedpackage" >
<context:exclude-filter type="regex" expression="co.excludedpackage.*Bean" />
</context:component-scan>
So It did not seem to me so terrible , and as it seems to be some imcompatibility I though It was better that JSF beans will not be managed by Spring.
2nd Question: Do you agree?
As I said, I will have some #Service (Spring annotations) beans which I will eventually have to inject into the JSF managed beans . Initially I used #Inject to inject the service bean into the JSF bean , and it worked perfectly , the only issue is that when the JSF bean was using javax.enterprise.context.SessionScoped , it forced that all attributes are Serializable, so I made the #Service Spring bean implement the Serializable interface, which I dont think it is nice , even if it works, it seems to me a contradiction and a spring singleton bean (stateless) is forced to be serialized. So I tried to use the #Autowired anotation in the JSF managed bean , but the bean was not been injected and I got a null reference. Basically I guess the error I think it was, to use #Autowired in a bean which is not managed by spring.
3rd Question: How can I make it work ? I really think it is better to use #Autowired than to have spring beans serializable .If the ApplicationScope/viewScope/SessionScope JSF bean is passivated, will the Spring bean be injected again?, I don´t think so. If #ManagedBean is used, will it work ?
Another issue I am having, is that if my JSF beans are managed by CDI, It seems that javax.faces.bean.ViewScoped does not work well with CDI
4th Question: Is that so? Do you recommend me to use #ManagedBean instead of #Named? If I use #ManagedBean, how do I inject Spring dependencies? Is there any other CDI scope I could use instead of ViewScoped?
Now moving from JSF to Spring, I really want to use Spring in my applications, Features like Spring-Data, Spring-Security and others, the advantages of Spring singleton beans over EJB Stateless beans, are things I don´t want to miss. In my application, I will have a datasource created in the Java EE server or Java EE container. Then, I will bind that datasource internally in my application. So in my applicationContext.xml, I have:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://www.springframework.org/schema/c"
xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.1.xsd
http://www.springframework.org/schema/data/jpa
http://www.springframework.org/schema/data/jpa/spring-jpa.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.1.xsd">
<bean id="datasource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:/jndi-spring"/>
<property name="lookupOnStartup" value="true"/>
<property name="proxyInterface" value="javax.sql.DataSource"/>
</bean>
<!-- <jee:jndi-lookup id="datasource" jndi-name="java:/ConnectNetworkDS"/> -->
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="datasource" />
<property name="persistenceUnitName" value="persistenceUnit2" />
<property name="packagesToScan" value="co.com.packagestoscan" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
</property>
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.Oracle10gDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</prop>
</props>
</property>
</bean>
<jpa:repositories base-package="co.com.packagewhererepositoriearelocated" />
</beans>
Please note that I am using Spring data and this line
<jpa:repositories base-package="co.com.packagewhererepositoriearelocated" />
is to indicate the interfaces annotated with #org.springframework.stereotype.Repository.Resository
Unfortunately, when I deploy my application, I get:
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."deployedwar.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."deployedwar.war".WeldStartService: Failed to start service
So I was doing so internet research, and I included :
persistence.xml
CdiConfig class
The content of persistence.xml is:
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="persistenceUnit">
<class>co.com.entityClass1</class>
<class>co.com.entityClass2</class>
<jta-data-source>java:/jndi-string</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect" />
<property name="hibernate.show_sql" value="true" />
<property name="hibernate.ejb.naming_strategy" value="org.hibernate.cfg.ImprovedNamingStrategy"/>
<property name="hibernate.cache.provider_class" value="org.hibernate.cache.EhCacheProvider" />
</properties>
</persistence-unit>
</persistence>
And CdiConfig class:
import javax.enterprise.context.Dependent;
import javax.enterprise.inject.Produces;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
public class CdiConfig {
#Produces
#Dependent
#PersistenceContext
private EntityManager entityManager;
}
5th Question: Can somebody please tell me why this is required ? Shouldn´t spring be able to inject the enntityManager into the #Repository Spring beans ? Why a persistence.xml is necessary ? Why does it seems that injection into #Repository Spring beans have to be done by Spring ? I think this somehow is redundant
Isn´t it recommendable to use old JSF annotations?
That's true. In JSF we're moving away from the JSF native beans and injection in favor of CDI. Although still not officially so, #ManagedBean and friends should be considered effectively deprecated.
#ViewScoped should work fine with CDI, but make sure you're importing the right one. The old one does not work, the newer one does. The one you need is:
javax.faces.view.ViewScoped
See CDI compatible #ViewScoped

JPA 2-level caching

Sorry for a providing a less specific title. Actually I am in a mess.
My actual problem: To improve performance of the application.
Good Thing: The data is inserted/updated through JPA through out the application.
Technology used so far: Spring 3.2 framework with JPA 2.0 and hibernate 3.2.
So far we don't have a direct dependency on Hibernate anywhere in our code.
Coming back to the problem:
I am planing to implement 2nd level Query caching for some queries which always fetch same data (dropdown values).
My 1st question :Does JPA provides 2nd level caching by itself(without using EHcache or any such dependency)?
What I found so far is using this property we can enable 2nd level caching
query.setHint("org.hibernate.cacheable", true);
My 2nd Question: Do I need to provide dependency for Ehcache or Hibernate-Ehcache is enough?
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>4.0.0</version>
</dependency>
or should I also need to provide
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache-core</artifactId>
<version>${ehcacheVersion}</version>
</dependency>
My third question: What are the properties I need to add in my persistence.xml.
I am sure about these two properties:
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
=====Thanks for the answer.This is the update might help the fellow developers.====
I am putting down the properties needs to be defined for enabling EHcache as lots of people face this exception
Caused by: org.hibernate.cache.NoCachingEnabledException: Second-level cache is not enabled for usage [hibernate.cache.use_second_level_cache | hibernate.cache.use_query_cache]
because of property mismatch and dependency mismatch.
The following property should work for hibernate 4.x along with Ehcache 2.4.3
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.generate_statistics" value="true"/>
<property name="hibernate.cache.provider_configuration_file_resource_path" value="classpath:ehcache.xml" />
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"/>
My 1st question :Does JPA provides 2nd level caching by itself (without
using EHcache or any such dependency)?
No, it doesn't. JPA is just a standard and doesn't provide any implementation. Hibernate provides implementation for JPA (EntityManager, EntityMangerFactory, etc) along with its own ORM implementation (Session, Session Factory, etc). Therefore, you need EHCache to support 2nd level cache. However, you can use JPA annotations/config for caching but that requires changes in persistence.xml.
Following two links explains each configuration options:
Caching using Hibernate specific classes/annotations.
Caching using JPA specific classes/annotations (with Hibernate as JPA provider)
My 2nd Question: Do I need to provide dependency for Ehcache or
Hibernate-Ehcache is enough?
You need to add ehcache-core, hibernate-ehcache and slf4j-simple (EHCache uses slf4j for logging). For dependencies details, check Hibernate EHCache Maven Dependencies section on this link.
My third question: What are the properties I need to add in my
persistence.xml.
If you go by JPA way, then the sample persistence.xml would be like:
<persistence-unit name="FooPu" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
...
<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
<properties>
...
<property name="hibernate.cache.provider_class" value="org.hibernate.cache.SingletonEhCacheProvider"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
</properties>
</persistence-unit>

How to get logging info for HikariCP

Using Hibernate 4.3.1, Hikari 2.3.2.
I have configured this in the hibernate persistence xml
...
<property name="hibernate.hikari.leakDetectionThreshold" value="3000" />
<property name="hibernate.hikari.poolName" value="KikariTest" />
<property name="hibernate.hikari.registerMbeans" value="true" />
And this in my log4j.properties
log4j.logger.com.zaxxer.hikari=DEBUG
log4j.additivity.com.zaxxer.hikari=false
Im not seeing any logging information printed. Any ideas?
It took me a whole day to get this right! Turns out I was using log4j libs only, whereas a needed to include the slf4j libs.
I think you want log4j.additivity.com.zaxxer.hikari=true (or not set at all, left at default). additivity=false means don't inherit the parent's appender, which probably means there is no appender at all.
Remove theese jars from your classpath or lib directory if you have.
logback-classic-1.1.7.jar
logback-core-1.1.7.jar

Has anyone tried datanucleus JPA implementation with orientdb?

I am trying to implement Datanucleus JPA for orientdb for my java project. I am able to successfully make it work with datanucleus3.1.2, mongodb. but when I tried to do with orientdb, I read it works with 2.x (i guess ONLY 2.x at moment). I replaced all datanucleus 3.x jars with 2.x.
For mongodb I have following works fine
Persistence.createEntityManagerFactory("mongodb");
with persistence.xml
<persistence-unit name="mongodb">
<properties>
<property name="datanucleus.ConnectionURL" value="mongodb:localhost:27017/db"/>
<property name="datanucleus.storeManagerType" value="mongodb" />
<property name="datanucleus.autoCreateSchema" value="true" />
</properties>
</persistence-unit>
Has anyone able to get it work? How to create entity manager factory for orientdb?
How the persistence.xml should look like?
I keep getting
javax.persistence.PersistenceException: No Persistence provider for EntityManager named orientdb
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:84)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:54)

Liferay JPA ClassLoader Error

EDITED (I'm simplifying as my original question was too convoluted):
Create a portlet plugin in Liferay 6.1.20
Add in your portlet's web.xml a spring context loader
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Add in your application context an instance of an EntityManagerFactory
<bean id="localEntityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation" value="WEB-INF/classes/META-INF/persistence.xml" />
</bean>
Make sure in your persistance definition you're referencing a JPA Implementation
<persistence-unit name="casd" transaction-type="RESOURCE_LOCAL">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<properties>
<property name="eclipselink.weaving" value="false" />
</properties>
</persistence-unit>
Watch Tomcat cry
java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.eclipse.persistence.jpa.PersistenceProvider.getProviderUtil()Ljavax/persistence/spi/ProviderUtil;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/eclipse/persistence/jpa/PersistenceProvider, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for interface javax/persistence/spi/PersistenceProvider have different Class objects for the type javax/persistence/spi/ProviderUtil used in the signature
Play with hibernate3.jar, eclipselink.jar, persistence.jar until exhaustion, and realize Liferay is grinning at you.
How would you erase that irritating smile from Liferay's face?
In other words,
How can I get a JPA provider instantiated in a spring context within a portlet plugin in liferay 6.1.20 without getting a classloader error?
Ok. I managed to "solve" the problem moving ecliseplink.jar from /ROOT/WEB-INF/lib to {tomcat}/lib/ext
I don't like it as a solution, having to mess with ext, but it's a take it or leave it situation.