Which values exist for the eclipselink.weaving property and what is their meaning?
In Spring we can create the entityManager using Java configuration or XML configuration, the following example is for XML:
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="jpaProperties">
<props>
<prop key="eclipselink.weaving">false</prop>
...
</props>
</property>
...
</bean>
We have the following option:
static - to static weaving to weave all applicable class files at build time so that you can deliver pre-woven class files.
What does the false means? And which options can we pass to eclipselink.weaving property?
EDIT:
I want to configure the weaving during compile time. I am using this maven plugin
<groupId>com.ethlo.persistence.tools</groupId>
<artifactId>eclipselink-maven-plugin</artifactId>
What value should I use false or static ?
Javadoc for the eclipselink.weaving property state 3 values:
"true" - requires that weaving is done. Will throw an exception if
entities are not woven
"false" - forces weaving not to be done
"static" - requires that the static weaving utility was used to weave
the entities
True aka Dynamic implies there is an agent that will weave the entities in the JVM. See the doc for setting it up outside of a container. Static tells EclipseLink you've done the weaving yourself on the java classes within the class loader (see the wiki for how to set it up), while false turns off any options that require woven classes (change tracking, lazy one to ones and more).
Related
I want to use two transaction managers as follows
<bean id="transactionManagerReadOnly" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactoryReadOnly" />
</bean>
<bean id="transactionManagerReadWrite" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactoryReadWrite" />
</bean>
and in my code there are tx:annotation-driven tags are present such as follows
<tx:annotation-driven mode="aspectj" transaction-manager="transactionManagerReadWrite"/>
<tx:annotation-driven mode="aspectj" transaction-manager="transactionManagerReadOnly"/>
but I read somewhere that there should be only one tx:annotation-driven present and refer another transaction manager by specifying in #Transaction tag such as folows
#Transactional("transactionManagerReadWrite")
#Transactional("transactionManagerReadOnly")
Following are my questions and queries
Which transaction manager is considered as a valid candidate for #Transactional if there are two transaction managers present and two tx:annotation-driven tags present in configuration file if we don't specify the name of transaction manager explicitly in #Transactional annotation ?
What would be the mode of second transaction manager if it is recommended to have only one tx:annotation-driven tag in application and we specify the mode in tx:annotation-driven tag only ?
i.e. springs default mode is proxy mode and I want to use two transaction manager's with aspectj mode
How to specify aspectj mode for second transaction manager if we can use only one tx:annotation-driven tag and default mode is proxy mode in spring ?
You can only have a single <tx:annotation-driven /> as that configured how #Transactional annotations are handled. You specify the mode (proxy or aspectj) and the default transaction manager to associate with #Transactional annotations.
The aspect is thus either applied through proxies (mode proxy) or load or compile time weaving (mode aspectj). There is just 1 aspect and that aspect either uses the default transaction manager or the one defined in the #Transactional annotation.
Given you specify the aspectj mode and transactionManagerReadWrite as the default transaction manager
<tx:annotation-driven mode="aspectj" transaction-manager="transactionManagerReadWrite"/>
Now when using a plain #Transactional it will use transactionManagerReadWrite, when using #Transactional("transactionManagerReadOnly") it will use the transactionManagerReadOnly. Either one will be weaved in as aspectj is used as the mode to apply transactions.
I'm using spring integration to create multiple services (each running in their own JVM) with JMS endpoints.
Once retry, exception handling, etc is added, the configuration is no longer trivial. I have moved the spring integration into its own context file and import it in all services to have a consistent setup.
eg
<import resource="classpath:/spring/jmsEndpoint.xml"/>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties">
<props>
<prop key="queueName">myServiceQueue</prop>
</props>
</property>
</bean>
<alias name="myBusinessLogic" alias="abstractJmsEndpoint"/>
<bean id="myBusinessLogic" class="..."/>
This configuration allows me to keep each individual service configuration simple, only requiring an override of an abstract bean and setting a few properties.
The problem is I now want multiple jms endpoints in the same service (jvm). As I can't import jmsEndpoint.xml multiple times, what is the best way to reuse the configuration?
See the dynamic-ftp sample - it uses a technique of creating instances of a parameterized application contexts, passing different properries into each. It's README also has links to forum discussions about how to make these contexts children of the main context, in cases where the child needs access to shared resources.
Right now i am using the following bean entry
<bean id="Service" >
<property name="target">
<bean class="someClass" lazy-init="false">
<property name="SessionFactory1"><ref bean="SessionFactory1"/></property>
<property name="SessionFactory2"><ref bean="SessionFactory2"/></property>
<property name="SessionFactory3"><ref bean="SessionFactory3"/></property>
</bean>
</property>
</bean>
Now the requirement is to first check which all session factories have an active datasource and include those only in the above bean definition. So that the application does not break if we try to initialize a session factory with inactive datasource.
sessionfactory initialization will be take care by using seperate config xml for session factories and loading only the ones with active datasources.
Please help on how can this be achieved.
You can use Spring InitializingBean interface, which makes you implement an afterPropertiesSet() method. This method will be executed after Spring instantiates your class, and you could check if your session factories are available or not.
InitializingBean: Interface to be implemented by beans that need to react once all their properties have been set by a BeanFactory: for example, to perform custom initialization, or merely to check that all mandatory properties have been set.
link: Spring InitializingBean
The following sample from the Spring manual confuses the heck out of me.
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheCacheManager"
p:cache-manager-ref="ehcache"/>
<!-- Ehcache library setup -->
<bean id="ehcache"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
p:config-location="ehcache.xml"/>
The naming convention mandates that EhCacheManagerFactoryBean produces a cache manager, more precisely it's a net.sf.ehcache.CacheManager instance. Yet, the bean is called ehcache not ehcachemanager. The actual cacheManager, however, references this bean.
In prose you could say that one is the Ehcache cache manager while the other is the Spring cache manager (which is backed by the former).
It gets worse if you use the EhCacheFactoryBean:
<bean
id="myCache"
class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager">
<ref local="ehcache" />
</property>
There's a property called cacheManager which references a bean called ehcache.
Did I misunderstand anything or is it really that confusing? Bad design or just bad naming in the example?
Spring framework recently introduced caching abstraction with org.springframework.cache.CacheManager central interface. This interface has few built-in implementations, including:
ConcurrentMapCacheManager
EhCacheCacheManager
NoOpCacheManager
SimpleCacheManager
This design allows you to switch caching library without touching application code. As you can see one of these built-in implementations is backed by EhCache. However notice that EhCacheCacheManager is just a bridge between Spring caching abstraction and EhCache library. Thus it needs existing net.sf.ehcache.CacheManager. You can either create an instance of this cache manager yourself or take advantage of existing factory bean, namely EhCacheManagerFactoryBean.
I understand it's confusing because of overlapping names, but it should be clear from the above which classes come from which library and why are they used.
I have a custom library that sends a JMS notification. The idea is that you can use the library by simply by setting some properties in your project.
The custom library is using the Apache Commons Configuration. (The reason I mention this is that I suspect it may be playing a role in my problem). I'm trying to use it in my current Spring project which doesn't use Commons Config but uses the PropertyPlaceholderConfigurer. I've got the properties I need written out in a .properties file.
I've added the library as a dependency in my pom.xml file. I tried adding it into my web.xml like so
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
...
classpath:mylibrary-context.xml
</param-value>
</context-param>
When creating a bean in my Spring project, I tried to reference one of the beans defined in the library, so I could use it. There's an error creating one of the library beans that requires a property from my properties file.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'libraryBean' defined in class path resource [mylibrary-context.xml]: Initialization of bean failed; nested exception is org.springframework.beans.TypeMismatchException: Failed to convert property value of type 'java.lang.String' to required type 'boolean' for property 'useCompression'; nested exception is java.lang.IllegalArgumentException: Invalid boolean value [${foo.bar.use.compression}]
I know some of the other properties files in the project have boolean properties set the exact same way without issue. Here is how I'm loading the properties files in the applicationContext.xml(which after checking the logs, seems to load correctly)
<bean id="propertyPlaceholderConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
...
<!-- loaded in order-->
<value>classpath:foo/bar/some-props.properties</value>
<value>classpath:foo/bar/some-monitoring.properties</value>
<value>file:/${user.home}/foo/bar/some-monitoring.properties</value>
<value>file:/etc/foo/bar/some-monitoring.properties</value>
</list>
</property>
<property name="ignoreResourceNotFound" value="true"/>
<property name="ignoreUnresolvablePlaceholders" value="true"/>
and finally my some-monitoring.properties file:
foo.bar.use.compression=true
foo.bar.name=foobar
foo.bar.broker.url=someurl
So I'm just wondering what's going on with the boolean property and why? If its a general problem with the PropertyPlaceholderConfigurer not loading boolean properties, its odd that I'm not having a problem with the other properties files. Is it that there is some conflict because of the library using the Commons Configuration? My knowledge of how Spring loads up these properties is pretty shallow so this seems like a chance to get a better handle on what's going on under the covers.
If anyone can shed some light on what's going on and how to fix/get around it, any help is greatly appreciated!
Quoting Jurgen on the spring-dev list:
PropertyPlaceholderConfigurer is an implementation of the BeanFactoryPostProcessor interface: This interface and its sibling
BeanPostProcessor just apply to the BeanFactory that defines them,
that is, to the application context that defines them.
If you combine multiple config files into a single
contextConfigLocation, a PropertyPlaceholderConfigurer defined in any
of the files will apply to all of the files, because they are loaded
into a single application context.
As far as I understand, you tried to combine all your application contexts into the contextConfigLocation. According to the quotation, it should work fine. I think that you have other kind of problem. In my opinion both boolean and string properties are not loaded at all. Maybe it seems as string properties are loaded, but I think that their values are set to ${foo.bar.name} and ${foo.bar.broker.url}. Since they are Strings, they can hold these values. When Spring tries to set ${foo.bar.use.compression} to the boolean, you have typecast problem which just reveals wider issue.
Probably, if you set:
<property name="ignoreResourceNotFound" value="false"/>
<property name="ignoreUnresolvablePlaceholders" value="false"/>
you will see that PropertyPlaceHolderConfigurer cannot resolve your properties files.
Please also try using classpath*: notation when you refer to resources from other JARs.