Strange Anomaly
I wonder if this error is related to the fact that it seems clearThreadContext is called before my method finished? Or is this a logger anomaly and clearThreadContext was called after the error was tossed? Thanks! DEBUG 2011-08-05 01:14:51,005 [Worker thread '25'] (DupFinderConnector.java:474) - Releaseing connection handle ERROR 2011-08-05 01:14:51,042 [Worker thread '25'] (WorkerThread.java:893) - Exception tossed: txn [createtopic] failed with error java.lang.NullPointerException org.apache.manifoldcf.core.interfaces.ManifoldCFException: txn [createtopic] failed with error java.lang.NullPointerException at com.systemware.ci.sdk.CIConnector.sendTxn(CIConnector.java:277) at com.systemware.ci.sdk.CIConnector.sendTxn(CIConnector.java:315) at org.apache.manifoldcf.agents.output.dupfinder.DupFinderConnector.captureUniqueDoc2CI(DupFinderConnector.java:370) at org.apache.manifoldcf.agents.output.dupfinder.DupFinderConnector.addOrReplaceDocument(DupFinderConnector.java:195) at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.addOrReplaceDocument(IncrementalIngester.java:1433) at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.performIngestion(IncrementalIngester.java:418) at org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.documentIngest(IncrementalIngester.java:313) at org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocument(WorkerThread.java:1565) at org.apache.manifoldcf.crawler.connectors.filesystem.FileConnector.processDocuments(FileConnector.java:275) at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.processDocuments(BaseRepositoryConnector.java:423) at org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:564)
[jira] [Created] (CONNECTORS-237) RSS Connector proxy code doesn't seem to function correctly
RSS Connector proxy code doesn't seem to function correctly --- Key: CONNECTORS-237 URL: https://issues.apache.org/jira/browse/CONNECTORS-237 Project: ManifoldCF Issue Type: Bug Components: RSS connector Affects Versions: ManifoldCF 0.3 Reporter: Karl Wright Trying to crawl through a proxy fails. No activity is recorded but all fetches fail (with timeout errors) and are requeued. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079506#comment-13079506 ] Karl Wright commented on CONNECTORS-236: I checked in the patch changes. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt, patch3.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-236: -- Attachment: patch3.txt This patch includes - a bugfix for a wrong setting in the Base class for the CMIS Server instance - refactor for the tests/cmis/pom.xml: added a new property to set the absolute path for the root lib directory Remind to add section here: http://incubator.apache.org/connectors/how-to-build-and-deploy.html#Preparation about the new property named opencmis.server.war.path. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt, patch3.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079498#comment-13079498 ] Karl Wright commented on CONNECTORS-236: I updated build.xml and Base.java to use relative paths to the wars. Now I can run the test under ant, but it fails in just the manner you describe (timeout waiting for job to finish). I was able to see manifoldcf.log when I exited; it's full of these: Error tossed: org.apache.chemistry.opencmis.client.runtime.FolderImpl java.lang.ClassCastException: org.apache.chemistry.opencmis.client.runtime.Folde rImpl at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector .getDocumentVersions(CmisRepositoryConnector.java:1026) at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.getD ocumentVersions(BaseRepositoryConnector.java:355) at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.getD ocumentVersions(BaseRepositoryConnector.java:336) at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.getD ocumentVersions(BaseRepositoryConnector.java:315) at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.getD ocumentVersions(BaseRepositoryConnector.java:292) at org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.ja va:321) > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079494#comment-13079494 ] Karl Wright commented on CONNECTORS-236: I think we should do what we do for other artifacts that are not yet available: ask the user to install them into maven, by just adding to the procedure described here: http://incubator.apache.org/connectors/how-to-build-and-deploy.html#Preparation > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[
https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079490#comment-13079490
]
Piergiorgio Lucidi commented on CONNECTORS-236:
---
Thanks.
Karl,
the CMIS server webapp is in the lib directory, but this directory is outside
of the Maven module for CMIS tests.
This means that now we need to add a new property in the tests/cmis/pom.xml to
set the absolute path of the CMIS server.
In the future we will fix this, when the new version of the CMIS Server will be
available in the Maven repo, so we will not have any problem.
But now it could be not good to leave the war artifact in the main lib
directory, because to build and run tests we need to insert the needed path as
a property value.
A possible solution could be create a lib folder inside tests/cmis and move the
CMIS server webapp in this new folder. In this way we can access using Maven
because we are now in the module and we can refer to the webapp using a
relative path.
With the war artifact in the following path:
{code}
tests/cmis/lib/chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war
{code}
We can refer to it using a relative path in the pom.xml:
{code}
lib/chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war
{code}
WDYT?
> Tests and test server needed for CMIS connector
> ---
>
> Key: CONNECTORS-236
> URL: https://issues.apache.org/jira/browse/CONNECTORS-236
> Project: ManifoldCF
> Issue Type: Bug
> Components: CMIS connector
>Reporter: Piergiorgio Lucidi
> Attachments:
> chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt,
> patch2.txt
>
>
> The CMIS connector needs tests, and a CMIS test server to run against.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079465#comment-13079465 ] Karl Wright commented on CONNECTORS-236: Added. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-236: -- Attachment: patch2.txt This patch must be applied to the new branch in order to add the test/cmis/pom.xml. I forgot to add it before. I'm sorry. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt, > patch2.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079452#comment-13079452 ] Karl Wright commented on CONNECTORS-236: I checked this in with two changes. First, the chemistry war I put into the lib directory. I presume that the artifact under maven will be deployed from there, and that the ant build will refer to the war directly. Second, I did not include the changes to jetty-runner, since they didn't make any sense to me. The branch these changes are in is: https://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-236. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079445#comment-13079445 ] Karl Wright commented on CONNECTORS-236: Ok, never mind - the pair of jetty servers is indeed separate as you say. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079441#comment-13079441 ] Karl Wright commented on CONNECTORS-236: Another change I'd like to see is to pull the snapshot war out of the maven repository. The filesystem tests do it that way by allowing optional -D arguments, which maven provides, to point at the repository war. Copying that would also make it possible to run the same tests under ant. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079439#comment-13079439 ] Piergiorgio Lucidi commented on CONNECTORS-236: --- In this patch I configured two instances of the Jetty server: an instance dedicated to ManifoldCF and a second instance dedicated for the CMIS server on port 9090. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079438#comment-13079438 ] Karl Wright commented on CONNECTORS-236: Hi Piergiorgio, I had a look at your Setup method, and what you do is create a second instance of Jetty that includes all the ManifoldCF web applications, as well as the CMIS server. This should not be needed since the MCF web applications are already deployed on the other instance of Jetty. You just need to use the right port number to talk with them, which I believe is 8346. I'm not sure this is causing your difficulties or not but it certainly isn't good. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: > chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-236) Tests and test server needed for CMIS connector
[
https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piergiorgio Lucidi updated CONNECTORS-236:
--
Attachment: chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war
This is the OpenCMIS InMemory Repository that is distributed as a web
application.
Now we need to include this web app in the SVN, because Chemistry guys have
patched for us this component.
When the latest version of this artifact will be released in the official
Chemistry Maven repository, it will be taken from Maven and we will remove it
from SVN.
This artifact must be dropped in the following folder in order to execute tests:
{code}
tests/cmis/war/
{code}
> Tests and test server needed for CMIS connector
> ---
>
> Key: CONNECTORS-236
> URL: https://issues.apache.org/jira/browse/CONNECTORS-236
> Project: ManifoldCF
> Issue Type: Bug
> Components: CMIS connector
>Reporter: Piergiorgio Lucidi
> Attachments:
> chemistry-opencmis-server-inmemory-war-0.5.0-SNAPSHOT.war, patch.txt
>
>
> The CMIS connector needs tests, and a CMIS test server to run against.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-236: -- Attachment: patch.txt This patch includes integration test for the CMIS Repository Connector. Probably there is an issue about starving on Jetty. Must be applied together with the latest version of the OpenCMIS InMemory Repository that is one of the attachments of this patch release. Follow another attachment. > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > Attachments: patch.txt > > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-236) Tests and test server needed for CMIS connector
[ https://issues.apache.org/jira/browse/CONNECTORS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-236: -- Status: Patch Available (was: Open) > Tests and test server needed for CMIS connector > --- > > Key: CONNECTORS-236 > URL: https://issues.apache.org/jira/browse/CONNECTORS-236 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Reporter: Piergiorgio Lucidi > > The CMIS connector needs tests, and a CMIS test server to run against. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CMIS Connector - Tests
2011/8/4 Karl Wright > Hmm, okay, then it must be something pretty strange. Maybe jetty is > getting starved of threads or something? > I think a similar problem... > I wonder if you can start a second Jetty instance for the CMIS server. > That would eliminate any kind of jetty resource conflict. > I'm trying to set up a new Jetty instance dedicated to the CMIS server. > Karl > > On Thu, Aug 4, 2011 at 10:23 AM, Piergiorgio Lucidi > wrote: > > 2011/8/4 Karl Wright > > > >> Sorry, I meant, "do the API sanity tests work properly for you when > >> you run them on a clean trunk checkout"? > >> > > > > The other tests yes, work correctly, only CMIS tests don't work. > > > > > >> > >> Karl > >> > >> On Thu, Aug 4, 2011 at 10:12 AM, Karl Wright > wrote: > >> > This is going to be complicated to debug. I'm happy to help but yes, > >> > we'll need a branch to work off of. If you can attach the patch file > >> > I'll try to set everything up this evening. > >> > > >> > Do the APISanity tests still work consistently on your setup? The "No > >> > current connection" error seems like it is coming from some very basic > >> > level and I would expect it to appear with APISanity as well. > >> > > >> > The timeout indicates that the job is not completing. If we can get > >> > at the log when the test fails before they are cleaned up we will > >> > probably learn why. > >> > > >> > Karl > >> > > >> > > >> > On Thu, Aug 4, 2011 at 10:06 AM, Piergiorgio Lucidi > >> > wrote: > >> >> After some minutes sometimes it returns the following exception to > check > >> the > >> >> timeout: > >> >> > >> >> org.apache.manifoldcf.core.interfaces.ManifoldCFException: > ManifoldCF > >> did > >> >>> not terminate in the allotted time of 12 milliseconds > >> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive( > >> >>> APISanityTest.java:529) > >> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck( > >> >>> APISanityTest.java:365) > >> >>> 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) > >> >>> at org.junit.internal.runners.model.ReflectiveCallable.run( > >> >>> ReflectiveCallable.java:15) > >> >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively( > >> >>> FrameworkMethod.java:41) > >> >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( > >> >>> InvokeMethod.java:20) > >> >>> at org.junit.internal.runners.statements.RunBefores.evaluate( > >> >>> RunBefores.java:28) > >> >>> at org.junit.internal.runners.statements.RunAfters.evaluate( > >> >>> RunAfters.java:31) > >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored( > >> >>> BlockJUnit4ClassRunner.java:79) > >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( > >> >>> BlockJUnit4ClassRunner.java:71) > >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( > >> >>> BlockJUnit4ClassRunner.java:49) > >> >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > >> >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > >> >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > >> >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > >> >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > >> >>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( > >> >>> JUnit4TestSet.java:53) > >> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet( > >> >>> JUnit4Provider.java:123) > >> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke( > >> >>> JUnit4Provider.java:104) > >> >>> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray( > >> >>> ReflectionUtils.java:164) > >> >>> at > >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke( > >> >>> ProviderFactory.java:110) > >> >>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider( > >> >>> SurefireStarter.java:172) > >> >>> at > >> >>> > >> > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked( > >> >>> SurefireStarter.java:78) > >> >>> at > >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70 > >> >>> ) > >> >> > >> >> > >> >> > >> >> 2011
Re: CMIS Connector - Tests
Hmm, okay, then it must be something pretty strange. Maybe jetty is getting starved of threads or something? I wonder if you can start a second Jetty instance for the CMIS server. That would eliminate any kind of jetty resource conflict. Karl On Thu, Aug 4, 2011 at 10:23 AM, Piergiorgio Lucidi wrote: > 2011/8/4 Karl Wright > >> Sorry, I meant, "do the API sanity tests work properly for you when >> you run them on a clean trunk checkout"? >> > > The other tests yes, work correctly, only CMIS tests don't work. > > >> >> Karl >> >> On Thu, Aug 4, 2011 at 10:12 AM, Karl Wright wrote: >> > This is going to be complicated to debug. I'm happy to help but yes, >> > we'll need a branch to work off of. If you can attach the patch file >> > I'll try to set everything up this evening. >> > >> > Do the APISanity tests still work consistently on your setup? The "No >> > current connection" error seems like it is coming from some very basic >> > level and I would expect it to appear with APISanity as well. >> > >> > The timeout indicates that the job is not completing. If we can get >> > at the log when the test fails before they are cleaned up we will >> > probably learn why. >> > >> > Karl >> > >> > >> > On Thu, Aug 4, 2011 at 10:06 AM, Piergiorgio Lucidi >> > wrote: >> >> After some minutes sometimes it returns the following exception to check >> the >> >> timeout: >> >> >> >> org.apache.manifoldcf.core.interfaces.ManifoldCFException: ManifoldCF >> did >> >>> not terminate in the allotted time of 12 milliseconds >> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive( >> >>> APISanityTest.java:529) >> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck( >> >>> APISanityTest.java:365) >> >>> 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) >> >>> at org.junit.internal.runners.model.ReflectiveCallable.run( >> >>> ReflectiveCallable.java:15) >> >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively( >> >>> FrameworkMethod.java:41) >> >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >> >>> InvokeMethod.java:20) >> >>> at org.junit.internal.runners.statements.RunBefores.evaluate( >> >>> RunBefores.java:28) >> >>> at org.junit.internal.runners.statements.RunAfters.evaluate( >> >>> RunAfters.java:31) >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored( >> >>> BlockJUnit4ClassRunner.java:79) >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( >> >>> BlockJUnit4ClassRunner.java:71) >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( >> >>> BlockJUnit4ClassRunner.java:49) >> >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) >> >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) >> >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) >> >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) >> >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236) >> >>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute( >> >>> JUnit4TestSet.java:53) >> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet( >> >>> JUnit4Provider.java:123) >> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke( >> >>> JUnit4Provider.java:104) >> >>> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray( >> >>> ReflectionUtils.java:164) >> >>> at >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke( >> >>> ProviderFactory.java:110) >> >>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider( >> >>> SurefireStarter.java:172) >> >>> at >> >>> >> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked( >> >>> SurefireStarter.java:78) >> >>> at >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70 >> >>> ) >> >> >> >> >> >> >> >> 2011/8/4 Piergiorgio Lucidi >> >> >> >>> Hi Karl, >> >>> >> >>> the integration test implementation is finished and it works fine using >> the >> >>> public Alfresco CMIS server. >> >>> >> >>> But now that I'm using the OpenCMIS InMemory Repository, deployed in >> the >> >>> same Jetty instance of Manifold, I have a problem, it seems that >> starting >> >>> test
Re: CMIS Connector - Tests
2011/8/4 Karl Wright
> Sorry, I meant, "do the API sanity tests work properly for you when
> you run them on a clean trunk checkout"?
>
The other tests yes, work correctly, only CMIS tests don't work.
>
> Karl
>
> On Thu, Aug 4, 2011 at 10:12 AM, Karl Wright wrote:
> > This is going to be complicated to debug. I'm happy to help but yes,
> > we'll need a branch to work off of. If you can attach the patch file
> > I'll try to set everything up this evening.
> >
> > Do the APISanity tests still work consistently on your setup? The "No
> > current connection" error seems like it is coming from some very basic
> > level and I would expect it to appear with APISanity as well.
> >
> > The timeout indicates that the job is not completing. If we can get
> > at the log when the test fails before they are cleaned up we will
> > probably learn why.
> >
> > Karl
> >
> >
> > On Thu, Aug 4, 2011 at 10:06 AM, Piergiorgio Lucidi
> > wrote:
> >> After some minutes sometimes it returns the following exception to check
> the
> >> timeout:
> >>
> >> org.apache.manifoldcf.core.interfaces.ManifoldCFException: ManifoldCF
> did
> >>> not terminate in the allotted time of 12 milliseconds
> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive(
> >>> APISanityTest.java:529)
> >>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
> >>> APISanityTest.java:365)
> >>> 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)
> >>> at org.junit.internal.runners.model.ReflectiveCallable.run(
> >>> ReflectiveCallable.java:15)
> >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> >>> FrameworkMethod.java:41)
> >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
> >>> InvokeMethod.java:20)
> >>> at org.junit.internal.runners.statements.RunBefores.evaluate(
> >>> RunBefores.java:28)
> >>> at org.junit.internal.runners.statements.RunAfters.evaluate(
> >>> RunAfters.java:31)
> >>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
> >>> BlockJUnit4ClassRunner.java:79)
> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> >>> BlockJUnit4ClassRunner.java:71)
> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> >>> BlockJUnit4ClassRunner.java:49)
> >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> >>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
> >>> JUnit4TestSet.java:53)
> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(
> >>> JUnit4Provider.java:123)
> >>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> >>> JUnit4Provider.java:104)
> >>> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> >>> ReflectionUtils.java:164)
> >>> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> >>> ProviderFactory.java:110)
> >>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(
> >>> SurefireStarter.java:172)
> >>> at
> >>>
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(
> >>> SurefireStarter.java:78)
> >>> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70
> >>> )
> >>
> >>
> >>
> >> 2011/8/4 Piergiorgio Lucidi
> >>
> >>> Hi Karl,
> >>>
> >>> the integration test implementation is finished and it works fine using
> the
> >>> public Alfresco CMIS server.
> >>>
> >>> But now that I'm using the OpenCMIS InMemory Repository, deployed in
> the
> >>> same Jetty instance of Manifold, I have a problem, it seems that
> starting
> >>> test from the Maven goal, the test can't startup any job, that stay in
> >>> starting state without moving on.
> >>>
> >>> Sometimes it returns the following exception during the startup:
> >>>
> 2011-08-04 16:00:26.172:INFO::Started SocketConnector@0.0.0.0:8346
> java.lang.Exception: API http error; expected 201, saw 200:
> {"error":"No
> current connection."}
> at org.apache.manifoldcf.cmis_tests.Base
Re: CMIS Connector - Tests
Sorry, I meant, "do the API sanity tests work properly for you when
you run them on a clean trunk checkout"?
Karl
On Thu, Aug 4, 2011 at 10:12 AM, Karl Wright wrote:
> This is going to be complicated to debug. I'm happy to help but yes,
> we'll need a branch to work off of. If you can attach the patch file
> I'll try to set everything up this evening.
>
> Do the APISanity tests still work consistently on your setup? The "No
> current connection" error seems like it is coming from some very basic
> level and I would expect it to appear with APISanity as well.
>
> The timeout indicates that the job is not completing. If we can get
> at the log when the test fails before they are cleaned up we will
> probably learn why.
>
> Karl
>
>
> On Thu, Aug 4, 2011 at 10:06 AM, Piergiorgio Lucidi
> wrote:
>> After some minutes sometimes it returns the following exception to check the
>> timeout:
>>
>> org.apache.manifoldcf.core.interfaces.ManifoldCFException: ManifoldCF did
>>> not terminate in the allotted time of 12 milliseconds
>>> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive(
>>> APISanityTest.java:529)
>>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
>>> APISanityTest.java:365)
>>> 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)
>>> at org.junit.internal.runners.model.ReflectiveCallable.run(
>>> ReflectiveCallable.java:15)
>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
>>> FrameworkMethod.java:41)
>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
>>> InvokeMethod.java:20)
>>> at org.junit.internal.runners.statements.RunBefores.evaluate(
>>> RunBefores.java:28)
>>> at org.junit.internal.runners.statements.RunAfters.evaluate(
>>> RunAfters.java:31)
>>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
>>> BlockJUnit4ClassRunner.java:79)
>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
>>> BlockJUnit4ClassRunner.java:71)
>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
>>> BlockJUnit4ClassRunner.java:49)
>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
>>> JUnit4TestSet.java:53)
>>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(
>>> JUnit4Provider.java:123)
>>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
>>> JUnit4Provider.java:104)
>>> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
>>> ReflectionUtils.java:164)
>>> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
>>> ProviderFactory.java:110)
>>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(
>>> SurefireStarter.java:172)
>>> at
>>> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(
>>> SurefireStarter.java:78)
>>> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70
>>> )
>>
>>
>>
>> 2011/8/4 Piergiorgio Lucidi
>>
>>> Hi Karl,
>>>
>>> the integration test implementation is finished and it works fine using the
>>> public Alfresco CMIS server.
>>>
>>> But now that I'm using the OpenCMIS InMemory Repository, deployed in the
>>> same Jetty instance of Manifold, I have a problem, it seems that starting
>>> test from the Maven goal, the test can't startup any job, that stay in
>>> starting state without moving on.
>>>
>>> Sometimes it returns the following exception during the startup:
>>>
2011-08-04 16:00:26.172:INFO::Started SocketConnector@0.0.0.0:8346
java.lang.Exception: API http error; expected 201, saw 200: {"error":"No
current connection."}
at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperation(
Base.java:208)
at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperationViaNodes(
Base.java:271)
at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
APISanityTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at su
Re: CMIS Connector - Tests
This is going to be complicated to debug. I'm happy to help but yes,
we'll need a branch to work off of. If you can attach the patch file
I'll try to set everything up this evening.
Do the APISanity tests still work consistently on your setup? The "No
current connection" error seems like it is coming from some very basic
level and I would expect it to appear with APISanity as well.
The timeout indicates that the job is not completing. If we can get
at the log when the test fails before they are cleaned up we will
probably learn why.
Karl
On Thu, Aug 4, 2011 at 10:06 AM, Piergiorgio Lucidi
wrote:
> After some minutes sometimes it returns the following exception to check the
> timeout:
>
> org.apache.manifoldcf.core.interfaces.ManifoldCFException: ManifoldCF did
>> not terminate in the allotted time of 12 milliseconds
>> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive(
>> APISanityTest.java:529)
>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
>> APISanityTest.java:365)
>> 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)
>> at org.junit.internal.runners.model.ReflectiveCallable.run(
>> ReflectiveCallable.java:15)
>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
>> FrameworkMethod.java:41)
>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
>> InvokeMethod.java:20)
>> at org.junit.internal.runners.statements.RunBefores.evaluate(
>> RunBefores.java:28)
>> at org.junit.internal.runners.statements.RunAfters.evaluate(
>> RunAfters.java:31)
>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
>> BlockJUnit4ClassRunner.java:79)
>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
>> BlockJUnit4ClassRunner.java:71)
>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
>> BlockJUnit4ClassRunner.java:49)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
>> JUnit4TestSet.java:53)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(
>> JUnit4Provider.java:123)
>> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
>> JUnit4Provider.java:104)
>> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
>> ReflectionUtils.java:164)
>> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
>> ProviderFactory.java:110)
>> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(
>> SurefireStarter.java:172)
>> at
>> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(
>> SurefireStarter.java:78)
>> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70
>> )
>
>
>
> 2011/8/4 Piergiorgio Lucidi
>
>> Hi Karl,
>>
>> the integration test implementation is finished and it works fine using the
>> public Alfresco CMIS server.
>>
>> But now that I'm using the OpenCMIS InMemory Repository, deployed in the
>> same Jetty instance of Manifold, I have a problem, it seems that starting
>> test from the Maven goal, the test can't startup any job, that stay in
>> starting state without moving on.
>>
>> Sometimes it returns the following exception during the startup:
>>
>>> 2011-08-04 16:00:26.172:INFO::Started SocketConnector@0.0.0.0:8346
>>> java.lang.Exception: API http error; expected 201, saw 200: {"error":"No
>>> current connection."}
>>> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperation(
>>> Base.java:208)
>>> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperationViaNodes(
>>> Base.java:271)
>>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
>>> APISanityTest.java:264)
>>>
>>> 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.runRe
Re: CMIS Connector - Tests
After some minutes sometimes it returns the following exception to check the
timeout:
org.apache.manifoldcf.core.interfaces.ManifoldCFException: ManifoldCF did
> not terminate in the allotted time of 12 milliseconds
> at org.apache.manifoldcf.cmis_tests.APISanityTest.waitJobInactive(
> APISanityTest.java:529)
> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
> APISanityTest.java:365)
> 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)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
> InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(
> RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
> BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
> JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(
> JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> JUnit4Provider.java:104)
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(
> SurefireStarter.java:172)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(
> SurefireStarter.java:78)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70
> )
2011/8/4 Piergiorgio Lucidi
> Hi Karl,
>
> the integration test implementation is finished and it works fine using the
> public Alfresco CMIS server.
>
> But now that I'm using the OpenCMIS InMemory Repository, deployed in the
> same Jetty instance of Manifold, I have a problem, it seems that starting
> test from the Maven goal, the test can't startup any job, that stay in
> starting state without moving on.
>
> Sometimes it returns the following exception during the startup:
>
>> 2011-08-04 16:00:26.172:INFO::Started SocketConnector@0.0.0.0:8346
>> java.lang.Exception: API http error; expected 201, saw 200: {"error":"No
>> current connection."}
>> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperation(
>> Base.java:208)
>> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperationViaNodes(
>> Base.java:271)
>> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
>> APISanityTest.java:264)
>>
>> 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)
>> at org.junit.internal.runners.model.ReflectiveCallable.run(
>> ReflectiveCallable.java:15)
>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
>> FrameworkMethod.java:41)
>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
>> InvokeMethod.java:20)
>> at org.junit.internal.runners.statements.RunBefores.evaluate(
>> RunBefores.java:28)
>>
>> at org.junit.internal.runners.statements.RunAfters.evaluate(
>> RunAfters.java:31)
>> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
>> BlockJUnit4ClassRunner.java:79)
>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
>> BlockJUnit4ClassRunner.java:71)
>> at org.junit.runners.Bl
Re: CMIS Connector - Tests
Hi Karl,
the integration test implementation is finished and it works fine using the
public Alfresco CMIS server.
But now that I'm using the OpenCMIS InMemory Repository, deployed in the
same Jetty instance of Manifold, I have a problem, it seems that starting
test from the Maven goal, the test can't startup any job, that stay in
starting state without moving on.
Sometimes it returns the following exception during the startup:
> 2011-08-04 16:00:26.172:INFO::Started SocketConnector@0.0.0.0:8346
> java.lang.Exception: API http error; expected 201, saw 200: {"error":"No
> current connection."}
> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperation(
> Base.java:208)
> at org.apache.manifoldcf.cmis_tests.Base.performAPIPutOperationViaNodes(
> Base.java:271)
> at org.apache.manifoldcf.cmis_tests.APISanityTest.sanityCheck(
> APISanityTest.java:264)
> 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)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
> InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(
> RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(
> BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
> JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(
> JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> JUnit4Provider.java:104)
> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(
> SurefireStarter.java:172)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(
> SurefireStarter.java:78)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70
> )
Starting the test from Eclipse it works fine.
Maybe it could be useful to create a branch to solve this problem, to
investigate together.
Then I could attach my patch for integration tests.
Can you help me?
Let me know.
Thank you for your support.
Piergiorgio
2011/8/4 Karl Wright
> Thanks for the update. Let me know if there's anything I can do to help.
>
> Karl
>
> On Thu, Aug 4, 2011 at 4:10 AM, Piergiorgio Lucidi
> wrote:
> > I found a solution to create the right configuration for the CMIS
> Repository
> > Connector in the integration test code, and now it works ;)
> >
> > Chemistry guys are supporting me about an issue that I have found in the
> > OpenCMIS InMemory Repository that I would like to use in the integration
> > test for Manifold.
> >
> > Now I'm finishing the integration test implementation using the public
> > Alfresco CMIS server. Then I can start to test this new version of the
> > InMemory Repository with the bugfix provided by Jens. And I have to
> follow
> > some useful suggestions provided by Florian.
> >
> > I'll let you know soon about all these tasks.
> >
> > Piergiorgio
> >
> > -- Forwarded message --
> > From: Jens Hübel
> > Date: 2011/8/4
> > Subject: RE: CMIS and Lucene
> > To: d...@chemistry.apache.org
> >
> >
> > Hi Piergiorgio,
> >
> > you are right. I could reproduce the problem. There is a bug in the query
> > implementation of the InMemory server if you query for predefined
> properties
> > like cmis:name, cmis:createdBy, etc. :-(
> >
> > I have fixed thi
[jira] [Commented] (CONNECTORS-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079312#comment-13079312 ] Karl Wright commented on CONNECTORS-193: I changed the output connector tab names because users were having problems figuring out what tabs came from the output connectors. r1153836. > Not all output connectors adhere to the standard convention for naming of > tabs, form elements, and javascript methods > - > > Key: CONNECTORS-193 > URL: https://issues.apache.org/jira/browse/CONNECTORS-193 > Project: ManifoldCF > Issue Type: Bug > Components: GTS connector, Lucene/SOLR connector >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 >Reporter: Karl Wright >Assignee: Erlend Garåsen > > The convention for form elements and javascript methods is that all element > names and methods must begin with lowercase "oc". The convention for output > specification tabs is that the tab name should contain the name of the > target, e.g. "GTS Parameters" or "Solr Metadata Mapping". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CMIS Connector - Tests
Thanks for the update. Let me know if there's anything I can do to help.
Karl
On Thu, Aug 4, 2011 at 4:10 AM, Piergiorgio Lucidi
wrote:
> I found a solution to create the right configuration for the CMIS Repository
> Connector in the integration test code, and now it works ;)
>
> Chemistry guys are supporting me about an issue that I have found in the
> OpenCMIS InMemory Repository that I would like to use in the integration
> test for Manifold.
>
> Now I'm finishing the integration test implementation using the public
> Alfresco CMIS server. Then I can start to test this new version of the
> InMemory Repository with the bugfix provided by Jens. And I have to follow
> some useful suggestions provided by Florian.
>
> I'll let you know soon about all these tasks.
>
> Piergiorgio
>
> -- Forwarded message --
> From: Jens Hübel
> Date: 2011/8/4
> Subject: RE: CMIS and Lucene
> To: d...@chemistry.apache.org
>
>
> Hi Piergiorgio,
>
> you are right. I could reproduce the problem. There is a bug in the query
> implementation of the InMemory server if you query for predefined properties
> like cmis:name, cmis:createdBy, etc. :-(
>
> I have fixed this, so hopefully this works for you now if you take the
> latest build. I have created CMIS-413 for this (
> https://issues.apache.org/jira/browse/CMIS-414). Please reopen if you still
> have issues.
>
> One more note: Your test code is quite fragile if you use a fixed name for
> your test document/folder. This implementation does not allow multiple
> objects with the same name in one folder. This means unless you restart the
> server your code will work only once. I recommend you using a random UUID as
> name or something like that. In the default configuration the InMemory
> creates a tree of document and folders by default. So it might not be
> necessary to create objects at all (use the Workbench to take a look at
> that). If you really need this reproducible behavior there is an option to
> run the server using the local binding in the same Java VM. Then you can
> restart the server with each test. The InMemory JUnit tests use this
> mechanism. I do not recommend this however, because you bypass the whole
> protocol layer for AtomPub/SOAP. This leaves many issues undetected a client
> may see in a real connection later (and of course you lose the option to
> switch to another CMIS server just by changing configuration).
>
> Jens
>
>
> -Original Message-
> From: Piergiorgio Lucidi [mailto:piergiorgioluc...@gmail.com]
> Sent: Mittwoch, 3. August 2011 14:48
> To: d...@chemistry.apache.org
> Subject: Re: CMIS and Lucene
>
> Hi Jens,
>
> here the code of my integration test that is used to create some content in
> the InMemory Repository, the OpenCMIS server is running because it is
> bootstrapped by Jetty / Maven. The CMIS Repository Connector works fine with
> Alfresco 3.4d Community, but I would like to have the OpenCMIS server in the
> test suite.
>
> In the following snippet I started to initialize the test environment with a
> new folder with a new content, here I don't have any problem, it works with
> the InMemory Repository:
>
> private Session getCmisClientSession(){
>> // default factory implementation
>> SessionFactory factory = SessionFactoryImpl.newInstance();
>> Map parameters = new HashMap();
>> // user credentials
>> parameters.put(SessionParameter.USER, "dummyuser");
>> parameters.put(SessionParameter.PASSWORD, "dummysecret");
>> // connection settings
>> parameters.put(SessionParameter.ATOMPUB_URL, CMIS_ENDPOINT_TEST_SERVER
>> );
>> parameters.put(SessionParameter.BINDING_TYPE, BindingType.ATOMPUB
>> .value());
>> // create session
>> return factory.getRepositories(parameters).get(0).createSession();
>> }
>> @Before
>> public void createTestArea()
>> throws Exception
>> {
>> try
>> {
>> Session session = getCmisClientSession();
>> //creating a new folder
>> Folder root = session.getRootFolder();
>> Map folderProperties = new HashMap> Object>();
>> folderProperties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:folder");
>> folderProperties.put(PropertyIds.NAME, "testdata");
>>
>> Folder newFolder = root.createFolder(folderProperties);
>> //create a new content in the folder
>> String name = "testdata1.txt";
>> // properties
>> // (minimal set: name and object type id)
>> Map contentProperties = new HashMap> Object>();
>> contentProperties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
>> contentProperties.put(PropertyIds.NAME, name);
>>
>> // content
>> byte[] content = "CMIS Testdata One".getBytes();
>> InputStream stream = new ByteArrayInputStream(content);
>> ContentStream contentStream = new ContentStreamImpl(name,
> newBigInteger(content),
>> "text/plain", stream);
>>
>> // create a major version
>> Document newContent1 = newFolder.createDocumen
Re: CMIS Connector - Tests
I found a solution to create the right configuration for the CMIS Repository
Connector in the integration test code, and now it works ;)
Chemistry guys are supporting me about an issue that I have found in the
OpenCMIS InMemory Repository that I would like to use in the integration
test for Manifold.
Now I'm finishing the integration test implementation using the public
Alfresco CMIS server. Then I can start to test this new version of the
InMemory Repository with the bugfix provided by Jens. And I have to follow
some useful suggestions provided by Florian.
I'll let you know soon about all these tasks.
Piergiorgio
-- Forwarded message --
From: Jens Hübel
Date: 2011/8/4
Subject: RE: CMIS and Lucene
To: d...@chemistry.apache.org
Hi Piergiorgio,
you are right. I could reproduce the problem. There is a bug in the query
implementation of the InMemory server if you query for predefined properties
like cmis:name, cmis:createdBy, etc. :-(
I have fixed this, so hopefully this works for you now if you take the
latest build. I have created CMIS-413 for this (
https://issues.apache.org/jira/browse/CMIS-414). Please reopen if you still
have issues.
One more note: Your test code is quite fragile if you use a fixed name for
your test document/folder. This implementation does not allow multiple
objects with the same name in one folder. This means unless you restart the
server your code will work only once. I recommend you using a random UUID as
name or something like that. In the default configuration the InMemory
creates a tree of document and folders by default. So it might not be
necessary to create objects at all (use the Workbench to take a look at
that). If you really need this reproducible behavior there is an option to
run the server using the local binding in the same Java VM. Then you can
restart the server with each test. The InMemory JUnit tests use this
mechanism. I do not recommend this however, because you bypass the whole
protocol layer for AtomPub/SOAP. This leaves many issues undetected a client
may see in a real connection later (and of course you lose the option to
switch to another CMIS server just by changing configuration).
Jens
-Original Message-
From: Piergiorgio Lucidi [mailto:piergiorgioluc...@gmail.com]
Sent: Mittwoch, 3. August 2011 14:48
To: d...@chemistry.apache.org
Subject: Re: CMIS and Lucene
Hi Jens,
here the code of my integration test that is used to create some content in
the InMemory Repository, the OpenCMIS server is running because it is
bootstrapped by Jetty / Maven. The CMIS Repository Connector works fine with
Alfresco 3.4d Community, but I would like to have the OpenCMIS server in the
test suite.
In the following snippet I started to initialize the test environment with a
new folder with a new content, here I don't have any problem, it works with
the InMemory Repository:
private Session getCmisClientSession(){
> // default factory implementation
> SessionFactory factory = SessionFactoryImpl.newInstance();
> Map parameters = new HashMap();
> // user credentials
> parameters.put(SessionParameter.USER, "dummyuser");
> parameters.put(SessionParameter.PASSWORD, "dummysecret");
> // connection settings
> parameters.put(SessionParameter.ATOMPUB_URL, CMIS_ENDPOINT_TEST_SERVER
> );
> parameters.put(SessionParameter.BINDING_TYPE, BindingType.ATOMPUB
> .value());
> // create session
> return factory.getRepositories(parameters).get(0).createSession();
> }
> @Before
> public void createTestArea()
> throws Exception
> {
> try
> {
> Session session = getCmisClientSession();
> //creating a new folder
> Folder root = session.getRootFolder();
> Map folderProperties = new HashMap Object>();
> folderProperties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:folder");
> folderProperties.put(PropertyIds.NAME, "testdata");
>
> Folder newFolder = root.createFolder(folderProperties);
> //create a new content in the folder
> String name = "testdata1.txt";
> // properties
> // (minimal set: name and object type id)
> Map contentProperties = new HashMap Object>();
> contentProperties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
> contentProperties.put(PropertyIds.NAME, name);
>
> // content
> byte[] content = "CMIS Testdata One".getBytes();
> InputStream stream = new ByteArrayInputStream(content);
> ContentStream contentStream = new ContentStreamImpl(name,
newBigInteger(content),
> "text/plain", stream);
>
>// create a major version
> Document newContent1 = newFolder.createDocument(contentProperties,
> contentStream, null);
But if I try to search the new content in the InMemory Repository, in the
same way I implemented in the CMIS Repository Connector:
ItemIterable results = session.query("SELECT * FROM
> cmis:folder WHERE cmis:name='testdata'", false);
> for (QueryResult resul
