[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-tabpanel&focusedCommentId=13258237#comment-13258237
]
Karl Wright commented on CONNECTORS-347:
A postgresql run is as follows:
{code}
testdb=# select dochash,docid from jobqueue;
dochash |
docid
--+-
EE6C0ED002CE9303183FEFEF111D6598203F6295 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata\testdir
181B9C9FB7F62D24461967391B73FF7CB0B14CD9 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata\test2.txt
24081AC0B03B2394F38D3EB78A3BEDB6CCF1D981 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata\test1.txt
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata\testdir\seconddir
4ED8AFCC917B604C1EE4C83458DB9B7265967F40 | C:\wip\mcf\trunk\tests\filesystem\te
st-postgresql-output\testdata\testdir\test3.txt
(6 rows)
testdb=# select parentidhash, childidhash from intrinsiclink;
parentidhash | childidhash
--+-
-
EE6C0ED002CE9303183FEFEF111D6598203F6295 |
181B9C9FB7F62D24461967391B73FF7CB0B14CD9 | EE6C0ED002CE9303183FEFEF111D6598203F
6295
24081AC0B03B2394F38D3EB78A3BEDB6CCF1D981 | EE6C0ED002CE9303183FEFEF111D6598203F
6295
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60 | EE6C0ED002CE9303183FEFEF111D6598203F
6295
4ED8AFCC917B604C1EE4C83458DB9B7265967F40 | E7DE0B8D3F153CECFD3C57B4D83E59073EC4
DD60
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666 | E7DE0B8D3F153CECFD3C57B4D83E59073EC4
DD60
7013D738BB77ED47763449997384046B20B77832 | 5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4
C666
(7 rows)
testdb=# select parentidhash, distance from hopcount;
parentidhash | distance
--+--
EE6C0ED002CE9303183FEFEF111D6598203F6295 |0
24081AC0B03B2394F38D3EB78A3BEDB6CCF1D981 |1
181B9C9FB7F62D24461967391B73FF7CB0B14CD9 |1
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60 |1
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666 |2
4ED8AFCC917B604C1EE4C83458DB9B7265967F40 |2
7013D738BB77ED47763449997384046B20B77832 |3
(7 rows)
testdb=#
{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-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258120#comment-13258120
]
Karl Wright commented on CONNECTORS-347:
My operating theory is now that the hopcount is for "seconddir" is unavailable
even though "seconddir" must have been processed in order to add either it or
its child to the tables. Furthermore, the removal of both of these does not
clean up properly because the deletion that takes place does not notice the
intrinsiclink rows corresponding to the documents for the same reason.
In other words, what we may have is the result of either a transaction
isolation bug in MySQL or improper usage of transaction isolation in the MySQL
ManifoldCF driver and/or the hopcount 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-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-345) Jetty Configuration Support
[ https://issues.apache.org/jira/browse/CONNECTORS-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-459) Move to JDK1.6
[ https://issues.apache.org/jira/browse/CONNECTORS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257169#comment-13257169 ] Karl Wright commented on CONNECTORS-459: r1327782 > Move to JDK1.6 > -- > > Key: CONNECTORS-459 > URL: https://issues.apache.org/jira/browse/CONNECTORS-459 > Project: ManifoldCF > Issue Type: Improvement > Components: Build >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > It turns out that there are a number of dependency upgrades we can't do until > we move completely to jdk1.6, such as going to jetty 7, tomcat 7 components, > axis 2.x, etc. In addition, certain connectors already require jdk1.6 (the > alfresco connector, for instance). Other dependencies must be built by us in > order to get a jdk1.5-compatible version. > Since jdk1.6 has been end-of-life'd, it may be the time to make this move. -- 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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}
-"
"+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+"=<"+Integer.toString(kmanager.getContents().length)+"
" + Messages.getString(locale,"DCTM.certificate") + ">\n"
+"
"+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+"=<"+Integer.toString(kmanager.getContents().length)+"
" + Messages.getAttributeString(locale,"DCTM.certificate") + ">\n"
{code}
The issue here is that the < and > for the message are not tags. They should
in fact be < and >, so that the line should originally read:
{code}
"
"+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+"=<"+Integer.toString(kmanager.getContents().length)+"
" + Messages.getString(locale,"DCTM.certificate") + ">\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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=13254623#comment-13254623
]
Karl Wright commented on CONNECTORS-460:
Agreed. I'll be pulling this up into trunk momentarily.
Thanks for your assistance on getting this tested in your environment.
> 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13254306#comment-13254306
]
Colin Anderson commented on CONNECTORS-460:
---
I'll be able to try this tomorrow
> 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13253440#comment-13253440
]
Karl Wright commented on CONNECTORS-460:
service doesn't handle multi-domain environments
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Looks simple to fix next time I have internet service.
Karl
Sent from my Windows Phone
From: Colin Anderson (Commented) (JIRA)
Sent: 4/13/2012 10:13 AM
To: connectors-dev@incubator.apache.org
Subject: [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-tabpanel&focusedCommentId=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.
--
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
> 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:
&
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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�]'
{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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13251631#comment-13251631
]
Karl Wright commented on CONNECTORS-460:
According to my colleague, it does not appear that we can get much help out of
LDAP. So I think the right approach is as you describe - entering multiple
domains one at a time, with complete information for each. For backwards
compatibility, and to handle the case where there is no domain suffix supplied
for a user, we'll keep the concept of a primary or default 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
> 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13251456#comment-13251456
]
Karl Wright commented on CONNECTORS-460:
If you are using SharePoint, the active directory domains must be related in
some way. SharePoint, as far as I know, does not support a model where two
unrelated domain controllers authorize documents. Can you provide details
about how the domains are related?
The obvious way to look at the problem is extending the Active Directory
Authority to be able to deal with related domains, but until we understand the
use case, that's going to be hard.
> 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-455) Max activity report has i18n bug
[ https://issues.apache.org/jira/browse/CONNECTORS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-452) Postgresql jar not included properly in build
[ https://issues.apache.org/jira/browse/CONNECTORS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247403#comment-13247403 ] Karl Wright commented on CONNECTORS-452: r1309965 (release branch) > 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\example>"c:\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-452) Postgresql jar not included properly in build
[ https://issues.apache.org/jira/browse/CONNECTORS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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\example>"c:\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-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-tabpanel&focusedCommentId=13247213#comment-13247213 ] Karl Wright commented on CONNECTORS-451: r1309855 (release branch) > 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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=13246299#comment-13246299 ] Karl Wright commented on CONNECTORS-448: r1309409 (release branch) > 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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=13245467#comment-13245467 ] Karl Wright commented on CONNECTORS-444: r1309023 (release branch) > 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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=13245271#comment-13245271 ] Karl Wright commented on CONNECTORS-443: r1308871 (release branch) > 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-tabpanel&focusedCommentId=13245270#comment-13245270 ] Karl Wright commented on CONNECTORS-443: r1308867 trunk > 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-437) Remove all binary objects from source distribution
[ https://issues.apache.org/jira/browse/CONNECTORS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-437) Remove all binary objects from source distribution
[ https://issues.apache.org/jira/browse/CONNECTORS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=13242522#comment-13242522 ] Karl Wright commented on CONNECTORS-430: I just added another fix to Javascript.py that should allow your second syntactical construction above to work properly. > 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-tabpanel&focusedCommentId=13242512#comment-13242512
]
Karl Wright commented on CONNECTORS-430:
The first error is the same as what I get, but if you go back further in the
output of the test you will see this:
{code}
[junit] ALERT: Invalid URLs in seeds list:n.comn
[junit] FOCUS: On field 'seeds'
{code}
That's the smoking gun of what is actually going wrong: the page is not
reloading because there's an alert (which outputs that busted message) and
there's a subsequent focus(), but no submit occurs. So the problem is that the
regexp is not matching.
About the only way to chase this down will be to dump the regexp as the browser
simulator sees it during the "test" method. The appropriate place to look at
the code is in
framework/core/src/test/resources/org/apache/manifoldcf/core/tests/Javascript.py.
> 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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13240390#comment-13240390 ] Karl Wright commented on CONNECTORS-430: I changed the === to == already in the updated patch. The remaining problem is not parsing related, but rather related to the regular expression, I think. Either the tester is not processing the regular expression properly or the actual regular expression is incorrect. But in any case I won't be able to look at this again until tonight. > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13240035#comment-13240035
]
Karl Wright commented on CONNECTORS-430:
After fixing the above problems, I'm still getting errors. I improved the
error output and now I see this:
{code}
[junit] Exception: Unexpected end of statement; unknown tokens: '['Symbol:
var', 'Symbol: regexp', 'Punctuation: =', 'Regexp:
http(s)?:\\/\\/([a-z0-9+!*(),;?&=\\$_.-]+(\\:[a-z0-9+!*(),;?&=\\$_.-]+)?@)?[a-z0-9+\\$_-]+(\\.[a-z0-9+\\$_-]+)*(\\:[0-9]{2,5})?(\\/([a-z0-9+\\$_-]\\.?)+)*\\/?(\\?[a-z+&\\$_.-][a-z0-9;:@()',
'Punctuation: &', 'Punctuation: %', 'Punctuation: =', 'Punctuation: +',
'Punctuation: \\', 'Punctuation: $', 'Symbol: _', 'Punctuation: .',
'Punctuation: -', 'Punctuation: ]', 'Punctuation: *', 'Punctuation: )',
'Punctuation: ?', 'Punctuation: (', 'Punctuation: #', 'Punctuation: [',
'Symbol: a', 'Punctuation: -', 'Symbol: z_', 'Punctuation: .', 'Punctuation:
-', 'Punctuation: ]', 'Punctuation: [', 'Symbol: a', 'Punctuation: -', 'Symbol:
z0', 'Punctuation: -', 'Int: 9', 'Punctuation: +', 'Punctuation: \\',
'Punctuation: $', 'Symbol: _', 'Punctuation: .', 'Punctuation: -',
'Punctuation: ]', 'Punctuation: *', 'Punctuation: )', 'Punctuation: ?',
'Regexp: ;\n var lines = editjob.seeds.value.split("\\n");\n var ...
{code}
It looks like the escaping of the large regular expression is incorrect, or the
parsing of the regular expression is incorrect in the tester. Looking
further...
> 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=MyOutputConnection&index=&recrawlinterval=1440&description=MyJob&startmethod=2&expirationinterval=&jobid=1332885945254&priority=5&reseedinterval=60&tabname=Connection&connectionname=MyRepositoryConnection&schedulerecords=0&scheduletype=1&type=job&op=Continue'
and 0 files...
[junit] Traceback (most recent call last):
[junit] File "test.py", line 166, in
[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-outpu
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13239716#comment-13239716 ] Karl Wright commented on CONNECTORS-430: You can also attach a new patch and I can see if the UI tests complete here on my system. > 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-tabpanel&focusedCommentId=13239715#comment-13239715 ] Karl Wright commented on CONNECTORS-430: I think it is possible that you have more than one version of python rattling around and it is picking up the wrong one. Try "which python" to see if you are getting the one you think. > 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-tabpanel&focusedCommentId=13239708#comment-13239708 ] Erlend Garåsen commented on CONNECTORS-430: --- The same error returns if I check out a new version from trunk and run the UI test, so the failure is not caused by my changes. I will try to upgrade to Python 2.7 later this evening and/or try to run the same test on Linux instead of OS X. > 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13238533#comment-13238533 ] Karl Wright commented on CONNECTORS-430: Before you commit, can you try: ant run-webcrawler-UI-tests-derby ... to make sure the UI tests continue to pass? You will first need to install the latest version of python 2.x on your system of course. Thanks! > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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}
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
