Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: ManifoldCF 0.3
    • Fix Version/s: ManifoldCF 0.3
    • Component/s: CMIS connector
    • Labels:
      None

      Description

      Several people have asked if ManifoldCF supports CMIS.

      1. CONNECTORS-221.txt
        38 kB
        Piergiorgio Lucidi
      2. CONNECTORS-221.zip
        3.82 MB
        Piergiorgio Lucidi
      3. ASF.LICENSE.NOT.GRANTED--screenshot-1.jpg
        76 kB
        Piergiorgio Lucidi
      4. ASF.LICENSE.NOT.GRANTED--screenshot-2.jpg
        87 kB
        Piergiorgio Lucidi
      5. ASF.LICENSE.NOT.GRANTED--screenshot-3.jpg
        157 kB
        Piergiorgio Lucidi
      6. ASF.LICENSE.NOT.GRANTED--screenshot-4.jpg
        90 kB
        Piergiorgio Lucidi
      7. CONNECTORS-221-Java.txt
        38 kB
        Piergiorgio Lucidi
      8. CONNECTORS-221-DEPENDENCIES.txt
        6 kB
        Piergiorgio Lucidi
      9. CONNECTORS-221-build-example-patch.txt
        1 kB
        Piergiorgio Lucidi
      10. ASF.LICENSE.NOT.GRANTED--screenshot-5.jpg
        157 kB
        Piergiorgio Lucidi
      11. ASF.LICENSE.NOT.GRANTED--screenshot-6.jpg
        93 kB
        Piergiorgio Lucidi
      12. ASF.LICENSE.NOT.GRANTED--screenshot-7.jpg
        97 kB
        Piergiorgio Lucidi
      13. ASF.LICENSE.NOT.GRANTED--screenshot-8.jpg
        61 kB
        Piergiorgio Lucidi
      14. CONNECTORS-221-branch-java-patch.txt
        15 kB
        Piergiorgio Lucidi
      15. CONNECTORS-221-branch-java-patch-2.txt
        20 kB
        Piergiorgio Lucidi
      16. CONNECTORS-221-branch-build-patch-2.txt
        1 kB
        Piergiorgio Lucidi
      17. CONNECTORS-221-branch-build-patch-3.txt
        2 kB
        Piergiorgio Lucidi
      18. CONNECTORS-221-branch-java-patch-3.txt
        49 kB
        Piergiorgio Lucidi
      19. CONNECTORS-221-branch-java-patch-4.txt
        19 kB
        Piergiorgio Lucidi
      20. CONNECTORS-221-branch-java-patch-5.txt
        3 kB
        Piergiorgio Lucidi
      21. CONNECTORS-221-branch-java-patch-6.txt
        2 kB
        Piergiorgio Lucidi

        Activity

        Hide
        Piergiorgio Lucidi added a comment - - edited

        This is the initial implementation of the CMIS Connector based on Apache Chemistry 0.4.0. The implementation uses the CMIS REST Atom binding. The CMIS Connector was implemented using an instance of an Alfresco repository and an instance of Solr 3.2.0.

        This patch will add the following features in Manifold:

        • CMIS Connector with
        • connector configuration paramaters: username, password, endopoint and repositoryId
        • Job configuration parameters: CMIS Query

        The patch provided has the following artifacts:

        • patch for the code
        • attachements of all the dependencies that must be places in the connectors/cmis/lib folder in the project three.

        Hope this helps

        Show
        Piergiorgio Lucidi added a comment - - edited This is the initial implementation of the CMIS Connector based on Apache Chemistry 0.4.0. The implementation uses the CMIS REST Atom binding. The CMIS Connector was implemented using an instance of an Alfresco repository and an instance of Solr 3.2.0. This patch will add the following features in Manifold: CMIS Connector with connector configuration paramaters: username, password, endopoint and repositoryId Job configuration parameters: CMIS Query The patch provided has the following artifacts: patch for the code attachements of all the dependencies that must be places in the connectors/cmis/lib folder in the project three. Hope this helps
        Hide
        Piergiorgio Lucidi added a comment -

        This patch includes the CMIS Connector Java code

        Show
        Piergiorgio Lucidi added a comment - This patch includes the CMIS Connector Java code
        Hide
        Piergiorgio Lucidi added a comment -

        This attachment includes all the Apache Chemistry 0.4.0 dependencies needed to build the CMIS Connector

        Show
        Piergiorgio Lucidi added a comment - This attachment includes all the Apache Chemistry 0.4.0 dependencies needed to build the CMIS Connector
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Repository Connection

        Show
        Piergiorgio Lucidi added a comment - CMIS Repository Connection
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Repository Connection - configuration

        Show
        Piergiorgio Lucidi added a comment - CMIS Repository Connection - configuration
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Connector used in an ingestion job with Solr 3.2.0

        Show
        Piergiorgio Lucidi added a comment - CMIS Connector used in an ingestion job with Solr 3.2.0
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Connector - Job Configuration with a CMIS Query

        Show
        Piergiorgio Lucidi added a comment - CMIS Connector - Job Configuration with a CMIS Query
        Hide
        Karl Wright added a comment -

        Can you confirm that the patches are correct? All I see in them are: (a) a set of jars, and (b) build.xml files, no java sources at all.

        Show
        Karl Wright added a comment - Can you confirm that the patches are correct? All I see in them are: (a) a set of jars, and (b) build.xml files, no java sources at all.
        Hide
        Piergiorgio Lucidi added a comment -

        This is the Java code for the CMIS Connector

        Show
        Piergiorgio Lucidi added a comment - This is the Java code for the CMIS Connector
        Hide
        Karl Wright added a comment -

        At first glance, this looks promising. Basic code structure seems correct. FYI, the places where I see difficulties are:
        (a) ACLs. I notice these are commented out. What is the design and do you need an authority too?
        (b) Jar dependencies. There's one that may conflict with a jar already in the standard build - saaj. I'll have to confirm that your version of saaj doesn't break the connectors that depend on the older version.
        (c) Formatting. The Apache standard is indent size of 2 spaces, with no tabs. If you are using Eclipse, reformatting accordingly should not be difficult for you.

        Other than that, thanks again! I'm thinking that I'll create a branch for doing the merge work - will let you know.

        Show
        Karl Wright added a comment - At first glance, this looks promising. Basic code structure seems correct. FYI, the places where I see difficulties are: (a) ACLs. I notice these are commented out. What is the design and do you need an authority too? (b) Jar dependencies. There's one that may conflict with a jar already in the standard build - saaj. I'll have to confirm that your version of saaj doesn't break the connectors that depend on the older version. (c) Formatting. The Apache standard is indent size of 2 spaces, with no tabs. If you are using Eclipse, reformatting accordingly should not be difficult for you. Other than that, thanks again! I'm thinking that I'll create a branch for doing the merge work - will let you know.
        Hide
        Piergiorgio Lucidi added a comment - - edited

        Thank you for your feedback!

        (a) ACLs. I notice these are commented out. What is the design and do you need an authority too?

        I have to work on the ACL section and I hope to let you know more details later.

        (b) Jar dependencies. There's one that may conflict with a jar already in the standard build - saaj. I'll have to confirm that your version of saaj doesn't break the connectors that depend on the older version.

        Ok, could you please check for this? Let me know. Thank you.

        (c) Formatting. The Apache standard is indent size of 2 spaces, with no tabs. If you are using Eclipse, reformatting accordingly should not be difficult for you.

        Ops, ok, I'll reformatting the code in this way and I will attach the new version.

        Show
        Piergiorgio Lucidi added a comment - - edited Thank you for your feedback! (a) ACLs. I notice these are commented out. What is the design and do you need an authority too? I have to work on the ACL section and I hope to let you know more details later. (b) Jar dependencies. There's one that may conflict with a jar already in the standard build - saaj. I'll have to confirm that your version of saaj doesn't break the connectors that depend on the older version. Ok, could you please check for this? Let me know. Thank you. (c) Formatting. The Apache standard is indent size of 2 spaces, with no tabs. If you are using Eclipse, reformatting accordingly should not be difficult for you. Ops, ok, I'll reformatting the code in this way and I will attach the new version.
        Hide
        Piergiorgio Lucidi added a comment -

        The new Java code for the CMIS Connector. Now the code is indent size of 2 spaces, with no tabs.

        Show
        Piergiorgio Lucidi added a comment - The new Java code for the CMIS Connector. Now the code is indent size of 2 spaces, with no tabs.
        Hide
        Karl Wright added a comment -

        Great!
        I've set up the branch; it's https://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-221. Feel free to check it out; I'll be merging in your contribution and updating it off and on throughout the day today. If we need future patches to complete the initial integration, svn diff'ing them against the branch checkout would be the right way to go.

        Show
        Karl Wright added a comment - Great! I've set up the branch; it's https://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-221 . Feel free to check it out; I'll be merging in your contribution and updating it off and on throughout the day today. If we need future patches to complete the initial integration, svn diff'ing them against the branch checkout would be the right way to go.
        Hide
        Karl Wright added a comment -

        We'll also need to include appropriate notices in LICENSE.txt and NOTICE.txt. If you can start assembling that, it would be great. Apache dependencies should be OK, but anything else needs a mention.

        Show
        Karl Wright added a comment - We'll also need to include appropriate notices in LICENSE.txt and NOTICE.txt. If you can start assembling that, it would be great. Apache dependencies should be OK, but anything else needs a mention.
        Hide
        Karl Wright added a comment -

        There's a dependency we definitely can't include: activation-1.1.jar. This jar is licensed by Sun/Oracle, which is incompatible with the Apache license. There is a "geronimo" reimplementation that's currently included with ManifoldCF which might work in this context, however. See:

        https://cwiki.apache.org/confluence/display/CONNECTORS/Maven+Dependencies

        I'll try to replace things accordingly once I figure out whether there is a saaj conflict.

        Show
        Karl Wright added a comment - There's a dependency we definitely can't include: activation-1.1.jar. This jar is licensed by Sun/Oracle, which is incompatible with the Apache license. There is a "geronimo" reimplementation that's currently included with ManifoldCF which might work in this context, however. See: https://cwiki.apache.org/confluence/display/CONNECTORS/Maven+Dependencies I'll try to replace things accordingly once I figure out whether there is a saaj conflict.
        Hide
        Karl Wright added a comment -

        axis-saaj.jar and saag-api.jar contain in fact the same classes. However, they are not identical. We'd probably want to continue to use the axis version since that may have special axis modifications, if it will indeed work with CMIS.

        However, saaj-impl.jar contains sun classes so I suspect it too is licensed by Sun/Oracle. Piergiorgio, can you describe where you got this jar? There may also be a replacement but I'm curious what the license there actually claims.

        Show
        Karl Wright added a comment - axis-saaj.jar and saag-api.jar contain in fact the same classes. However, they are not identical. We'd probably want to continue to use the axis version since that may have special axis modifications, if it will indeed work with CMIS. However, saaj-impl.jar contains sun classes so I suspect it too is licensed by Sun/Oracle. Piergiorgio, can you describe where you got this jar? There may also be a replacement but I'm curious what the license there actually claims.
        Hide
        Piergiorgio Lucidi added a comment -

        Karl, activation-1.1.jar is released as one of the official dependencies of the Apache Chemistry project.
        The only one dependency that I have added is Apache Commons Lang, all the others are Apache Chemistry dependencies.

        Could we ask about this to some of the Chemistry guys?

        Anyway I have to test it using geronimo implementation.

        Another question is, on this new branch could I create the new patch or can I commit the patch directly in the SVN server?

        Show
        Piergiorgio Lucidi added a comment - Karl, activation-1.1.jar is released as one of the official dependencies of the Apache Chemistry project. The only one dependency that I have added is Apache Commons Lang, all the others are Apache Chemistry dependencies. Could we ask about this to some of the Chemistry guys? Anyway I have to test it using geronimo implementation. Another question is, on this new branch could I create the new patch or can I commit the patch directly in the SVN server?
        Hide
        Karl Wright added a comment -

        I committed your patch to the branch just now, except the jars, so you should see it if you sync up. Since you're not a MCF committer, you cannot commit directly to it, but you can generate new patches against it as needed. I am planning to get the build stuff up to MCF-0.3 standards, which I will try to do shortly, but before I do even that I'm still trying to figure out how to include the jars in the appropriate way.

        The general@incubator.apache.org list will have useful recommendations about what is a legal jar to include in Apache distributions, what is not. They were the folks who pointed me at geronimo-activation.jar when I was told activation.jar was not Apache legal. I would certainly talk with the Chemistry folks, though, to find out what their understanding is and why they think it is OK to include it. And then, I'd post their answers to general@i.a.o to see if they all agree.

        Show
        Karl Wright added a comment - I committed your patch to the branch just now, except the jars, so you should see it if you sync up. Since you're not a MCF committer, you cannot commit directly to it, but you can generate new patches against it as needed. I am planning to get the build stuff up to MCF-0.3 standards, which I will try to do shortly, but before I do even that I'm still trying to figure out how to include the jars in the appropriate way. The general@incubator.apache.org list will have useful recommendations about what is a legal jar to include in Apache distributions, what is not. They were the folks who pointed me at geronimo-activation.jar when I was told activation.jar was not Apache legal. I would certainly talk with the Chemistry folks, though, to find out what their understanding is and why they think it is OK to include it. And then, I'd post their answers to general@i.a.o to see if they all agree.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok Karl, I checked out the new branch and I sync up with the new Ant files and the new Java code.
        Now I'm trying to test Chemistry libraries using the geronimo implementation.

        Let me know how can I help you to continue to solve this issue.

        Show
        Piergiorgio Lucidi added a comment - Ok Karl, I checked out the new branch and I sync up with the new Ant files and the new Java code. Now I'm trying to test Chemistry libraries using the geronimo implementation. Let me know how can I help you to continue to solve this issue.
        Hide
        Karl Wright added a comment -

        I've resolved the legal issues, I think. The incubator says that the Sun stuff has been released under CDDL for a while and that is a permitted license, although we have to handle it properly in NOTICE.txt. That means that we should do the following:
        (a) Get the proper text CDDL attributions for ManifoldCF's NOTICE.txt. We can probably just take this from Chemistry's NOTICE.txt.I'd suggest adding a patch with that material if you have the time.
        (b) I'm going to try to replace geronimo-activation.jar with activation.jar, and also rename axis-saaj to saaj-api. I'll add saaj-impl, and all the other Chemistry jars we don't currently have, right into the main lib directory. Then we'll see what breaks.

        Show
        Karl Wright added a comment - I've resolved the legal issues, I think. The incubator says that the Sun stuff has been released under CDDL for a while and that is a permitted license, although we have to handle it properly in NOTICE.txt. That means that we should do the following: (a) Get the proper text CDDL attributions for ManifoldCF's NOTICE.txt. We can probably just take this from Chemistry's NOTICE.txt.I'd suggest adding a patch with that material if you have the time. (b) I'm going to try to replace geronimo-activation.jar with activation.jar, and also rename axis-saaj to saaj-api. I'll add saaj-impl, and all the other Chemistry jars we don't currently have, right into the main lib directory. Then we'll see what breaks.
        Hide
        Piergiorgio Lucidi added a comment -

        (a) Get the proper text CDDL attributions for ManifoldCF's NOTICE.txt. We can probably just take this from Chemistry's NOTICE.txt.I'd suggest adding a patch with that material if you have the time.

        Ok, in Chemistry I found these license attributions in the DEPENDENCIES file.
        So, I think that we can copy all these declarations in the same way in the ManifoldCF's DEPENDENCIES.txt.
        I'm preparing this new file for the patch.

        (b) I'm going to try to replace geronimo-activation.jar with activation.jar, and also rename axis-saaj to saaj-api. I'll add saaj-impl, and all the other Chemistry jars we don't currently have, right into the main lib directory. Then we'll see what breaks.

        Ok, good luck :-P

        Show
        Piergiorgio Lucidi added a comment - (a) Get the proper text CDDL attributions for ManifoldCF's NOTICE.txt. We can probably just take this from Chemistry's NOTICE.txt.I'd suggest adding a patch with that material if you have the time. Ok, in Chemistry I found these license attributions in the DEPENDENCIES file. So, I think that we can copy all these declarations in the same way in the ManifoldCF's DEPENDENCIES.txt. I'm preparing this new file for the patch. (b) I'm going to try to replace geronimo-activation.jar with activation.jar, and also rename axis-saaj to saaj-api. I'll add saaj-impl, and all the other Chemistry jars we don't currently have, right into the main lib directory. Then we'll see what breaks. Ok, good luck :-P
        Hide
        Piergiorgio Lucidi added a comment -

        The new DEPENDENCIES.txt file updated with all the attributions of the Apache Chemisty project related to the CMIS Connector.

        Show
        Piergiorgio Lucidi added a comment - The new DEPENDENCIES.txt file updated with all the attributions of the Apache Chemisty project related to the CMIS Connector.
        Hide
        Karl Wright added a comment -

        Ok - the branch now builds. I made one change - there were two stax-api jars (1.0 and 1.0.1). I kept the 1.0.1 and did not include the 1.0 version.

        If you can confirm that the connector works as intended when built from the branch that would be super.

        Show
        Karl Wright added a comment - Ok - the branch now builds. I made one change - there were two stax-api jars (1.0 and 1.0.1). I kept the 1.0.1 and did not include the 1.0 version. If you can confirm that the connector works as intended when built from the branch that would be super.
        Hide
        Piergiorgio Lucidi added a comment -

        If you can confirm that the connector works as intended when built from the branch that would be super.

        It seems that Apache Commons Lang library is missing. Could you please update the branch adding commons-lang-2.6.jar?

        Show
        Piergiorgio Lucidi added a comment - If you can confirm that the connector works as intended when built from the branch that would be super. It seems that Apache Commons Lang library is missing. Could you please update the branch adding commons-lang-2.6.jar?
        Hide
        Karl Wright added a comment -

        Included. FWIW, I don't think you sent it in the original zip, but it's there now.

        Show
        Karl Wright added a comment - Included. FWIW, I don't think you sent it in the original zip, but it's there now.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, you're right, thank you!

        Now I'm starting to build and test the CMIS connector.

        Show
        Piergiorgio Lucidi added a comment - Ok, you're right, thank you! Now I'm starting to build and test the CMIS connector.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, I have tested the CMIS Connector building from the branch and the only one issue was in the example building that now I have patched with a new attachment CONNECTORS-221-build-example-patch.txt.

        Now all the Chemistry dependencies are correctly copied in the example/connector-lib folder.

        Show
        Piergiorgio Lucidi added a comment - Ok, I have tested the CMIS Connector building from the branch and the only one issue was in the example building that now I have patched with a new attachment CONNECTORS-221 -build-example-patch.txt. Now all the Chemistry dependencies are correctly copied in the example/connector-lib folder.
        Hide
        Piergiorgio Lucidi added a comment -

        This patch will solve an issue during the building of the example application: now all the Chemistry dependencies are correctly copied in the example/connector-lib folder.

        Show
        Piergiorgio Lucidi added a comment - This patch will solve an issue during the building of the example application: now all the Chemistry dependencies are correctly copied in the example/connector-lib folder.
        Hide
        Karl Wright added a comment -

        The example build patch was not correct in that it did not put the jars in the dist/jar folder for the connector. I therefore checked in a different fix. Please confirm that it works for you.

        Show
        Karl Wright added a comment - The example build patch was not correct in that it did not put the jars in the dist/jar folder for the connector. I therefore checked in a different fix. Please confirm that it works for you.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, now it works correctly.

        Show
        Piergiorgio Lucidi added a comment - Ok, now it works correctly.
        Hide
        Piergiorgio Lucidi added a comment -

        This patch contains:

        • some bugfixes for the CMIS connector configuration in the crawler web app: now all the parameters are stored in the correct way in ManifoldCF
        • improvement of the HTML for the CMIS repository connector setup form
        • new feature added: now it is possible to fetch ACL also, configuring a parameter in the job configuration form (tab CMIS Query-> ACL Fetch)

        In this way ACL informations can be indexed to perform searches against this type of info.

        ACL metadata is indexed using a cmis:permission multivalue property as the following example:

        ACE1 -> 
cmis:permission='johndoe,cmis:write'

        ACE2 -> cmis:permission='guest,cmis:read'

        ACE3 -> cmis:permission='admin,cmis:all'

        On an Apache Solr server you can configure the a new permissions field for permissions in the schema.xml in the following way:

        <field name="permissions" type="string" indexed="true" stored="true" multiValued="true"/>

        Then inside the job configuration form you can set the following field mapping:
        cmis:permission -> permissions

        I'll attach more screenshots to show all these new improvements.

        Show
        Piergiorgio Lucidi added a comment - This patch contains: some bugfixes for the CMIS connector configuration in the crawler web app: now all the parameters are stored in the correct way in ManifoldCF improvement of the HTML for the CMIS repository connector setup form new feature added: now it is possible to fetch ACL also, configuring a parameter in the job configuration form (tab CMIS Query-> ACL Fetch) In this way ACL informations can be indexed to perform searches against this type of info. ACL metadata is indexed using a cmis:permission multivalue property as the following example: ACE1 -> 
cmis:permission='johndoe,cmis:write'
 ACE2 -> cmis:permission='guest,cmis:read'
 ACE3 -> cmis:permission='admin,cmis:all' On an Apache Solr server you can configure the a new permissions field for permissions in the schema.xml in the following way: <field name="permissions" type="string" indexed="true" stored="true" multiValued="true"/> Then inside the job configuration form you can set the following field mapping: cmis:permission -> permissions I'll attach more screenshots to show all these new improvements.
        Hide
        Karl Wright added a comment -

        I've merged the latest patch into the branch. The ACE form, however, will need to use the same conventions as all other repository connectors - so instead of relying on Solr knowing the form of the permission tokens, you'll need to convert these to opaque strings and write an authority connector that can map a user name to a set of access tokens.

        Show
        Karl Wright added a comment - I've merged the latest patch into the branch. The ACE form, however, will need to use the same conventions as all other repository connectors - so instead of relying on Solr knowing the form of the permission tokens, you'll need to convert these to opaque strings and write an authority connector that can map a user name to a set of access tokens.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, I think that I have understood what ManifoldCF needs, so now I would like to continue in this way:

        • submit a new patch to remove the ACE form (creating a new issue)
        • submit a new patch with the CMIS Authority Connector (creating a new issue)

        Karl, could you please confirm this plan?
        Thank you.

        Show
        Piergiorgio Lucidi added a comment - Ok, I think that I have understood what ManifoldCF needs, so now I would like to continue in this way: submit a new patch to remove the ACE form (creating a new issue) submit a new patch with the CMIS Authority Connector (creating a new issue) Karl, could you please confirm this plan? Thank you.
        Hide
        Karl Wright added a comment - - edited

        I think your plan is fine - but let's continue to work within the same ticket. I know the attachments are getting messy, but I am planning to merge the whole connector onto trunk when it is ready, so people will not need to rely on the patches in the ticket. So please, attach both new patches to CONNECTORS-221.

        Show
        Karl Wright added a comment - - edited I think your plan is fine - but let's continue to work within the same ticket. I know the attachments are getting messy, but I am planning to merge the whole connector onto trunk when it is ready, so people will not need to rely on the patches in the ticket. So please, attach both new patches to CONNECTORS-221 .
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, I hope to submit all these patches soon, maybe tomorrow.

        Show
        Piergiorgio Lucidi added a comment - Ok, I hope to submit all these patches soon, maybe tomorrow.
        Hide
        Piergiorgio Lucidi added a comment -

        This patch contains the latest CMIS Repository Connector implementation:

        • removed the ACL Fetch mechanism
        • fixed the configuration form
        • added the implementation of the getDocumentVersions method to avoid to process the same content more than one time
        Show
        Piergiorgio Lucidi added a comment - This patch contains the latest CMIS Repository Connector implementation: removed the ACL Fetch mechanism fixed the configuration form added the implementation of the getDocumentVersions method to avoid to process the same content more than one time
        Hide
        Piergiorgio Lucidi added a comment -

        This patch contains a bugfix for the building process of the example application:

        • now all the Apache Chemistry dependencies are available in the correct folder
        Show
        Piergiorgio Lucidi added a comment - This patch contains a bugfix for the building process of the example application: now all the Apache Chemistry dependencies are available in the correct folder
        Hide
        Karl Wright added a comment -

        I applied the java patch but not the build patch. This is because I added code that transfers the jars to the dist/lib area into connectors/cmis/build.xml a while back. So the build patch is both unnecessary and violates the rule that the connector build.xml provides the jars necessary for the connector to run, rather than adding such logic into the root build file. The root build file's logic remains simple: just pick up what is in connectors/cmis/dist/lib, and use that.

        Show
        Karl Wright added a comment - I applied the java patch but not the build patch. This is because I added code that transfers the jars to the dist/lib area into connectors/cmis/build.xml a while back. So the build patch is both unnecessary and violates the rule that the connector build.xml provides the jars necessary for the connector to run, rather than adding such logic into the root build file. The root build file's logic remains simple: just pick up what is in connectors/cmis/dist/lib, and use that.
        Hide
        Karl Wright added a comment -

        Any progress on an authority connector?

        Show
        Karl Wright added a comment - Any progress on an authority connector?
        Hide
        Piergiorgio Lucidi added a comment - - edited

        I tried but I have these problems:

        • I have to understand in a better way when the AuthorityConnector is used, it seems that its methods are never invoked in the process (I configured a CMIS Repository Connector with a CMIS Authority Connector but no one method are invoked)
        • The only one example in the code is the Active Directory Authority Connector but I think that it is an exception for this model. Anyway with CMIS I can't execute similar queries. I would like to see more examples for this type of connector.
        • CMIS is a content-centric protocol, I can't retrieve information on users without any content id.
        Show
        Piergiorgio Lucidi added a comment - - edited I tried but I have these problems: I have to understand in a better way when the AuthorityConnector is used, it seems that its methods are never invoked in the process (I configured a CMIS Repository Connector with a CMIS Authority Connector but no one method are invoked) The only one example in the code is the Active Directory Authority Connector but I think that it is an exception for this model. Anyway with CMIS I can't execute similar queries. I would like to see more examples for this type of connector. CMIS is a content-centric protocol, I can't retrieve information on users without any content id.
        Hide
        Karl Wright added a comment -

        You have to invoke the authority service to have the authority connector invoked. This is an HTTP request. For example (if you have curl) "curl http://localhost:8345/mcf-authority-service/UserACLs?username=foo@bar.com".

        The Active Directory connector is not an exception at all. Other connectors that have authorities are: Documentum, Livelink, and Meridio.

        As for how to do this with CMIS, let's ask a few basic questions. First, does CMIS have a notion of user groups? I see from your earlier comment that the user id's might be something like "johndoe" or "admin". Are there group ID's too? Because all you really need to do at authority time is come up with the list of user id's and group id's that correspond to a user, nothing having to do with content.

        Show
        Karl Wright added a comment - You have to invoke the authority service to have the authority connector invoked. This is an HTTP request. For example (if you have curl) "curl http://localhost:8345/mcf-authority-service/UserACLs?username=foo@bar.com ". The Active Directory connector is not an exception at all. Other connectors that have authorities are: Documentum, Livelink, and Meridio. As for how to do this with CMIS, let's ask a few basic questions. First, does CMIS have a notion of user groups? I see from your earlier comment that the user id's might be something like "johndoe" or "admin". Are there group ID's too? Because all you really need to do at authority time is come up with the list of user id's and group id's that correspond to a user, nothing having to do with content.
        Hide
        Piergiorgio Lucidi added a comment - - edited

        You have to invoke the authority service to have the authority connector invoked. This is an HTTP request. For example (if you have curl) "curl http://localhost:8345/mcf-authority-service/UserACLs?username=foo@bar.com".

        The Active Directory connector is not an exception at all. Other connectors that have authorities are: Documentum, Livelink, and Meridio.

        Thank you for this clarification!

        As for how to do this with CMIS, let's ask a few basic questions. First, does CMIS have a notion of user groups? I see from your earlier comment that the user id's might be something like "johndoe" or "admin". Are there group ID's too? Because all you really need to do at authority time is come up with the list of user id's and group id's that correspond to a user, nothing having to do with content.

        The CMIS specification provides a mechanism to get and apply an ACE but only if referred to a specific object in the repository, because it is a content-centric protocol. This means that there isn't a way to retrieve informations about permissions for an user without any object IDs.

        I hope that in the next version of the specification we will find a new service for this type of operations.
        In conclusion I think that I can't implement any AuthorityConnector for CMIS.

        Show
        Piergiorgio Lucidi added a comment - - edited You have to invoke the authority service to have the authority connector invoked. This is an HTTP request. For example (if you have curl) "curl http://localhost:8345/mcf-authority-service/UserACLs?username=foo@bar.com ". The Active Directory connector is not an exception at all. Other connectors that have authorities are: Documentum, Livelink, and Meridio. Thank you for this clarification! As for how to do this with CMIS, let's ask a few basic questions. First, does CMIS have a notion of user groups? I see from your earlier comment that the user id's might be something like "johndoe" or "admin". Are there group ID's too? Because all you really need to do at authority time is come up with the list of user id's and group id's that correspond to a user, nothing having to do with content. The CMIS specification provides a mechanism to get and apply an ACE but only if referred to a specific object in the repository, because it is a content-centric protocol. This means that there isn't a way to retrieve informations about permissions for an user without any object IDs. I hope that in the next version of the specification we will find a new service for this type of operations. In conclusion I think that I can't implement any AuthorityConnector for CMIS.
        Hide
        Karl Wright added a comment -

        The CMIS specification provides a mechanism to get and apply an ACE but only if referred to a specific object in the repository, because it is a content-centric protocol. This means that there isn't a way to retrieve informations about permissions for an user without any object IDs.

        This won't matter unless there's actually something to retrieve. So the question becomes, how are ACE's mapped in CMIS? What do they actually mean? Does their form depend on the underlying repository? Or do those user id's like "admin" and "johndoe" have cross-repository meaning of some kind? Do all underlying repositories use actual user names here?

        If the latter, you might consider a straight pass-through authority connector, for now. Basically it would be a modification of the null authority connector, with the ability to perform regular expression mapping of the incoming user active directory name to the "CMIS" name, and that's it. Then, the repository connector will simply look at all the "xxx:read" ACE's and strip off the ":read" part to get the "CMIS access token", because all you will care about is read access.

        Show
        Karl Wright added a comment - The CMIS specification provides a mechanism to get and apply an ACE but only if referred to a specific object in the repository, because it is a content-centric protocol. This means that there isn't a way to retrieve informations about permissions for an user without any object IDs. This won't matter unless there's actually something to retrieve. So the question becomes, how are ACE's mapped in CMIS? What do they actually mean? Does their form depend on the underlying repository? Or do those user id's like "admin" and "johndoe" have cross-repository meaning of some kind? Do all underlying repositories use actual user names here? If the latter, you might consider a straight pass-through authority connector, for now. Basically it would be a modification of the null authority connector, with the ability to perform regular expression mapping of the incoming user active directory name to the "CMIS" name, and that's it. Then, the repository connector will simply look at all the "xxx:read" ACE's and strip off the ":read" part to get the "CMIS access token", because all you will care about is read access.
        Hide
        Piergiorgio Lucidi added a comment - - edited

        So the question becomes, how are ACE's mapped in CMIS?

        An ACE is mapped directly into contents, this means for example that after we get an object reference to a content we can get the ACL for that specific object.

        What do they actually mean?

        Each ACE can map specific permissions for users on the content, for example an ACE for a read permission is mapped as a "cmis:read" string. For any other specific repository role or permission will be mapped as the specific way for that repository: for example the Collaborator role in Alfresco is mapped with the following string: "

        {alfrescoSpecificNamespace}

        Collaborator".

        So we can have an ACL as the following values list with the user and the specific permission:

        • user: admin | permissions: cmis:all (ACE1)
        • user: johndoe | permissions: cmis:write, {alfrescoNamespace}

          Collaborator (ACE2)

        • user: guest | permissions: cmis:read (ACE3)

        Does their form depend on the underlying repository?

        It depends on contents, using CMIS we can get ACL only if we have a reference for a specific object, supposing that we have a nodeId as the documentIdentifier, using Apache Chemistry we can get ACL only in this way:

        //get a specific CMIS object
              CmisObject cmisObject = session.getObject(nodeId);
              
              //get the ACL for this specific CMIS object
              Acl acl = cmisObject.getAcl();
              
              //get all the ACEs for the ACL
              List<Ace> aces =acl.getAces();
              
              for (Ace ace : aces) {
                String principalId = ace.getPrincipalId();
                List<String> permissions = ace.getPermissions();
                for (String permission : permissions) {
                  System.out.println("ACE user: "+principalId+"| permission: "+permission);
                }
              }
        

        Or do those user id's like "admin" and "johndoe" have cross-repository meaning of some kind? Do all underlying repositories use actual user names here?

        Each CMIS repository could have different population, the username has meaning only for a specific CMIS repository (it depends on the repositoryId that could be added in the configuration).

        If the latter, you might consider a straight pass-through authority connector, for now. Basically it would be a modification of the null authority connector, with the ability to perform regular expression mapping of the incoming user active directory name to the "CMIS" name, and that's it. Then, the repository connector will simply look at all the "xxx:read" ACE's and strip off the ":read" part to get the "CMIS access token", because all you will care about is read access.

        I'm not sure that I can implement this solution, but I can investigate.

        Show
        Piergiorgio Lucidi added a comment - - edited So the question becomes, how are ACE's mapped in CMIS? An ACE is mapped directly into contents, this means for example that after we get an object reference to a content we can get the ACL for that specific object. What do they actually mean? Each ACE can map specific permissions for users on the content, for example an ACE for a read permission is mapped as a "cmis:read" string. For any other specific repository role or permission will be mapped as the specific way for that repository: for example the Collaborator role in Alfresco is mapped with the following string: " {alfrescoSpecificNamespace} Collaborator". So we can have an ACL as the following values list with the user and the specific permission: user: admin | permissions: cmis:all (ACE1) user: johndoe | permissions: cmis:write, {alfrescoNamespace} Collaborator (ACE2) user: guest | permissions: cmis:read (ACE3) Does their form depend on the underlying repository? It depends on contents, using CMIS we can get ACL only if we have a reference for a specific object, supposing that we have a nodeId as the documentIdentifier, using Apache Chemistry we can get ACL only in this way: //get a specific CMIS object CmisObject cmisObject = session.getObject(nodeId); //get the ACL for this specific CMIS object Acl acl = cmisObject.getAcl(); //get all the ACEs for the ACL List<Ace> aces =acl.getAces(); for (Ace ace : aces) { String principalId = ace.getPrincipalId(); List< String > permissions = ace.getPermissions(); for ( String permission : permissions) { System .out.println( "ACE user: " +principalId+ "| permission: " +permission); } } Or do those user id's like "admin" and "johndoe" have cross-repository meaning of some kind? Do all underlying repositories use actual user names here? Each CMIS repository could have different population, the username has meaning only for a specific CMIS repository (it depends on the repositoryId that could be added in the configuration). If the latter, you might consider a straight pass-through authority connector, for now. Basically it would be a modification of the null authority connector, with the ability to perform regular expression mapping of the incoming user active directory name to the "CMIS" name, and that's it. Then, the repository connector will simply look at all the "xxx:read" ACE's and strip off the ":read" part to get the "CMIS access token", because all you will care about is read access. I'm not sure that I can implement this solution, but I can investigate.
        Hide
        Karl Wright added a comment -

        Each CMIS repository could have different population, the username has meaning only for a specific CMIS repository (it depends on the repositoryId that could be added in the configuration).

        So your pass-through authority connector would have to require you to specify the repositoryId as part of its configuration information, even though it will not use this value in any way. That will separate the user space and force the MCF user to choose which user space they mean for the repository tokens.

        I'm not sure that I can implement this solution, but I can investigate.

        The authority connector would not need to even communicate to the repository. It would simply provide a MCF-user-specified regular-expression-based mapping from the active directory user name to the user names used by that particular repository, but would not involve the repository in this at all. It would always return exactly one access token for a given user request.

        Have a look at the null authority, which does almost what you need this to do. You will need to add regular-expression-based mapping, that is all. See ManifoldCF in Action chapter 8 for a description of how that can be done.

        Show
        Karl Wright added a comment - Each CMIS repository could have different population, the username has meaning only for a specific CMIS repository (it depends on the repositoryId that could be added in the configuration). So your pass-through authority connector would have to require you to specify the repositoryId as part of its configuration information, even though it will not use this value in any way. That will separate the user space and force the MCF user to choose which user space they mean for the repository tokens. I'm not sure that I can implement this solution, but I can investigate. The authority connector would not need to even communicate to the repository. It would simply provide a MCF-user-specified regular-expression-based mapping from the active directory user name to the user names used by that particular repository, but would not involve the repository in this at all. It would always return exactly one access token for a given user request. Have a look at the null authority, which does almost what you need this to do. You will need to add regular-expression-based mapping, that is all. See ManifoldCF in Action chapter 8 for a description of how that can be done.
        Hide
        Piergiorgio Lucidi added a comment -

        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.

        Show
        Piergiorgio Lucidi added a comment - 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.
        Hide
        Piergiorgio Lucidi added a comment -

        This patch will generate the new CMIS Authority Connector configuration parameter in the example application inside the connectors.xml file.

        Show
        Piergiorgio Lucidi added a comment - This patch will generate the new CMIS Authority Connector configuration parameter in the example application inside the connectors.xml file.
        Hide
        Piergiorgio Lucidi added a comment -

        This patch add the CMIS Authority Connector: now it supports only the regular expression checker for usernames.

        Show
        Piergiorgio Lucidi added a comment - This patch add the CMIS Authority Connector: now it supports only the regular expression checker for usernames.
        Hide
        Karl Wright added a comment -

        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.

        Show
        Karl Wright added a comment - 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.
        Hide
        Karl Wright added a comment -

        Committed these changes to the branch. r1148064.

        Show
        Karl Wright added a comment - Committed these changes to the branch. r1148064.
        Hide
        Karl Wright added a comment -

        I posted to the java-dev@axis.apache.org list with the question of whether or not there were any axis-specific changes in the axis version of the saaj jar. The post seems to be blocked however, even though I had no problem signing up for the list. I wonder if it is defunct? axis2 exists and has the same mailing list; they put out a release in May, so I'd think they'd answer.

        If somebody else wants to try, this is what I tried to post:

        >>>>>>
        I hope I have the right list.

        I’m a principal developer of Apache ManifoldCF. We have two connectors which depend on Apache Axis 1.4. Thus, they include a saaj.jar which came from Axis but whose etiology I do not know. We’ve received a new connector which includes a dependency on a slightly different saaj jar – this one from Sun, apparently based on the 1.3 version of the specification. This seems to be a newer jar than the Axis-provided one.

        My question is, since we cannot use both of these at the same time, is there any reason why I should not replace the Axis saaj jar with the newer sun jar? Would this have any chance of breaking Axis?

        Thanks!
        Karl
        <<<<<<

        Show
        Karl Wright added a comment - I posted to the java-dev@axis.apache.org list with the question of whether or not there were any axis-specific changes in the axis version of the saaj jar. The post seems to be blocked however, even though I had no problem signing up for the list. I wonder if it is defunct? axis2 exists and has the same mailing list; they put out a release in May, so I'd think they'd answer. If somebody else wants to try, this is what I tried to post: >>>>>> I hope I have the right list. I’m a principal developer of Apache ManifoldCF. We have two connectors which depend on Apache Axis 1.4. Thus, they include a saaj.jar which came from Axis but whose etiology I do not know. We’ve received a new connector which includes a dependency on a slightly different saaj jar – this one from Sun, apparently based on the 1.3 version of the specification. This seems to be a newer jar than the Axis-provided one. My question is, since we cannot use both of these at the same time, is there any reason why I should not replace the Axis saaj jar with the newer sun jar? Would this have any chance of breaking Axis? Thanks! Karl <<<<<<
        Hide
        Karl Wright added a comment -

        The pertinent response is:

        Karl,

        Axis 1.4 is known to work on application servers that come with a more recent version of the SAAJ API (which is basically the case for all Java EE 5 compliant servers because the SAAJ API is a dependency of the JAX-WS API). Therefore, it should work in your case as well.

        Andreas

        So, I'm willing to merge this branch into trunk. I'll look into doing that sometime this week. In the meantime, please confirm that development is essentially complete for the moment.

        Show
        Karl Wright added a comment - The pertinent response is: Karl, Axis 1.4 is known to work on application servers that come with a more recent version of the SAAJ API (which is basically the case for all Java EE 5 compliant servers because the SAAJ API is a dependency of the JAX-WS API). Therefore, it should work in your case as well. Andreas So, I'm willing to merge this branch into trunk. I'll look into doing that sometime this week. In the meantime, please confirm that development is essentially complete for the moment.
        Hide
        Karl Wright added a comment -

        I just tried out setting a dummy authority connection, just accepting the defaults everywhere. Upon save i get this exception:

        2011-07-24 21:59:11.954:WARN::Nested in org.apache.jasper.JasperException: An ex
        ception occurred processing JSP page /viewauthority.jsp at line 105||102: ???{|1
        03: ????try|104: ????

        {|105: ?????connectionStatus = c.check();|106: ????}

        |107: ?
        ???finally|108: ????{|||Stacktrace::
        java.lang.ClassCastException: org.apache.chemistry.opencmis.commons.exceptions.C
        misConnectionException cannot be cast to java.lang.Error
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector.
        getSession(CmisAuthorityConnector.java:539)
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector.
        checkConnection(CmisAuthorityConnector.java:468)
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector.
        check(CmisAuthorityConnector.java:455)
        at org.apache.jsp.viewauthority_jsp._jspService(viewauthority_jsp.java:3
        23)
        ...

        Can you fix this, and also fix it if it happens in the repository connector too?

        Show
        Karl Wright added a comment - I just tried out setting a dummy authority connection, just accepting the defaults everywhere. Upon save i get this exception: 2011-07-24 21:59:11.954:WARN::Nested in org.apache.jasper.JasperException: An ex ception occurred processing JSP page /viewauthority.jsp at line 105||102: ???{|1 03: ????try|104: ???? {|105: ?????connectionStatus = c.check();|106: ????} |107: ? ???finally|108: ????{|||Stacktrace:: java.lang.ClassCastException: org.apache.chemistry.opencmis.commons.exceptions.C misConnectionException cannot be cast to java.lang.Error at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector. getSession(CmisAuthorityConnector.java:539) at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector. checkConnection(CmisAuthorityConnector.java:468) at org.apache.manifoldcf.crawler.connectors.cmis.CmisAuthorityConnector. check(CmisAuthorityConnector.java:455) at org.apache.jsp.viewauthority_jsp._jspService(viewauthority_jsp.java:3 23) ... Can you fix this, and also fix it if it happens in the repository connector too?
        Hide
        Piergiorgio Lucidi added a comment -

        I'm going to reproduce this issue. I'll let you know soon.

        Show
        Piergiorgio Lucidi added a comment - I'm going to reproduce this issue. I'll let you know soon.
        Hide
        Piergiorgio Lucidi added a comment - - edited

        In the trunk I don't see the CmisAuthority connector class, maybe you have to commit this class.
        I notice that the DEPENDECIES file is not updated with the file that I have submitted.

        Could you please check it?

        Show
        Piergiorgio Lucidi added a comment - - edited In the trunk I don't see the CmisAuthority connector class, maybe you have to commit this class. I notice that the DEPENDECIES file is not updated with the file that I have submitted. Could you please check it?
        Hide
        Karl Wright added a comment -

        I have not yet merged the branch into trunk. I discovered the problem during merge testing. I will commit your fix to the branch first.

        Show
        Karl Wright added a comment - I have not yet merged the branch into trunk. I discovered the problem during merge testing. I will commit your fix to the branch first.
        Hide
        Piergiorgio Lucidi added a comment -

        Ok, in the Authority Connector now I have removed all the old code that it managed the repository sessions: it doesn't need it anymore. I removed the username and password parameters.
        I replicated the issue and now I have solved it.

        I'm cleaning the code and then I'll attach the new patch.

        Show
        Piergiorgio Lucidi added a comment - Ok, in the Authority Connector now I have removed all the old code that it managed the repository sessions: it doesn't need it anymore. I removed the username and password parameters. I replicated the issue and now I have solved it. I'm cleaning the code and then I'll attach the new patch.
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Repository Connector: added a new log when there are wrong settings for the endpoint.

        CMIS Authority Connector: removed all the code that managed CMIS sessions. Now this connector is based only on a regular expression matcher.

        Show
        Piergiorgio Lucidi added a comment - CMIS Repository Connector: added a new log when there are wrong settings for the endpoint. CMIS Authority Connector: removed all the code that managed CMIS sessions. Now this connector is based only on a regular expression matcher.
        Hide
        Karl Wright added a comment -

        Hi Piergiorgio,

        The authority connector now no longer throws an exception when the connection parameters are bogus, but the Repository connector does:

        java.lang.ClassCastException: org.apache.chemistry.opencmis.commons.exceptions.C
        misConnectionException cannot be cast to java.lang.Error
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector
        .getSession(CmisRepositoryConnector.java:327)
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector
        .checkConnection(CmisRepositoryConnector.java:407)
        at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector
        .check(CmisRepositoryConnector.java:284)
        at org.apache.jsp.viewconnection_jsp._jspService(viewconnection_jsp.java
        :326)

        Can you look at this? The check() method should either throw a ManifoldCFException or return an appropriate string.

        Show
        Karl Wright added a comment - Hi Piergiorgio, The authority connector now no longer throws an exception when the connection parameters are bogus, but the Repository connector does: java.lang.ClassCastException: org.apache.chemistry.opencmis.commons.exceptions.C misConnectionException cannot be cast to java.lang.Error at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector .getSession(CmisRepositoryConnector.java:327) at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector .checkConnection(CmisRepositoryConnector.java:407) at org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector .check(CmisRepositoryConnector.java:284) at org.apache.jsp.viewconnection_jsp._jspService(viewconnection_jsp.java :326) Can you look at this? The check() method should either throw a ManifoldCFException or return an appropriate string.
        Hide
        Piergiorgio Lucidi added a comment -

        CMIS Repository Connector patch: now the connection error is managed using ManifoldCFException with an interrupt message.

        Show
        Piergiorgio Lucidi added a comment - CMIS Repository Connector patch: now the connection error is managed using ManifoldCFException with an interrupt message.
        Hide
        Karl Wright added a comment -

        INTERRUPTED is definitely the wrong kind of exception to be throwing here. INTERRUPTED exceptions are used only when the process is shutting down and the thread should immediately terminate.

        The general way exceptions should be handled is described in ManifoldCF in Action in Chapter 5.

        Show
        Karl Wright added a comment - INTERRUPTED is definitely the wrong kind of exception to be throwing here. INTERRUPTED exceptions are used only when the process is shutting down and the thread should immediately terminate. The general way exceptions should be handled is described in ManifoldCF in Action in Chapter 5.
        Hide
        Piergiorgio Lucidi added a comment -

        Now the CMIS Repository Connector uses the GENERAL code for exception handling related to a CmisConnectionException.

        Show
        Piergiorgio Lucidi added a comment - Now the CMIS Repository Connector uses the GENERAL code for exception handling related to a CmisConnectionException.
        Hide
        Karl Wright added a comment -

        I tried to apply either patch 5 or patch 6 to the branch and they both failed to apply cleanly. I've committed all patches up to patch 4. Any hints?

        Show
        Karl Wright added a comment - I tried to apply either patch 5 or patch 6 to the branch and they both failed to apply cleanly. I've committed all patches up to patch 4. Any hints?
        Hide
        Piergiorgio Lucidi added a comment -

        Now the CMIS Repository Connector uses the GENERAL code for exception handling related to a CmisConnectionException.

        Show
        Piergiorgio Lucidi added a comment - Now the CMIS Repository Connector uses the GENERAL code for exception handling related to a CmisConnectionException.
        Hide
        Karl Wright added a comment -

        r1151106, merging CONNECTORS-221 branch into trunk

        Show
        Karl Wright added a comment - r1151106, merging CONNECTORS-221 branch into trunk

          People

          • Assignee:
            Karl Wright
            Reporter:
            Karl Wright
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development