[jira] [Commented] (CONNECTORS-221) A CMIS connector would be helpful
[ https://issues.apache.org/jira/browse/CONNECTORS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067324#comment-13067324 ] Karl Wright commented on CONNECTORS-221: Committed these changes to the branch. r1148064. > A CMIS connector would be helpful > - > > Key: CONNECTORS-221 > URL: https://issues.apache.org/jira/browse/CONNECTORS-221 > Project: ManifoldCF > Issue Type: New Feature > Components: CMIS connector >Affects Versions: ManifoldCF 0.3 >Reporter: Karl Wright > Attachments: CONNECTORS-221-DEPENDENCIES.txt, > CONNECTORS-221-Java.txt, CONNECTORS-221-branch-build-patch-2.txt, > CONNECTORS-221-branch-build-patch-3.txt, > CONNECTORS-221-branch-java-patch-2.txt, > CONNECTORS-221-branch-java-patch-3.txt, CONNECTORS-221-branch-java-patch.txt, > CONNECTORS-221-build-example-patch.txt, CONNECTORS-221.txt, > CONNECTORS-221.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, > screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg, screenshot-7.jpg, > screenshot-8.jpg > > > Several people have asked if ManifoldCF supports CMIS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-221) A CMIS connector would be helpful
[ https://issues.apache.org/jira/browse/CONNECTORS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067179#comment-13067179 ] Karl Wright commented on CONNECTORS-221: Patch looks good; I'll commit it to the branch this evening. I'm still waiting on confirmation that the substitution of the newer saaj.jar doesn't break our current version of Axis before merging into trunk. I posted to news hoping to find a SharePoint or Meridio user who would be willing to test this, but no answer so far. Setting up a SharePoint 2010 instance on Amazon EC2 is likely to be time consuming and require expenditure, but that's all I can think to do. Alternatively, I can commit the code as it stands and wait for somebody to complain if it doesn't work properly, but that's a lousy way to do software development. A final alternative is just setting up a testbed SOAP web server that receives requests and responds accordingly. This might actually be the easiest thing to do, perhaps with something like cherrypy. > A CMIS connector would be helpful > - > > Key: CONNECTORS-221 > URL: https://issues.apache.org/jira/browse/CONNECTORS-221 > Project: ManifoldCF > Issue Type: New Feature > Components: CMIS connector >Affects Versions: ManifoldCF 0.3 >Reporter: Karl Wright > Attachments: CONNECTORS-221-DEPENDENCIES.txt, > CONNECTORS-221-Java.txt, CONNECTORS-221-branch-build-patch-2.txt, > CONNECTORS-221-branch-build-patch-3.txt, > CONNECTORS-221-branch-java-patch-2.txt, > CONNECTORS-221-branch-java-patch-3.txt, CONNECTORS-221-branch-java-patch.txt, > CONNECTORS-221-build-example-patch.txt, CONNECTORS-221.txt, > CONNECTORS-221.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, > screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg, screenshot-7.jpg, > screenshot-8.jpg > > > Several people have asked if ManifoldCF supports CMIS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-221) A CMIS connector would be helpful
[ https://issues.apache.org/jira/browse/CONNECTORS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-221: -- Attachment: CONNECTORS-221-branch-java-patch-3.txt This patch add the CMIS Authority Connector: now it supports only the regular expression checker for usernames. > A CMIS connector would be helpful > - > > Key: CONNECTORS-221 > URL: https://issues.apache.org/jira/browse/CONNECTORS-221 > Project: ManifoldCF > Issue Type: New Feature > Components: CMIS connector >Affects Versions: ManifoldCF 0.3 >Reporter: Karl Wright > Attachments: CONNECTORS-221-DEPENDENCIES.txt, > CONNECTORS-221-Java.txt, CONNECTORS-221-branch-build-patch-2.txt, > CONNECTORS-221-branch-build-patch-3.txt, > CONNECTORS-221-branch-java-patch-2.txt, > CONNECTORS-221-branch-java-patch-3.txt, CONNECTORS-221-branch-java-patch.txt, > CONNECTORS-221-build-example-patch.txt, CONNECTORS-221.txt, > CONNECTORS-221.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, > screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg, screenshot-7.jpg, > screenshot-8.jpg > > > Several people have asked if ManifoldCF supports CMIS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONNECTORS-221) A CMIS connector would be helpful
[ https://issues.apache.org/jira/browse/CONNECTORS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piergiorgio Lucidi updated CONNECTORS-221: -- Attachment: CONNECTORS-221-branch-build-patch-3.txt This patch will generate the new CMIS Authority Connector configuration parameter in the example application inside the connectors.xml file. > A CMIS connector would be helpful > - > > Key: CONNECTORS-221 > URL: https://issues.apache.org/jira/browse/CONNECTORS-221 > Project: ManifoldCF > Issue Type: New Feature > Components: CMIS connector >Affects Versions: ManifoldCF 0.3 >Reporter: Karl Wright > Attachments: CONNECTORS-221-DEPENDENCIES.txt, > CONNECTORS-221-Java.txt, CONNECTORS-221-branch-build-patch-2.txt, > CONNECTORS-221-branch-build-patch-3.txt, > CONNECTORS-221-branch-java-patch-2.txt, CONNECTORS-221-branch-java-patch.txt, > CONNECTORS-221-build-example-patch.txt, CONNECTORS-221.txt, > CONNECTORS-221.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, > screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg, screenshot-7.jpg, > screenshot-8.jpg > > > Several people have asked if ManifoldCF supports CMIS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: invalid unit tests
So please let me know if I should commit the patch I created which allows tests to run all in the same JVM. It's reasonably harmless (I think), but I'd not want to commit it if it was unnecessary. Thanks, Karl On Mon, Jul 18, 2011 at 10:26 AM, Tobias Rübner wrote: > Ahh ok, sorry for that! > I run all the tests of a module at once. That leads to confusing results. > Now I would also structure the tests in maven to run the derby tests per > default. > All other test must be invoked through different profiles. > > Tobias > > > > On Mon, Jul 18, 2011 at 3:58 PM, Karl Wright wrote: > >> run-tests-framework only invokes the Derby tests. That's why you are >> not seeing any others. >> >> Karl >> >> On Mon, Jul 18, 2011 at 9:50 AM, Tobias Rübner wrote: >> > Maybe I'm on the wrong track, but there are currently 2 modules (agents | >> > pull-agent) containing 3 individual test cases (Derby, HSQLDB, >> postgresql). >> > In maven I run the test for the agents module and I thought I would end >> up >> > with 3 "Configuration file successfully read" messages, because each Test >> > would like to create its own properties files. >> > So, for building the framework with ant I supposed ending up with 6 >> > "Configuration file successfully read" messages. >> > >> > Let's take as example the >> > org.apache.manifoldcf.agents.tests.SanityPostgresqlTest of the agents >> > module. >> > On the localSetUp method of the parent class >> > (org.apache.manifoldcf.core.tests.BasePostgresql) is >> > org.apache.manifoldcf.core.database.DBInterfacePostgreSQL as database >> > implementation class defined. >> > I supposed to see this class name as implementationClass output in my >> > previous message. >> > >> > Tobias >> > >> > >> > >> > On Mon, Jul 18, 2011 at 3:22 PM, Karl Wright wrote: >> > >> >> Each time you see "Configuration file successfully read" it indicates >> >> that isInitialized must have been false. Since there is more than one >> >> of these it is clear that in ant you are getting two process >> >> initializations. This makes perfect sense in that two tests are being >> >> invoked. So the process model is working as expected under ant. >> >> >> >> Do you mind telling us what "side effects" are you seeing? >> >> >> >> Karl >> >> >> >> >> >> On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner wrote: >> >> > I rerun the tests with ant and ended up with the same side effects. >> >> > I did a svn update and added some logging information to the >> framework. >> >> > Now I'm logging the database implemention class (DBInterfaceFactory - >> >> > make()) and the initialization status on the Manifold class >> >> > (initializeEnvironment()). >> >> > I started the ant build from the mcf root directory with the following >> >> > command: >> >> > "ant clean build run-tests-framework" >> >> > >> >> > >> >> > run-tests: >> >> > [mkdir] Created dir: >> >> > /home/tobr/dev/workspace/apache-mcf/framework/test-output >> >> > [junit] Configuration file successfully read >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] isInitialized: true >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] isInitialized: true >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] Configuration file successfully read >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] isInitialized: true >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] isInitialized: true >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] isInitialized: true >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > [junit] implementationClass: >> >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> >> > >> >> > BUILD SUCCESSFUL >> >> > >> >> > >> >> > >> >> > >> >> > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright >> wrote: >> >> > >> >> >> Looking at this a little more, the proper cleanup of a ManifoldCF >> >> >> process requires that the shutdown thread be run. This thread is >> >> >> added as a shutdown hook to the JVM.
Re: invalid unit tests
Ahh ok, sorry for that! I run all the tests of a module at once. That leads to confusing results. Now I would also structure the tests in maven to run the derby tests per default. All other test must be invoked through different profiles. Tobias On Mon, Jul 18, 2011 at 3:58 PM, Karl Wright wrote: > run-tests-framework only invokes the Derby tests. That's why you are > not seeing any others. > > Karl > > On Mon, Jul 18, 2011 at 9:50 AM, Tobias Rübner wrote: > > Maybe I'm on the wrong track, but there are currently 2 modules (agents | > > pull-agent) containing 3 individual test cases (Derby, HSQLDB, > postgresql). > > In maven I run the test for the agents module and I thought I would end > up > > with 3 "Configuration file successfully read" messages, because each Test > > would like to create its own properties files. > > So, for building the framework with ant I supposed ending up with 6 > > "Configuration file successfully read" messages. > > > > Let's take as example the > > org.apache.manifoldcf.agents.tests.SanityPostgresqlTest of the agents > > module. > > On the localSetUp method of the parent class > > (org.apache.manifoldcf.core.tests.BasePostgresql) is > > org.apache.manifoldcf.core.database.DBInterfacePostgreSQL as database > > implementation class defined. > > I supposed to see this class name as implementationClass output in my > > previous message. > > > > Tobias > > > > > > > > On Mon, Jul 18, 2011 at 3:22 PM, Karl Wright wrote: > > > >> Each time you see "Configuration file successfully read" it indicates > >> that isInitialized must have been false. Since there is more than one > >> of these it is clear that in ant you are getting two process > >> initializations. This makes perfect sense in that two tests are being > >> invoked. So the process model is working as expected under ant. > >> > >> Do you mind telling us what "side effects" are you seeing? > >> > >> Karl > >> > >> > >> On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner wrote: > >> > I rerun the tests with ant and ended up with the same side effects. > >> > I did a svn update and added some logging information to the > framework. > >> > Now I'm logging the database implemention class (DBInterfaceFactory - > >> > make()) and the initialization status on the Manifold class > >> > (initializeEnvironment()). > >> > I started the ant build from the mcf root directory with the following > >> > command: > >> > "ant clean build run-tests-framework" > >> > > >> > > >> > run-tests: > >> >[mkdir] Created dir: > >> > /home/tobr/dev/workspace/apache-mcf/framework/test-output > >> >[junit] Configuration file successfully read > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] isInitialized: true > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] isInitialized: true > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] Configuration file successfully read > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] isInitialized: true > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] isInitialized: true > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] isInitialized: true > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> >[junit] implementationClass: > >> > org.apache.manifoldcf.core.database.DBInterfaceDerby > >> > > >> > BUILD SUCCESSFUL > >> > > >> > > >> > > >> > > >> > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright > wrote: > >> > > >> >> Looking at this a little more, the proper cleanup of a ManifoldCF > >> >> process requires that the shutdown thread be run. This thread is > >> >> added as a shutdown hook to the JVM. The "alreadyClosed" flag is > used > >> >> to prevent it from being run more than once if more than one shutdown > >> >> signal is received, since it's also executed during object > >> >> finalization (so that we catch termination within Tomcat and other > >> >> application servers). > >> >> > >> >> So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed > >> >> perform this
Re: invalid unit tests
run-tests-framework only invokes the Derby tests. That's why you are not seeing any others. Karl On Mon, Jul 18, 2011 at 9:50 AM, Tobias Rübner wrote: > Maybe I'm on the wrong track, but there are currently 2 modules (agents | > pull-agent) containing 3 individual test cases (Derby, HSQLDB, postgresql). > In maven I run the test for the agents module and I thought I would end up > with 3 "Configuration file successfully read" messages, because each Test > would like to create its own properties files. > So, for building the framework with ant I supposed ending up with 6 > "Configuration file successfully read" messages. > > Let's take as example the > org.apache.manifoldcf.agents.tests.SanityPostgresqlTest of the agents > module. > On the localSetUp method of the parent class > (org.apache.manifoldcf.core.tests.BasePostgresql) is > org.apache.manifoldcf.core.database.DBInterfacePostgreSQL as database > implementation class defined. > I supposed to see this class name as implementationClass output in my > previous message. > > Tobias > > > > On Mon, Jul 18, 2011 at 3:22 PM, Karl Wright wrote: > >> Each time you see "Configuration file successfully read" it indicates >> that isInitialized must have been false. Since there is more than one >> of these it is clear that in ant you are getting two process >> initializations. This makes perfect sense in that two tests are being >> invoked. So the process model is working as expected under ant. >> >> Do you mind telling us what "side effects" are you seeing? >> >> Karl >> >> >> On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner wrote: >> > I rerun the tests with ant and ended up with the same side effects. >> > I did a svn update and added some logging information to the framework. >> > Now I'm logging the database implemention class (DBInterfaceFactory - >> > make()) and the initialization status on the Manifold class >> > (initializeEnvironment()). >> > I started the ant build from the mcf root directory with the following >> > command: >> > "ant clean build run-tests-framework" >> > >> > >> > run-tests: >> > [mkdir] Created dir: >> > /home/tobr/dev/workspace/apache-mcf/framework/test-output >> > [junit] Configuration file successfully read >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] isInitialized: true >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] isInitialized: true >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] Configuration file successfully read >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] isInitialized: true >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] isInitialized: true >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] isInitialized: true >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > [junit] implementationClass: >> > org.apache.manifoldcf.core.database.DBInterfaceDerby >> > >> > BUILD SUCCESSFUL >> > >> > >> > >> > >> > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright wrote: >> > >> >> Looking at this a little more, the proper cleanup of a ManifoldCF >> >> process requires that the shutdown thread be run. This thread is >> >> added as a shutdown hook to the JVM. The "alreadyClosed" flag is used >> >> to prevent it from being run more than once if more than one shutdown >> >> signal is received, since it's also executed during object >> >> finalization (so that we catch termination within Tomcat and other >> >> application servers). >> >> >> >> So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed >> >> perform this coordinated dance on a per-JVM basis. ManifoldCF system >> >> initialization is meant to occur once per JVM. Without starting and >> >> stopping a JVM, it's therefore not a realistic test. Is there any way >> >> for Maven to run each test class in its own JVM, or does it insist on >> >> running them all within one? >> >> >> >> If there is no such possibility, we can look to adding a manual >> >> shutdown thread invocation in a reset method. There are lots of >> >> potential problems with this approach in that dangling
Re: invalid unit tests
Maybe I'm on the wrong track, but there are currently 2 modules (agents | pull-agent) containing 3 individual test cases (Derby, HSQLDB, postgresql). In maven I run the test for the agents module and I thought I would end up with 3 "Configuration file successfully read" messages, because each Test would like to create its own properties files. So, for building the framework with ant I supposed ending up with 6 "Configuration file successfully read" messages. Let's take as example the org.apache.manifoldcf.agents.tests.SanityPostgresqlTest of the agents module. On the localSetUp method of the parent class (org.apache.manifoldcf.core.tests.BasePostgresql) is org.apache.manifoldcf.core.database.DBInterfacePostgreSQL as database implementation class defined. I supposed to see this class name as implementationClass output in my previous message. Tobias On Mon, Jul 18, 2011 at 3:22 PM, Karl Wright wrote: > Each time you see "Configuration file successfully read" it indicates > that isInitialized must have been false. Since there is more than one > of these it is clear that in ant you are getting two process > initializations. This makes perfect sense in that two tests are being > invoked. So the process model is working as expected under ant. > > Do you mind telling us what "side effects" are you seeing? > > Karl > > > On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner wrote: > > I rerun the tests with ant and ended up with the same side effects. > > I did a svn update and added some logging information to the framework. > > Now I'm logging the database implemention class (DBInterfaceFactory - > > make()) and the initialization status on the Manifold class > > (initializeEnvironment()). > > I started the ant build from the mcf root directory with the following > > command: > > "ant clean build run-tests-framework" > > > > > > run-tests: > >[mkdir] Created dir: > > /home/tobr/dev/workspace/apache-mcf/framework/test-output > >[junit] Configuration file successfully read > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] isInitialized: true > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] isInitialized: true > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] Configuration file successfully read > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] isInitialized: true > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] isInitialized: true > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] isInitialized: true > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > >[junit] implementationClass: > > org.apache.manifoldcf.core.database.DBInterfaceDerby > > > > BUILD SUCCESSFUL > > > > > > > > > > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright wrote: > > > >> Looking at this a little more, the proper cleanup of a ManifoldCF > >> process requires that the shutdown thread be run. This thread is > >> added as a shutdown hook to the JVM. The "alreadyClosed" flag is used > >> to prevent it from being run more than once if more than one shutdown > >> signal is received, since it's also executed during object > >> finalization (so that we catch termination within Tomcat and other > >> application servers). > >> > >> So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed > >> perform this coordinated dance on a per-JVM basis. ManifoldCF system > >> initialization is meant to occur once per JVM. Without starting and > >> stopping a JVM, it's therefore not a realistic test. Is there any way > >> for Maven to run each test class in its own JVM, or does it insist on > >> running them all within one? > >> > >> If there is no such possibility, we can look to adding a manual > >> shutdown thread invocation in a reset method. There are lots of > >> potential problems with this approach in that dangling temporary > >> threads that are waiting forever on sockets etc might be left around > >> from previous tests, and other JVM static state such as the cache > >> might also not get cleared, but the tests would probably execute > >> nonetheless. > >> > >> Karl > >> > >> > >> On Mon, Ju
Re: invalid unit tests
Each time you see "Configuration file successfully read" it indicates that isInitialized must have been false. Since there is more than one of these it is clear that in ant you are getting two process initializations. This makes perfect sense in that two tests are being invoked. So the process model is working as expected under ant. Do you mind telling us what "side effects" are you seeing? Karl On Mon, Jul 18, 2011 at 9:12 AM, Tobias Rübner wrote: > I rerun the tests with ant and ended up with the same side effects. > I did a svn update and added some logging information to the framework. > Now I'm logging the database implemention class (DBInterfaceFactory - > make()) and the initialization status on the Manifold class > (initializeEnvironment()). > I started the ant build from the mcf root directory with the following > command: > "ant clean build run-tests-framework" > > > run-tests: > [mkdir] Created dir: > /home/tobr/dev/workspace/apache-mcf/framework/test-output > [junit] Configuration file successfully read > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] isInitialized: true > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] isInitialized: true > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] Configuration file successfully read > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] isInitialized: true > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] isInitialized: true > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] isInitialized: true > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > [junit] implementationClass: > org.apache.manifoldcf.core.database.DBInterfaceDerby > > BUILD SUCCESSFUL > > > > > On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright wrote: > >> Looking at this a little more, the proper cleanup of a ManifoldCF >> process requires that the shutdown thread be run. This thread is >> added as a shutdown hook to the JVM. The "alreadyClosed" flag is used >> to prevent it from being run more than once if more than one shutdown >> signal is received, since it's also executed during object >> finalization (so that we catch termination within Tomcat and other >> application servers). >> >> So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed >> perform this coordinated dance on a per-JVM basis. ManifoldCF system >> initialization is meant to occur once per JVM. Without starting and >> stopping a JVM, it's therefore not a realistic test. Is there any way >> for Maven to run each test class in its own JVM, or does it insist on >> running them all within one? >> >> If there is no such possibility, we can look to adding a manual >> shutdown thread invocation in a reset method. There are lots of >> potential problems with this approach in that dangling temporary >> threads that are waiting forever on sockets etc might be left around >> from previous tests, and other JVM static state such as the cache >> might also not get cleared, but the tests would probably execute >> nonetheless. >> >> Karl >> >> >> On Mon, Jul 18, 2011 at 8:26 AM, Karl Wright wrote: >> > I think the likely difference is that ant is running each test in its >> > own JVM, and Maven is not. >> > >> > Now, it is straightforward enough to add functionality that resets the >> > ManifoldCF core classes, and tie that into the tests. However, that >> > is not how ManifoldCF will be used in practice. The concern I have is >> > that there are other static variables (for instance, the cache >> > manager) which are never "reset", but would be if we need to "start >> > from scratch" again inside the same JVM every time a test is run. >> > Identifying all such cases may take some time. >> > >> > Karl >> > >> > >> > On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright wrote: >> >> These tests run fine under ant, but the ant build invokes test files >> >> explicitly. I'm not quite sure what Ant's behavior is here, and how >> >> exactly it differs from Maven's. >> >> >> >> Karl >> >> >> >> On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: >> >>> The unit tests are currently not working. >> >>> The first test in a module creates the propertie
Re: invalid unit tests
I rerun the tests with ant and ended up with the same side effects. I did a svn update and added some logging information to the framework. Now I'm logging the database implemention class (DBInterfaceFactory - make()) and the initialization status on the Manifold class (initializeEnvironment()). I started the ant build from the mcf root directory with the following command: "ant clean build run-tests-framework" run-tests: [mkdir] Created dir: /home/tobr/dev/workspace/apache-mcf/framework/test-output [junit] Configuration file successfully read [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] isInitialized: true [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] isInitialized: true [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] Configuration file successfully read [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] isInitialized: true [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] isInitialized: true [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] isInitialized: true [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby [junit] implementationClass: org.apache.manifoldcf.core.database.DBInterfaceDerby BUILD SUCCESSFUL On Mon, Jul 18, 2011 at 2:49 PM, Karl Wright wrote: > Looking at this a little more, the proper cleanup of a ManifoldCF > process requires that the shutdown thread be run. This thread is > added as a shutdown hook to the JVM. The "alreadyClosed" flag is used > to prevent it from being run more than once if more than one shutdown > signal is received, since it's also executed during object > finalization (so that we catch termination within Tomcat and other > application servers). > > So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed > perform this coordinated dance on a per-JVM basis. ManifoldCF system > initialization is meant to occur once per JVM. Without starting and > stopping a JVM, it's therefore not a realistic test. Is there any way > for Maven to run each test class in its own JVM, or does it insist on > running them all within one? > > If there is no such possibility, we can look to adding a manual > shutdown thread invocation in a reset method. There are lots of > potential problems with this approach in that dangling temporary > threads that are waiting forever on sockets etc might be left around > from previous tests, and other JVM static state such as the cache > might also not get cleared, but the tests would probably execute > nonetheless. > > Karl > > > On Mon, Jul 18, 2011 at 8:26 AM, Karl Wright wrote: > > I think the likely difference is that ant is running each test in its > > own JVM, and Maven is not. > > > > Now, it is straightforward enough to add functionality that resets the > > ManifoldCF core classes, and tie that into the tests. However, that > > is not how ManifoldCF will be used in practice. The concern I have is > > that there are other static variables (for instance, the cache > > manager) which are never "reset", but would be if we need to "start > > from scratch" again inside the same JVM every time a test is run. > > Identifying all such cases may take some time. > > > > Karl > > > > > > On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright wrote: > >> These tests run fine under ant, but the ant build invokes test files > >> explicitly. I'm not quite sure what Ant's behavior is here, and how > >> exactly it differs from Maven's. > >> > >> Karl > >> > >> On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: > >>> The unit tests are currently not working. > >>> The first test in a module creates the properties and logging files and > >>> initializes the framework. > >>> All following tests are also creating those files, but because the > framework > >>> is already initialized, they are useless. > >>> > >>> This depends on the static behaviour of ManifoldCF.isInitialized. > >>> After a test is done the ManifoldCF Object should also be reseted. > >>> > >> > > >
Re: invalid unit tests
I've attached a patch which, given the caveats already mentioned, should allow a single-process model to execute the tests. Please let me know if it seems to work for you. Karl On Mon, Jul 18, 2011 at 8:49 AM, Karl Wright wrote: > Looking at this a little more, the proper cleanup of a ManifoldCF > process requires that the shutdown thread be run. This thread is > added as a shutdown hook to the JVM. The "alreadyClosed" flag is used > to prevent it from being run more than once if more than one shutdown > signal is received, since it's also executed during object > finalization (so that we catch termination within Tomcat and other > application servers). > > So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed > perform this coordinated dance on a per-JVM basis. ManifoldCF system > initialization is meant to occur once per JVM. Without starting and > stopping a JVM, it's therefore not a realistic test. Is there any way > for Maven to run each test class in its own JVM, or does it insist on > running them all within one? > > If there is no such possibility, we can look to adding a manual > shutdown thread invocation in a reset method. There are lots of > potential problems with this approach in that dangling temporary > threads that are waiting forever on sockets etc might be left around > from previous tests, and other JVM static state such as the cache > might also not get cleared, but the tests would probably execute > nonetheless. > > Karl > > > On Mon, Jul 18, 2011 at 8:26 AM, Karl Wright wrote: >> I think the likely difference is that ant is running each test in its >> own JVM, and Maven is not. >> >> Now, it is straightforward enough to add functionality that resets the >> ManifoldCF core classes, and tie that into the tests. However, that >> is not how ManifoldCF will be used in practice. The concern I have is >> that there are other static variables (for instance, the cache >> manager) which are never "reset", but would be if we need to "start >> from scratch" again inside the same JVM every time a test is run. >> Identifying all such cases may take some time. >> >> Karl >> >> >> On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright wrote: >>> These tests run fine under ant, but the ant build invokes test files >>> explicitly. I'm not quite sure what Ant's behavior is here, and how >>> exactly it differs from Maven's. >>> >>> Karl >>> >>> On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: The unit tests are currently not working. The first test in a module creates the properties and logging files and initializes the framework. All following tests are also creating those files, but because the framework is already initialized, they are useless. This depends on the static behaviour of ManifoldCF.isInitialized. After a test is done the ManifoldCF Object should also be reseted. >>> >> >
Re: invalid unit tests
Looking at this a little more, the proper cleanup of a ManifoldCF process requires that the shutdown thread be run. This thread is added as a shutdown hook to the JVM. The "alreadyClosed" flag is used to prevent it from being run more than once if more than one shutdown signal is received, since it's also executed during object finalization (so that we catch termination within Tomcat and other application servers). So, basically, ManifoldCF.isInitialized and ManifoldCF.alreadyClosed perform this coordinated dance on a per-JVM basis. ManifoldCF system initialization is meant to occur once per JVM. Without starting and stopping a JVM, it's therefore not a realistic test. Is there any way for Maven to run each test class in its own JVM, or does it insist on running them all within one? If there is no such possibility, we can look to adding a manual shutdown thread invocation in a reset method. There are lots of potential problems with this approach in that dangling temporary threads that are waiting forever on sockets etc might be left around from previous tests, and other JVM static state such as the cache might also not get cleared, but the tests would probably execute nonetheless. Karl On Mon, Jul 18, 2011 at 8:26 AM, Karl Wright wrote: > I think the likely difference is that ant is running each test in its > own JVM, and Maven is not. > > Now, it is straightforward enough to add functionality that resets the > ManifoldCF core classes, and tie that into the tests. However, that > is not how ManifoldCF will be used in practice. The concern I have is > that there are other static variables (for instance, the cache > manager) which are never "reset", but would be if we need to "start > from scratch" again inside the same JVM every time a test is run. > Identifying all such cases may take some time. > > Karl > > > On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright wrote: >> These tests run fine under ant, but the ant build invokes test files >> explicitly. I'm not quite sure what Ant's behavior is here, and how >> exactly it differs from Maven's. >> >> Karl >> >> On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: >>> The unit tests are currently not working. >>> The first test in a module creates the properties and logging files and >>> initializes the framework. >>> All following tests are also creating those files, but because the framework >>> is already initialized, they are useless. >>> >>> This depends on the static behaviour of ManifoldCF.isInitialized. >>> After a test is done the ManifoldCF Object should also be reseted. >>> >> >
Re: invalid unit tests
I think the likely difference is that ant is running each test in its own JVM, and Maven is not. Now, it is straightforward enough to add functionality that resets the ManifoldCF core classes, and tie that into the tests. However, that is not how ManifoldCF will be used in practice. The concern I have is that there are other static variables (for instance, the cache manager) which are never "reset", but would be if we need to "start from scratch" again inside the same JVM every time a test is run. Identifying all such cases may take some time. Karl On Mon, Jul 18, 2011 at 8:04 AM, Karl Wright wrote: > These tests run fine under ant, but the ant build invokes test files > explicitly. I'm not quite sure what Ant's behavior is here, and how > exactly it differs from Maven's. > > Karl > > On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: >> The unit tests are currently not working. >> The first test in a module creates the properties and logging files and >> initializes the framework. >> All following tests are also creating those files, but because the framework >> is already initialized, they are useless. >> >> This depends on the static behaviour of ManifoldCF.isInitialized. >> After a test is done the ManifoldCF Object should also be reseted. >> >
[jira] [Commented] (CONNECTORS-223) Tests in project hierarchy do not adhere to maven conventions
[ https://issues.apache.org/jira/browse/CONNECTORS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066923#comment-13066923 ] Karl Wright commented on CONNECTORS-223: The only requirement I have for creation of the test databases and configuration files is that it must be possible to have multiple workareas checked out with on tests running on each so that the tests do not collide with one another. Setting up paths that depend on resources may therefore not work. Other than than, I'm open to any patch you want to propose. > Tests in project hierarchy do not adhere to maven conventions > - > > Key: CONNECTORS-223 > URL: https://issues.apache.org/jira/browse/CONNECTORS-223 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.3 > > > Maven expects unit tests under .../src/test/java, and root-level project > tests under tests/xxx/src/test/java (or equivalent, along with their own > pom.xml at tests and tests/xxx). This is basically compatible with the ant > build except in location detail. The proposal is to move stuff around to > make the tests work with maven. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: invalid unit tests
These tests run fine under ant, but the ant build invokes test files explicitly. I'm not quite sure what Ant's behavior is here, and how exactly it differs from Maven's. Karl On Mon, Jul 18, 2011 at 7:41 AM, Tobias Rübner wrote: > The unit tests are currently not working. > The first test in a module creates the properties and logging files and > initializes the framework. > All following tests are also creating those files, but because the framework > is already initialized, they are useless. > > This depends on the static behaviour of ManifoldCF.isInitialized. > After a test is done the ManifoldCF Object should also be reseted. >
invalid unit tests
The unit tests are currently not working. The first test in a module creates the properties and logging files and initializes the framework. All following tests are also creating those files, but because the framework is already initialized, they are useless. This depends on the static behaviour of ManifoldCF.isInitialized. After a test is done the ManifoldCF Object should also be reseted.
[jira] [Commented] (CONNECTORS-223) Tests in project hierarchy do not adhere to maven conventions
[
https://issues.apache.org/jira/browse/CONNECTORS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066858#comment-13066858
]
Tobias Rübner commented on CONNECTORS-223:
--
Thank you. Now I run into some other problems.
Running the tests creates the databses files in the root directory of the
module.
This depends on the test configuration defined in
org.apache.manifoldcf.core.tests.BaseHSQLDB.
Maybe we could change that path to the test classpath
{code}
currentPath = new File(".").getCanonicalFile();
//currentPath = new
File(this.getClass().getClassLoader().getResource(".").getPath()).getCanonicalFile();
{code}
> Tests in project hierarchy do not adhere to maven conventions
> -
>
> Key: CONNECTORS-223
> URL: https://issues.apache.org/jira/browse/CONNECTORS-223
> Project: ManifoldCF
> Issue Type: Bug
> Components: Build
>Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.3
>
>
> Maven expects unit tests under .../src/test/java, and root-level project
> tests under tests/xxx/src/test/java (or equivalent, along with their own
> pom.xml at tests and tests/xxx). This is basically compatible with the ant
> build except in location detail. The proposal is to move stuff around to
> make the tests work with maven.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-221) A CMIS connector would be helpful
[ https://issues.apache.org/jira/browse/CONNECTORS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066852#comment-13066852 ] Piergiorgio Lucidi commented on CONNECTORS-221: --- Ok, thank you for your suggestions! I think that during these days I will work on the CMIS Authority Connector. I hope to release a new patch file soon. I'll let you know all the updates about this. > A CMIS connector would be helpful > - > > Key: CONNECTORS-221 > URL: https://issues.apache.org/jira/browse/CONNECTORS-221 > Project: ManifoldCF > Issue Type: New Feature > Components: CMIS connector >Affects Versions: ManifoldCF 0.3 >Reporter: Karl Wright > Attachments: CONNECTORS-221-DEPENDENCIES.txt, > CONNECTORS-221-Java.txt, CONNECTORS-221-branch-build-patch-2.txt, > CONNECTORS-221-branch-java-patch-2.txt, CONNECTORS-221-branch-java-patch.txt, > CONNECTORS-221-build-example-patch.txt, CONNECTORS-221.txt, > CONNECTORS-221.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, > screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg, screenshot-7.jpg, > screenshot-8.jpg > > > Several people have asked if ManifoldCF supports CMIS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
