Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Switched to ModeShapeEngine for deploy/undeploy/shutdown of repository #260

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
Member

gregjan commented Feb 28, 2014

Edits to repo.xml files reflect the new ModeShapeEngine and destroy hook on ModeShapeRepositoryFactoryBean
Retooled several ITs to create just a container context and get at beans via singleton pattern
Some ITs were starting two repositories (in two different application contexts)

Member

gregjan commented Mar 7, 2014

If you don't dirty the context, then it may be reused for the next test class, which means leaving the repo running. I was trying to avoid collision between tests, but we may be able to avoid shutdown/startup costs by taking that annotation out. I will try it again that way and see if all works.

Member

ajs6f commented Mar 7, 2014

@gregjan Are you sure? My impression was that Spring's test framework caches contexts if possible...

http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/testing.html#testing-ctx-management

Member

gregjan commented Mar 7, 2014

Well, that doc is pretty clear. I am trying it without dirt.

Member

gregjan commented Mar 7, 2014

Okay, this was the reason:
Caused by: org.fusesource.leveldbjni.internal.NativeDB$DBException: IO error: lock /home/count0/fcrepo4/fcrepo-transform/target/data/LOCK: already held by process
at org.fusesource.leveldbjni.internal.NativeDB.checkStatus(NativeDB.java:200)

Lock issues due to it trying to start a second modeshape instance with the same data home. When I add dirt, it works.

Member

gregjan commented Mar 7, 2014

The reason we need to restart the contexts is that we have ITs that use master.xml and others that use test-container.xml. The repository loaded by the grizzly container will conflict with the repository loaded by master.xml if they are both cached. It is for this reason that I have noted the dirt.

Member

gregjan commented Mar 7, 2014

All of that happens in the fcrepo-transform project.

@gregjan gregjan Switched to ModeShapeEngine for deploy/undeploy/shutdown of repository
Edits to repo.xml files reflect the new ModeShapeEngine and destroy hook on ModeShapeRepositoryFactoryBean
Retooled several ITs to create just a container context and get at beans via singleton pattern
Some ITs were starting two repositories (in two different application contexts)
8290c65

@gregjan gregjan commented on the diff Mar 21, 2014

...kernel/spring/ModeShapeRepositoryFactoryBeanTest.java
}
- @Test
- public void testFactory() throws RepositoryException, IOException {
+ // @Test
@gregjan

gregjan Mar 21, 2014

Member

This line note identifies the disabled test. It is a strange test, in that it verifies that the factory returns a mock repo object delivered via an injected mock modeshapeengine object. If it verified something more meaningful as a unit test, then I would keep it, but this seems like more of an IT thing. To re-implement this test, one would have to mock at least one more object, the "Problems" interface, which is returned by repository startup.

IOW, all I can verify with this unit test is that our factory bean calls API methods in the expected sequence. It is like documenting the modeshape engine API, but it does increase coverage

@mikedurbin mikedurbin referenced this pull request Sep 16, 2014

Closed

Shutdown hook #476

Owner

awoods commented Jan 21, 2015

This PR was the core of the eventual resolution: #476

@awoods awoods closed this Jan 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment