[jira] [Commented] (CONNECTORS-476) When running on MySQL initialize.sh causes access denied error
[
https://issues.apache.org/jira/browse/CONNECTORS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280678#comment-13280678
]
Karl Wright commented on CONNECTORS-476:
r1341288.
> When running on MySQL initialize.sh causes access denied error
> --
>
> Key: CONNECTORS-476
> URL: https://issues.apache.org/jira/browse/CONNECTORS-476
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Shigeki Kobayashi
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> initialize.sh causes access denied error if DB server is seperated from MCF's.
> Suppose each server's IP are like followings:
> MySQL Server IP: A
> MCF Server IP: B
> and properties.xml has the follwing parameters and values:
> {code}
> value="org.apache.manifoldcf.core.database.DBInterfaceMySQL"/>
>
> value=""/>
>
>
> {code}
> Then, executing initialize.sh causes the follwing error:
> {code}
> Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
> (using password: YES)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
> at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
> at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
> at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
> at
> com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
> at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
> at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
> at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> {code}
> The problem is that MCF requests MySQL to create a new "manifoldcf" user with
> localhost access.
> In this case, of course, MCF is on the server with IP B, MySQL should create
> a new user with IP Address B.
> The following method is the one creating a new MySQL user in the user table.
> Modifying the part where IP information is added solves this problem.
> JAR NAME :mcf-core.jar
> PACKAGE:org.apache.manifoldcf.core.database
> CLASS NAME :DBInterfaceMySQL
> METHOD NAME: public void createUserAndDatabase
> {code}
> if(userName != null)
> try
> {
> list.clear();
> list.add(userName);
> // list.add("localhost");
> list.add(IP_ADDRESS_B);
> list.add(password);
>...
>...
> }
> {code}
> I guess it would be nice if properties.xml can have a new property taking MCF
> server IP to
> have MySQL create a "manifoldcf" user with that IP.
--
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] [Resolved] (CONNECTORS-476) When running on MySQL initialize.sh causes access denied error
[
https://issues.apache.org/jira/browse/CONNECTORS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-476.
Resolution: Fixed
> When running on MySQL initialize.sh causes access denied error
> --
>
> Key: CONNECTORS-476
> URL: https://issues.apache.org/jira/browse/CONNECTORS-476
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Shigeki Kobayashi
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> initialize.sh causes access denied error if DB server is seperated from MCF's.
> Suppose each server's IP are like followings:
> MySQL Server IP: A
> MCF Server IP: B
> and properties.xml has the follwing parameters and values:
> {code}
> value="org.apache.manifoldcf.core.database.DBInterfaceMySQL"/>
>
> value=""/>
>
>
> {code}
> Then, executing initialize.sh causes the follwing error:
> {code}
> Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
> (using password: YES)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
> at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
> at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
> at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
> at
> com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
> at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
> at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
> at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> {code}
> The problem is that MCF requests MySQL to create a new "manifoldcf" user with
> localhost access.
> In this case, of course, MCF is on the server with IP B, MySQL should create
> a new user with IP Address B.
> The following method is the one creating a new MySQL user in the user table.
> Modifying the part where IP information is added solves this problem.
> JAR NAME :mcf-core.jar
> PACKAGE:org.apache.manifoldcf.core.database
> CLASS NAME :DBInterfaceMySQL
> METHOD NAME: public void createUserAndDatabase
> {code}
> if(userName != null)
> try
> {
> list.clear();
> list.add(userName);
> // list.add("localhost");
> list.add(IP_ADDRESS_B);
> list.add(password);
>...
>...
> }
> {code}
> I guess it would be nice if properties.xml can have a new property taking MCF
> server IP to
> have MySQL create a "manifoldcf" user with that IP.
--
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] [Updated] (CONNECTORS-476) When running on MySQL initialize.sh causes access denied error
[
https://issues.apache.org/jira/browse/CONNECTORS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-476:
---
Affects Version/s: ManifoldCF 0.6
Fix Version/s: ManifoldCF 0.6
Assignee: Karl Wright
> When running on MySQL initialize.sh causes access denied error
> --
>
> Key: CONNECTORS-476
> URL: https://issues.apache.org/jira/browse/CONNECTORS-476
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Shigeki Kobayashi
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> initialize.sh causes access denied error if DB server is seperated from MCF's.
> Suppose each server's IP are like followings:
> MySQL Server IP: A
> MCF Server IP: B
> and properties.xml has the follwing parameters and values:
> {code}
> value="org.apache.manifoldcf.core.database.DBInterfaceMySQL"/>
>
> value=""/>
>
>
> {code}
> Then, executing initialize.sh causes the follwing error:
> {code}
> Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
> (using password: YES)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
> at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
> at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
> at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
> at
> com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
> at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
> at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
> at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> {code}
> The problem is that MCF requests MySQL to create a new "manifoldcf" user with
> localhost access.
> In this case, of course, MCF is on the server with IP B, MySQL should create
> a new user with IP Address B.
> The following method is the one creating a new MySQL user in the user table.
> Modifying the part where IP information is added solves this problem.
> JAR NAME :mcf-core.jar
> PACKAGE:org.apache.manifoldcf.core.database
> CLASS NAME :DBInterfaceMySQL
> METHOD NAME: public void createUserAndDatabase
> {code}
> if(userName != null)
> try
> {
> list.clear();
> list.add(userName);
> // list.add("localhost");
> list.add(IP_ADDRESS_B);
> list.add(password);
>...
>...
> }
> {code}
> I guess it would be nice if properties.xml can have a new property taking MCF
> server IP to
> have MySQL create a "manifoldcf" user with that IP.
--
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] [Updated] (CONNECTORS-476) When running on MySQL initialize.sh causes access denied error
[
https://issues.apache.org/jira/browse/CONNECTORS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-476:
---
Description:
initialize.sh causes access denied error if DB server is seperated from MCF's.
Suppose each server's IP are like followings:
MySQL Server IP: A
MCF Server IP: B
and properties.xml has the follwing parameters and values:
{code}
{code}
Then, executing initialize.sh causes the follwing error:
{code}
Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
(using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
at
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
{code}
The problem is that MCF requests MySQL to create a new "manifoldcf" user with
localhost access.
In this case, of course, MCF is on the server with IP B, MySQL should create a
new user with IP Address B.
The following method is the one creating a new MySQL user in the user table.
Modifying the part where IP information is added solves this problem.
JAR NAME :mcf-core.jar
PACKAGE:org.apache.manifoldcf.core.database
CLASS NAME :DBInterfaceMySQL
METHOD NAME: public void createUserAndDatabase
{code}
if(userName != null)
try
{
list.clear();
list.add(userName);
// list.add("localhost");
list.add(IP_ADDRESS_B);
list.add(password);
...
...
}
{code}
I guess it would be nice if properties.xml can have a new property taking MCF
server IP to
have MySQL create a "manifoldcf" user with that IP.
was:
initialize.sh causes access denied error if DB server is seperated from MCF's.
Suppose each server's IP are like followings:
MySQL Server IP: A
MCF Server IP: B
and properties.xml has the follwing parameters and values:
Then, executing initialize.sh causes the follwing error:
Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
(using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
at
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
The problem is that MCF requests MySQL to create a new "manifoldcf" user with
localhost access.
In this case, of course, MCF is on the server with IP B, MySQL should create a
new user with IP Address B.
The following method is the one creating a new MySQL user in the user table.
Modifying the part where IP information is added solves this problem.
JAR NAME :mcf-core.jar
PACKAGE:org.apache.manifoldcf.core.database
CLASS NAME :DBInterfaceMySQL
METHOD NAME: public void createUserAndDatabase
if(userName != null)
try
{
list.clear();
list.add(userName);
// list.add("localhost");
list.add(IP_ADDRESS_B);
list.add(password);
...
...
}
I guess it would be nice if prop
[jira] [Created] (CONNECTORS-476) When running on MySQL initialize.sh causes access denied error
Shigeki Kobayashi created CONNECTORS-476:
Summary: When running on MySQL initialize.sh causes access denied
error
Key: CONNECTORS-476
URL: https://issues.apache.org/jira/browse/CONNECTORS-476
Project: ManifoldCF
Issue Type: Improvement
Components: Framework core
Affects Versions: ManifoldCF 0.5
Reporter: Shigeki Kobayashi
initialize.sh causes access denied error if DB server is seperated from MCF's.
Suppose each server's IP are like followings:
MySQL Server IP: A
MCF Server IP: B
and properties.xml has the follwing parameters and values:
Then, executing initialize.sh causes the follwing error:
Caused by: java.sql.SQLException: Access denied for user 'manifoldcf'@'B'
(using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:943)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:4113)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1308)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2336)
at
com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2369)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2153)
at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
The problem is that MCF requests MySQL to create a new "manifoldcf" user with
localhost access.
In this case, of course, MCF is on the server with IP B, MySQL should create a
new user with IP Address B.
The following method is the one creating a new MySQL user in the user table.
Modifying the part where IP information is added solves this problem.
JAR NAME :mcf-core.jar
PACKAGE:org.apache.manifoldcf.core.database
CLASS NAME :DBInterfaceMySQL
METHOD NAME: public void createUserAndDatabase
if(userName != null)
try
{
list.clear();
list.add(userName);
// list.add("localhost");
list.add(IP_ADDRESS_B);
list.add(password);
...
...
}
I guess it would be nice if properties.xml can have a new property taking MCF
server IP to
have MySQL create a "manifoldcf" user with that IP.
--
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-474) Create build stubs for all proprietary connectors
[ https://issues.apache.org/jira/browse/CONNECTORS-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280051#comment-13280051 ] Karl Wright commented on CONNECTORS-474: Completed Documentum stubs; working now on FileNet. > Create build stubs for all proprietary connectors > - > > Key: CONNECTORS-474 > URL: https://issues.apache.org/jira/browse/CONNECTORS-474 > Project: ManifoldCF > Issue Type: Improvement > Components: Build >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > If we create build stubs for all connectors with proprietary dependencies, > then anyone will be able to build a bin release or the website. -- 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] [Updated] (CONNECTORS-475) A Hydra Output Connector
[ https://issues.apache.org/jira/browse/CONNECTORS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Ebbesson updated CONNECTORS-475: --- Component/s: Framework agents process > A Hydra Output Connector > > > Key: CONNECTORS-475 > URL: https://issues.apache.org/jira/browse/CONNECTORS-475 > Project: ManifoldCF > Issue Type: New Feature > Components: Framework agents process >Reporter: Magnus Ebbesson >Priority: Minor > Labels: output, outputconnector > > Hydra Processing Framework was recently released into the wild. > Hydra offers to solve the the missing piece into creating great consolidated > search solutions. > What is Hydra? > When working with free text search using for example Apache Solr the quality > of the data in the index is a key factor of the quality of the results > delivered. Hydra is designed to give the search solution the tools necessary > to modify the data that is to be indexed in an efficient and flexible way. > This is done by providing a scalable and efficient pipeline which the > documents will have to pass through before being indexed into the search > engine. > Architecturally Hydra sits in between the search engine and the source > integration. A common use-case would be to use Apache Manifold CF to crawl a > folder on a filesystem and send the documents to hydra which in turn will > process and dispatch processed documents to Solr for indexing. > More information and code to the framework on > https://github.com/Findwise/Hydra -- 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] [Updated] (CONNECTORS-475) A Hydra Output Connector
[ https://issues.apache.org/jira/browse/CONNECTORS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Ebbesson updated CONNECTORS-475: --- Labels: output outputconnector (was: ) > A Hydra Output Connector > > > Key: CONNECTORS-475 > URL: https://issues.apache.org/jira/browse/CONNECTORS-475 > Project: ManifoldCF > Issue Type: New Feature >Reporter: Magnus Ebbesson >Priority: Minor > Labels: output, outputconnector > > Hydra Processing Framework was recently released into the wild. > Hydra offers to solve the the missing piece into creating great consolidated > search solutions. > What is Hydra? > When working with free text search using for example Apache Solr the quality > of the data in the index is a key factor of the quality of the results > delivered. Hydra is designed to give the search solution the tools necessary > to modify the data that is to be indexed in an efficient and flexible way. > This is done by providing a scalable and efficient pipeline which the > documents will have to pass through before being indexed into the search > engine. > Architecturally Hydra sits in between the search engine and the source > integration. A common use-case would be to use Apache Manifold CF to crawl a > folder on a filesystem and send the documents to hydra which in turn will > process and dispatch processed documents to Solr for indexing. > More information and code to the framework on > https://github.com/Findwise/Hydra -- 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] [Created] (CONNECTORS-475) A Hydra Output Connector
Magnus Ebbesson created CONNECTORS-475: -- Summary: A Hydra Output Connector Key: CONNECTORS-475 URL: https://issues.apache.org/jira/browse/CONNECTORS-475 Project: ManifoldCF Issue Type: New Feature Reporter: Magnus Ebbesson Priority: Minor Hydra Processing Framework was recently released into the wild. Hydra offers to solve the the missing piece into creating great consolidated search solutions. What is Hydra? When working with free text search using for example Apache Solr the quality of the data in the index is a key factor of the quality of the results delivered. Hydra is designed to give the search solution the tools necessary to modify the data that is to be indexed in an efficient and flexible way. This is done by providing a scalable and efficient pipeline which the documents will have to pass through before being indexed into the search engine. Architecturally Hydra sits in between the search engine and the source integration. A common use-case would be to use Apache Manifold CF to crawl a folder on a filesystem and send the documents to hydra which in turn will process and dispatch processed documents to Solr for indexing. More information and code to the framework on https://github.com/Findwise/Hydra -- 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] [Created] (CONNECTORS-474) Create build stubs for all proprietary connectors
Karl Wright created CONNECTORS-474: -- Summary: Create build stubs for all proprietary connectors Key: CONNECTORS-474 URL: https://issues.apache.org/jira/browse/CONNECTORS-474 Project: ManifoldCF Issue Type: Improvement Components: Build Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 If we create build stubs for all connectors with proprietary dependencies, then anyone will be able to build a bin release or the website. -- 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] [Created] (CONNECTORS-473) We need to separate our site into two pieces: One for the ManifoldCF project, and one for each release
Karl Wright created CONNECTORS-473: -- Summary: We need to separate our site into two pieces: One for the ManifoldCF project, and one for each release Key: CONNECTORS-473 URL: https://issues.apache.org/jira/browse/CONNECTORS-473 Project: ManifoldCF Issue Type: Improvement Components: Build, Documentation Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 Part of the ManifoldCF site has to do with the ManifoldCF project, and part of it is germane to a given release. We should separate these so that the project-related part builds separately, under "site/trunk", and references one (or more) release-related sites, under branches/XXX/site. -- 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] [Resolved] (CONNECTORS-472) Changes related to graduation
[ https://issues.apache.org/jira/browse/CONNECTORS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-472. Resolution: Fixed > Changes related to graduation > - > > Key: CONNECTORS-472 > URL: https://issues.apache.org/jira/browse/CONNECTORS-472 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.5.1, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > We need to do the following: > - remove the disclaimer.txt files > - modify the site to remove the disclaimer -- 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-472) Changes related to graduation
[ https://issues.apache.org/jira/browse/CONNECTORS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277187#comment-13277187 ] Karl Wright commented on CONNECTORS-472: r1339386 (0.5 release branch) > Changes related to graduation > - > > Key: CONNECTORS-472 > URL: https://issues.apache.org/jira/browse/CONNECTORS-472 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.5.1, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > We need to do the following: > - remove the disclaimer.txt files > - modify the site to remove the disclaimer -- 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-472) Changes related to graduation
[ https://issues.apache.org/jira/browse/CONNECTORS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277179#comment-13277179 ] Karl Wright commented on CONNECTORS-472: r1339383 (trunk) > Changes related to graduation > - > > Key: CONNECTORS-472 > URL: https://issues.apache.org/jira/browse/CONNECTORS-472 > Project: ManifoldCF > Issue Type: Bug > Components: Build >Affects Versions: ManifoldCF 0.5.1, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > We need to do the following: > - remove the disclaimer.txt files > - modify the site to remove the disclaimer -- 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] [Created] (CONNECTORS-472) Changes related to graduation
Karl Wright created CONNECTORS-472: -- Summary: Changes related to graduation Key: CONNECTORS-472 URL: https://issues.apache.org/jira/browse/CONNECTORS-472 Project: ManifoldCF Issue Type: Bug Components: Build Affects Versions: ManifoldCF 0.5.1, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 We need to do the following: - remove the disclaimer.txt files - modify the site to remove the disclaimer -- 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-470) SharePoint 2010 support
[ https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274809#comment-13274809 ] Karl Wright commented on CONNECTORS-470: My colleague says the following: "Yes, we have a customer that has updated to SharePoint 2010 so we've had to update the connector. I went into this knowing nothing about SharePoint and found ... I hate SharePoint. Here is what I know at this point: - I never could get the DspSts.asmx service to work with 2010. Found a couple forum posts from MS employees that say that the DspSts interfaces are deprecated in 2010 and should not be used. Use the lists.amx service to get the same information. In the crawler, I wrote another proxy class that inherits from the original and uses the lists.asmx service to get the same information for version 4.0 (2010). - You still need the MCPermssions.asmx service as there still exists no way through the web services to get permissions info at the file level. - MS has added a feature in 2010 call the “List View Threshold” to help with performance. This does not allow users to get the items in a list if the list has more than a “threshold” amount of items, default being 5000. This means that a crawing user cannot crawl a list having more than 5000 items without getting a “List View Threshold” exception from the SharePoint server (even using the lists.asmx web services). Unfortunately our clients have lists with WAY more than this number (closer to a million items). Some ways around this: -- Have the SharePoint admins turn off the list view threshold for the lists in question, which most are NOT willing to do. -- Crawl with a admin user (their threshold is defaulted at 20,000). -- Have the SharePoint admins increase the Threshold of the crawling user (again, they’re not crazy about that). -- I have implemented a couple more custom web service methods that the crawler uses to get list items that use the .NET SharePoint Server Object Model API. There are ways to circumvent this threshold using this API, then page the results back to the crawler. This allows us to crawl lists with an unlimited number of items. We are still in a testing phase with a customer for this. -- Here is a link the describes this: http://blogs.technet.com/b/speschka/archive/2009/10/27/working-with-large-lists-in-sharepoint-2010-list-throttling.aspx " > SharePoint 2010 support > --- > > Key: CONNECTORS-470 > URL: https://issues.apache.org/jira/browse/CONNECTORS-470 > Project: ManifoldCF > Issue Type: Improvement > Components: SharePoint connector >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > See here for list of the SharePoint web services for SharePoint 2010: > http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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-470) SharePoint 2010 support
[ https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274244#comment-13274244 ] Karl Wright commented on CONNECTORS-470: Apparently the problematic GUID represents web pages or forms, not a library. > SharePoint 2010 support > --- > > Key: CONNECTORS-470 > URL: https://issues.apache.org/jira/browse/CONNECTORS-470 > Project: ManifoldCF > Issue Type: Improvement > Components: SharePoint connector >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > See here for list of the SharePoint web services for SharePoint 2010: > http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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-470) SharePoint 2010 support
[ https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274214#comment-13274214 ] Karl Wright commented on CONNECTORS-470: We use the DspSts.asmx web service for two purposes: First, to find the list of documents for a given site and library GUID (the query that is failing), and second, to find the list of metadata field names for a given site and library GUID (we don't even get that far, unfortunately). I don't see any evidence whatsoever that the Google appliance uses this web service for either of these purposes, but it obviously needs to do the equivalent somehow, so I'll be doing some research as to how (so as to hopefully avoid using the DspSts service altogether). > SharePoint 2010 support > --- > > Key: CONNECTORS-470 > URL: https://issues.apache.org/jira/browse/CONNECTORS-470 > Project: ManifoldCF > Issue Type: Improvement > Components: SharePoint connector >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > See here for list of the SharePoint web services for SharePoint 2010: > http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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-470) SharePoint 2010 support
[ https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274212#comment-13274212 ] Karl Wright commented on CONNECTORS-470: I took the step of looking at the google appliance SharePoint Connector code, which also uses the SharePoint web services to crawl. While it doesn't explicitly use the same /list query, it does not treat SharePoint web services any differently between SP 2007 and SP 2010. > SharePoint 2010 support > --- > > Key: CONNECTORS-470 > URL: https://issues.apache.org/jira/browse/CONNECTORS-470 > Project: ManifoldCF > Issue Type: Improvement > Components: SharePoint connector >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > See here for list of the SharePoint web services for SharePoint 2010: > http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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] [Issue Comment Edited] (CONNECTORS-470) SharePoint 2010 support
[
https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274208#comment-13274208
]
Karl Wright edited comment on CONNECTORS-470 at 5/13/12 4:52 AM:
-
Further analysis indicates that some of these services still work, while others
(e.g. the DspSts service) have problems. Specifically, this query request:
{code}
{code}
yields:
{code}
HTTP/1.1 500 Internal Server Error
{code}
... plus some stuff that the user didn't actually include from the transaction
which might have been helpful.
>From this I conclude that the DspSts service on this installation is broken -
>and ONLY that service is broken. This is because the GUID that is included is
>indeed valid and must have come from somewhere - the Lists service, no doubt,
>which still seems to actually work on SharePoint 2010.
was (Author: kwri...@metacarta.com):
Further analysis indicates that some of these services still work, while
others (e.g. the DspSts service) have problems. Specifically, this query
request:
{code}
{code}
yields:
{code}
HTTP/1.1 500 Internal Server Error
{code}
... plus some stuff that the user didn't actually include from the transaction
which might have been helpful.
> SharePoint 2010 support
> ---
>
> Key: CONNECTORS-470
> URL: https://issues.apache.org/jira/browse/CONNECTORS-470
> Project: ManifoldCF
> Issue Type: Improvement
> Components: SharePoint connector
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> See here for list of the SharePoint web services for SharePoint 2010:
> http://msdn.microsoft.com/en-us/library/ee705814.aspx
--
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-470) SharePoint 2010 support
[
https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274208#comment-13274208
]
Karl Wright commented on CONNECTORS-470:
Further analysis indicates that some of these services still work, while others
(e.g. the DspSts service) have problems. Specifically, this query request:
{code}
{code}
yields:
{code}
HTTP/1.1 500 Internal Server Error
{code}
... plus some stuff that the user didn't actually include from the transaction
which might have been helpful.
> SharePoint 2010 support
> ---
>
> Key: CONNECTORS-470
> URL: https://issues.apache.org/jira/browse/CONNECTORS-470
> Project: ManifoldCF
> Issue Type: Improvement
> Components: SharePoint connector
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> See here for list of the SharePoint web services for SharePoint 2010:
> http://msdn.microsoft.com/en-us/library/ee705814.aspx
--
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] [Resolved] (CONNECTORS-453) ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-453. Resolution: Fixed > ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs > - > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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-453) ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273872#comment-13273872 ] Karl Wright commented on CONNECTORS-453: r1337457 (release branch) > ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs > - > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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] [Reopened] (CONNECTORS-453) ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reopened CONNECTORS-453: Reopening for inclusion in 0.5.1 > ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs > - > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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] [Updated] (CONNECTORS-453) ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-453: --- Priority: Critical (was: Major) Fix Version/s: ManifoldCF 0.5.1 > ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs > - > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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] [Resolved] (CONNECTORS-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-471. Resolution: Fixed > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273864#comment-13273864 ] Karl Wright commented on CONNECTORS-471: r1337452 on release branch > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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] [Resolved] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-467. Resolution: Fixed > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Erlend Garåsen >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273862#comment-13273862 ] Karl Wright commented on CONNECTORS-467: r1337451 on release branch. > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Erlend Garåsen >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Reopened] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reopened CONNECTORS-467: > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Erlend Garåsen >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Updated] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-467: --- Priority: Critical (was: Major) Affects Version/s: ManifoldCF 0.6 Fix Version/s: ManifoldCF 0.5.1 Assignee: Karl Wright (was: Erlend Garåsen) Triaging this for the 0.5.1 release. > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Erlend Garåsen >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Reopened] (CONNECTORS-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reopened CONNECTORS-471: > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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] [Updated] (CONNECTORS-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-471: --- Priority: Critical (was: Major) Fix Version/s: ManifoldCF 0.5.1 > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright >Priority: Critical > Fix For: ManifoldCF 0.5.1, ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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] [Updated] (CONNECTORS-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-471: --- Affects Version/s: ManifoldCF 0.5 > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > 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 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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] [Resolved] (CONNECTORS-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-471. Resolution: Fixed > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273560#comment-13273560 ] Karl Wright commented on CONNECTORS-471: r1337350 > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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-471) HSQLDB runs out of memory during load test
[ https://issues.apache.org/jira/browse/CONNECTORS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273440#comment-13273440 ] Karl Wright commented on CONNECTORS-471: The HSQLDB team responds: Hi Karl, A regression was found and fixed. Please use the latest snapshot jar for 2.2.9 (at hsqldb.org) and let me know if it fixes the issue. If the issue is still there, I will fix it. Regards Fred > HSQLDB runs out of memory during load test > -- > > Key: CONNECTORS-471 > URL: https://issues.apache.org/jira/browse/CONNECTORS-471 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete > with 384M. It now runs out of memory even with 1.5G, which is the maximum my > machine has. -- 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] [Created] (CONNECTORS-471) HSQLDB runs out of memory during load test
Karl Wright created CONNECTORS-471: -- Summary: HSQLDB runs out of memory during load test Key: CONNECTORS-471 URL: https://issues.apache.org/jira/browse/CONNECTORS-471 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 For ManifoldCF 0.4-incubating, the standard HSQLDB load test could complete with 384M. It now runs out of memory even with 1.5G, which is the maximum my machine has. -- 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] [Resolved] (CONNECTORS-96) Replace the current connection pool by one that is more up-to-date
[ https://issues.apache.org/jira/browse/CONNECTORS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-96. --- Resolution: Fixed > Replace the current connection pool by one that is more up-to-date > -- > > Key: CONNECTORS-96 > URL: https://issues.apache.org/jira/browse/CONNECTORS-96 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2 >Reporter: Jettro Coenradie >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > At the moment we use a connection pool from bitmechanic. This is the least to > say some what outdated. Hard to find any information about it. The only thing > I could find was this: > http://www.knightsofthenet.com/projects/SQLPool/ > Can we replace this with an implementation of for instance dbcp > http://commons.apache.org/dbcp/index.html > I think there is a big risk in using this old versions that are not tested on > new java systems anymore. We can be missing a lot of optimizations (jdbc4 for > instance) > For the pooling behavior we can use something like commons-pool -- 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-96) Replace the current connection pool by one that is more up-to-date
[ https://issues.apache.org/jira/browse/CONNECTORS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272906#comment-13272906 ] Karl Wright commented on CONNECTORS-96: --- r1336965 > Replace the current connection pool by one that is more up-to-date > -- > > Key: CONNECTORS-96 > URL: https://issues.apache.org/jira/browse/CONNECTORS-96 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2 >Reporter: Jettro Coenradie >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > At the moment we use a connection pool from bitmechanic. This is the least to > say some what outdated. Hard to find any information about it. The only thing > I could find was this: > http://www.knightsofthenet.com/projects/SQLPool/ > Can we replace this with an implementation of for instance dbcp > http://commons.apache.org/dbcp/index.html > I think there is a big risk in using this old versions that are not tested on > new java systems anymore. We can be missing a lot of optimizations (jdbc4 for > instance) > For the pooling behavior we can use something like commons-pool -- 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-470) SharePoint 2010 moves web services to new names; need SharePoint 2010 support to be able to reach them
[
https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270593#comment-13270593
]
Karl Wright commented on CONNECTORS-470:
It turns out that these services are considered "obsolete" but are nonetheless
present.
{code}
DspSts Web Service
SharePoint 2010
This topic has not yet been rated - Rate this topic
Obsolete. Use the managed client object model to perform queries against
SharePoint Foundation site and list data, instead. This Web service is an
adapter service that provides a method for performing queries, and it is
maintained for backward compatibility.
To access this Web service set a Web reference to
http:///_vti_bin/DspSts.asmx.
{code}
So it looks like they are all present, or at least you can still get them
installed if you select the right installation option.
> SharePoint 2010 moves web services to new names; need SharePoint 2010 support
> to be able to reach them
> --
>
> Key: CONNECTORS-470
> URL: https://issues.apache.org/jira/browse/CONNECTORS-470
> Project: ManifoldCF
> Issue Type: Improvement
> Components: SharePoint connector
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> See here for list of the SharePoint web services for SharePoint 2010:
> http://msdn.microsoft.com/en-us/library/ee705814.aspx
--
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] [Updated] (CONNECTORS-470) SharePoint 2010 support
[ https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-470: --- Summary: SharePoint 2010 support (was: SharePoint 2010 moves web services to new names; need SharePoint 2010 support to be able to reach them) > SharePoint 2010 support > --- > > Key: CONNECTORS-470 > URL: https://issues.apache.org/jira/browse/CONNECTORS-470 > Project: ManifoldCF > Issue Type: Improvement > Components: SharePoint connector >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > See here for list of the SharePoint web services for SharePoint 2010: > http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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] [Created] (CONNECTORS-470) SharePoint 2010 moves web services to new names; need SharePoint 2010 support to be able to reach them
Karl Wright created CONNECTORS-470: -- Summary: SharePoint 2010 moves web services to new names; need SharePoint 2010 support to be able to reach them Key: CONNECTORS-470 URL: https://issues.apache.org/jira/browse/CONNECTORS-470 Project: ManifoldCF Issue Type: Improvement Components: SharePoint connector Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 See here for list of the SharePoint web services for SharePoint 2010: http://msdn.microsoft.com/en-us/library/ee705814.aspx -- 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] [Updated] (CONNECTORS-96) Replace the current connection pool by one that is more up-to-date
[ https://issues.apache.org/jira/browse/CONNECTORS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-96: -- Fix Version/s: (was: ManifoldCF next) ManifoldCF 0.6 > Replace the current connection pool by one that is more up-to-date > -- > > Key: CONNECTORS-96 > URL: https://issues.apache.org/jira/browse/CONNECTORS-96 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2 >Reporter: Jettro Coenradie >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > At the moment we use a connection pool from bitmechanic. This is the least to > say some what outdated. Hard to find any information about it. The only thing > I could find was this: > http://www.knightsofthenet.com/projects/SQLPool/ > Can we replace this with an implementation of for instance dbcp > http://commons.apache.org/dbcp/index.html > I think there is a big risk in using this old versions that are not tested on > new java systems anymore. We can be missing a lot of optimizations (jdbc4 for > instance) > For the pooling behavior we can use something like commons-pool -- 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] [Assigned] (CONNECTORS-96) Replace the current connection pool by one that is more up-to-date
[ https://issues.apache.org/jira/browse/CONNECTORS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-96: - Assignee: Karl Wright > Replace the current connection pool by one that is more up-to-date > -- > > Key: CONNECTORS-96 > URL: https://issues.apache.org/jira/browse/CONNECTORS-96 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2 >Reporter: Jettro Coenradie >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > At the moment we use a connection pool from bitmechanic. This is the least to > say some what outdated. Hard to find any information about it. The only thing > I could find was this: > http://www.knightsofthenet.com/projects/SQLPool/ > Can we replace this with an implementation of for instance dbcp > http://commons.apache.org/dbcp/index.html > I think there is a big risk in using this old versions that are not tested on > new java systems anymore. We can be missing a lot of optimizations (jdbc4 for > instance) > For the pooling behavior we can use something like commons-pool -- 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-469) Upgrade the way framework core is shut down to also allow for webapp context shutdowns
[
https://issues.apache.org/jira/browse/CONNECTORS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268012#comment-13268012
]
Karl Wright commented on CONNECTORS-469:
r1333735
> Upgrade the way framework core is shut down to also allow for webapp context
> shutdowns
> --
>
> Key: CONNECTORS-469
> URL: https://issues.apache.org/jira/browse/CONNECTORS-469
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> Shutdown of a web application under Tomcat sometimes leaves exceptions due to
> non-up-to-date ability to deal with web application shutdown events.
> Specifically, we need the following:
> (1) An implementation of javax.servlet.ServletContextListener in every web
> application
> (2) Appropriate locking to prevent an already-shut-down web application from
> trying to shut itself down another time
> (3) The following addition to the web.xml file for the web applications:
> {code}
>
>
>
> com.mycompany.MyClass
>
>
> {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] [Resolved] (CONNECTORS-469) Upgrade the way framework core is shut down to also allow for webapp context shutdowns
[
https://issues.apache.org/jira/browse/CONNECTORS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-469.
Resolution: Fixed
> Upgrade the way framework core is shut down to also allow for webapp context
> shutdowns
> --
>
> Key: CONNECTORS-469
> URL: https://issues.apache.org/jira/browse/CONNECTORS-469
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> Shutdown of a web application under Tomcat sometimes leaves exceptions due to
> non-up-to-date ability to deal with web application shutdown events.
> Specifically, we need the following:
> (1) An implementation of javax.servlet.ServletContextListener in every web
> application
> (2) Appropriate locking to prevent an already-shut-down web application from
> trying to shut itself down another time
> (3) The following addition to the web.xml file for the web applications:
> {code}
>
>
>
> com.mycompany.MyClass
>
>
> {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] [Updated] (CONNECTORS-469) Upgrade the way framework core is shut down to also allow for webapp context shutdowns
[
https://issues.apache.org/jira/browse/CONNECTORS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-469:
---
Fix Version/s: (was: ManifoldCF 0.5)
ManifoldCF 0.6
> Upgrade the way framework core is shut down to also allow for webapp context
> shutdowns
> --
>
> Key: CONNECTORS-469
> URL: https://issues.apache.org/jira/browse/CONNECTORS-469
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> Shutdown of a web application under Tomcat sometimes leaves exceptions due to
> non-up-to-date ability to deal with web application shutdown events.
> Specifically, we need the following:
> (1) An implementation of javax.servlet.ServletContextListener in every web
> application
> (2) Appropriate locking to prevent an already-shut-down web application from
> trying to shut itself down another time
> (3) The following addition to the web.xml file for the web applications:
> {code}
>
>
>
> com.mycompany.MyClass
>
>
> {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] [Created] (CONNECTORS-469) Upgrade the way framework core is shut down to also allow for webapp context shutdowns
Karl Wright created CONNECTORS-469:
--
Summary: Upgrade the way framework core is shut down to also allow
for webapp context shutdowns
Key: CONNECTORS-469
URL: https://issues.apache.org/jira/browse/CONNECTORS-469
Project: ManifoldCF
Issue Type: Improvement
Components: Framework core
Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 0.5
Shutdown of a web application under Tomcat sometimes leaves exceptions due to
non-up-to-date ability to deal with web application shutdown events.
Specifically, we need the following:
(1) An implementation of javax.servlet.ServletContextListener in every web
application
(2) Appropriate locking to prevent an already-shut-down web application from
trying to shut itself down another time
(3) The following addition to the web.xml file for the web applications:
{code}
com.mycompany.MyClass
{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-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263531#comment-13263531 ] Karl Wright commented on CONNECTORS-467: Attached the patch, since the community will want it for the 0.5 release. > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Updated] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-467: --- Attachment: CONNECTORS-467.patch > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > Attachments: CONNECTORS-467.patch > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Updated] (CONNECTORS-453) ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-453: --- Summary: ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs (was: ManifoldCF running with Derby 10.8.1.1 has severe performance problems) > ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs > - > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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-453) ManifoldCF running with Derby 10.8.1.1 has severe performance problems
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263148#comment-13263148 ] Karl Wright commented on CONNECTORS-453: r1331102 > ManifoldCF running with Derby 10.8.1.1 has severe performance problems > -- > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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] [Resolved] (CONNECTORS-453) ManifoldCF running with Derby 10.8.1.1 has severe performance problems
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-453. Resolution: Fixed > ManifoldCF running with Derby 10.8.1.1 has severe performance problems > -- > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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-453) ManifoldCF running with Derby 10.8.1.1 has severe performance problems
[
https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263092#comment-13263092
]
Karl Wright commented on CONNECTORS-453:
Here's another example:
Error!
A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, JOBS, (1,7) Waiting XID : {157800, X} , APP, UPDATE jobs SET
status=? WHERE id=? Granted XID : {157521, S} , {157653, S} Lock : ROW,
JOBQUEUE, (503,86) Waiting XID : {157653, S} , APP, SELECT
t0.id,t0.jobid,t0.dochash,t0.docid,t0.status,t0.failtime,t0.failcount,t0.priorityset
FROM jobqueue t0 WHERE t0.status IN (?,?) AND t0.checkaction=? AND
t0.checktime<=? AND EXISTS(SELECT 'x' FROM jobs t1 WHERE t1.status IN (?,?) AND
t1.id=t0.jobid AND t1.priority=?) AND NOT EXISTS(SELECT 'x' FROM jobqueue t2
WHERE t2.dochash=t0.dochash AND t2.status IN (?,?,?,?,?,?) AND
t2.jobid!=t0.jobid) AND NOT EXISTS(SELECT 'x' FROM prereqevents t3,events t4
WHERE t0.id=t3.owner AND t3.eventname=t4.name) ORDER BY t0.docpriority
ASC,t0.status ASC,t0.checkaction ASC,t0.checktime ASC FETCH NEXT 120 ROWS ONLY
Granted XID : {157557, X} Lock : ROW, JOBS, (1,7) Waiting XID : {157557, S} ,
APP, INSERT INTO hopcount (deathmark,parentidhash,id,distance,jobid,linktype)
VALUES (?,?,?,?,?,?) . The selected victim is XID : 157800.
> ManifoldCF running with Derby 10.8.1.1 has severe performance problems
> --
>
> Key: CONNECTORS-453
> URL: https://issues.apache.org/jira/browse/CONNECTORS-453
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework core
>Affects Versions: ManifoldCF 0.5
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20
> documents. Clearly the Derby contention/locking bugs are back with a
> vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to
> look at them again.
> In the interim, maybe it is time to use hsqldb as the default embedded
> database for the single-process example instead of Derby.
--
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-453) ManifoldCF running with Derby 10.8.1.1 has severe performance problems
[
https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263090#comment-13263090
]
Karl Wright commented on CONNECTORS-453:
Clicking pause during the job run yields the following to be displayed in the
UI:
A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, JOBS, (1,7) Waiting XID : {147028, X} , APP, UPDATE jobs SET
status=? WHERE id=? Granted XID : {146703, S} , {146941, S} Lock : ROW,
JOBQUEUE, (481,10) Waiting XID : {146941, S} , APP, SELECT
jobid,CAST(COUNT(dochash) AS bigint) AS doccount FROM jobqueue t1 WHERE
EXISTS(SELECT 'x' FROM jobs t0 WHERE t0.id=t1.jobid AND id=?) GROUP BY jobid
Granted XID : {146612, X} Lock : ROW, HOPCOUNT, (1734,27) Waiting XID :
{146612, S} , APP, SELECT parentidhash,linktype,distance FROM hopcount WHERE
jobid=? AND parentidhash IN (?,?,?,?,?,?,?,?,?,?) AND linktype=? Granted XID :
{14, X} Lock : ROW, JOBS, (1,7) Waiting XID : {14, S} , APP, INSERT
INTO hopcount (deathmark,parentidhash,id,distance,jobid,linktype) VALUES
(?,?,?,?,?,?) . The selected victim is XID : 147028.
> ManifoldCF running with Derby 10.8.1.1 has severe performance problems
> --
>
> Key: CONNECTORS-453
> URL: https://issues.apache.org/jira/browse/CONNECTORS-453
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework core
>Affects Versions: ManifoldCF 0.5
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20
> documents. Clearly the Derby contention/locking bugs are back with a
> vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to
> look at them again.
> In the interim, maybe it is time to use hsqldb as the default embedded
> database for the single-process example instead of Derby.
--
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-453) ManifoldCF running with Derby 10.8.1.1 has severe performance problems
[ https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263086#comment-13263086 ] Karl Wright commented on CONNECTORS-453: I see stalls only at the very beginning of a crawl. Long crawls with lots of documents don't appear to stall, however. Still trying to figure out if this is an actual problem or something more innocuous. > ManifoldCF running with Derby 10.8.1.1 has severe performance problems > -- > > Key: CONNECTORS-453 > URL: https://issues.apache.org/jira/browse/CONNECTORS-453 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > Since upgrading to Derby 10.8.x.x, tt takes minutes to crawl just 20 > documents. Clearly the Derby contention/locking bugs are back with a > vengeance in 10.8.x.x. Either we use 10.7.x.x or we get the Derby team to > look at them again. > In the interim, maybe it is time to use hsqldb as the default embedded > database for the single-process example instead of Derby. -- 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] [Resolved] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlend Garåsen resolved CONNECTORS-467. --- Resolution: Fixed r1330696. > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261687#comment-13261687 ] Erlend Garåsen commented on CONNECTORS-467: --- It seems that we need to go for the first option instead in order to keep JSP 1.x compatibility. Since the tag libraries in JSTL 1.2 have new URIs (e.g. http://java.sun.com/jsp/jstl/core), web containers will probably assume the new URIs unless the old ones are specified. I have placed the directives inside a directive and tested MCF on Resin 4.0.19, Tomcat 7.0.6 and Jetty 7.5.4 without any problems. If there are no comments, I will commit my changes tomorrow. > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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-468) Using ResourceBundle under Velocity has unhelpful behavior when a key is missing
[ https://issues.apache.org/jira/browse/CONNECTORS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261595#comment-13261595 ] Karl Wright commented on CONNECTORS-468: r1330240. Forgot to add the darned file to svn. > Using ResourceBundle under Velocity has unhelpful behavior when a key is > missing > > > Key: CONNECTORS-468 > URL: https://issues.apache.org/jira/browse/CONNECTORS-468 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > When you use ResourceBundle.getString in a Velocity template, the behavior > for a missing key is to throw an exception - which causes the template to not > render and an exception to be printed in the log. It would be much better if > the behavior was more similar to Messages.getString. We can do this by > wrapping ResourceBundle and using the wrapped class in the context instead of > ResourceBundle itself. -- 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-468) Using ResourceBundle under Velocity has unhelpful behavior when a key is missing
[
https://issues.apache.org/jira/browse/CONNECTORS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261429#comment-13261429
]
Erlend Garåsen commented on CONNECTORS-468:
---
I'm afraid that this change have some unwanted side effects. I just did a clean
svn co after i upgraded to SVN 1.7, and now I get the following error:
{code}
[javac] Compiling 8 source files to
/Users/erlendfg/tmp/mcf_2012/framework/build/ui-core/classes
[javac]
/Users/erlendfg/tmp/mcf_2012/framework/ui-core/src/main/java/org/apache/manifoldcf/ui/i18n/Messages.java:142:
cannot find symbol
[javac] symbol : class ResourceBundleWrapper
[javac] location: class org.apache.manifoldcf.ui.i18n.Messages
[javac] context.put("ResourceBundle",new
ResourceBundleWrapper(rb,bundleName,locale));
{code}
> Using ResourceBundle under Velocity has unhelpful behavior when a key is
> missing
>
>
> Key: CONNECTORS-468
> URL: https://issues.apache.org/jira/browse/CONNECTORS-468
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Framework core
>Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> When you use ResourceBundle.getString in a Velocity template, the behavior
> for a missing key is to throw an exception - which causes the template to not
> render and an exception to be printed in the log. It would be much better if
> the behavior was more similar to Messages.getString. We can do this by
> wrapping ResourceBundle and using the wrapped class in the context instead of
> ResourceBundle itself.
--
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-468) Using ResourceBundle under Velocity has unhelpful behavior when a key is missing
[ https://issues.apache.org/jira/browse/CONNECTORS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260867#comment-13260867 ] Karl Wright commented on CONNECTORS-468: r1329957 > Using ResourceBundle under Velocity has unhelpful behavior when a key is > missing > > > Key: CONNECTORS-468 > URL: https://issues.apache.org/jira/browse/CONNECTORS-468 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > When you use ResourceBundle.getString in a Velocity template, the behavior > for a missing key is to throw an exception - which causes the template to not > render and an exception to be printed in the log. It would be much better if > the behavior was more similar to Messages.getString. We can do this by > wrapping ResourceBundle and using the wrapped class in the context instead of > ResourceBundle itself. -- 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] [Resolved] (CONNECTORS-468) Using ResourceBundle under Velocity has unhelpful behavior when a key is missing
[ https://issues.apache.org/jira/browse/CONNECTORS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-468. Resolution: Fixed > Using ResourceBundle under Velocity has unhelpful behavior when a key is > missing > > > Key: CONNECTORS-468 > URL: https://issues.apache.org/jira/browse/CONNECTORS-468 > Project: ManifoldCF > Issue Type: Improvement > Components: Framework core >Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > When you use ResourceBundle.getString in a Velocity template, the behavior > for a missing key is to throw an exception - which causes the template to not > render and an exception to be printed in the log. It would be much better if > the behavior was more similar to Messages.getString. We can do this by > wrapping ResourceBundle and using the wrapped class in the context instead of > ResourceBundle itself. -- 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] [Updated] (CONNECTORS-467) Remove outdated taglib directives in web.xml
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlend Garåsen updated CONNECTORS-467: -- Summary: Remove outdated taglib directives in web.xml (was: MCF version 0.5 does not run on Resin) > Remove outdated taglib directives in web.xml > > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Created] (CONNECTORS-468) Using ResourceBundle under Velocity has unhelpful behavior when a key is missing
Karl Wright created CONNECTORS-468: -- Summary: Using ResourceBundle under Velocity has unhelpful behavior when a key is missing Key: CONNECTORS-468 URL: https://issues.apache.org/jira/browse/CONNECTORS-468 Project: ManifoldCF Issue Type: Improvement Components: Framework core Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 When you use ResourceBundle.getString in a Velocity template, the behavior for a missing key is to throw an exception - which causes the template to not render and an exception to be printed in the log. It would be much better if the behavior was more similar to Messages.getString. We can do this by wrapping ResourceBundle and using the wrapped class in the context instead of ResourceBundle itself. -- 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-467) MCF version 0.5 does not run on Resin
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260385#comment-13260385 ] Karl Wright commented on CONNECTORS-467: You would only need to open a vote thread if you are removing an option or destroying backwards compatibility. So please just go ahead with (2). > MCF version 0.5 does not run on Resin > - > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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-467) MCF version 0.5 does not run on Resin
[
https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260373#comment-13260373
]
Erlend Garåsen commented on CONNECTORS-467:
---
bq. Alternatively, if there is a way to do the same thing without wrecking JSP
1.x compatibility, then we can just fix this.
JSP 1.2 TLD files, to which the path is referenced in our web.xml, should be
upward compatible. There should be no need to change them in order to be
compatible with JSP 2.0. Some web containers, such as Resin, complains because
we are now pointing to an XSD which does not have any reference to a taglib
alement:
{code}
http://java.sun.com/xml.ns/javaee/web-app_2_5.xsd"; version="2.5">
{code}
We have two options:
1. Place the taglib directives inside a directive.
2. Just remove the taglibs directives. JSP containers should automatically look
for TLD files in all subfolders of /WEB-INF which is the case for MCF
(they are placed inside the subfolder "jsp").
I think we should go for the last option. I can try to deploy the application
on both Resin and Tomcat in order to test whether it works as expected. Do you
think we should open a vote thread for these two options mentioned above?
> MCF version 0.5 does not run on Resin
> -
>
> Key: CONNECTORS-467
> URL: https://issues.apache.org/jira/browse/CONNECTORS-467
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework core
>Affects Versions: ManifoldCF 0.5
>Reporter: Erlend Garåsen
>Assignee: Erlend Garåsen
> Fix For: ManifoldCF 0.6
>
>
> Resin does not accept the web.xml file which belongs to the web-crawler-ui
> application and returns 500 Server error after deployment. Resin complains
> about an unexpected -tag. The taglib directive is not longer needed
> in JSP 2.0 which we're now using. Some information about how we can configure
> MCF properly for JSP 2.0:
> http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml
> It's probably possible to place the taglib directives inside a
> directive as a quick fix as well.
--
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-467) MCF version 0.5 does not run on Resin
[ https://issues.apache.org/jira/browse/CONNECTORS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259667#comment-13259667 ] Karl Wright commented on CONNECTORS-467: If this is a jsp 1.x vs jsp 2.0 issue, I think we'd better get buy-in from the community before making this change. We will also need to update or create a document describing the webapp compatibility of the ManifoldCF web applications. Alternatively, if there is a way to do the same thing without wrecking JSP 1.x compatibility, then we can just fix this. If there is no backward-compatible fix that you can find, can you open a [VOTE] thread in connectors-dev so we can have a show of hands on whether we should move from JSP 1.x to JSP 2.0 application servers? Thanks! > MCF version 0.5 does not run on Resin > - > > Key: CONNECTORS-467 > URL: https://issues.apache.org/jira/browse/CONNECTORS-467 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Affects Versions: ManifoldCF 0.5 >Reporter: Erlend Garåsen >Assignee: Erlend Garåsen > Fix For: ManifoldCF 0.6 > > > Resin does not accept the web.xml file which belongs to the web-crawler-ui > application and returns 500 Server error after deployment. Resin complains > about an unexpected -tag. The taglib directive is not longer needed > in JSP 2.0 which we're now using. Some information about how we can configure > MCF properly for JSP 2.0: > http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml > It's probably possible to place the taglib directives inside a > directive as a quick fix as well. -- 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] [Created] (CONNECTORS-467) MCF version 0.5 does not run on Resin
Erlend Garåsen created CONNECTORS-467: - Summary: MCF version 0.5 does not run on Resin Key: CONNECTORS-467 URL: https://issues.apache.org/jira/browse/CONNECTORS-467 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 0.5 Reporter: Erlend Garåsen Assignee: Erlend Garåsen Fix For: ManifoldCF 0.6 Resin does not accept the web.xml file which belongs to the web-crawler-ui application and returns 500 Server error after deployment. Resin complains about an unexpected -tag. The taglib directive is not longer needed in JSP 2.0 which we're now using. Some information about how we can configure MCF properly for JSP 2.0: http://wiki.metawerx.net/wiki/RemovingTaglibFromWeb.xml It's probably possible to place the taglib directives inside a directive as a quick fix as well. -- 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] [Resolved] (CONNECTORS-466) CMIS UI test fails
[ https://issues.apache.org/jira/browse/CONNECTORS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-466. Resolution: Fixed > CMIS UI test fails > -- > > Key: CONNECTORS-466 > URL: https://issues.apache.org/jira/browse/CONNECTORS-466 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > The CMIS UI test fails. Not clear yet whether this is a bug in the > Javascript or in the revised Javascript tester. -- 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-466) CMIS UI test fails
[ https://issues.apache.org/jira/browse/CONNECTORS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259493#comment-13259493 ] Karl Wright commented on CONNECTORS-466: r1329160 (fix to CMIS connector) > CMIS UI test fails > -- > > Key: CONNECTORS-466 > URL: https://issues.apache.org/jira/browse/CONNECTORS-466 > Project: ManifoldCF > Issue Type: Bug > Components: CMIS connector >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > The CMIS UI test fails. Not clear yet whether this is a bug in the > Javascript or in the revised Javascript tester. -- 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-466) CMIS UI test fails
[
https://issues.apache.org/jira/browse/CONNECTORS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259468#comment-13259468
]
Karl Wright commented on CONNECTORS-466:
Here's the error:
{code}
[junit] Multipart posting url
'http://localhost:8346/mcf-crawler-ui/execute.jsp' with parameters
'username=foo&password=bar&throttlecount=0&description=&connname=MyRepositoryConnection&isnewconnection=true&binding=atom&server=localhost&classname=org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnector&tabname=Name&maxconnections=10&protocol=http&path=%2Fchemistry-opencmis-server-inmemory%2Fatom&authorityname=_none_&type=connection&port=9090&repositoryId=&op=Continue'
and 0 files...
[junit] Traceback (most recent call last):
[junit] File "test.py", line 102, in
[junit] var73.click()
...
[junit] File
"C:\wip\mcf\trunk\tests\cmis\test-derby-output\Javascript.py", line 69, in
bool_value
[junit] raise Exception("Object %s has no boolean value" %
unicode(self) )
[junit] Exception: Object Numeric value (-1) has no boolean value
{code}
> CMIS UI test fails
> --
>
> Key: CONNECTORS-466
> URL: https://issues.apache.org/jira/browse/CONNECTORS-466
> Project: ManifoldCF
> Issue Type: Bug
> Components: CMIS connector
>Affects Versions: ManifoldCF 0.6
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> The CMIS UI test fails. Not clear yet whether this is a bug in the
> Javascript or in the revised Javascript tester.
--
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] [Created] (CONNECTORS-466) CMIS UI test fails
Karl Wright created CONNECTORS-466: -- Summary: CMIS UI test fails Key: CONNECTORS-466 URL: https://issues.apache.org/jira/browse/CONNECTORS-466 Project: ManifoldCF Issue Type: Bug Components: CMIS connector Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The CMIS UI test fails. Not clear yet whether this is a bug in the Javascript or in the revised Javascript tester. -- 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=13259186#comment-13259186
]
Karl Wright commented on CONNECTORS-347:
After the fix for CONNECTORS-464, I've been unable to reproduce the MySQL
issue. Still trying...
> 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] [Resolved] (CONNECTORS-465) Python UI tester needs an overhaul
[ https://issues.apache.org/jira/browse/CONNECTORS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-465. Resolution: Fixed > Python UI tester needs an overhaul > -- > > Key: CONNECTORS-465 > URL: https://issues.apache.org/jira/browse/CONNECTORS-465 > Project: ManifoldCF > Issue Type: Improvement > Components: Tests >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > The python UI tester needs to handle references reasonably throughout its > entire expression evaluation process, rather than special-casing them deep > inside the innermost level. -- 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-465) Python UI tester needs an overhaul
[ https://issues.apache.org/jira/browse/CONNECTORS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259176#comment-13259176 ] Karl Wright commented on CONNECTORS-465: r1328897 > Python UI tester needs an overhaul > -- > > Key: CONNECTORS-465 > URL: https://issues.apache.org/jira/browse/CONNECTORS-465 > Project: ManifoldCF > Issue Type: Improvement > Components: Tests >Affects Versions: ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > The python UI tester needs to handle references reasonably throughout its > entire expression evaluation process, rather than special-casing them deep > inside the innermost level. -- 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] [Created] (CONNECTORS-465) Python UI tester needs an overhaul
Karl Wright created CONNECTORS-465: -- Summary: Python UI tester needs an overhaul Key: CONNECTORS-465 URL: https://issues.apache.org/jira/browse/CONNECTORS-465 Project: ManifoldCF Issue Type: Improvement Components: Tests Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The python UI tester needs to handle references reasonably throughout its entire expression evaluation process, rather than special-casing them deep inside the innermost level. -- 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] [Resolved] (CONNECTORS-464) Hopcount logic does not remove all references to a document when the document is deleted from the queue
[ https://issues.apache.org/jira/browse/CONNECTORS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-464. Resolution: Fixed > Hopcount logic does not remove all references to a document when the document > is deleted from the queue > --- > > Key: CONNECTORS-464 > URL: https://issues.apache.org/jira/browse/CONNECTORS-464 > Project: ManifoldCF > Issue Type: Bug > Components: Framework crawler agent >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, > ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > When a document is deleted during crawling, the hopcount, intrinsiclink, and > hopdeletedeps tables are incompletely cleaned up to reflect the deletion. > Specifically, only child references of the document are removed; references > from parents are not. -- 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=13259082#comment-13259082
]
Karl Wright commented on CONNECTORS-347:
I've created (and resolved) a new ticket, CONNECTORS-464, to cover the
long-standing document deletion cleanup problem.
> 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-464) Hopcount logic does not remove all references to a document when the document is deleted from the queue
[ https://issues.apache.org/jira/browse/CONNECTORS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259081#comment-13259081 ] Karl Wright commented on CONNECTORS-464: r1328881 > Hopcount logic does not remove all references to a document when the document > is deleted from the queue > --- > > Key: CONNECTORS-464 > URL: https://issues.apache.org/jira/browse/CONNECTORS-464 > Project: ManifoldCF > Issue Type: Bug > Components: Framework crawler agent >Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3, > ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6 >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: ManifoldCF 0.6 > > > When a document is deleted during crawling, the hopcount, intrinsiclink, and > hopdeletedeps tables are incompletely cleaned up to reflect the deletion. > Specifically, only child references of the document are removed; references > from parents are not. -- 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] [Created] (CONNECTORS-464) Hopcount logic does not remove all references to a document when the document is deleted from the queue
Karl Wright created CONNECTORS-464: -- Summary: Hopcount logic does not remove all references to a document when the document is deleted from the queue Key: CONNECTORS-464 URL: https://issues.apache.org/jira/browse/CONNECTORS-464 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 0.5, ManifoldCF 0.4, ManifoldCF 0.3, ManifoldCF 0.2, ManifoldCF 0.1, ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 When a document is deleted during crawling, the hopcount, intrinsiclink, and hopdeletedeps tables are incompletely cleaned up to reflect the deletion. Specifically, only child references of the document are removed; references from parents are not. -- 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] [Resolved] (CONNECTORS-463) Update the site to show how fixing the maven build process for the 0.5-incubating release
[
https://issues.apache.org/jira/browse/CONNECTORS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piergiorgio Lucidi resolved CONNECTORS-463.
---
Resolution: Fixed
r1328455.
> Update the site to show how fixing the maven build process for the
> 0.5-incubating release
> -
>
> Key: CONNECTORS-463
> URL: https://issues.apache.org/jira/browse/CONNECTORS-463
> Project: ManifoldCF
> Issue Type: Bug
> Components: Site
>Affects Versions: ManifoldCF 0.5
>Reporter: Piergiorgio Lucidi
>Assignee: Piergiorgio Lucidi
> Fix For: ManifoldCF 0.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> We need to update the site in order to guide developers to correctly build
> the project using Maven.
> Due to the latest changes during the 0.5-incubating release, we released the
> source package with a problem with the Maven build.
> So, before running mvn clean install, it is needed to run the following
> command:
> {code}
> mvn install:install-file -Dfile=lib/commons-httpclient.jar
> -DgroupId=commons-httpclient -DartifactId=commons-httpclient-mcf
> -Dversion=3.1 -Dpackaging=jar
> {code}
> The execution of the command above fixes the issue on the source code of the
> 0.5-incubating release.
> I tested the command using an empty Maven repository.
--
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] [Created] (CONNECTORS-463) Update the site to show how fixing the maven build process for the 0.5-incubating release
Update the site to show how fixing the maven build process for the
0.5-incubating release
-
Key: CONNECTORS-463
URL: https://issues.apache.org/jira/browse/CONNECTORS-463
Project: ManifoldCF
Issue Type: Bug
Components: Site
Affects Versions: ManifoldCF 0.5
Reporter: Piergiorgio Lucidi
Assignee: Piergiorgio Lucidi
Fix For: ManifoldCF 0.6
We need to update the site in order to guide developers to correctly build the
project using Maven.
Due to the latest changes during the 0.5-incubating release, we released the
source package with a problem with the Maven build.
So, before running mvn clean install, it is needed to run the following command:
{code}
mvn install:install-file -Dfile=lib/commons-httpclient.jar
-DgroupId=commons-httpclient -DartifactId=commons-httpclient-mcf -Dversion=3.1
-Dpackaging=jar
{code}
The execution of the command above fixes the issue on the source code of the
0.5-incubating release.
I tested the command using an empty Maven repository.
--
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] [Issue Comment Edited] (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 edited comment on CONNECTORS-347 at 4/20/12 1:27 PM:
-
A postgresql run is as follows:
{code}
testdb=# select dochash,docid from jobqueue;
dochash | docid
--+-
EE6C0ED002CE9303183FEFEF111D6598203F6295 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata\testdir
181B9C9FB7F62D24461967391B73FF7CB0B14CD9 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata\test2.txt
24081AC0B03B2394F38D3EB78A3BEDB6CCF1D981 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata\test1.txt
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata\testdir\seconddir
4ED8AFCC917B604C1EE4C83458DB9B7265967F40 |
C:\wip\mcf\trunk\tests\filesystem\test-postgresql-output\testdata\testdir\test3.txt
(6 rows)
testdb=# select parentidhash, childidhash from intrinsiclink;
parentidhash | childidhash
--+--
EE6C0ED002CE9303183FEFEF111D6598203F6295 |
181B9C9FB7F62D24461967391B73FF7CB0B14CD9 |
EE6C0ED002CE9303183FEFEF111D6598203F6295
24081AC0B03B2394F38D3EB78A3BEDB6CCF1D981 |
EE6C0ED002CE9303183FEFEF111D6598203F6295
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60 |
EE6C0ED002CE9303183FEFEF111D6598203F6295
4ED8AFCC917B604C1EE4C83458DB9B7265967F40 |
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666 |
E7DE0B8D3F153CECFD3C57B4D83E59073EC4DD60
7013D738BB77ED47763449997384046B20B77832 |
5AA0DB8B2B7D267FAD5E3E0E8926996DEFC4C666
(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}
was (Author: kwri...@metacarta.com):
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 |
[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] [Issue Comment Edited] (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 edited comment on CONNECTORS-347 at 4/20/12 12:58 PM:
--
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}
Even in this one, the jobqueue table is inconsistent with the hopcount and
intrinsiclink tables. They should all be consistent.
was (Author: kwri...@metacarta.com):
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 |
| 9F6F59234CC
[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] [Issue Comment Edited] (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 edited comment on CONNECTORS-347 at 4/20/12 1:42 AM:
-
Just saw it again; clearly it is "real".
My working hypothesis is that the counts returned by count() in the SQL
statements are in fact not synchronized with the transactions, so maybe the
count can "run behind". The context in which this happens is an initial crawl
of six documents, with a hopcount filter. If the filter is not working the
count would be 7; with a working filter, it's 6. But how can we then get 4?
was (Author: kwri...@metacarta.com):
Just saw it again; clearly it is "real".
My working hypothesis is that the counts returned by count(x) in the SQL
statements are in fact not synchronized with the transactions, so maybe the
count can "run behind". The context in which this happens is an initial crawl
of six documents, with a hopcount filter. If the filter is not working the
count would be 7; with a working filter, it's 6. But how can we then get 4?
> 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] [Updated] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-347:
---
Affects Version/s: ManifoldCF 0.6
Fix Version/s: (was: ManifoldCF next)
ManifoldCF 0.6
> 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] [Issue Comment Edited] (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 edited comment on CONNECTORS-347 at 4/19/12 11:23 PM:
--
Just saw it again; clearly it is "real".
My working hypothesis is that the counts returned by count(x) in the SQL
statements are in fact not synchronized with the transactions, so maybe the
count can "run behind". The context in which this happens is an initial crawl
of six documents, with a hopcount filter. If the filter is not working the
count would be 7; with a working filter, it's 6. But how can we then get 4?
was (Author: kwri...@metacarta.com):
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-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-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] [Resolved] (CONNECTORS-459) Move to JDK1.6
[ https://issues.apache.org/jira/browse/CONNECTORS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-459. Resolution: Fixed > 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-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=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] [Resolved] (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:all-tabpanel
]
Karl Wright resolved CONNECTORS-460.
Resolution: Fixed
> 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
