Graduation-related tickets
Hi all, The Apache IT folks have an additional requirement which we will need to fulfill at some point as part of the graduation process. It is apparently a requirement that at least the site be completely buildable using only materials that we can obtain a zero-cost license for. We've been publishing our site including javadoc including the documentum, filenet, livelink, and meridio connectors, which technically violates this principle. There are two ways to address the problem. The first way is to check into trunk somewhere the javadocs, and periodically regenerate/check in changes. The second way is to write stubs for all of the proprietary libraries, and build and javadoc against those stubs rather than against the actual libraries themselves. After thinking about this a while, I concluded that it might be feasible to create stubs, and there would be additional benefits to the approach. Specifically, it would no longer be necessary for our release engineer to obtain the necessary proprietary materials in order to produce a release, and that would be a huge benefit in the long run. Also, Apache IT communicated that they were concerned that some of the proprietary materials might have javadoc restrictions such that we could not legally release javadoc for code that compiled against these jars. I do not think this is true but in the interests of trying to be a good Apache citizen we should eliminate this concern if it is reasonably possible to do so. I've therefore created a ticket, CONNECTORS-474, and a corresponding branch, and am working away on this. It will, of course, take some time. There will also need to be some testing of the proprietary connectors needed before the branch is committed, because building against stubs might inadvertantly introduce linkage errors. In the interim I've been assured that the migration to our TLP resources will continue as planned. Thanks, Karl
[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-tabpanelfocusedCommentId=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-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}
property name=org.apache.manifoldcf.databaseimplementationclass
value=org.apache.manifoldcf.core.database.DBInterfaceMySQL/
property name=org.apache.manifoldcf.dbsuperusername value=root/
property name=org.apache.manifoldcf.dbsuperuserpassword value=password/
property name=org.apache.manifoldcf.database.name value=manifoldcf/
property name=org.apache.manifoldcf.mysql.server value=A/
{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.init(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.init(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:
property name=org.apache.manifoldcf.databaseimplementationclass
value=org.apache.manifoldcf.core.database.DBInterfaceMySQL/
property name=org.apache.manifoldcf.dbsuperusername value=root/
property name=org.apache.manifoldcf.dbsuperuserpassword value=password/
property name=org.apache.manifoldcf.database.name value=manifoldcf/
property name=org.apache.manifoldcf.mysql.server value=A/
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.init(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.init(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
[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}
property name=org.apache.manifoldcf.databaseimplementationclass
value=org.apache.manifoldcf.core.database.DBInterfaceMySQL/
property name=org.apache.manifoldcf.dbsuperusername value=root/
property name=org.apache.manifoldcf.dbsuperuserpassword
value=password/
property name=org.apache.manifoldcf.database.name value=manifoldcf/
property name=org.apache.manifoldcf.mysql.server value=A/
{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.init(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.init(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] [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-tabpanelfocusedCommentId=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}
property name=org.apache.manifoldcf.databaseimplementationclass
value=org.apache.manifoldcf.core.database.DBInterfaceMySQL/
property name=org.apache.manifoldcf.dbsuperusername value=root/
property name=org.apache.manifoldcf.dbsuperuserpassword
value=password/
property name=org.apache.manifoldcf.database.name value=manifoldcf/
property name=org.apache.manifoldcf.mysql.server value=A/
{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.init(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.init(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}
property name=org.apache.manifoldcf.databaseimplementationclass
value=org.apache.manifoldcf.core.database.DBInterfaceMySQL/
property name=org.apache.manifoldcf.dbsuperusername value=root/
property name=org.apache.manifoldcf.dbsuperuserpassword
value=password/
property name=org.apache.manifoldcf.database.name value=manifoldcf/
property name=org.apache.manifoldcf.mysql.server value=A/
{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.init(ConnectionImpl.java:792)
at com.mysql.jdbc.JDBC4Connection.init(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] [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
Re: [VOTE] Release ManifoldCF 0.5.1, RC1
I unpacked the bin and gave it a hand test. Looks good. +1 Karl On Thu, May 17, 2012 at 10:40 PM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hi, You can download the release candidate from http://people.apache.org/~shinichiro/apache-manifoldcf-0.5.1-RC1/ and there is also a tag in svn under https://svn.apache.org/repos/asf/incubator/lcf/tags RC1 includes revising the pom.xml versions. I've already checked signatures. Thank you, Shinichiro Abe
[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
Re: [VOTE] Release ManifoldCF 0.5.1, RC0
I see two problems. First, the outer level names are correct (apache-manifoldcf-0.5.1-xxx), but the prefix inside is incorrect (apache-manifoldcf-0.5). This is odd because the build.xml has this line: target name=set-version property name=release-version value=0.5.1/ /target so I cannot explain this unless somehow the artifacts were built with an old version of build.xml. The second problem is that we need to rev the pom.xml versions also. They have to be 0.5.1 not 0.5. I'll take care of that. Karl On Wed, May 16, 2012 at 10:26 PM, Karl Wright daddy...@gmail.com wrote: Thanks! I'll have a look in the morning... Karl On Wed, May 16, 2012 at 10:24 PM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hi, You can download the release candidate from http://people.apache.org/~shinichiro/apache-manifoldcf-0.5.1-RC0/ and there is also a tag in svn under https://svn.apache.org/repos/asf/incubator/lcf/tags I've already checked signatures, run example and run ant test-dr test-hs. Thank you, Shinichiro Abe
Re: [VOTE] Release ManifoldCF 0.5.1, RC0
ok - I'm done with the maven work. Abe-san, can you check to be sure that the release branch builds with the proper prefixes before tagging again? Thanks! Karl On Thu, May 17, 2012 at 6:08 PM, Karl Wright daddy...@gmail.com wrote: I see two problems. First, the outer level names are correct (apache-manifoldcf-0.5.1-xxx), but the prefix inside is incorrect (apache-manifoldcf-0.5). This is odd because the build.xml has this line: target name=set-version property name=release-version value=0.5.1/ /target so I cannot explain this unless somehow the artifacts were built with an old version of build.xml. The second problem is that we need to rev the pom.xml versions also. They have to be 0.5.1 not 0.5. I'll take care of that. Karl On Wed, May 16, 2012 at 10:26 PM, Karl Wright daddy...@gmail.com wrote: Thanks! I'll have a look in the morning... Karl On Wed, May 16, 2012 at 10:24 PM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hi, You can download the release candidate from http://people.apache.org/~shinichiro/apache-manifoldcf-0.5.1-RC0/ and there is also a tag in svn under https://svn.apache.org/repos/asf/incubator/lcf/tags I've already checked signatures, run example and run ant test-dr test-hs. Thank you, Shinichiro Abe
Re: [VOTE] Release ManifoldCF 0.5.1, RC0
If you open up the zip or tar, the top-level directory is
apache-manifoldcf-0.5. That directory is set in build.xml when the
zip or tar is built:
zip destfile=apache-manifoldcf-${release-version}-src.zip
update=false
zipfileset dir=. prefix=apache-manifoldcf-${release-version}
So, ${release-version} must have been incorrect. But it is correct
now on the branch:
target name=set-version
property name=release-version value=0.5.1/
/target
So somehow you must have built the artifacts from a version of the
branch before you checked in the release-version change.
Karl
On Thu, May 17, 2012 at 8:27 PM, Shinichiro Abe
shinichiro.ab...@gmail.com wrote:
What is the prefix inside?
I ' m not sure where prefixes is.
Where do I check? the source code or jar file?
Thank you for modifying the pom.xml.
Shinichiro Abe
On 2012/05/18, at 7:13, Karl Wright wrote:
ok - I'm done with the maven work. Abe-san, can you check to be sure
that the release branch builds with the proper prefixes before tagging
again?
Thanks!
Karl
On Thu, May 17, 2012 at 6:08 PM, Karl Wright daddy...@gmail.com wrote:
I see two problems.
First, the outer level names are correct
(apache-manifoldcf-0.5.1-xxx), but the prefix inside is incorrect
(apache-manifoldcf-0.5). This is odd because the build.xml has this
line:
target name=set-version
property name=release-version value=0.5.1/
/target
so I cannot explain this unless somehow the artifacts were built with
an old version of build.xml.
The second problem is that we need to rev the pom.xml versions also.
They have to be 0.5.1 not 0.5. I'll take care of that.
Karl
On Wed, May 16, 2012 at 10:26 PM, Karl Wright daddy...@gmail.com wrote:
Thanks!
I'll have a look in the morning...
Karl
On Wed, May 16, 2012 at 10:24 PM, Shinichiro Abe
shinichiro.ab...@gmail.com wrote:
Hi,
You can download the release candidate from
http://people.apache.org/~shinichiro/apache-manifoldcf-0.5.1-RC0/
and there is also a tag in svn under
https://svn.apache.org/repos/asf/incubator/lcf/tags
I've already checked signatures,
run example and run ant test-dr test-hs.
Thank you,
Shinichiro Abe
FW: ASF Board Meeting Summary - May 16, 2012
Congratulations to all - we are now an official Apache project! Karl Sent from my Windows Phone From: Doug Cutting Sent: 5/16/2012 4:32 PM To: committ...@apache.org Subject: ASF Board Meeting Summary - May 16, 2012 The May board meeting took place on the 16th. The following directors were present: Shane Curcuru Doug Cutting Bertrand Delacretaz Roy T. Fielding Jim Jagielski Daniel Kulp Brett Porter Sam Ruby Greg Stein The following officers were present: Noirin Plunkett Craig L Russell The following guests were present: Gavin McDonald Hadrian Zbarcea The April minutes were approved. All of the received reports to the board were approved. The following reports were not received and are expected next month: Status report for the Apache Abdera Project Status report for the Apache Attic Project Status report for the Apache Creadur Project Status report for the Apache XMLBeans Project The following resolutions were passed unaminously: A. Change the Apache James Project Chair (Eric Charles, VP) B. Establish the Apache Hama Project (Edward J. Yoon, VP) C. Establish the Apache MRUnit Project (Brock Noland, VP) D. Establish the Apache Giraph Project (Avery Ching, VP) E. Establish the Apache ManifoldCF Project (Karl Wright, VP) F. Change the Apache MINA Project Chair (Emmanuel Lecharny, VP) G. Change the Apache Tcl Project Chair (Massimo Manghi, VP) H. Change the Apache Web Services Project Chair (Sagara Gunathunga) I. Change the Apache Continuum Project Chair (Brett Porter, VP) J. Approve the 2012-2013FY Budget The next board meeting will be on the 20th of June. Doug
[jira] [Commented] (CONNECTORS-472) Changes related to graduation
[ https://issues.apache.org/jira/browse/CONNECTORS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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
Proposed first graduation step: Moving the repository
Folks, Heads up: Now that we've graduated, I'd like to move the repository from https://svn.apache.org/repos/asf/incubator/lcf to https://svn.apache.org/repos/asf/manifoldcf. This, of course, will mean that all workspaces will need to do a svn switch operation to change their path. svn help switch should give you sufficient hints as to how. I'm planning to do the move tomorrow morning, as soon as Abe-san is done producing a 0.5.1 RC0 release candidate. Please object if you want me to hold off. [I'm hoping, of course, that I now have the proper permissions to do this. We'll see shortly.] Karl
Re: [VOTE] Release ManifoldCF 0.5.1, RC0
Thanks! I'll have a look in the morning... Karl On Wed, May 16, 2012 at 10:24 PM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hi, You can download the release candidate from http://people.apache.org/~shinichiro/apache-manifoldcf-0.5.1-RC0/ and there is also a tag in svn under https://svn.apache.org/repos/asf/incubator/lcf/tags I've already checked signatures, run example and run ant test-dr test-hs. Thank you, Shinichiro Abe
Re: Proposed first graduation step: Moving the repository
Since he's already done, I'm going to give this a try right now. Karl On Wed, May 16, 2012 at 10:25 PM, Karl Wright daddy...@gmail.com wrote: Folks, Heads up: Now that we've graduated, I'd like to move the repository from https://svn.apache.org/repos/asf/incubator/lcf to https://svn.apache.org/repos/asf/manifoldcf. This, of course, will mean that all workspaces will need to do a svn switch operation to change their path. svn help switch should give you sufficient hints as to how. I'm planning to do the move tomorrow morning, as soon as Abe-san is done producing a 0.5.1 RC0 release candidate. Please object if you want me to hold off. [I'm hoping, of course, that I now have the proper permissions to do this. We'll see shortly.] Karl
Re: Proposed first graduation step: Moving the repository
Looks like I don't have permissions to do this. I suppose I would need to open an infra ticket? Karl On Wed, May 16, 2012 at 10:25 PM, Karl Wright daddy...@gmail.com wrote: Folks, Heads up: Now that we've graduated, I'd like to move the repository from https://svn.apache.org/repos/asf/incubator/lcf to https://svn.apache.org/repos/asf/manifoldcf. This, of course, will mean that all workspaces will need to do a svn switch operation to change their path. svn help switch should give you sufficient hints as to how. I'm planning to do the move tomorrow morning, as soon as Abe-san is done producing a 0.5.1 RC0 release candidate. Please object if you want me to hold off. [I'm hoping, of course, that I now have the proper permissions to do this. We'll see shortly.] Karl
Re: Should we release an 0.5.1?
Feel free to generate an RC0 for 0.5.1 any time; I think all the correct tickets have been pulled up into the branch already. Thanks! Karl On Sat, May 12, 2012 at 7:08 AM, Karl Wright daddy...@gmail.com wrote: Yes we do. Would you be willing to do that? Thanks! Karl On Sat, May 12, 2012 at 7:03 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Okay. Do we need to change release-version into 0.5.1 at build.xml in the branch? Shinichiro Abe On 2012/05/12, at 19:39, Karl Wright wrote: Hi Abe-san, For point releases, the usual standard is to use the same branch as the main release. So we would continue to use the 0.5-incubating branch, and just make a new release from it, and of course new tags. Thanks, Karl On Sat, May 12, 2012 at 5:35 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Yes I did. I will be able to work as release manager next week. Please create 0.5.1 branch. Regards, Shinichiro Abe On 2012/05/12, at 16:14, Karl Wright wrote: It looks like this is probably happening, so I've pulled up three tickets into the 0.5 release branch: CONNECTORS-453 CONNECTORS-467 CONNECTORS-471 I suppose we could even spin a release candidate now, even though we shouldn't probably vote on it until we've officially graduated. The release candidate should be 0.5.1, not 0.5.1-incubating. Abe-san, did you want to be release manager for this? Karl On Mon, May 7, 2012 at 7:00 AM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: If we succeed in graduating in May, then +1 from me. This problem does not only affects Tomcat, but also Resin, and probably other web containers as well. Erlend On 04.05.12 21.03, Karl Wright wrote: My view: It will be relatively easy to do this once we graduate, and too much of a pain before then. If we succeed in graduating in May, I'd give a +1. If not, then maybe we should just try to release the 0.6 version instead. Karl On Fri, May 4, 2012 at 1:01 PM, Piergiorgio Lucidi piergior...@apache.org wrote: I think that it is important to release a 0.5.1 version to enable compatibility for Tomcat 7.x. +1 for me for releasing a 0.5.1 version Piergiorgio 2012/5/1 Karl Wrightdaddy...@gmail.com We've had a number of people using Tomcat 7.x who have tripped over CONNECTORS-467. Does the community want to release a 0.5.1 version to fix this one issue? Or, alternatively, try to push 0.6 out the door early? Karl -- Piergiorgio Lucidi http://www.open4dev.com -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
[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] [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] [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 taglib-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 jsp-config 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 taglib-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 jsp-config 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-tabpanelfocusedCommentId=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 taglib-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 jsp-config 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-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 taglib-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 jsp-config 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-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-tabpanelfocusedCommentId=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] [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] [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] [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-tabpanelfocusedCommentId=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] [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
Re: Should we release an 0.5.1?
It looks like this is probably happening, so I've pulled up three tickets into the 0.5 release branch: CONNECTORS-453 CONNECTORS-467 CONNECTORS-471 I suppose we could even spin a release candidate now, even though we shouldn't probably vote on it until we've officially graduated. The release candidate should be 0.5.1, not 0.5.1-incubating. Abe-san, did you want to be release manager for this? Karl On Mon, May 7, 2012 at 7:00 AM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: If we succeed in graduating in May, then +1 from me. This problem does not only affects Tomcat, but also Resin, and probably other web containers as well. Erlend On 04.05.12 21.03, Karl Wright wrote: My view: It will be relatively easy to do this once we graduate, and too much of a pain before then. If we succeed in graduating in May, I'd give a +1. If not, then maybe we should just try to release the 0.6 version instead. Karl On Fri, May 4, 2012 at 1:01 PM, Piergiorgio Lucidi piergior...@apache.org wrote: I think that it is important to release a 0.5.1 version to enable compatibility for Tomcat 7.x. +1 for me for releasing a 0.5.1 version Piergiorgio 2012/5/1 Karl Wrightdaddy...@gmail.com We've had a number of people using Tomcat 7.x who have tripped over CONNECTORS-467. Does the community want to release a 0.5.1 version to fix this one issue? Or, alternatively, try to push 0.6 out the door early? Karl -- Piergiorgio Lucidi http://www.open4dev.com -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
Re: Should we release an 0.5.1?
Hi Abe-san, For point releases, the usual standard is to use the same branch as the main release. So we would continue to use the 0.5-incubating branch, and just make a new release from it, and of course new tags. Thanks, Karl On Sat, May 12, 2012 at 5:35 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Yes I did. I will be able to work as release manager next week. Please create 0.5.1 branch. Regards, Shinichiro Abe On 2012/05/12, at 16:14, Karl Wright wrote: It looks like this is probably happening, so I've pulled up three tickets into the 0.5 release branch: CONNECTORS-453 CONNECTORS-467 CONNECTORS-471 I suppose we could even spin a release candidate now, even though we shouldn't probably vote on it until we've officially graduated. The release candidate should be 0.5.1, not 0.5.1-incubating. Abe-san, did you want to be release manager for this? Karl On Mon, May 7, 2012 at 7:00 AM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: If we succeed in graduating in May, then +1 from me. This problem does not only affects Tomcat, but also Resin, and probably other web containers as well. Erlend On 04.05.12 21.03, Karl Wright wrote: My view: It will be relatively easy to do this once we graduate, and too much of a pain before then. If we succeed in graduating in May, I'd give a +1. If not, then maybe we should just try to release the 0.6 version instead. Karl On Fri, May 4, 2012 at 1:01 PM, Piergiorgio Lucidi piergior...@apache.org wrote: I think that it is important to release a 0.5.1 version to enable compatibility for Tomcat 7.x. +1 for me for releasing a 0.5.1 version Piergiorgio 2012/5/1 Karl Wrightdaddy...@gmail.com We've had a number of people using Tomcat 7.x who have tripped over CONNECTORS-467. Does the community want to release a 0.5.1 version to fix this one issue? Or, alternatively, try to push 0.6 out the door early? Karl -- Piergiorgio Lucidi http://www.open4dev.com -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
Re: Should we release an 0.5.1?
Yes we do. Would you be willing to do that? Thanks! Karl On Sat, May 12, 2012 at 7:03 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Okay. Do we need to change release-version into 0.5.1 at build.xml in the branch? Shinichiro Abe On 2012/05/12, at 19:39, Karl Wright wrote: Hi Abe-san, For point releases, the usual standard is to use the same branch as the main release. So we would continue to use the 0.5-incubating branch, and just make a new release from it, and of course new tags. Thanks, Karl On Sat, May 12, 2012 at 5:35 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Yes I did. I will be able to work as release manager next week. Please create 0.5.1 branch. Regards, Shinichiro Abe On 2012/05/12, at 16:14, Karl Wright wrote: It looks like this is probably happening, so I've pulled up three tickets into the 0.5 release branch: CONNECTORS-453 CONNECTORS-467 CONNECTORS-471 I suppose we could even spin a release candidate now, even though we shouldn't probably vote on it until we've officially graduated. The release candidate should be 0.5.1, not 0.5.1-incubating. Abe-san, did you want to be release manager for this? Karl On Mon, May 7, 2012 at 7:00 AM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: If we succeed in graduating in May, then +1 from me. This problem does not only affects Tomcat, but also Resin, and probably other web containers as well. Erlend On 04.05.12 21.03, Karl Wright wrote: My view: It will be relatively easy to do this once we graduate, and too much of a pain before then. If we succeed in graduating in May, I'd give a +1. If not, then maybe we should just try to release the 0.6 version instead. Karl On Fri, May 4, 2012 at 1:01 PM, Piergiorgio Lucidi piergior...@apache.org wrote: I think that it is important to release a 0.5.1 version to enable compatibility for Tomcat 7.x. +1 for me for releasing a 0.5.1 version Piergiorgio 2012/5/1 Karl Wrightdaddy...@gmail.com We've had a number of people using Tomcat 7.x who have tripped over CONNECTORS-467. Does the community want to release a 0.5.1 version to fix this one issue? Or, alternatively, try to push 0.6 out the door early? Karl -- Piergiorgio Lucidi http://www.open4dev.com -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
[jira] [Commented] (CONNECTORS-470) SharePoint 2010 support
[
https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
dsQuery select=/list[@id='{D7E22603-5B7D-415D-B12A-4543957E8430}']/
{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] [Issue Comment Edited] (CONNECTORS-470) SharePoint 2010 support
[
https://issues.apache.org/jira/browse/CONNECTORS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
dsQuery select=/list[@id='{D7E22603-5B7D-415D-B12A-4543957E8430}']/
{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}
dsQuery select=/list[@id='{D7E22603-5B7D-415D-B12A-4543957E8430}']/
{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] [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-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-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-tabpanelfocusedCommentId=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] [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] [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] [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-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-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}
web-app
!-- Usual stuff here --
listener
listener-classcom.mycompany.MyClass/listener-class
/listener
/web-app
{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-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-tabpanelfocusedCommentId=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}
web-app
!-- Usual stuff here --
listener
listener-classcom.mycompany.MyClass/listener-class
/listener
/web-app
{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
Re: [DISCUSS] Graduation resolution for ManifoldCF
Seems reasonable; I'll revise the resolution accordingly and put it up for a vote over the next couple of hours. Thanks! Karl On Tue, May 1, 2012 at 5:16 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Apr 30, 2012 at 3:13 PM, Karl Wright daddy...@gmail.com wrote: Looks like we missed a step; we need a graduation resolution for the board to vote on. Here's my proposal, basically copied from Apache Chemistry's, but I have a question. Since no distinction is made between the PPMC members and committers in this resolution, and since many of the original committers/IPMC members have become inactive, and others have not yet been voted in as PPMC members, how should we deal with that? * Overall the resolution looks good, though note my comment on the scope below. * As discussed before, I don't think making a distinction between committers and (P)PMC members is useful for us. IMO such a setup only makes sense for umbrella projects like the Incubator and Lucene before it split out most of its subprojects. So my recommendation would be to make all (still active) committers also PMC members and stick with that policy going forward. * As for inactive people, you're already doing a good job asking them whether they still want to be involved. In case someone doesn't reply and hasn't shown up on the lists over the last year or so, it's fine to simply drop them from the resolution for lack of response. Also, do we need to vote on who the vice president will be? I believe we do... but maybe we can do this as part of the vote on the resolution itself? You're already doing all the stuff a VP should be doing, and more, so I hereby nominate you to be the VP, Apache ManifoldCF. We can have a vote if other nominations are made, or consider you selected by lazy consensus otherwise. WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software providing a framework for transferring content from source content repositories to target repositories or indexes, including a security model permitting target repositories to enforce source repository security, for distribution at no charge to the public; This is a pretty lengthy scope definition. Can we simplify it a bit? For example something like: ... open-source software for transferring content between repositories or search indexes. The details of how this is achieved (framework, security model, etc.) are IMHO best left outside the scope to allow more freedom down the line for the project to evolve. RESOLVED, that the Apache ManifoldCF Project be and hereby is responsible for the creation and maintenance of software providing a framework for transferring content from source content repositories to target repositories or indexes, including a security model permitting target repositories to enforce source repository security, for distribution at no charge to the public. This should also be updated as discussed above. PS. If you don't mind, I'd be happy to stay on board the new ManifoldCF PMC at least for some time to help out with the transition to TLP. BR, Jukka Zitting
[VOTE] Graduation resolution for ManifoldCF
Thanks, Jukka, I'd be honored to take on the role of VP in a ManifoldCF top-level project. Incorporating Jukka's invaluable advice, I've updated the proposed resolution, and am opening a vote on it. Please vote +1 if you agree that this is the resolution that should be presented, in total, including myself in the role of Vice President, or -1 if you see changes you would like to make (or if you'd like to nominate someone else and hold a formal vote on the VP role). == WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for transferring content between repositories or search indexes, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache ManifoldCF Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ManifoldCF Project be and hereby is responsible for the creation and maintenance of open-source software for transferring content between repositories or search indexes, for distribution at no charge to the public. RESOLVED, that the office of Vice President, ManifoldCF be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ManifoldCF Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ManifoldCF Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ManifoldCF Project: * Shinichiro Abe (shinich...@apache.org) * Erlend Garåsen(rid...@apache.org) * Piergiorgio Lucidi (piergior...@apache.org) * Hitoshi Ozawa (hoz...@apache.org) * Tommaso Teofili (tomm...@apache.org) * Simon Willnauer(sim...@apache.org) * Karl Wright (kwri...@apache.org) * Jukka Zitting (ju...@apache.org) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Karl Wright be appointed to the office of Vice President, ManifoldCF, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache ManifoldCF Project be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the ManifoldCF Project; and be it further RESOLVED, that the initial Apache ManifoldCF Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ManifoldCF podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator ManifoldCF podling encumbered upon the Apache Incubator PMC are hereafter discharged. == +1 from me. Thanks again for the vote of confidence! Karl On Tue, May 1, 2012 at 5:16 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Apr 30, 2012 at 3:13 PM, Karl Wright daddy...@gmail.com wrote: Looks like we missed a step; we need a graduation resolution for the board to vote on. Here's my proposal, basically copied from Apache Chemistry's, but I have a question. Since no distinction is made between the PPMC members and committers in this resolution, and since many of the original committers/IPMC members have become inactive, and others have not yet been voted in as PPMC members, how should we deal with that? * Overall the resolution looks good, though note my comment on the scope below. * As discussed before, I don't think making a distinction between committers and (P)PMC members is useful for us. IMO such a setup only makes sense for umbrella projects like the Incubator and Lucene before it split out most of its subprojects. So my recommendation would be to make all (still active) committers also PMC members and stick with that policy going forward. * As for inactive people, you're already doing a good job asking them whether they still want to be involved. In case someone doesn't reply and hasn't shown up on the lists over the last year or so, it's fine to simply drop them from the resolution for lack of response. Also, do we need to vote on who the vice president will be? I believe we do... but maybe we can do this as part
[DISCUSS] Graduation resolution for ManifoldCF
Looks like we missed a step; we need a graduation resolution for the board to vote on. Here's my proposal, basically copied from Apache Chemistry's, but I have a question. Since no distinction is made between the PPMC members and committers in this resolution, and since many of the original committers/IPMC members have become inactive, and others have not yet been voted in as PPMC members, how should we deal with that? Also, do we need to vote on who the vice president will be? I believe we do... but maybe we can do this as part of the vote on the resolution itself? Here's the proposed resolution: WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software providing a framework for transferring content from source content repositories to target repositories or indexes, including a security model permitting target repositories to enforce source repository security, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache ManifoldCF Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ManifoldCF Project be and hereby is responsible for the creation and maintenance of software providing a framework for transferring content from source content repositories to target repositories or indexes, including a security model permitting target repositories to enforce source repository security, for distribution at no charge to the public. RESOLVED, that the office of Vice President, ManifoldCF be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ManifoldCF Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ManifoldCF Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ManifoldCF Project: * Shinichiro Abe (shinich...@apache.org) * Erlend Garåsen(rid...@apache.org) * Grant Ingersoll(gsing...@apache.org) * Piergiorgio Lucidi (piergior...@apache.org) * Shalin Shekhar Mangar (sha...@apache.org) * Mark Miller (markrmil...@apache.org) * Robert Muir (rm...@apache.org) * Ryan McKinley (r...@apache.org) * Hitoshi Ozawa (hoz...@apache.org) * Sami Siren (si...@apache.org) * Tommaso Teofili (tomm...@apache.org) * Simon Willnauer(sim...@apache.org) * Karl Wright (kwri...@apache.org) * Jukka Zitting (ju...@apache.org) NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, ManifoldCF, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache ManifoldCF Project be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the ManifoldCF Project; and be it further RESOLVED, that the initial Apache ManifoldCF Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ManifoldCF podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator ManifoldCF podling encumbered upon the Apache Incubator PMC are hereafter discharged. Comments? Karl On Mon, Apr 30, 2012 at 6:34 AM, Karl Wright daddy...@gmail.com wrote: I've opened the vote in the general@i.a.o list. Karl On Fri, Apr 27, 2012 at 6:10 AM, Karl Wright daddy...@gmail.com wrote: Six binding +1's. No -1's or abstentions. 72 hours. Vote passes! Karl On Wed, Apr 25, 2012 at 3:55 PM, Alex Ott alex...@gmail.com wrote: +1, although I'm not developer... On Tue, Apr 24, 2012 at 12:08 PM, Karl Wright daddy...@gmail.com wrote: Please vote +1 if you think we should propose to the Incubator that we graduate as a top level project at this time. If this vote passes, I will open a [DISCUSS] thread in gene...@incubator.apache.org, and turn it into a [VOTE] thread if the discussion looks positive. +1(binding) from me
Re: [DISCUSS] Graduation resolution for ManifoldCF
Done, and thanks! Karl On Mon, Apr 30, 2012 at 11:36 AM, Sami Siren ssi...@gmail.com wrote: On Mon, Apr 30, 2012 at 4:13 PM, Karl Wright daddy...@gmail.com wrote: Since no distinction is made between the PPMC members and committers in this resolution, and since many of the original committers/IPMC members have become inactive, and others have not yet been voted in as PPMC members, how should we deal with that? Karl, you can remove my name from the proposal (total lack of activity). thanks, and congrats for the coming graduation! -- Sami Siren
[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-tabpanelfocusedCommentId=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 taglib-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 jsp-config 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
[RESULT][VOTE] Propose graduation of ManifoldCF from the Incubator as a Top Level Project
Six binding +1's. No -1's or abstentions. 72 hours. Vote passes! Karl On Wed, Apr 25, 2012 at 3:55 PM, Alex Ott alex...@gmail.com wrote: +1, although I'm not developer... On Tue, Apr 24, 2012 at 12:08 PM, Karl Wright daddy...@gmail.com wrote: Please vote +1 if you think we should propose to the Incubator that we graduate as a top level project at this time. If this vote passes, I will open a [DISCUSS] thread in gene...@incubator.apache.org, and turn it into a [VOTE] thread if the discussion looks positive. +1(binding) from me. Karl -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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 taglib-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 jsp-config 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
[VOTE] Propose graduation of ManifoldCF from the Incubator as a Top Level Project
Please vote +1 if you think we should propose to the Incubator that we graduate as a top level project at this time. If this vote passes, I will open a [DISCUSS] thread in gene...@incubator.apache.org, and turn it into a [VOTE] thread if the discussion looks positive. +1(binding) from me. Karl
[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
Re: Build fails with Maven while building MCF from trunk
Trunk is now built using different jars because we've gone to jdk 1.6. On trunk there is no -lib distribution you can download; you must build it: ant clean-core-deps make-core-deps Thanks, Karl On Tue, Apr 24, 2012 at 3:13 PM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: On 12.04.12 23.46, Karl Wright wrote: The build process has changed. The incubator required we remove all binaries. You will need to do one of the following: (a) Download the -lib package from the release candidate and follow the instructions I tried to place all the jars from the lib distribution into a lib folder in my working trunk version. I tried to follow the instructions in the README file. What exactly is the corresponding lib distribution if you work with trunk? The latest 0.5 release? Here's what I did: 1. Downloaded apache-manifoldcf-0.5-incubating-lib.tar.gz and unpacked it 2. Created a lib directory in the project root and copied all jars from the lib distribution into that directory 3. ran ant build (nothing really happens) 4. Tried ant make-deps followed by ant build. I guess there is one detail I have missed. Your suggestions work perfectly if I download the corresponding source package, but not with the latest version from trunk. Erlend (b) Make sure you have svn 1.7 installed and run ant make-core-deps It's not straight forward to upgrade SVN to version 1.7 on OS X. Fink is the most common tool for installing/upgrading SVN, but the current/stable version is 1.6.17-4: http://pdb.finkproject.org/pdb/package.php/svn If I _should_ use SVN 1.7, I can try to install it from MacPorts. Erlend -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
[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-tabpanelfocusedCommentId=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] [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-466) CMIS UI test fails
[
https://issues.apache.org/jira/browse/CONNECTORS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=foopassword=barthrottlecount=0description=connname=MyRepositoryConnectionisnewconnection=truebinding=atomserver=localhostclassname=org.apache.manifoldcf.crawler.connectors.cmis.CmisRepositoryConnectortabname=Namemaxconnections=10protocol=httppath=%2Fchemistry-opencmis-server-inmemory%2Fatomauthorityname=_none_type=connectionport=9090repositoryId=op=Continue'
and 0 files...
[junit] Traceback (most recent call last):
[junit] File test.py, line 102, in module
[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] [Commented] (CONNECTORS-466) CMIS UI test fails
[ https://issues.apache.org/jira/browse/CONNECTORS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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
Thoughts on graduation?
It may be a little too soon after the last (somewhat traumatic) release, but I'm thinking we've pretty well met the diversity requirement now for graduation. Should we open a graduation vote in the incubator at this time? Karl
Re: Thoughts on graduation?
Hi Tommaso, I didn't see anything in the checklist we hadn't done. Indeed, for some things (like the name) we've done it more than once. Do you think we're missing anything? Do you think the incubator page is sufficiently up to date as well? Looked reasonable to me... Are we agreed that ManifoldCF would graduate as a TLP at this time? The Lucene PMC dropped us some two years ago so it would be appropriate, I think. Karl On Mon, Apr 23, 2012 at 8:05 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: Hi Karl, I think times are mature for talking about graduation, it may be helpful to explicitly get through the graduation requirements [1][2] and open a [DISCUSSION] thread before start voting to check everyone is happy with it and also, for example, to choose the right target (TLP or subproject). However I'm confident we can graduate soon. Tommaso [1] : http://incubator.apache.org/guides/graduation.html [2] : http://incubator.apache.org/guides/graduation.html#checklist 2012/4/23 Karl Wright daddy...@gmail.com It may be a little too soon after the last (somewhat traumatic) release, but I'm thinking we've pretty well met the diversity requirement now for graduation. Should we open a graduation vote in the incubator at this time? Karl
[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] [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-tabpanelfocusedCommentId=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] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258111#comment-13258111
]
Karl Wright commented on CONNECTORS-347:
I was able to catch it again and do a database postmortem. Here's how the
involved tables appear:
{code}
mysql select dochash,docid from jobqueue;
+--++
| dochash | docid
|
+--++
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test1.txt |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test2.txt |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir |
+--++
4 rows in set (0.00 sec)
mysql select parentidhash,childidhash from intrinsiclink;
+--+--+
| parentidhash | childidhash |
+--+--+
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
+--+--+
6 rows in set (0.00 sec)
mysql select parentidhash,distance from hopcount;
+--+--+
| parentidhash | distance |
+--+--+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |0 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |1 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |1 |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |1 |
+--+--+
4 rows in set (0.00 sec)
{code}
While the jobqueue and hopcount tables are self-consistent, the intrinsiclink
table is pretty broken here. There are rows that should not even be there.
I'll need to compare against a run on postgresql to establish whether this is a
bug in the code we've just missed, or is particular to mysql somehow.
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 0.6
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258202#comment-13258202
]
Karl Wright commented on CONNECTORS-347:
Here's a postmortem for a run that succeeded:
{code}
mysql select parentidhash,distance from hopcount;
+--+--+
| parentidhash | distance |
+--+--+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |0 |
| 718564BC3D0C94B0F88B36B7FA2FC915F665A5E2 |3 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |2 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |2 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |1 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |1 |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |1 |
+--+--+
7 rows in set (0.00 sec)
mysql select parentidhash,childidhash from intrinsiclink;
+--+--+
| parentidhash | childidhash |
+--+--+
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | |
| 718564BC3D0C94B0F88B36B7FA2FC915F665A5E2 |
1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
+--+--+
7 rows in set (0.00 sec)
mysql select dochash,docid from jobqueue;
+--++
| dochash | docid
|
+--++
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir\test3.txt |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir\seconddir |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test1.txt |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test2.txt |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir |
+--++
6 rows in set (0.00 sec)
{code}
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 0.6
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60
[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-tabpanelfocusedCommentId=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 |2
4ED8AFCC917B604C1EE4C83458DB9B7265967F40
Re: Upgrade ManifoldCF to JDK 1.6
For what it is worth, there were a number of things broken in the maven build for the 0.5-incubating version we just shipped. Karl On Thu, Apr 19, 2012 at 2:33 AM, Piergiorgio Lucidi piergior...@apache.org wrote: Ok, I should try today! I'll let you know. Thank you. Piergiorgio Il giorno 19 aprile 2012 04:27, Karl Wright daddy...@gmail.com ha scritto: I've committed the changes to upgrade ManifoldCF to require JDK 1.6. I've also made sure that the Maven build is consistent with the ant build in this regard. Please let me know if you run into any problems. Karl -- Piergiorgio Lucidi http://www.open4dev.com
[jira] [Commented] (CONNECTORS-193) Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods
[ https://issues.apache.org/jira/browse/CONNECTORS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257519#comment-13257519 ] Karl Wright commented on CONNECTORS-193: No, the SelectTab JS method is provided by the framework. I am talking about Javascript methods that are local to specific output connectors. Not all output connectors adhere to the standard convention for naming of tabs, form elements, and javascript methods - Key: CONNECTORS-193 URL: https://issues.apache.org/jira/browse/CONNECTORS-193 Project: ManifoldCF Issue Type: Task Components: GTS connector, Lucene/SOLR connector Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3 Reporter: Karl Wright Assignee: Erlend Garåsen Fix For: ManifoldCF next The convention for form elements and javascript methods is that all element names and methods must begin with lowercase oc. The convention for output specification tabs is that the tab name should contain the name of the target, e.g. GTS Parameters or Solr Metadata Mapping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-347) MySQL HopCount test sometimes fails
[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257899#comment-13257899
]
Karl Wright commented on CONNECTORS-347:
Just saw it again; clearly it is real.
MySQL HopCount test sometimes fails
---
Key: CONNECTORS-347
URL: https://issues.apache.org/jira/browse/CONNECTORS-347
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 0.5
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF next
The HopcountMySQLIT test sometimes fails complaining that it is expecting to
see 6 documents but only sees 4.
{code}
[junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
number of documents processed - expected 6, saw 4
[junit] at
org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
{code}
This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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
Upgrade ManifoldCF to JDK 1.6
I've committed the changes to upgrade ManifoldCF to require JDK 1.6. I've also made sure that the Maven build is consistent with the ant build in this regard. Please let me know if you run into any problems. Karl
[jira] [Commented] (CONNECTORS-345) Jetty Configuration Support
[ https://issues.apache.org/jira/browse/CONNECTORS-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257172#comment-13257172 ] Karl Wright commented on CONNECTORS-345: As part of the upgrade to JDK 1.6, I took the liberty of upgrading the jetty 7. That should make it easier to determine what the next steps should be in regards to this ticket. Jetty Configuration Support --- Key: CONNECTORS-345 URL: https://issues.apache.org/jira/browse/CONNECTORS-345 Project: ManifoldCF Issue Type: Improvement Components: Framework core Affects Versions: ManifoldCF 0.4 Environment: Jetty Configuration Reporter: Michael J. Kelleher Assignee: Karl Wright Fix For: ManifoldCF next Can the single process example be extended to support Jetty configuration? 1) jetty.xml 2) webdefault.xml 3) OPTIONS= along with their corresponding XML config files, most importantly the JMX option, Server,ajp,setuid would be nice to have -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-435) Replace incorrect Messages.getString() calls in the main UI with correct ones.
[
https://issues.apache.org/jira/browse/CONNECTORS-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255511#comment-13255511
]
Karl Wright commented on CONNECTORS-435:
Looks generally good, although I didn't check every line. However, I did see
one weird thing:
{code}
-
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=+Integer.toString(kmanager.getContents().length)+
+ Messages.getString(locale,DCTM.certificate) + /nobrbr/\n
+
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=+Integer.toString(kmanager.getContents().length)+
+ Messages.getAttributeString(locale,DCTM.certificate) + /nobrbr/\n
{code}
The issue here is that the and for the message are not tags. They should
in fact be lt; and gt;, so that the line should originally read:
{code}
nobr+org.apache.manifoldcf.ui.util.Encoder.bodyEscape(param)+=lt;+Integer.toString(kmanager.getContents().length)+
+ Messages.getString(locale,DCTM.certificate) + gt;/nobrbr/\n
{code}
Once that is done it is clear that you need Messages.getBodyString() here, not
Messages.getAttributeString().
Replace incorrect Messages.getString() calls in the main UI with correct ones.
--
Key: CONNECTORS-435
URL: https://issues.apache.org/jira/browse/CONNECTORS-435
Project: ManifoldCF
Issue Type: Task
Components: Framework core
Affects Versions: ManifoldCF 0.4
Reporter: Erlend Garåsen
Assignee: Erlend Garåsen
Fix For: ManifoldCF 0.6
Attachments: CONNECTORS-435.patch
The Messages.getString() calls in the main UI are incorrect much of the time.
They should usually be replaced by one of:
{code}
Messages.getBodyJavascriptString()
Messages.getAttributeJavascriptString()
Messages.getBodyString()
Messages.getAttributeString()
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-458) Incubator site has moved; adjust crawler-ui documentation reference accordingly
[ https://issues.apache.org/jira/browse/CONNECTORS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254579#comment-13254579 ] Karl Wright commented on CONNECTORS-458: It turns out that the URLs haven't changed; just the location from which they are mirrored. So this can be closed. Incubator site has moved; adjust crawler-ui documentation reference accordingly --- Key: CONNECTORS-458 URL: https://issues.apache.org/jira/browse/CONNECTORS-458 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Fix For: ManifoldCF 0.6 The ManifoldCF site has moved from http://incubator.apache.org/connectors to http://incubator.apache.org/content/connectors. The crawler UI references the on-line documentation and should be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONNECTORS-458) Incubator site has moved; adjust crawler-ui documentation reference accordingly
[ https://issues.apache.org/jira/browse/CONNECTORS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-458. Resolution: Not A Problem Incubator site has moved; adjust crawler-ui documentation reference accordingly --- Key: CONNECTORS-458 URL: https://issues.apache.org/jira/browse/CONNECTORS-458 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6 Reporter: Karl Wright Fix For: ManifoldCF 0.6 The ManifoldCF site has moved from http://incubator.apache.org/connectors to http://incubator.apache.org/content/connectors. The crawler UI references the on-line documentation and should be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONNECTORS-438) Only the current release should be referred to by the documentation on the mirror - the rest should point to the archive
[ https://issues.apache.org/jira/browse/CONNECTORS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-438. Resolution: Fixed Resolved as part of another commit Only the current release should be referred to by the documentation on the mirror - the rest should point to the archive Key: CONNECTORS-438 URL: https://issues.apache.org/jira/browse/CONNECTORS-438 Project: ManifoldCF Issue Type: Task Components: Documentation Affects Versions: ManifoldCF 0.6 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 0.6 The download page should refer to only the current release via the mirror. All older releases should refer to http://archive.apache.org/dist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254625#comment-13254625
]
Karl Wright commented on CONNECTORS-460:
r1326543
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[RESULT][VOTE] Upgrade ManifoldCF to jdk 1.6 prior to next release
Looks like there's no problem with going ahead with this. The ticket is CONNECTORS-459, and I've created a corresponding branch to work on the ticket. Karl On Wed, Apr 11, 2012 at 3:29 PM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: +1 Erlend On 11.04.12 02.39, Karl Wright wrote: Folks, When doing the dependency rework, it became clear that many of our binary dependencies are stuck without fixes or upgrades because we are still using jdk 1.5. I'd like to get a sense from the community whether everyone thinks we should abandon support for jdk1.5 in our next release. The pros of such a move include allowing us to upgrade to jetty 7 (which brings in a number of bug fixes), tomcat 7 components, and off-the-shelf hsqldb builds. I cannot at this time identify any obvious cons. Please let me know your opinion. +1 to upgrade, from me. Thanks, Karl -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
Re: [ANNOUNCE] ManifoldCF 0.5-incubating has been released!
A big congratulations to Abe-san for pulling all of this together! It was a difficult release. Karl On Mon, Apr 16, 2012 at 11:15 AM, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Thanks to all who put time and effort into this release! The site and download mirrors should update in a day or so, but if you cannot wait, you can download the release in the interim from http://www.apache.org/dist/incubator/manifoldcf. Thank you, Shinichiro Abe - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Missing pom.xml files for some (proprietary?) connectors
The reason that Maven cannot build proprietary connectors is because the dependencies are unavailable via Maven. For instance, you cannot build the LiveLink connector without a lapi.jar, and you can only get that by purchasing a license from OpenText. Karl On Sun, Apr 15, 2012 at 2:29 PM, Erlend Garåsen e.f.gara...@usit.uio.no wrote: Is the following the reason why there are no pom.xml files for some connectors, for instance Documentum? The biggest limitation of the current Maven build is that it does not support any of the proprietary connectors ... Erlend -- Erlend Garåsen Center for Information Technology Services University of Oslo P.O. Box 1086 Blindern, N-0317 OSLO, Norway Ph: (+47) 22840193, Fax: (+47) 22852970, Mobile: (+47) 91380968, VIP: 31050
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253235#comment-13253235
]
Karl Wright commented on CONNECTORS-460:
The branch
https://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-460 contains
a revised active directory authority connector (plus one other fix that's
needed to make it work). Colin, if you can check out and build this branch,
I'd love to hear if it works for you.
The doc is not done yet, but the way it's supposed to work is that you create a
sequence of rules. Each rule has a suffix; if that matches the end of the
domain attached to the username (everything case insensitive), then the
corresponding domain controller will be the one that is used to resolve that
user's SIDs.
Please let me know what you find.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253327#comment-13253327
]
Karl Wright commented on CONNECTORS-460:
No idea what is wrong offhand. But we can debug.
Some questions:
(1) When you set up a connection with the old Active Directory connector using
the same (identical) parameters, do you get a successful connection?
(2) Please look carefully at the connection on the view page. Did all your
settings seem to get saved correctly? (other than the passwords, which you
can't see obviously).
(3) Do you see any exceptions in manifoldcf.log? They may be helpful in
figuring out what is going wrong.
Meanwhile I'll eyeball the code and see if I can find something obvious...
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253336#comment-13253336
]
Karl Wright commented on CONNECTORS-460:
I did find a problem; passwords were not being properly de-encrypted. Can you
synch up and try again?
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253338#comment-13253338
]
Karl Wright commented on CONNECTORS-460:
I hope this works for you now; if not, I'm going to be unavailable until Sunday
afternoon, at which point I can look at this again (or, hopefully, just update
the documentation and commit it to trunk!)
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] [Commented] (CONNECTORS-460) ManifoldCF authority
service doesn't handle multi-domain environments
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Looks simple to fix next time I have internet service.
Karl
Sent from my Windows Phone
From: Colin Anderson (Commented) (JIRA)
Sent: 4/13/2012 10:13 AM
To: connectors-dev@incubator.apache.org
Subject: [jira] [Commented] (CONNECTORS-460) ManifoldCF authority
service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253396#comment-13253396
]
Colin Anderson commented on CONNECTORS-460:
---
Hi Karl,
I can create the authority with multiple domains now, so that side seems OK.
When crawling, I get {{allow_token_document}} values all prefixed with
the name of new, single authority.
But the ManifoldCF authority service doesn't work - if I call:
{{http://localhost:8345/mcf-authority-service/UserACLs?username=123...@ap.enterdir.com}}
I get:
{{UNREACHABLEAUTHORITY:Active+Directory}}
{{TOKEN:AD:DEAD_AUTHORITY}}
And in the log I see:
{quote}
WARN 2012-04-13 15:06:07,253 (Auth check thread 0) - Authority
connection error: null
java.lang.NullPointerException
at
org.apache.manifoldcf.authorities.authorities.activedirectory.ActiveDirectoryAuthority$AuthorizationResponseDescription.getCriticalSectionName(ActiveDirectoryAuthority.java:1024)
at
org.apache.manifoldcf.core.cachemanager.CacheManager.enterCreateSection(CacheManager.java:343)
at
org.apache.manifoldcf.authorities.authorities.activedirectory.ActiveDirectoryAuthority.getAuthorizationResponse(ActiveDirectoryAuthority.java:260)
at
org.apache.manifoldcf.authorities.system.AuthCheckThread.run(AuthCheckThread.java:92)
WARN 2012-04-13 15:06:07,253 (13242994@qtp-32105264-0) - Authority
'Active Directory' is unreachable for user '123...@ap.enterdir.com'
{quote}
I get the same if I try with a user in the {{external.com}} domain.
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] [Commented] (CONNECTORS-460) ManifoldCF authority service doesn't handle multi-domain environments
[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253858#comment-13253858
]
Karl Wright commented on CONNECTORS-460:
I fixed the problem with the cache key computation; it was a simple typo. If
you synch up and try again, I feel pretty good about it working completely this
time. ;-)
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Affects Versions: ManifoldCF 0.1, ManifoldCF 0.2, ManifoldCF 0.3,
ManifoldCF 0.4, ManifoldCF 0.5, ManifoldCF 0.6
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Assignee: Karl Wright
Labels: active-directory, authorization, security
Fix For: ManifoldCF 0.6
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
