[jira] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258111#comment-13258111
]
Karl Wright commented on CONNECTORS-347:
I was able to catch it again and do a database postmortem. Here's how the
involved tables appear:
{code}
mysql select dochash,docid from jobqueue;
+--++
| dochash | docid
|
+--++
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test1.txt |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test2.txt |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir |
+--++
4 rows in set (0.00 sec)
mysql select parentidhash,childidhash from intrinsiclink;
+--+--+
| parentidhash | childidhash |
+--+--+
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
+--+--+
6 rows in set (0.00 sec)
mysql select parentidhash,distance from hopcount;
+--+--+
| parentidhash | distance |
+--+--+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |0 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |1 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |1 |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |1 |
+--+--+
4 rows in set (0.00 sec)
{code}
While the jobqueue and hopcount tables are self-consistent, the intrinsiclink
table is pretty broken here. There are rows that should not even be there.
I'll need to compare against a run on postgresql to establish whether this is a
bug in the code we've just missed, or is particular to mysql somehow.
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 0.6
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258202#comment-13258202
]
Karl Wright commented on CONNECTORS-347:
Here's a postmortem for a run that succeeded:
{code}
mysql select parentidhash,distance from hopcount;
+--+--+
| parentidhash | distance |
+--+--+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |0 |
| 718564BC3D0C94B0F88B36B7FA2FC915F665A5E2 |3 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |2 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |2 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |1 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |1 |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |1 |
+--+--+
7 rows in set (0.00 sec)
mysql select parentidhash,childidhash from intrinsiclink;
+--+--+
| parentidhash | childidhash |
+--+--+
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | |
| 718564BC3D0C94B0F88B36B7FA2FC915F665A5E2 |
1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
+--+--+
7 rows in set (0.00 sec)
mysql select dochash,docid from jobqueue;
+--++
| dochash | docid
|
+--++
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir\test3.txt |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir\seconddir |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test1.txt |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test2.txt |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir |
+--++
6 rows in set (0.00 sec)
{code}
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 0.6
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257515#comment-13257515 ] Erlend Garåsen commented on CONNECTORS-193: --- Such as the JavaScript method SelectTab? This is not only related to the GTS and Solr connector, but all of them. At least the connectors I have checked. Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods - Key: CONNECTORS-193 URL: https://issues.apache.org/jira/browse/CONNECTORS-193 Project: ManifoldCF Issue Type: Task Components: GTS connector, Lucene/SOLR connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Karl Wright Assignee: Erlend Garåsen Fix For: ManifoldCF next The convention for form elements and javascript methods is that all element names and methods must begin with lowercase oc. The convention for output specification tabs is that the tab name should contain the name of the target, e.g. GTS Parameters or Solr Metadata Mapping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257519#comment-13257519 ] Karl Wright commented on CONNECTORS-193: No, the SelectTab JS method is provided by the framework. I am talking about Javascript methods that are local to specific output connectors. Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods - Key: CONNECTORS-193 URL: https://issues.apache.org/jira/browse/CONNECTORS-193 Project: ManifoldCF Issue Type: Task Components: GTS connector, Lucene/SOLR connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Karl Wright Assignee: Erlend Garåsen Fix For: ManifoldCF next The convention for form elements and javascript methods is that all element names and methods must begin with lowercase oc. The convention for output specification tabs is that the tab name should contain the name of the target, e.g. GTS Parameters or Solr Metadata Mapping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257899#comment-13257899
]
Karl Wright commented on CONNECTORS-347:
Just saw it again; clearly it is real.
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF next
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-345) Jetty Configuration Support
[ https://issues.apache.org/jira/browse/CONNECTORS-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257172#comment-13257172 ] Karl Wright commented on CONNECTORS-345: As part of the upgrade to JDK 1.6, I took the liberty of upgrading the jetty 7. That should make it easier to determine what the next steps should be in regards to this ticket. Jetty Configuration Support --- Key: CONNECTORS-345 URL: https://issues.apache.org/jira/browse/CONNECTORS-345 Project: ManifoldCF Issue Type: Improvement Components: Framework core Affects Versions: ManifoldCF 0.4 Environment: Jetty Configuration Reporter: Michael J. Kelleher Assignee: Karl Wright Fix For: ManifoldCF next Can the single process example be extended to support Jetty configuration? 1) jetty.xml 2) webdefault.xml 3) OPTIONS= along with their corresponding XML config files, most importantly the JMX option, Server,ajp,setuid would be nice to have -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-435) Replace incorrect Messages.getString() calls in the main UI with correct ones.
[
https://issues.apache.org/jira/browse/CONNECTORS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255511#comment-13255511
]
Karl Wright commented on CONNECTORS-435:
Looks generally good, although I didn't check every line. However, I did see
one weird thing:
{code}
-
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=+Integer.toString(kmanager.getContents().length)+
+ Messages.getString(locale,DCTM.certificate) + /nobrbr/\n
+
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=+Integer.toString(kmanager.getContents().length)+
+ Messages.getAttributeString(locale,DCTM.certificate) + /nobrbr/\n
{code}
The issue here is that the and for the message are not tags. They should
in fact be lt; and gt;, so that the line should originally read:
{code}
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=lt;+Integer.toString(kmanager.getContents().length)+
+ Messages.getString(locale,DCTM.certificate) + gt;/nobrbr/\n
{code}
Once that is done it is clear that you need Messages.getBodyString() here, not
Messages.getAttributeString().
Replace incorrect Messages.getString() calls in the main UI with correct ones.
--
Key: CONNECTORS-435
URL: https://issues.apache.org/jira/browse/CONNECTORS-435
Project: ManifoldCF
Issue Type: Task
Components: Framework core
Affects Versions: ManifoldCF 0.4
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-435.patch
The Messages.getString() calls in the main UI are incorrect much of the time.
They should usually be replaced by one of:
{code}
Messages.getBodyJavascriptString()
Messages.getAttributeJavascriptString()
Messages.getBodyString()
Messages.getAttributeString()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-435) Replace incorrect Messages.getString() calls in the main UI with correct ones.
[
https://issues.apache.org/jira/browse/CONNECTORS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255524#comment-13255524
]
Erlend Garåsen commented on CONNECTORS-435:
---
That makes sense! I'll add the correct HTML entities for these operators, then
run the tests once again before I commit my changes. Thanks for your review.
Replace incorrect Messages.getString() calls in the main UI with correct ones.
--
Key: CONNECTORS-435
URL: https://issues.apache.org/jira/browse/CONNECTORS-435
Project: ManifoldCF
Issue Type: Task
Components: Framework core
Affects Versions: ManifoldCF 0.4
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-435.patch
The Messages.getString() calls in the main UI are incorrect much of the time.
They should usually be replaced by one of:
{code}
Messages.getBodyJavascriptString()
Messages.getAttributeJavascriptString()
Messages.getBodyString()
Messages.getAttributeString()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-458) Incubator site has moved; adjust crawler-ui documentation reference accordingly
[ https://issues.apache.org/jira/browse/CONNECTORS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254579#comment-13254579 ] Karl Wright commented on CONNECTORS-458: It turns out that the URLs haven't changed; just the location from which they are mirrored. So this can be closed. Incubator site has moved; adjust crawler-ui documentation reference accordingly --- Key: CONNECTORS-458 URL: https://issues.apache.org/jira/browse/CONNECTORS-458 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Fix For: ManifoldCF 0.6 The ManifoldCF site has moved from http://incubator.apache.org/connectors to http://incubator.apache.org/content/connectors. The crawler UI references the on-line documentation and should be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254605#comment-13254605
]
Colin Anderson commented on CONNECTORS-460:
---
Hi Karl,
It works!
I also had to remove the '@' from the start of the domain suffix (so it is
{{ap.internal.com}} rather than {{@ap.internal.com}})
Many thanks for your swift work on this :D
I expect this functionality will be useful to other large organisation too, so
it's good to have it in ManifoldCF
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254625#comment-13254625
]
Karl Wright commented on CONNECTORS-460:
r1326543
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253218#comment-13253218 ] Erlend Garåsen commented on CONNECTORS-430: --- Japanese translation added and tested. r1325649 An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253235#comment-13253235
]
Karl Wright commented on CONNECTORS-460:
The branch
https://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-460 contains
a revised active directory authority connector (plus one other fix that's
needed to make it work). Colin, if you can check out and build this branch,
I'd love to hear if it works for you.
The doc is not done yet, but the way it's supposed to work is that you create a
sequence of rules. Each rule has a suffix; if that matches the end of the
domain attached to the username (everything case insensitive), then the
corresponding domain controller will be the one that is used to resolve that
user's SIDs.
Please let me know what you find.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253310#comment-13253310
]
Colin Anderson commented on CONNECTORS-460:
---
I've got it built and running, but I'm unable to get a connection to AD working.
I've added one domain with the following parameters:
{quote}
Domain controller name: ap.internal.com
Domain suffix: @ap.internal.com
Administrative user name: 123456
Authentication: simple
Login attribute: sAMAccountName
{quote}
When I hit save I get this error
{quote}
Threw exception: 'Authentication problem authenticating admin user '123456':
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 525, vece#0;]'
{quote}
Any idea what could be wrong?
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253327#comment-13253327
]
Karl Wright commented on CONNECTORS-460:
No idea what is wrong offhand. But we can debug.
Some questions:
(1) When you set up a connection with the old Active Directory connector using
the same (identical) parameters, do you get a successful connection?
(2) Please look carefully at the connection on the view page. Did all your
settings seem to get saved correctly? (other than the passwords, which you
can't see obviously).
(3) Do you see any exceptions in manifoldcf.log? They may be helpful in
figuring out what is going wrong.
Meanwhile I'll eyeball the code and see if I can find something obvious...
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253336#comment-13253336
]
Karl Wright commented on CONNECTORS-460:
I did find a problem; passwords were not being properly de-encrypted. Can you
synch up and try again?
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253338#comment-13253338
]
Karl Wright commented on CONNECTORS-460:
I hope this works for you now; if not, I'm going to be unavailable until Sunday
afternoon, at which point I can look at this again (or, hopefully, just update
the documentation and commit it to trunk!)
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253396#comment-13253396
]
Colin Anderson commented on CONNECTORS-460:
---
Hi Karl,
I can create the authority with multiple domains now, so that side seems OK.
When crawling, I get {{allow_token_document}} values all prefixed with the name
of new, single authority.
But the ManifoldCF authority service doesn't work - if I call:
{{http://localhost:8345/mcf-authority-service/UserACLs?username=123...@ap.enterdir.com}}
I get:
{{UNREACHABLEAUTHORITY:Active+Directory}}
{{TOKEN:AD:DEAD_AUTHORITY}}
And in the log I see:
{quote}
WARN 2012-04-13 15:06:07,253 (Auth check thread 0) - Authority connection
error: null
java.lang.NullPointerException
at
org.apache.manifoldcf.authorities.authorities.activedirectory.ActiveDirectoryAuthority$AuthorizationResponseDescription.getCriticalSectionName(ActiveDirectoryAuthority.java:1024)
at
org.apache.manifoldcf.core.cachemanager.CacheManager.enterCreateSection(CacheManager.java:343)
at
org.apache.manifoldcf.authorities.authorities.activedirectory.ActiveDirectoryAuthority.getAuthorizationResponse(ActiveDirectoryAuthority.java:260)
at
org.apache.manifoldcf.authorities.system.AuthCheckThread.run(AuthCheckThread.java:92)
WARN 2012-04-13 15:06:07,253 (13242994@qtp-32105264-0) - Authority 'Active
Directory' is unreachable for user '123...@ap.enterdir.com'
{quote}
I get the same if I try with a user in the {{external.com}} domain.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253858#comment-13253858
]
Karl Wright commented on CONNECTORS-460:
I fixed the problem with the cache key computation; it was a simple typo. If
you synch up and try again, I feel pretty good about it working completely this
time. ;-)
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253863#comment-13253863
]
Colin Anderson commented on CONNECTORS-460:
---
I'm out of the office, returning on the 1st of May.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251463#comment-13251463
]
Colin Anderson commented on CONNECTORS-460:
---
I assure you it works fine in SharePoint 2007, and has been doing so for years
now :)
{{internal.com}} is a forest root for 3 regional domains, e.g.
{{ap.internal.com}}, while {{external.com}} is it's own forest. Each of the
internal regional domains is configured to trust external.com. That is really
as far as they are 'related'.
* {{external.com}}
* {{internal.com}}
** {{ap.internal.com}} trusts {{external.com}}
** {{eu.internal.com}} trusts {{external.com}}
** {{am.internal.com}} trusts {{external.com}}
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251471#comment-13251471
]
Karl Wright commented on CONNECTORS-460:
So, how is SharePoint configured to authenticate users who log into it? What
domain controller does it use for authentication (i.e. what domain is the
SharePoint server(s) joined to)?
I am not an active directory expert, but I've never found any indication that
you can join a Windows machine to more than one domain. I presume, therefore,
that the joined domain controller delegates authentication to the external.com
domain controller. If that is that case, everything might already work for you
if you simply specify the internal.com DC in your active directory authority
connection.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251486#comment-13251486
]
Colin Anderson commented on CONNECTORS-460:
---
The SharePoint servers are joined to the {{internal.com}} domain.
When logging in, users authenticate with their usernames in the form
'DOMAIN\USERNAME', which I guess tells SharePoint which domain to use for
authentication.
I already specify the {{internal.com}} DC in the 'InternalAD' authority
connector, but as above, this doesn't work. The authority service returns
something like this:
{{AUTHORIZED:ExternalAD}}
{{TOKEN:ExternalAD:S-1-5-21-1234569890-1234569890-1234569890-1234}}
{{USERNOTFOUND:InternalAD}}
{{TOKEN:InternalAD:DEAD_AUTHORITY}}
while the document tokens are still all prefixed by 'InternalAD'
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251493#comment-13251493
]
Karl Wright commented on CONNECTORS-460:
Hi Colin,
The prefixes are not the issue. In ManifoldCF, there should be one authority
that is capable of dealing with all the interacting domains, just like
SharePoint understands all the domains by talking with just one domain
controller. An authority's job is to look up the SIDs for a given username,
and since your SharePoint instance can do this by talking with only one DC,
ManifoldCF's active directory authority connector ought to be able to do the
same thing.
The issue, then, is that the active directory authority connector doesn't know
how to deal with external, trusted domains. The authority must located the
DC(s) for these domains within LDAP (I believe) and route requests to the
appropriate DC. Alternatively, if automatic discovery of the external DC is
too hard, we can modify the AD authority connector to simply allow the user to
describe multiple domain controllers.
Does this sound reasonable to you?
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251500#comment-13251500
]
Karl Wright commented on CONNECTORS-460:
Oh, and one other thing: the ManifoldCF authorities ONLY support incoming user
names of the form: name@domain. They do not support domain\name. The AD
authority connector also has this restriction.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251502#comment-13251502
]
Colin Anderson commented on CONNECTORS-460:
---
Hi Karl,
I'm not sure that SharePoint _is_ just talking to one DC :) Actually, I'm
fairly sure it talks to both the {{internal.com}} and {{external.com}} DCs.
Whether the {{internal.com}} domain 'tells' it to talk to {{extranet.com}}, I
don't know.
But regardless it still seems like a good idea to be able to specify multiple
domains within a single AD authority connector. We should be able to set the
different parameters for each DC (username, password, auth type, AD attribute).
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251513#comment-13251513
]
Karl Wright commented on CONNECTORS-460:
Hi Colin,
If SharePoint talks to multiple DC's, it is nevertheless mediated by the main
DC, otherwise it would have no idea what it should trust. Otherwise, if you
logged in as co...@baddomain.com and set up your own baddomain.com DC, it
would authenticate you even though it shouldn't.
But that's neither here nor there. I agree that just supporting multiple DC's
in the AD authority is probably the way to go. The only other way would be to
locate trusted domains in the main domain's LDAP; I've asked a colleague
whether that info exists and is likely to be useful or not. Stay tuned.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251534#comment-13251534
]
Colin Anderson commented on CONNECTORS-460:
---
Hi Karl,
Even if it could automatically discover trusted domains, I think it best to
have the option to manually specify the other domains, so we can exclude some
if desired, and so we can supply username/password etc for those domains we do
want.
I will stay tuned :)
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251010#comment-13251010 ] Erlend Garåsen commented on CONNECTORS-430: --- Great! Perhaps you should reassign the issue to Hitoshi in order to add the Japanese error message before we close it. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-456) README.txt for binary distribution refers to dist directory incorrectly
[ https://issues.apache.org/jira/browse/CONNECTORS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249719#comment-13249719 ] Karl Wright commented on CONNECTORS-456: r1311156 README.txt for binary distribution refers to dist directory incorrectly --- Key: CONNECTORS-456 URL: https://issues.apache.org/jira/browse/CONNECTORS-456 Project: ManifoldCF Issue Type: Bug Components: Documentation Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Priority: Minor Fix For: ManifoldCF 0.6 The README.txt for binary distribution refers to dist/example directory instead of just example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-455) Max activity report has i18n bug
[ https://issues.apache.org/jira/browse/CONNECTORS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248196#comment-13248196 ] Karl Wright commented on CONNECTORS-455: r1310240 Max activity report has i18n bug Key: CONNECTORS-455 URL: https://issues.apache.org/jira/browse/CONNECTORS-455 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Priority: Minor Fix For: ManifoldCF 0.6 The Max Activity report has a column header that does not output as proper English but rather maxactivityreport.HighestActivityRate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-457) Strange i18n behavior on some Italian or German machines
[ https://issues.apache.org/jira/browse/CONNECTORS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248261#comment-13248261 ] Karl Wright commented on CONNECTORS-457: I haven't been able to make this happen locally even with the Firefox plugin that allows me to change the browser locale at will. One hypothesis is that this is happening because the locale on these machines is in fact being picked up as null or the empty string. There is a commons.properties file (which should not be there anyhow) at framework/ui-core/src/main/native2ascii/org/apache/manifoldcf/uicore/i18n which then might be being picked up as a resource bundle. Haven't been able to confirm this picture; an output of the locale name as picked up by the jsp pages on one of the affected machines would be very very helpful. Strange i18n behavior on some Italian or German machines Key: CONNECTORS-457 URL: https://issues.apache.org/jira/browse/CONNECTORS-457 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 When ManifoldCF is run on some machines that are neither en_US or ja_JP, certain specific messages render with the key value rather than falling back to en_US. One specific field that this happens to is in listconnections.jsp, and is the listconnections.ListOfRepositoryConnections message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-457) Strange i18n behavior on some Italian or German machines
[ https://issues.apache.org/jira/browse/CONNECTORS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248562#comment-13248562 ] Karl Wright commented on CONNECTORS-457: r1310531 (trunk) Strange i18n behavior on some Italian or German machines Key: CONNECTORS-457 URL: https://issues.apache.org/jira/browse/CONNECTORS-457 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 When ManifoldCF is run on some machines that are neither en_US or ja_JP, certain specific messages render with the key value rather than falling back to en_US. One specific field that this happens to is in listconnections.jsp, and is the listconnections.ListOfRepositoryConnections message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-457) Strange i18n behavior on some Italian or German machines
[ https://issues.apache.org/jira/browse/CONNECTORS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248570#comment-13248570 ] Karl Wright commented on CONNECTORS-457: r1310533 (release branch) Strange i18n behavior on some Italian or German machines Key: CONNECTORS-457 URL: https://issues.apache.org/jira/browse/CONNECTORS-457 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 When ManifoldCF is run on some machines that are neither en_US or ja_JP, certain specific messages render with the key value rather than falling back to en_US. One specific field that this happens to is in listconnections.jsp, and is the listconnections.ListOfRepositoryConnections message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-450) Execs in ant build do not properly check for errors
[ https://issues.apache.org/jira/browse/CONNECTORS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247078#comment-13247078 ] Karl Wright commented on CONNECTORS-450: r1309682 Execs in ant build do not properly check for errors --- Key: CONNECTORS-450 URL: https://issues.apache.org/jira/browse/CONNECTORS-450 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The exec ant calls are not checking for errors; this can cause builds to fail later if (for instance) the svn client is at the wrong version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-451) mvn-bootstrap scripts use incorrect target for ant
[ https://issues.apache.org/jira/browse/CONNECTORS-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247200#comment-13247200 ] Karl Wright commented on CONNECTORS-451: r1309838 mvn-bootstrap scripts use incorrect target for ant -- Key: CONNECTORS-451 URL: https://issues.apache.org/jira/browse/CONNECTORS-451 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The mvn-bootstrap scripts don't use the right ant target anymore; they should use ant make-deps not ant download-dependencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-452) Postgresql jar not included properly in build
[ https://issues.apache.org/jira/browse/CONNECTORS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247401#comment-13247401 ] Karl Wright commented on CONNECTORS-452: r1309962 (trunk) Postgresql jar not included properly in build - Key: CONNECTORS-452 URL: https://issues.apache.org/jira/browse/CONNECTORS-452 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 When you start the ManifoldCF single-process example, you get this: C:\release-0.5\apache-manifoldcf-0.5-incubating-bin\apache-manifoldcf-0.5-incuba ting\examplec:\Program Files\Java\jdk1.5.0_22\bin\java -jar start.jar Configuration file successfully read org.apache.manifoldcf.core.interfaces.ManifoldCFException: Unable to load databa se driver: org.postgresql.Driver at org.apache.manifoldcf.core.database.ConnectionFactory$PoolManager.ens urePoolExists(ConnectionFactory.java:212) at org.apache.manifoldcf.core.database.ConnectionFactory.getConnection(C onnectionFactory.java:55) at org.apache.manifoldcf.core.database.Database.executeUncachedQuery(Dat abase.java:721) at org.apache.manifoldcf.core.database.Database$QueryCacheExecutor.creat e(Database.java:1393) at org.apache.manifoldcf.core.cachemanager.CacheManager.findObjectsAndEx ecute(CacheManager.java:144) at org.apache.manifoldcf.core.database.Database.executeQuery(Database.ja va:185) at org.apache.manifoldcf.core.database.DBInterfacePostgreSQL.createUserA ndDatabase(DBInterfacePostgreSQL.java:524) at org.apache.manifoldcf.core.system.ManifoldCF.createSystemDatabase(Man ifoldCF.java:698) at org.apache.manifoldcf.crawler.system.ManifoldCF.createSystemDatabase( ManifoldCF.java:123) at org.apache.manifoldcf.jettyrunner.ManifoldCFJettyRunner.main(Manifold CFJettyRunner.java:224) Caused by: java.lang.ClassNotFoundException: org.postgresql.Driver at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at org.apache.manifoldcf.core.database.ConnectionFactory$PoolManager.ens urePoolExists(ConnectionFactory.java:208) ... 9 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-454) lib and bin distributions should have disclaimer.txt
[ https://issues.apache.org/jira/browse/CONNECTORS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247710#comment-13247710 ] Karl Wright commented on CONNECTORS-454: r1310079 (trunk) lib and bin distributions should have disclaimer.txt Key: CONNECTORS-454 URL: https://issues.apache.org/jira/browse/CONNECTORS-454 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Incubator rules say that all packages released under the incubator should have a disclaimer file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-454) lib and bin distributions should have disclaimer.txt
[ https://issues.apache.org/jira/browse/CONNECTORS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247712#comment-13247712 ] Karl Wright commented on CONNECTORS-454: r1310080 (release branch) lib and bin distributions should have disclaimer.txt Key: CONNECTORS-454 URL: https://issues.apache.org/jira/browse/CONNECTORS-454 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Incubator rules say that all packages released under the incubator should have a disclaimer file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-447) It would be better if the lib distribution contained jars without being under lib
[ https://issues.apache.org/jira/browse/CONNECTORS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246156#comment-13246156 ] Karl Wright commented on CONNECTORS-447: r1309322 (trunk) It would be better if the lib distribution contained jars without being under lib --- Key: CONNECTORS-447 URL: https://issues.apache.org/jira/browse/CONNECTORS-447 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 Since the lib distribution should contain only what's under lib, we should just ship the contents of lib, without insisting it's in a folder 'lib' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-446) Build target make-core-deps fails on sjis system
[ https://issues.apache.org/jira/browse/CONNECTORS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246157#comment-13246157 ] Karl Wright commented on CONNECTORS-446: r1309322 (trunk) Build target make-core-deps fails on sjis system Key: CONNECTORS-446 URL: https://issues.apache.org/jira/browse/CONNECTORS-446 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The build target make-core-deps fails on an sjis system, during the patch builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-446) Build target make-core-deps fails on sjis system
[ https://issues.apache.org/jira/browse/CONNECTORS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246158#comment-13246158 ] Karl Wright commented on CONNECTORS-446: r1309323 (release branch) Build target make-core-deps fails on sjis system Key: CONNECTORS-446 URL: https://issues.apache.org/jira/browse/CONNECTORS-446 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The build target make-core-deps fails on an sjis system, during the patch builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-447) It would be better if the lib distribution contained jars without being under lib
[ https://issues.apache.org/jira/browse/CONNECTORS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246159#comment-13246159 ] Karl Wright commented on CONNECTORS-447: r 1309323 (release branch) It would be better if the lib distribution contained jars without being under lib --- Key: CONNECTORS-447 URL: https://issues.apache.org/jira/browse/CONNECTORS-447 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 Since the lib distribution should contain only what's under lib, we should just ship the contents of lib, without insisting it's in a folder 'lib' too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-448) make-core-deps does not work on Linux
[ https://issues.apache.org/jira/browse/CONNECTORS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246298#comment-13246298 ] Karl Wright commented on CONNECTORS-448: r1309407 (trunk) make-core-deps does not work on Linux - Key: CONNECTORS-448 URL: https://issues.apache.org/jira/browse/CONNECTORS-448 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Building xerces fails because the exec command in the build.xml file is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-449) UI tests broken due to buggy browser simulator
[ https://issues.apache.org/jira/browse/CONNECTORS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246850#comment-13246850 ] Karl Wright commented on CONNECTORS-449: r1309626 (trunk) UI tests broken due to buggy browser simulator -- Key: CONNECTORS-449 URL: https://issues.apache.org/jira/browse/CONNECTORS-449 Project: ManifoldCF Issue Type: Bug Components: Tests Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The UI tests aren't working due to a regression in the browser simulator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246877#comment-13246877 ] Karl Wright commented on CONNECTORS-430: After yet a third fix to the virtual browser, the test passed, so I committed the code. r1309631 An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245062#comment-13245062 ] Piergiorgio Lucidi commented on CONNECTORS-443: --- Here the two dependencies URLs for the Alfresco Connector that are not in public Maven repositories: * http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/3rd-party/lib/wss4j-1.5.4-patched.jar * http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/3rd-party/lib/opensaml-1.0.1.jar All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245094#comment-13245094 ] Piergiorgio Lucidi commented on CONNECTORS-443: --- Here xmlsec: * http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/3rd-party/lib/xmlsec-1.4.1.jar All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245107#comment-13245107 ] Piergiorgio Lucidi commented on CONNECTORS-443: --- Here the dependencies for H2 support: * http://clojars.org/repo/it/sk/alfresco/h2-support/1.1/h2-support-1.1.jar * http://repo2.maven.org/maven2/com/h2database/h2/1.3.158/h2-1.3.158.jar All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245131#comment-13245131 ] Piergiorgio Lucidi commented on CONNECTORS-443: --- Another here: * http://repo1.maven.org/maven2/org/apache/felix/org.osgi.core/1.0.0/org.osgi.core-1.0.0.jar All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245258#comment-13245258 ] Karl Wright commented on CONNECTORS-443: Thanks to Piergiorgio, all downloads are now taken care of, so no Apache resource other than Maven is accessed when grabbing the dependent jars. The one exception is building the patched xerces and commons-httpclient jars, which check these projects out from tags in order to build. If tests pass, we may be ready for the next 0.5-incubating RC. All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-441) Build needs some refactoring on how to handle integration tasks
[ https://issues.apache.org/jira/browse/CONNECTORS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245262#comment-13245262 ] Karl Wright commented on CONNECTORS-441: r1308858 (release branch) Build needs some refactoring on how to handle integration tasks --- Key: CONNECTORS-441 URL: https://issues.apache.org/jira/browse/CONNECTORS-441 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 The integration directories for connectors no longer contain the integration binaries. The binaries are copied twice, once to the integration area, and then to the dist/integration area. A single copy would make life much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-442) Binary distributions should not include build.xml, pom.xml or common-build.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245443#comment-13245443 ] Karl Wright commented on CONNECTORS-442: r1309008 (release branch) Binary distributions should not include build.xml, pom.xml or common-build.xml -- Key: CONNECTORS-442 URL: https://issues.apache.org/jira/browse/CONNECTORS-442 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5 Since sources are not included, pom.xml, build.xml, and common-build.xml are useless and confusing in the binary packages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-444) README.txt and DEPENDENCIES.txt need to be updated to reflect separation of source and lib distributions
[ https://issues.apache.org/jira/browse/CONNECTORS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245464#comment-13245464 ] Karl Wright commented on CONNECTORS-444: r1309020 (trunk) README.txt and DEPENDENCIES.txt need to be updated to reflect separation of source and lib distributions Key: CONNECTORS-444 URL: https://issues.apache.org/jira/browse/CONNECTORS-444 Project: ManifoldCF Issue Type: Bug Components: Documentation Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The README.txt and DEPENDENCIES.txt files need to be updated to mention lib distributions, as well as the new ant targets. While we're at it, the how-to-build-and-deploy page should likewise be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-445) Each artifact must have different license, notice, and readme files
[ https://issues.apache.org/jira/browse/CONNECTORS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245637#comment-13245637 ] Karl Wright commented on CONNECTORS-445: r1309105 (trunk) Each artifact must have different license, notice, and readme files --- Key: CONNECTORS-445 URL: https://issues.apache.org/jira/browse/CONNECTORS-445 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Every distribution package that is produced must have a uniquely customized README, LICENSE, and NOTICE file. This means that we can no longer have one set of files at the root level. Instead we will need to create a separate image for each package we create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-445) Each artifact must have different license, notice, and readme files
[ https://issues.apache.org/jira/browse/CONNECTORS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245643#comment-13245643 ] Karl Wright commented on CONNECTORS-445: r1309107 (release branch) Each artifact must have different license, notice, and readme files --- Key: CONNECTORS-445 URL: https://issues.apache.org/jira/browse/CONNECTORS-445 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Every distribution package that is produced must have a uniquely customized README, LICENSE, and NOTICE file. This means that we can no longer have one set of files at the root level. Instead we will need to create a separate image for each package we create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-440) Source bin/tar includes solr integration jars and shouldn't
[ https://issues.apache.org/jira/browse/CONNECTORS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244088#comment-13244088 ] Karl Wright commented on CONNECTORS-440: r1308270 (trunk) Source bin/tar includes solr integration jars and shouldn't --- Key: CONNECTORS-440 URL: https://issues.apache.org/jira/browse/CONNECTORS-440 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The solr integration jars apparently get included in the source zip/tar. They should be excluded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-440) Source bin/tar includes solr integration jars and shouldn't
[ https://issues.apache.org/jira/browse/CONNECTORS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244089#comment-13244089 ] Karl Wright commented on CONNECTORS-440: r1308271 (release branch) Source bin/tar includes solr integration jars and shouldn't --- Key: CONNECTORS-440 URL: https://issues.apache.org/jira/browse/CONNECTORS-440 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The solr integration jars apparently get included in the source zip/tar. They should be excluded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-441) Build needs some refactoring on how to handle integration tasks
[ https://issues.apache.org/jira/browse/CONNECTORS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244098#comment-13244098 ] Karl Wright commented on CONNECTORS-441: r1308277 Build needs some refactoring on how to handle integration tasks --- Key: CONNECTORS-441 URL: https://issues.apache.org/jira/browse/CONNECTORS-441 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The integration directories for connectors no longer contain the integration binaries. The binaries are copied twice, once to the integration area, and then to the dist/integration area. A single copy would make life much easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244493#comment-13244493 ] Karl Wright commented on CONNECTORS-443: Another complication is other Apache Java projects which have patched jars in their dependencies. Apache Chemistry has a couple, I believe, and we have a CMIS connector. All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-443) All patched jars must be built within ManifoldCF release process
[ https://issues.apache.org/jira/browse/CONNECTORS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244788#comment-13244788 ] Karl Wright commented on CONNECTORS-443: For jetty, it looks like the right answer might be to move to Jetty 7, since that supposedly fixes the problems. Jetty 6 builds with Maven, which definitely would complicate the build even further by providing yet more build dependencies. Hopefully the port won't be too painful. All patched jars must be built within ManifoldCF release process Key: CONNECTORS-443 URL: https://issues.apache.org/jira/browse/CONNECTORS-443 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 Downloading already-built patched jars is not permissible within Apache any longer. The fix to this will entail downloading source and patching that as part of the build process. In order for the build process to succeed on Windows, this currently means that the sources must be checked out using svn. The following changes will therefore need to occur under this ticket: (1) Apache binaries that are available as releases but which are not in Maven should be downloaded and unpacked from http://archive.apache.org/dist. This will include the solr and sharepoint mcf plugins. (2) The download-dependencies target must be split into download-dependencies and download-proprietary-dependencies. The download-dependencies target will become responsible for downloading, patching, and building the non-proprietary packages. Packages that will need to be checked out by this target from svn include: httpclient 3.1, xerces 2.9.1, hsqldb 2.2.8, and jetty 6.1.26. (3) A new release artifact, XXX-dep.zip/tar.gz, will be produced which will contain all the dependency binaries. (4) Any non-sourceable dependency binaries we find must be replaced with a sourced equivalent, or code for it developed from scratch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-437) Remove all binary objects from source distribution
[ https://issues.apache.org/jira/browse/CONNECTORS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243748#comment-13243748 ] Karl Wright commented on CONNECTORS-437: r1308136 (trunk) Remove all binary objects from source distribution -- Key: CONNECTORS-437 URL: https://issues.apache.org/jira/browse/CONNECTORS-437 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 A board member of the ASF has indicated that it is a violation of policy for any project to include binary objects as part of its distribution. While the discussion is ongoing, it seems prudent to capture the required modifications to ManifoldCF which will bring it into compliance into a ticket. As far as I see it, these required modifications consist of the following: (1) Separate releases of all dependencies that have been patched. This includes ManifoldCF's patched httpclient, xerces, and jetty dependencies. The patches and/or patched sources are currently in Jira or are in the upstream area of svn. This should also include a Java 1.5 build of HSQLDB, since this database is currently built by its owner only for Java 1.6 and up. ManifoldCF releases of these packages may require modification of the packages' ant builds to also adhere to the new Apache rule. Since we will be checking in sources for non-Apache projects, namely Jetty and HSQLDB, we will need to confirm that this is permitted under Apache rules. If it is not, a separate googlecode project should be created instead to make these artifacts available. (2) Removal of all jars under the lib directory, and under the integration areas of individual connectors. (3) Additional ant download-dependencies actions to download all jars that were formerly in the above locations. (4) Removal of all mention of jars in the LICENSE.txt and NOTICE.txt files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-437) Remove all binary objects from source distribution
[ https://issues.apache.org/jira/browse/CONNECTORS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243750#comment-13243750 ] Karl Wright commented on CONNECTORS-437: r1308137 (release 0.5-incubating branch) Remove all binary objects from source distribution -- Key: CONNECTORS-437 URL: https://issues.apache.org/jira/browse/CONNECTORS-437 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 A board member of the ASF has indicated that it is a violation of policy for any project to include binary objects as part of its distribution. While the discussion is ongoing, it seems prudent to capture the required modifications to ManifoldCF which will bring it into compliance into a ticket. As far as I see it, these required modifications consist of the following: (1) Separate releases of all dependencies that have been patched. This includes ManifoldCF's patched httpclient, xerces, and jetty dependencies. The patches and/or patched sources are currently in Jira or are in the upstream area of svn. This should also include a Java 1.5 build of HSQLDB, since this database is currently built by its owner only for Java 1.6 and up. ManifoldCF releases of these packages may require modification of the packages' ant builds to also adhere to the new Apache rule. Since we will be checking in sources for non-Apache projects, namely Jetty and HSQLDB, we will need to confirm that this is permitted under Apache rules. If it is not, a separate googlecode project should be created instead to make these artifacts available. (2) Removal of all jars under the lib directory, and under the integration areas of individual connectors. (3) Additional ant download-dependencies actions to download all jars that were formerly in the above locations. (4) Removal of all mention of jars in the LICENSE.txt and NOTICE.txt files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242347#comment-13242347
]
Erlend Garåsen commented on CONNECTORS-430:
---
I have got rid of the annoying error after I upgraded to version 2.7.2 of
Python. Now I get a different error message, but I'm afraid that it is not
related to an invalid regular expression. I simplified the regexp just in case,
but it still fails.
{code}
var regexp = /http(s)?:\/\/.*/;
{code}
I think the problem is related to the variable declaration above, i.e. the
browser simulator think it is an invalid variable declaration.
{code}
[junit] File
/Users/erlendfg/tmp/mcf_2012/tests/webcrawler/test-derby-output/Javascript.py,
line 790, in evaluate_statement
[junit] raise Exception(Didn't find expected ';' at end of var
statement, saw %s, in %s % (unicode(token),place))
[junit] Exception: Didn't find expected ';' at end of var statement, saw
Punctuation: ., in method check_seedsList
[junit] 2012-03-30 15:40:22.530:INFO::Stopped SocketConnector@0.0.0.0:8346
{code}
My intention is to solve the problem before I fly to Azerbaijan tomorrow
morning.
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242410#comment-13242410 ] Karl Wright commented on CONNECTORS-430: Did you svn update? I fixed several issues in the simulator a while back, and this was one of them. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242509#comment-13242509
]
Erlend Garåsen commented on CONNECTORS-430:
---
Now I did a svn up. I noticed a few things. If I keep my simplified shortened
regexp mentioned above, I get the following error:
{code}
[junit] File
/Users/erlendfg/tmp/mcf_2012/tests/webcrawler/test-derby-output/VirtualBrowser.py,
line 870, in find_button
[junit] raise Exception(Can't find button %s on page %s %
(alt,self.current_url))
[junit] Exception: Can't find button Add url regexp on page
http://localhost:8346/mcf-cr ...
{code}
If I remove the regexp var and do the following:
{code}
if (! /http(s)?:\/\/.*/.test(line))
{code}
I get:
{code}
[junit] File
/Users/erlendfg/tmp/mcf_2012/tests/webcrawler/test-derby-output/Javascript.py,
line 72, in get_referenced_object
[junit] raise Exception(Object %s has no legal object reference %
unicode(self))
[junit] Exception: Object Javascript.JSRegexp instance at 0x1005a03b0 has
no legal object reference
[junit] 2012-03-30 18:12:52.429:INFO::Stopped SocketConnector@0.0.0.0:8346
{code}
If I comment out the regexp check (two lines), the test passes. I guess it is
something about the test() function which does not play well with the browser
simulator.
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240257#comment-13240257 ] Erlend Garåsen commented on CONNECTORS-430: --- Thanks, I will also try to debug some more today if I get sufficient time. By the way, the === operator might not be supported as well? I can try to change it to == if it helps. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch, CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239962#comment-13239962
]
Erlend Garåsen commented on CONNECTORS-430:
---
The UI test ran successfully on Linux with version 2.4.3 of Python.
I have attached a new patch. If it looks OK and that the UI test passes on your
computer, I suggest that I commit my changes and later try to find the reason
why these tests do not run on my mac. I don't think I have several versions of
Python installed.
{code}
erlend-garasens-macbook-pro:~ erlendfg$ which python
/usr/bin/python
{code}
{code}
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239993#comment-13239993
]
Karl Wright commented on CONNECTORS-430:
For me it fails:
{code}
[junit] Multipart posting url
'http://localhost:8346/mcf-crawler-ui/execute.jsp' with parameters
'outputname=MyOutputConnectionindex=recrawlinterval=1440description=MyJobstartmethod=2expirationinterval=jobid=1332885945254priority=5reseedinterval=60tabname=Connectionconnectionname=MyRepositoryConnectionschedulerecords=0scheduletype=1type=jobop=Continue'
and 0 files...
[junit] Traceback (most recent call last):
[junit] File test.py, line 166, in module
[junit] var124.click()
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/VirtualBrowser.py,
line 120, in click
[junit] self.get_form( ).execute_javascript_expression( self.onclick )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/VirtualBrowser.py,
line 672, in execute_javascript_expression
[junit] return self.window_instance.execute_javascript_expression(
javascript )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/VirtualBrowser.py,
line 920, in execute_javascript_expression
[junit] return tokenstream.evaluate_expr( self.jscontext, HTML )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1085, in evaluate_expr
[junit] rval = self.evaluate_expr1( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1120, in evaluate_expr1
[junit] rval = self.evaluate_expr2( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1164, in evaluate_expr2
[junit] return self.evaluate_expr3( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1176, in evaluate_expr3
[junit] rval = self.evaluate_expr4( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1264, in evaluate_expr4
[junit] rval = self.evaluate_expr5( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1299, in evaluate_expr5
[junit] rval = self.evaluate_expr6( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1341, in evaluate_expr6
[junit] return self.evaluate_expr7( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1438, in evaluate_expr7
[junit] return reference_object.call( arguments, context )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 554, in call
[junit] return self.get_referenced_object().call(argset,context)
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 186, in call
[junit] response = ts.evaluate_statement( context, method %s %
self.name )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 752, in evaluate_statement
[junit] result = self.evaluate_statement( newscope, place )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 988, in evaluate_statement
[junit] if self.evaluate_expr( context, place ) == None:
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1085, in evaluate_expr
[junit] rval = self.evaluate_expr1( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1120, in evaluate_expr1
[junit] rval = self.evaluate_expr2( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1164, in evaluate_expr2
[junit] return self.evaluate_expr3( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1176, in evaluate_expr3
[junit] rval = self.evaluate_expr4( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1264, in evaluate_expr4
[junit] rval = self.evaluate_expr5( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk/tests/webcrawler/test-derby-output/Javascript.py,
line 1299, in evaluate_expr5
[junit] rval = self.evaluate_expr6( context, place, parse_only )
[junit] File
/home/kwright/wip/trunk
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240005#comment-13240005 ] Karl Wright commented on CONNECTORS-430: Further research shows that the problem is due to the tester and is twofold: (1) Only while loops are supported (2) The ++ operator is not supported So if you change the for loop to a while, and use i = i+1 instead of i++, the test should pass. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240076#comment-13240076
]
Karl Wright commented on CONNECTORS-430:
Fixed a problem in the tester. Now I get this, which could well be just a test
error:
{code}
[junit] ALERT: Invalid URLs in seeds list:n.comn
[junit] FOCUS: On field 'seeds'
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240078#comment-13240078 ] Karl Wright commented on CONNECTORS-430: It's not a test error. The test line uses a full URL, which is not appropriately flagged: textarea.setValue(testerInstance.createStringDescription(http://www.cnn.com;)); I'm going to attach the patch as I currently have it and debug some more tomorrow. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-434) LICENSE file does not specify which license we are using for dual-licensed jars
[ https://issues.apache.org/jira/browse/CONNECTORS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238459#comment-13238459 ] Karl Wright commented on CONNECTORS-434: r1305382 (trunk) LICENSE file does not specify which license we are using for dual-licensed jars --- Key: CONNECTORS-434 URL: https://issues.apache.org/jira/browse/CONNECTORS-434 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The LICENSE file notes some jars which are dual-licensed and does not specify which license we pick. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-433) NOTICE copyright date needs updating
[ https://issues.apache.org/jira/browse/CONNECTORS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238463#comment-13238463 ] Karl Wright commented on CONNECTORS-433: r1305385 (branch) NOTICE copyright date needs updating Key: CONNECTORS-433 URL: https://issues.apache.org/jira/browse/CONNECTORS-433 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The NOTICE file copyright date does not include 2012. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-434) LICENSE file does not specify which license we are using for dual-licensed jars
[ https://issues.apache.org/jira/browse/CONNECTORS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238462#comment-13238462 ] Karl Wright commented on CONNECTORS-434: r1305387 (release branch) LICENSE file does not specify which license we are using for dual-licensed jars --- Key: CONNECTORS-434 URL: https://issues.apache.org/jira/browse/CONNECTORS-434 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Priority: Blocker Fix For: ManifoldCF 0.5 The LICENSE file notes some jars which are dual-licensed and does not specify which license we pick. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238508#comment-13238508
]
Karl Wright commented on CONNECTORS-430:
It looks like replace is supported:
{code}
def get_value( self, member_name ):
if member_name == indexOf:
return JSIndexOf( self )
if member_name == charAt:
return JSCharAt( self )
if member_name == length:
return JSNumber( len(self.value) )
if member_name == search:
return JSSearch( self )
if member_name == replace:
return JSReplace( self )
if member_name == split:
return JSSplit( self )
if member_name == substring:
return JSSubstring( self )
return JSObject.get_value( self, member_name )
{code}
Can you attach the trace you are seeing?
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238517#comment-13238517
]
Erlend Garåsen commented on CONNECTORS-430:
---
You mean the content of the hidden seeds field if it contains white spaces?
{code}
input type=hidden name=seeds value=#13;#10;http://www.uio.no//
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238520#comment-13238520 ] Karl Wright commented on CONNECTORS-430: bq. You mean the content of the hidden seeds field if it contains white spaces? No, I think I misunderstood you when you said: bq.I found a problem while testing my changes. I thought by problem you meant that the UI test failed. Clearly you meant that you wanted to use replace, but hadn't yet. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238531#comment-13238531 ] Erlend Garåsen commented on CONNECTORS-430: --- bq. Clearly you meant that you wanted to use replace, but hadn't yet. Exactly. I will probably commit my changes within few hours unless I find another problem. Then I will reassign the ticket to Hitoshi in order to add a Japanese translation of the error message. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238540#comment-13238540 ] Erlend Garåsen commented on CONNECTORS-430: --- I will. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238758#comment-13238758
]
Erlend Garåsen commented on CONNECTORS-430:
---
The UI tests actually failed. I will take a closer look tomorrow in order to
find the reason. BTW, I already have Python 2.6 installed. Do you think it's
necessary to upgrade to version 2.7?
Everything seems to work fine by using Firefox, Opera and Safari.
{code}
[junit] File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/httplib.py,
line 714, in send
[junit] TypeError: fromfile() takes exactly 2 arguments (1 given)
[junit] 2012-03-26 21:49:26.260:INFO::Stopped SocketConnector@0.0.0.0:8346
[junit] - ---
[junit] Testcase:
createConnectionsAndJob(org.apache.manifoldcf.webcrawler_tests.NavigationDerbyUI):
Caused an ERROR
[junit] UI test failed; error code: 1
[junit] java.lang.Exception: UI test failed; error code: 1
[junit] at
org.apache.manifoldcf.core.tests.HTMLTester.executeTest(HTMLTester.java:183)
[junit] at
org.apache.manifoldcf.webcrawler_tests.NavigationDerbyUI.createConnectionsAndJob(NavigationDerbyUI.java:282)
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238777#comment-13238777 ] Karl Wright commented on CONNECTORS-430: I have never seen this before; the tester was originally developed on python 2.3 and has worked ever since. I use 2.7 at the moment. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-432) Quotation marks in translated messages should be removed
[ https://issues.apache.org/jira/browse/CONNECTORS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237839#comment-13237839 ] Erlend Garåsen commented on CONNECTORS-432: --- No problem. I thought this could be an ideal issue to work with in order to get a better overview over MCF. I will create another ticket regarding Messages.getString(). Quotation marks in translated messages should be removed Key: CONNECTORS-432 URL: https://issues.apache.org/jira/browse/CONNECTORS-432 Project: ManifoldCF Issue Type: Task Components: Framework core Affects Versions: ManifoldCF 0.4 Reporter: Erlend Garåsen Assignee: Karl Wright Fix For: ManifoldCF 0.6 Quotation marks exist in some translated messages, e.g. in common_en_US.properties for the Web Connector. These should be removed and added elsewhere. An example: editjob.ExpirationIntervalMustBeAValidIntegerOrNull=Expiration interval must be a valid integer or null The quotation marks should in the example above be placed in the JSP file instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237840#comment-13237840 ] Erlend Garåsen commented on CONNECTORS-430: --- Thanks for clarifying. This was also the reason why I created a patch in the first place. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-432) Quotation marks in translated messages should be removed
[ https://issues.apache.org/jira/browse/CONNECTORS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236495#comment-13236495 ] Karl Wright commented on CONNECTORS-432: Hi Erlend, I completed this work without realizing you'd assigned the ticket to yourself. I should have checked first - my apologies. However, while looking at this, I found that the Messages.getString() calls in the main UI are actually incorrect much of the time. They should usually be replaced by one of: Messages.getBodyJavascriptString() Messages.getAttributeJavascriptString() Messages.getBodyString() Messages.getAttributeString() ... depending on the context they are used in. If you want to tackle that part of the problem (for which a different ticket would be appropriate) I will try to stay out of the way. ;-) Quotation marks in translated messages should be removed Key: CONNECTORS-432 URL: https://issues.apache.org/jira/browse/CONNECTORS-432 Project: ManifoldCF Issue Type: Task Components: Framework core Affects Versions: ManifoldCF 0.4 Reporter: Erlend Garåsen Assignee: Karl Wright Fix For: ManifoldCF 0.6 Quotation marks exist in some translated messages, e.g. in common_en_US.properties for the Web Connector. These should be removed and added elsewhere. An example: editjob.ExpirationIntervalMustBeAValidIntegerOrNull=Expiration interval must be a valid integer or null The quotation marks should in the example above be placed in the JSP file instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235765#comment-13235765 ] Karl Wright commented on CONNECTORS-430: Hi Erlend, All looks good except the check for editjob.seeds == undefined. That's not supported. The whole conditional should be unneeded because there is always a editjobs.seeds.value available, either as a hidden or as a text box. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235781#comment-13235781 ] Erlend Garåsen commented on CONNECTORS-430: --- bq. The whole conditional should be unneeded because there is always a editjobs.seeds.value available, either as a hidden or as a text box. I'm afraid not, and that's the reason why I added this check. Sorry, I thought it was the typeof function that wasn't supported by the browser simulator. Anyway, I'll double-check the requirement for this check later. If it's required, I'll add the necessary hidden element instead. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235805#comment-13235805
]
Karl Wright commented on CONNECTORS-430:
bq. I'm afraid not...
All tabs are coded so that either the displayed form element is output, or
instead a corresponding hidden is output. The web connector's tabs are no
different. The code is:
{code}
if (tabName.equals(Messages.getString(locale,WebcrawlerConnector.Seeds)))
{
out.print(
table class=\displaytable\\n+
trtd class=\separator\ colspan=\2\hr//td/tr\n+
tr\n+
td class=\value\ colspan=\2\\n+
textarea rows=\25\ cols=\80\
name=\seeds\+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(seeds)+/textarea\n+
/td\n+
/tr\n+
/table\n
);
}
else
{
out.print(
input type=\hidden\ name=\seeds\
value=\+org.apache.manifoldcf.ui.util.Encoder.attributeEscape(seeds)+\/\n
);
}
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235854#comment-13235854
]
Erlend Garåsen commented on CONNECTORS-430:
---
If I comment out the if check, I get the following error in my Error console
(Firefox):
{code}
Timestamp: 22.03.12 19.25.43
Error: editjob.seeds is undefined
Source File: http://localhost:8345/mcf-crawler-ui/editjob.jsp
Line: 243
{code}
This happens when I press the Connection tab just after I have named my new
job. I _think_ it is due to a missing hidden element, something I will figure
out tomorrow.
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-430.patch
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235897#comment-13235897 ] Karl Wright commented on CONNECTORS-430: Ah, I see the problem - you are putting your check in the main UI javascript, not in the javascript that the web connector is supposed to provide. You should be editing the method WebCrawlerConnector.outputSpecificationHeader(), not editing the UI JSP. So please don't commit this change in its current form. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 Attachments: CONNECTORS-430.patch If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-431) Update all pom.xml files on trunk to specify a version of 0.6
[ https://issues.apache.org/jira/browse/CONNECTORS-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234200#comment-13234200 ] Karl Wright commented on CONNECTORS-431: r1303308 Update all pom.xml files on trunk to specify a version of 0.6 - Key: CONNECTORS-431 URL: https://issues.apache.org/jira/browse/CONNECTORS-431 Project: ManifoldCF Issue Type: Task Components: Build Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Fix For: ManifoldCF 0.6 The pom.xml files must all be updated for the new version, 0.6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234236#comment-13234236 ] Erlend Garåsen commented on CONNECTORS-430: --- If we shouldn't include quotation marks in translated messages, we should change similar occurrences as well, for instance: editjob.ExpirationIntervalMustBeAValidIntegerOrNull=Expiration interval must be a valid integer or null Do you think we should create another ticket about these quotation marks as well? Is it difficult to add more functionality to the browser simulator or is it a better approach to follow some strict rules when writing JavaScript? If there are so many restrictions, I think it is a good idea to provide a list of safe JavaScript functions to use. My apologizes if such a list exists. It would be great if the browser simulator could support the split function. Otherwise the JavaScript code will be harder to read due to a lot more lines of code. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234264#comment-13234264 ] Karl Wright commented on CONNECTORS-430: bq. If we shouldn't include quotation marks in translated messages, we should change similar occurrences as well, for instance: bq. editjob.ExpirationIntervalMustBeAValidIntegerOrNull=Expiration interval must be a valid integer or null bq. bq. Do you think we should create another ticket about these quotation marks as well? Yes, I thought I'd fixed all of those, but I must have missed some. An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[
https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233468#comment-13233468
]
Erlend Garåsen commented on CONNECTORS-430:
---
This can be fixed by using JavaScript which performs an url validation. I have
entered the following in editjobs.jsp (vrawler-ui) which seems to work. This
code is not finished since some URLs (localhost) are not accepted.
{code}
function checkSeedsList()
{
if (typeof(editjob.seeds) != undefined)
{
var regexp =
/http(s)?:\/\/[a-z0-9-\.]+\.[a-z]{2,4}\/?([^\s\#%\,\{\}\\|\\\^\[\]`]+)?/;
var lines = editjob.seeds.value.toString().split(\n);
var invalidUrlList = ;
for (var i = 0; i lines.length; i++) {
if (lines[i].length 0
!regexp.test(lines[i]))
{
invalidUrlList += lines[i] + \n;
}
}
if (invalidUrlList.length 0)
{
alert(%=Messages.getString(pageContext.getRequest().getLocale(),editjob.InvalidUrlInSeedsList)%
+ \n + invalidUrlList);
editjob.seeds.focus();
return false;
}
}
return true;
}
{code}
An error should be returned if invalid seeds are typed into the seeds list
for the web connector
Key: CONNECTORS-430
URL: https://issues.apache.org/jira/browse/CONNECTORS-430
Project: ManifoldCF
Issue Type: Improvement
Components: Web connector
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Priority: Minor
Fix For: ManifoldCF 0.6
If you create a job for the web connector and enter an invalid URL into the
seeds list, any value is accepted. An error message should be returned to the
user in order to prevent invalid seeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-430) An error should be returned if invalid seeds are typed into the seeds list for the web connector
[ https://issues.apache.org/jira/browse/CONNECTORS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233515#comment-13233515 ] Karl Wright commented on CONNECTORS-430: Some comments. First, it is not a good idea to include quotation marks in translated messages. The quotation marks belong as part of the Javascript. Second, the following Javascript constructs are unsupported by the browser simulator: - typeof() - it looks like you could just remove this, however. - toString() - once again, looks like this could be just removed. - split() - easy to add. - the += operator - can be added, or you might more readily just rephrase the expression to not use it An error should be returned if invalid seeds are typed into the seeds list for the web connector Key: CONNECTORS-430 URL: https://issues.apache.org/jira/browse/CONNECTORS-430 Project: ManifoldCF Issue Type: Improvement Components: Web connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, ManifoldCF 0.4, ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Priority: Minor Fix For: ManifoldCF 0.6 If you create a job for the web connector and enter an invalid URL into the seeds list, any value is accepted. An error message should be returned to the user in order to prevent invalid seeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-423) Elastic Search connector should handle document metadata
[ https://issues.apache.org/jira/browse/CONNECTORS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232589#comment-13232589 ] Piergiorgio Lucidi commented on CONNECTORS-423: --- I tested the connector trying to ingest documents using the CMIS and Alfresco connectors. The connectors works fine ingesting all the metadata and the binary creating all the needed indexes in the ElasticSearch instance. I tried to execute full text queries to test the binary indexes and it works :) So I think that after we fix the Ant build for integration tests, then we can close this ticket as resolved. Elastic Search connector should handle document metadata Key: CONNECTORS-423 URL: https://issues.apache.org/jira/browse/CONNECTORS-423 Project: ManifoldCF Issue Type: Improvement Components: Elastic Search connector Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Piergiorgio Lucidi Fix For: ManifoldCF 0.5 Original Estimate: 72h Remaining Estimate: 72h The Elastic Search connector does not currently handle metadata, but it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-425) Elastic Search documentation missing images
[ https://issues.apache.org/jira/browse/CONNECTORS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232691#comment-13232691 ] Piergiorgio Lucidi commented on CONNECTORS-425: --- Partially solved: I added english language images (r1302515). Elastic Search documentation missing images --- Key: CONNECTORS-425 URL: https://issues.apache.org/jira/browse/CONNECTORS-425 Project: ManifoldCF Issue Type: Bug Components: Documentation Reporter: Karl Wright Assignee: Piergiorgio Lucidi Fix For: ManifoldCF 0.5 The ElasticSearch documentation refers to images that never actually were committed. Looking back at the ticket, they were never included in any uploaded patch either. These are: [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-connection-parameters.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-user.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-job-parameters.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-history-report.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-connection-parameters.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-user.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-job-parameters.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://en_US/images/en_US/elasticsearch-history-report.PNG. (No context info available) [exec] X [0] ja_JP/images/ja_JP/elasticsearch-connection-parameters_ja_JP.PNG BROKEN: No pipeline matched request: ja_ JP/images/ja_JP/elasticsearch-connection-parameters_ja_JP.PNG [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-connection-parameters_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-user_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-job-parameters_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-history-report_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-connection-parameters_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-user_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-job-parameters_ja_JP.PNG. (No context info available) [exec] ERROR - Image not found. URI: cocoon://ja_JP/images/ja_JP/elasticsearch-history-report_ja_JP.PNG. (No context info available) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-423) Elastic Search connector should handle document metadata
[ https://issues.apache.org/jira/browse/CONNECTORS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231175#comment-13231175 ] Piergiorgio Lucidi commented on CONNECTORS-423: --- I added a post in the ElasticSearch group about this: https://groups.google.com/d/msg/elasticsearch/XVaKf1gDrNA/9uyub7s7YEwJ In the meanwhile I'm trying to solve looking at the ElasticSearch code. Elastic Search connector should handle document metadata Key: CONNECTORS-423 URL: https://issues.apache.org/jira/browse/CONNECTORS-423 Project: ManifoldCF Issue Type: Improvement Components: Elastic Search connector Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Piergiorgio Lucidi Fix For: ManifoldCF 0.5 Original Estimate: 72h Remaining Estimate: 72h The Elastic Search connector does not currently handle metadata, but it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-423) Elastic Search connector should handle document metadata
[ https://issues.apache.org/jira/browse/CONNECTORS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231547#comment-13231547 ] Piergiorgio Lucidi commented on CONNECTORS-423: --- After executing the download-dependencies, there will be all the libraries in this folder: connectors/elasticsearch/test-materials-proprietary/elasticsearch-0.19.0. All the needed dependencies to run an ElasticSearch instance with the attachment plugin using Ant are the following: * lib/elasticsearch-0.19.0.jar * lib/jna-3.3.0.jar * lib/log4j-1.2.16.jar * lib/lucene-analyzers-3.5.0.jar * lib/lucene-core-3.5.0.jar * lib/lucene-highlighter-3.5.0.jar * lib/lucene-memory-3.5.0.jar * lib/lucene-queries-3.5.0.jar * plugins/mapper-attachments/elasticsearch-mapper-attachments-1.2.0.jar * plugins/mapper-attachments/tika-app-1.0.jar Elastic Search connector should handle document metadata Key: CONNECTORS-423 URL: https://issues.apache.org/jira/browse/CONNECTORS-423 Project: ManifoldCF Issue Type: Improvement Components: Elastic Search connector Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Piergiorgio Lucidi Fix For: ManifoldCF 0.5 Original Estimate: 72h Remaining Estimate: 72h The Elastic Search connector does not currently handle metadata, but it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-426) Alfresco test exception
[
https://issues.apache.org/jira/browse/CONNECTORS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229991#comment-13229991
]
Piergiorgio Lucidi commented on CONNECTORS-426:
---
I tried to reproduce the issue running all the Maven lifecycle process.
I updated the code from SVN and I have executed the following command line from
the root of the project:
{code}mvn clean install{code}
This because you have to update all the dependencies in your local Maven
repository to be sure that the integration tests will use all the latest
changes done in the trunk.
All the unit and integration tests are executed successfully.
So I think that it could be a problem with the Ant build script.
I'm going forward...
Alfresco test exception
---
Key: CONNECTORS-426
URL: https://issues.apache.org/jira/browse/CONNECTORS-426
Project: ManifoldCF
Issue Type: Bug
Components: Alfresco connector
Affects Versions: ManifoldCF 0.5
Reporter: Karl Wright
Assignee: Piergiorgio Lucidi
Priority: Minor
Fix For: ManifoldCF 0.5
The Alfresco tests spit out this exception, which looks like it is the result
of a bug in the test itself:
{code}
[junit] 2012-03-14
14:36:08.423:WARN::/alfresco/download/direct/workspace/Sp
acesStore/c262b38f-1e7d-4319-bb39-f0128188b9c8/testdata1.txt
[junit] java.lang.UnsupportedOperationException: Entity deletion by key
is n
ot supported
[junit] at
org.alfresco.repo.cache.lookup.EntityLookupCache$EntityLookup
CallbackDAOAdaptor.deleteByKey(EntityLookupCache.java:202)
[junit] at
org.alfresco.repo.cache.lookup.EntityLookupCache.deleteByKey(
EntityLookupCache.java:639)
[junit] at
org.alfresco.repo.domain.node.AbstractNodeDAOImpl.addNodeAspe
cts(AbstractNodeDAOImpl.java:1987)
[junit] at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProp
erties(DbNodeServiceImpl.java:526)
[junit] at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProp
erties(DbNodeServiceImpl.java:439)
[junit] at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspect(DbNodeS
erviceImpl.java:736)
[junit] at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown
Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:592)
[junit] at
org.springframework.aop.support.AopUtils.invokeJoinpointUsing
Reflection(AopUtils.java:307)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
invokeJoinpoint(ReflectiveMethodInvocation.java:183)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
proceed(ReflectiveMethodInvocation.java:150)
[junit] at
org.alfresco.repo.tenant.MultiTNodeServiceInterceptor.invoke(
MultiTNodeServiceInterceptor.java:104)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
proceed(ReflectiveMethodInvocation.java:172)
[junit] at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(J
dkDynamicAopProxy.java:202)
[junit] at $Proxy10.addAspect(Unknown Source)
[junit] at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown
Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:592)
[junit] at
org.alfresco.repo.service.StoreRedirectorProxyFactory$Redirec
torInvocationHandler.invoke(StoreRedirectorProxyFactory.java:215)
[junit] at $Proxy11.addAspect(Unknown Source)
[junit] at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown
Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:592)
[junit] at
org.springframework.aop.support.AopUtils.invokeJoinpointUsing
Reflection(AopUtils.java:307)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
invokeJoinpoint(ReflectiveMethodInvocation.java:183)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
proceed(ReflectiveMethodInvocation.java:150)
[junit] at
org.alfresco.repo.node.MLPropertyInterceptor.invoke(MLPropert
yInterceptor.java:303)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
proceed(ReflectiveMethodInvocation.java:172)
[junit] at
org.alfresco.repo.node.MLPropertyInterceptor.invoke(MLPropert
yInterceptor.java:303)
[junit] at
org.springframework.aop.framework.ReflectiveMethodInvocation.
proceed
