[Hibernate-JIRA] Created: (HSEARCH-931) CollectionUpdateEventTest fails from the commans line when run after a unit test which extends JPATestcase
by Hardy Ferentschik (JIRA)
CollectionUpdateEventTest fails from the commans line when run after a unit test which extends JPATestcase
----------------------------------------------------------------------------------------------------------
Key: HSEARCH-931
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-931
Project: Hibernate Search
Issue Type: Bug
Components: tests
Affects Versions: 4.0.0.Beta2
Reporter: Hardy Ferentschik
Fix For: 4.0.0.CR1
The first problem was that we could not reproduce the problem and that was due to the fact that the execution order of tests varies depending on the OS. The surefire plugin has the _runOrder_ property to define the order. The default is _filesystem_ which has different results on Mac vs Linux. On Mac the tests are run in alphabetical order on Linux in "random" order.
If the tests are ordered alphabetically JPA tests are run after _CollectionUpdateEventTest_ and all works fine. If the order is random and a JPA test runs first we get the following error:
{noformat}
-------------------------------------------------------------------------------
Test set: org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest
-------------------------------------------------------------------------------
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.574 sec <<< FAILURE!
testWithClassBridge(org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest) Time elapsed: 0.242 sec <<< FAILURE!
org.junit.ComparisonFailure: [catalogItems should have been initialized] expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.fest.assertions.ConstructorInvoker.newInstance(ConstructorInvoker.java:36)
at org.fest.assertions.ComparisonFailureFactory.newComparisonFailure(ComparisonFailureFactory.java:60)
at org.fest.assertions.ComparisonFailureFactory.comparisonFailure(ComparisonFailureFactory.java:46)
at org.fest.assertions.Fail.comparisonFailed(Fail.java:83)
at org.fest.assertions.Fail.failIfNotEqual(Fail.java:71)
at org.fest.assertions.GenericAssert.isEqualTo(GenericAssert.java:217)
at org.fest.assertions.BooleanAssert.isEqualTo(BooleanAssert.java:73)
at org.fest.assertions.BooleanAssert.isTrue(BooleanAssert.java:55)
at org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest.testScenario(CollectionUpdateEventTest.java:98)
at org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest.testWithClassBridge(CollectionUpdateEventTest.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
{noformat}
At the moment we explicitly set the _runOrder_ option in the surefire plugin to _alphabetical_ which will make the tests pass. To trigger the failure you can change _runOrder_ to _reversealphabetical_ and run:
{code}
mvn test -Dtest=org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest,EntityManagerTest
{code}
Also important for this issue is that the surefire plugin is configured to only fork _once_ for all tests, so the same JVM is shared between tests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[Hibernate-JIRA] Created: (HHH-6609) Provide a way to supply prebuild ConnectionProvider to Hibernate
by Christoph Läubrich (JIRA)
Provide a way to supply prebuild ConnectionProvider to Hibernate
----------------------------------------------------------------
Key: HHH-6609
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6609
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.6.7
Reporter: Christoph Läubrich
Currently it is only possible to provide a ConnectionProvider via the property Environment.CONNECTION_PROVIDER which only accepts a class-name which later is instantiated via ConnectionProviderFactory:
private static ConnectionProvider initializeConnectionProviderFromConfig(String providerClass) {
ConnectionProvider connections;
try {
log.info( "Initializing connection provider: " + providerClass );
connections = (ConnectionProvider) ReflectHelper.classForName( providerClass ).newInstance();
}
catch ( Exception e ) {
log.error( "Could not instantiate connection provider", e );
throw new HibernateException( "Could not instantiate connection provider: " + providerClass );
}
return connections;
}
This aproch is okay for connectionprovider which are very generic and can build up completely by the configuration, but under some circumstances the creation and setup is out of scope of the Provider implementation class.
For this case it would be helpfull to have a configuration property like Environment.CONNECTION_PROVIDER_REFERENCE and a static public Method in the ConnectionProviderFactory like
ConnectionProviderFactory.addConnectionProviderReference(ConnectionProvider provider, String reference)
So it would be possible to make something like this:
ConnectionProvider provider = new MySpecialProvider(x, y, z);
provider.doSpecialSetup(d);
ConnectionProviderFactory.addConnectionProviderReference(provider, "MySpecialProvider");
.
.
.
Configuration configuration = new Configuration();
configuration.setProperty(Environment.CONNECTION_PROVIDER_REFERENCE, "MySpecialProvider");
SessionFactory factory = configuration.buildSessionFactory();
The only alternative to this in current days is to create a ConnectionProvider class which completely relies on static setup methods, making the code relativly complicated and error prone, as well as introducing class not found problems if the provider is not in the same class loader context as hibernate or the module which creates the configuration (for example in OSGi applications).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months