Sebastian Celis wrote:
Now the User Guild talks a lot about JNDI. Am I correct in understanding
that if I want to use the TCK-webapp, that I don't implement a custom
RepositoryStub class? That instead I use the default one and register my
repository via JNDI so that the JCR TCK Web Application can connect to it?
yes, that's correct. The default setup already does it that way. The reference
implementation is registered via JNDI and the TCK web application looks up the
repository using predefined JNDI settings.
If so, how do I do this? I have been reading about JNDI, but it is not clear
to me how to use it to allow the provided RepositoryStub to find my
repository.
There is a 'Test Config' tab in the TCK web application that contains the JNDI
settings. The relevant parameters are:
- java.naming.provider.url
- java.naming.factory.initial
Once you saved your changes (the button at the very bottom of the page), the TCK
will look up the repository with the new JNDI parameters.
If I do decide to implement a custom RepositoryStub class, then how do I
invoke the TCK so that it uses this class to connect to my JSR-170
implementation?
That's a bit more difficult, because there's no parameter on the 'Test Config'
tab. In that case you should use the default settings within the tck-webapp.war
(/WEB-INF/classes/repositoryStubImpl.properties) as a basis for your own
configuration and then provide the location of your file as a java system
property: -Djavax.jcr.tck.properties=<location-of-your-file>
In there you can define the stub implementation:
# Stub implementation class
javax.jcr.tck.repository_stub_impl=org.apache.jackrabbit.test.JNDIRepositoryStub
The TCK web application will first check if the system property is set and load
the configuration from there or otherwise use the default one, which is shipped
with the TCK web application itself.
regards
marcel
