Vote +1 if you think the Apache ManifoldCF SharePoint 2010 plugin 0.1
RC0 is ready for release.

The release artifact can be found at:
http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1
.

There is also a release tag at:
https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC0

Karl

Hi Karl,

With a document library that 7,888 items, I setup a crawl with mcf-trunk. Sometimes I get this exception : Error: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500

If i don't get exception only 1000 docs are indexed.

ERROR 2012-09-06 19:55:13,587 (Worker thread '30') - Exception tossed: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500
org.apache.manifoldcf.core.interfaces.ManifoldCFException: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500
at org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:585)
Caused by: org.apache.manifoldcf.core.interfaces.ManifoldCFException: Ingestion HTTP error code 500
at org.apache.manifoldcf.agents.output.solr.HttpPoster$IngestThread.run(HttpPoster.java:1386)

Ahmet
--- On Wed, 9/5/12, Karl Wright <[EMAIL PROTECTED]> wrote:

> From: Karl Wright <[EMAIL PROTECTED]>
> Subject: [VOTE] Release Apache ManifoldCF SharePoint 2010 plugin 0.1 RC0
> To: "dev" <[EMAIL PROTECTED]>
> Date: Wednesday, September 5, 2012, 11:52 PM
> Vote +1 if you think the Apache
> ManifoldCF SharePoint 2010 plugin 0.1
> RC0 is ready for release.
>
> The release artifact can be found at:
> http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1
> .
>
> There is also a release tag at:
> https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC0
>
> Karl
>

It looks like two problems here.  First, it looks like Solr is
throwing a 500 error for at least one of the documents in your set.

However, the fact that you only get 1000 documents indexed also shows
that the code is still broken in some way.  I will check into whether
this looks like a problem in the connector or in the plugin.

Karl

On Thu, Sep 6, 2012 at 1:06 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
> Hi Karl,
>
> With a document library that 7,888 items, I setup a crawl with mcf-trunk. Sometimes I get this exception : Error: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500
>
> If i don't get exception only 1000 docs are indexed.
>
> ERROR 2012-09-06 19:55:13,587 (Worker thread '30') - Exception tossed: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500
> org.apache.manifoldcf.core.interfaces.ManifoldCFException: Repeated service interruptions - failure processing document: Ingestion HTTP error code 500
>         at org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:585)
> Caused by: org.apache.manifoldcf.core.interfaces.ManifoldCFException: Ingestion HTTP error code 500
>         at org.apache.manifoldcf.agents.output.solr.HttpPoster$IngestThread.run(HttpPoster.java:1386)
>
> Ahmet
> --- On Wed, 9/5/12, Karl Wright <[EMAIL PROTECTED]> wrote:
>
>> From: Karl Wright <[EMAIL PROTECTED]>
>> Subject: [VOTE] Release Apache ManifoldCF SharePoint 2010 plugin 0.1 RC0
>> To: "dev" <[EMAIL PROTECTED]>
>> Date: Wednesday, September 5, 2012, 11:52 PM
>> Vote +1 if you think the Apache
>> ManifoldCF SharePoint 2010 plugin 0.1
>> RC0 is ready for release.
>>
>> The release artifact can be found at:
>> http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1
>> .
>>
>> There is also a release tag at:
>> https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC0
>>
>> Karl
>>

Hi,

On Wed, Sep 5, 2012 at 7:33 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Still need 2 votes for this...

+1 from me

BR,

Jukka Zitting

+1 from me as well.
Karl

On Fri, Sep 7, 2012 at 1:34 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, Sep 5, 2012 at 7:33 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
>> Still need 2 votes for this...
>
> +1 from me
>
> BR,
>
> Jukka Zitting

Please vote +1 if you think the SharePoint 2010 plugin is ready for release.

Tag in the usual place
(https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC1).
 Artifact at http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1.

Fixed: Pagination handling

Thanks,
Karl

Piergiorgio and I got things working on his box, so +1 from me.

On Sun, Sep 9, 2012 at 12:52 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Please vote +1 if you think the SharePoint 2010 plugin is ready for release.
>
> Tag in the usual place
> (https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC1).
>  Artifact at http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1.
>
> Fixed: Pagination handling
>
> Thanks,
> Karl

We have just finishing crawling my SharePoint 2010 instance correctly :)

+1 from me.

Piergiorgio

2012/9/10 Karl Wright <[EMAIL PROTECTED]>

> Piergiorgio and I got things working on his box, so +1 from me.
>
> On Sun, Sep 9, 2012 at 12:52 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> > Please vote +1 if you think the SharePoint 2010 plugin is ready for
> release.
> >
> > Tag in the usual place
> > (
> https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC1
> ).
> >  Artifact at
> http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1
> .
> >
> > Fixed: Pagination handling
> >
> > Thanks,
> > Karl
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

Only one more vote needed!
Karl

On Mon, Sep 10, 2012 at 2:16 PM, Piergiorgio Lucidi
<[EMAIL PROTECTED]> wrote:
> We have just finishing crawling my SharePoint 2010 instance correctly :)
>
> +1 from me.
>
> Piergiorgio
>
> 2012/9/10 Karl Wright <[EMAIL PROTECTED]>
>
>> Piergiorgio and I got things working on his box, so +1 from me.
>>
>> On Sun, Sep 9, 2012 at 12:52 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
>> > Please vote +1 if you think the SharePoint 2010 plugin is ready for
>> release.
>> >
>> > Tag in the usual place
>> > (
>> https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC1
>> ).
>> >  Artifact at
>> http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1
>> .
>> >
>> > Fixed: Pagination handling
>> >
>> > Thanks,
>> > Karl
>>
>> --
>> Piergiorgio Lucidi
>> http://www.open4dev.com
>>
>>

Hello,

I was able to index:

1) Document Library that contains 7888 text documents. (where List View Threshold is 5000)
2) Document Library that contains 91 folder documents(ppt, doc, etc).
3) SharePoint List that has 798 items.
4) Document Library that contains 127 aspx files.

Here is my +1 for this vote.

Ahmet

--- On Mon, 9/10/12, Karl Wright <[EMAIL PROTECTED]> wrote:

> From: Karl Wright <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] Release Apache ManifoldCF Sharepoint 2010 plugin 0.1, RC1
> To: "dev" <[EMAIL PROTECTED]>
> Date: Monday, September 10, 2012, 9:14 PM
> Piergiorgio and I got things working
> on his box, so +1 from me.
>
> On Sun, Sep 9, 2012 at 12:52 PM, Karl Wright <[EMAIL PROTECTED]>
> wrote:
> > Please vote +1 if you think the SharePoint 2010 plugin
> is ready for release.
> >
> > Tag in the usual place
> > (https://svn.apache.org/repos/asf/manifoldcf/integration/sharepoint-2010/tags/release-0.1-RC1).
> >  Artifact at http://people.apache.org/~kwright/apache-manifoldcf-sharepoint-2010-plugin-0.1.
> >
> > Fixed: Pagination handling
> >
> > Thanks,
> > Karl
>

Please vote +1 to release ManifoldCF 1.0, RC0.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC0

Karl

I have deployed this version on a development server running Resin. The
only thing I have experienced so far is that I cannot delete any
connections.

Here's the following error when I try to delete the Solr Output connection:
Can't delete output connection 'Solr': existing entities refer to it

I have no authority connections, but I do have two repository
connections. When I try to delete my file system connection, I get the
following error:
Can't delete repository connection 'file system': existing jobs refer to it

But I *have* deleted my jobs! When I check the job statuses, it is
"cleaning up". Start time and end time says "not started" / "never run".

My connections were created on a previous version of MCF. The settings
were imported by using the ImportConfiguration tool.

Otherwise, everything seems to work as expected. I have tested:
- Deployment on Resin 4 on Linux
- ant test on OS X.
- My new file encryption function.

I'll wait with my vote until the above behaviour is explained.

Erlend
On 21.09.12 02.46, Karl Wright wrote:
> Please vote +1 to release ManifoldCF 1.0, RC0.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC0
>
> 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

When a job is in the process of being deleted, it will display as
"cleaning up".  The document count will go to zero and then the job
will be removed.

If you shut down the agents process, then of course none of this
happens.  The document count stays the same and the job does not go
away, and the status page says "cleaning up" indefinitely.

If you think the agents process is running, and yet you cannot delete
a job, you should see stuff in the manifoldcf log that would indicate
what the trouble likely is.

Karl

On Fri, Sep 21, 2012 at 7:21 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> I have deployed this version on a development server running Resin. The only
> thing I have experienced so far is that I cannot delete any connections.
>
> Here's the following error when I try to delete the Solr Output connection:
> Can't delete output connection 'Solr': existing entities refer to it
>
> I have no authority connections, but I do have two repository connections.
> When I try to delete my file system connection, I get the following error:
> Can't delete repository connection 'file system': existing jobs refer to it
>
> But I *have* deleted my jobs! When I check the job statuses, it is "cleaning
> up". Start time and end time says "not started" / "never run".
>
> My connections were created on a previous version of MCF. The settings were
> imported by using the ImportConfiguration tool.
>
> Otherwise, everything seems to work as expected. I have tested:
> - Deployment on Resin 4 on Linux
> - ant test on OS X.
> - My new file encryption function.
>
> I'll wait with my vote until the above behaviour is explained.
>
> Erlend
>
>
>
> On 21.09.12 02.46, Karl Wright wrote:
>>
>> Please vote +1 to release ManifoldCF 1.0, RC0.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC0
>>
>> 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

On 21.09.12 14.07, Karl Wright wrote:

> If you think the agents process is running, and yet you cannot delete
> a job, you should see stuff in the manifoldcf log that would indicate
> what the trouble likely is.

solr-test02 mcf-1 $ /www/var/data/mcf/mcf-1/agentctl start
Error: MCF Agent seems to be running already with PID 26310

You're right. It has some problems with several documents:
  WARN 2012-08-10 14:25:10,421 (Worker thread '4') - Pre-ingest service
interruption reported for job 1335434066944 connection 'web_crawler':
Http response temporary error on
'http://www.apollon.uio.no/vis/art/1998/3/intervju': 503

So I will ignore this at the moment and try to test a little bit more
with other parts of MCF.

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

A temporary error should not block a (non running) job from getting
cleaned up.  The job can't be deleted until it is stopped, and no
outstanding documents are being worked on.

How many documents are still listed for the job in the UI?

Karl

On Fri, Sep 21, 2012 at 8:36 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
> On 21.09.12 14.07, Karl Wright wrote:
>
>> If you think the agents process is running, and yet you cannot delete
>> a job, you should see stuff in the manifoldcf log that would indicate
>> what the trouble likely is.
>
>
> solr-test02 mcf-1 $ /www/var/data/mcf/mcf-1/agentctl start
> Error: MCF Agent seems to be running already with PID 26310
>
> You're right. It has some problems with several documents:
>  WARN 2012-08-10 14:25:10,421 (Worker thread '4') - Pre-ingest service
> interruption reported for job 1335434066944 connection 'web_crawler': Http
> response temporary error on
> 'http://www.apollon.uio.no/vis/art/1998/3/intervju': 503
>
> So I will ignore this at the moment and try to test a little bit more with
> other parts of MCF.
>
> 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

On 21.09.12 14.47, Karl Wright wrote:
> A temporary error should not block a (non running) job from getting
> cleaned up.  The job can't be deleted until it is stopped, and no
> outstanding documents are being worked on.
>
> How many documents are still listed for the job in the UI?

Documents: 0
Active: 0
Proceed: 0

Nothing in the simple history, but I get a 500 Server Exceptions if I
try to read the history of the file connector (due to a NPE) - stack
trace further down in this post.

I can try to unregister all connectors and empty the database and try again.

[2012-09-21 14:57:10.220] {resin-port-127.0.0.1:6945-143}
java.lang.NullPointerException
                                                           at
_jsp._simplereport__jsp._jspService(_simplereport__jsp.java:367)
                                                           at
_jsp._simplereport__jsp._jspService(_simplereport__jsp.java:36)
                                                           at
com.caucho.jsp.JavaPage.service(JavaPage.java:64)
                                                           at
com.caucho.jsp.Page.pageservice(Page.java:542)
                                                           at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
                                                           at
com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:126)
                                                           at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:289)
                                                           at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:298)
                                                           at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:116)
                                                           at
com.caucho.jsp.PageContextImpl.forward(PageContextImpl.java:1149)
                                                           at
_jsp._execute__jsp._jspService(_execute__jsp.java:1072)
                                                           at
_jsp._execute__jsp._jspService(_execute__jsp.java:36)
                                                           at
com.caucho.jsp.JavaPage.service(JavaPage.java:64)
                                                           at
com.caucho.jsp.Page.pageservice(Page.java:542)
                                                           at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
                                                           at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
                                                           at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:289)
                                                           at
com.caucho.server.hmux.HmuxRequest.handleInvocation(HmuxRequest.java:468)
                                                           at
com.caucho.server.hmux.HmuxRequest.handleRequestImpl(HmuxRequest.java:369)
                                                           at
com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:336)
                                                           at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:1301)
                                                           at
com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:1257)
                                                           at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:1241)
                                                           at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:1149)
                                                           at
com.caucho.network.listen.TcpSocketLink.handleAcceptTaskImpl(TcpSocketLink.java:950)
                                                           at
com.caucho.network.listen.TcpSocketLink.handleAcceptTask(TcpSocketLink.java:902)
                                                           at
com.caucho.network.listen.ConnectionTask.runThread(ConnectionTask.java:114)
                                                           at
com.caucho.network.listen.ConnectionTask.run(ConnectionTask.java:93)
                                                           at
com.caucho.network.listen.SocketLinkThreadLauncher.handleTasks(SocketLinkThreadLauncher.java:169)
                                                           at
com.caucho.network.listen.TcpSocketResumeThread.run(TcpSocketResumeThread.java:62)
                                                           at
com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)
                                                           at
com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)

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

Hmm, that's not good.

Can you open a ticket for this NPE, and also please attach the .java
file it is referring to: _simplereport__jsp.java?  It should be found
in resin's workarea somewhere.

As for the job not being deleted, can you supply further details of
your setup?  Specifically, properties.xml (so I can see what synch
settings you have), and what database, etc.

If there is nothing in the log, I'd shut down everything, execute the
lock-clean procedure, and start everything back up, and see if that
fixed the issue.

Karl
On Fri, Sep 21, 2012 at 9:01 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
> On 21.09.12 14.47, Karl Wright wrote:
>>
>> A temporary error should not block a (non running) job from getting
>> cleaned up.  The job can't be deleted until it is stopped, and no
>> outstanding documents are being worked on.
>>
>> How many documents are still listed for the job in the UI?
>
>
> Documents: 0
> Active: 0
> Proceed: 0
>
> Nothing in the simple history, but I get a 500 Server Exceptions if I try to
> read the history of the file connector (due to a NPE) - stack trace further
> down in this post.
>
> I can try to unregister all connectors and empty the database and try again.
>
> [2012-09-21 14:57:10.220] {resin-port-127.0.0.1:6945-143}
> java.lang.NullPointerException
>                                                                 at
> _jsp._simplereport__jsp._jspService(_simplereport__jsp.java:367)
>                                                                 at
> _jsp._simplereport__jsp._jspService(_simplereport__jsp.java:36)
>                                                                 at
> com.caucho.jsp.JavaPage.service(JavaPage.java:64)
>                                                                 at
> com.caucho.jsp.Page.pageservice(Page.java:542)
>                                                                 at
> com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
>                                                                 at
> com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:126)
>                                                                 at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:289)
>                                                                 at
> com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:298)
>                                                                 at
> com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:116)
>                                                                 at
> com.caucho.jsp.PageContextImpl.forward(PageContextImpl.java:1149)
>                                                                 at
> _jsp._execute__jsp._jspService(_execute__jsp.java:1072)
>                                                                 at
> _jsp._execute__jsp._jspService(_execute__jsp.java:36)
>                                                                 at
> com.caucho.jsp.JavaPage.service(JavaPage.java:64)
>                                                                 at
> com.caucho.jsp.Page.pageservice(Page.java:542)
>                                                                 at
> com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
>                                                                 at
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
>                                                                 at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:289)
>                                                                 at
> com.caucho.server.hmux.HmuxRequest.handleInvocation(HmuxRequest.java:468)
>                                                                 at
> com.caucho.server.hmux.HmuxRequest.handleRequestImpl(HmuxRequest.java:369)
>                                                                 at

According to my bash history, I did a LockClean prior to the upgrade:
solr-test02 mcf-1 $ history | grep LockClean
   154  $MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.core.LockClean

I will create a ticket. Let's hope this is a local problem on my server
and not a bug, but I think it's best to investigate it to be sure.

I will try to provide as much information as possible in the ticket.

Erlend

On 21.09.12 15.08, Karl Wright wrote:
> Hmm, that's not good.
>
> Can you open a ticket for this NPE, and also please attach the .java
> file it is referring to: _simplereport__jsp.java?  It should be found
> in resin's workarea somewhere.
>
> As for the job not being deleted, can you supply further details of
> your setup?  Specifically, properties.xml (so I can see what synch
> settings you have), and what database, etc.
>
> If there is nothing in the log, I'd shut down everything, execute the
> lock-clean procedure, and start everything back up, and see if that
> fixed the issue.
>
> Karl
>
>
> On Fri, Sep 21, 2012 at 9:01 AM, Erlend Gar�sen <[EMAIL PROTECTED]> wrote:
>> On 21.09.12 14.47, Karl Wright wrote:
>>>
>>> A temporary error should not block a (non running) job from getting
>>> cleaned up.  The job can't be deleted until it is stopped, and no
>>> outstanding documents are being worked on.
>>>
>>> How many documents are still listed for the job in the UI?
>>
>>
>> Documents: 0
>> Active: 0
>> Proceed: 0
>>
>> Nothing in the simple history, but I get a 500 Server Exceptions if I try to
>> read the history of the file connector (due to a NPE) - stack trace further
>> down in this post.
>>
>> I can try to unregister all connectors and empty the database and try again.
>>
>> [2012-09-21 14:57:10.220] {resin-port-127.0.0.1:6945-143}
>> java.lang.NullPointerException
>>                                                                  at
>> _jsp._simplereport__jsp._jspService(_simplereport__jsp.java:367)
>>                                                                  at
>> _jsp._simplereport__jsp._jspService(_simplereport__jsp.java:36)
>>                                                                  at
>> com.caucho.jsp.JavaPage.service(JavaPage.java:64)
>>                                                                  at
>> com.caucho.jsp.Page.pageservice(Page.java:542)
>>                                                                  at
>> com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
>>                                                                  at
>> com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:126)
>>                                                                  at
>> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:289)
>>                                                                  at
>> com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:298)
>>                                                                  at
>> com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:116)
>>                                                                  at
>> com.caucho.jsp.PageContextImpl.forward(PageContextImpl.java:1149)
>>                                                                  at
>> _jsp._execute__jsp._jspService(_execute__jsp.java:1072)
>>                                                                  at
>> _jsp._execute__jsp._jspService(_execute__jsp.java:36)
>>                                                                  at
>> com.caucho.jsp.JavaPage.service(JavaPage.java:64)
>>                                                                  at
>> com.caucho.jsp.Page.pageservice(Page.java:542)
>>                                                                  at
>> com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
>>                                                                  at
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

- Tried to use Alfresco and CMIS with success
- checked signatures

+1 from me

Piergiorgio

2012/9/21 Karl Wright <[EMAIL PROTECTED]>

> Please vote +1 to release ManifoldCF 1.0, RC0.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC0
>
> Karl
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

I have created a ticket and attached _simplereport__jsp.java.

I will catch a train early tomorrow morning up to the mountains and will
therefore be unavailable for a couple of days. I can investigate this
further on Monday.

Happy weekend to you all!

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

Thanks - have a good weekend.

I will also withhold my vote for this RC until this is ironed out.
What I'm worried about is that all of the startup/shutdown model
changes might have impacted ManifoldCF running on Resin, so I think it
is essential we wait until this is resolved before declaring any
release candidate "done".

Karl
On Fri, Sep 21, 2012 at 10:12 AM, Erlend Garåsen
<[EMAIL PROTECTED]> wrote:
>
> I have created a ticket and attached _simplereport__jsp.java.
>
> I will catch a train early tomorrow morning up to the mountains and will
> therefore be unavailable for a couple of days. I can investigate this
> further on Monday.
>
> Happy weekend to you all!
>
>
> 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

Hi,

I see what has happened here.  You unregistered the connectors before
you deleted the job.  That basically meant that the job cleanup can't
take place until the connector(s) it requires are registered again.

This is "as designed".  You should be aware that it is unnecessary to
delete jobs and connections when you upgrade.  Nor is
unregistering/reregistering your connectors.

I'm going to spin a new RC with the NPE fix and a bunch of other
things - but I'm pretty certain the mystery is solved.

Thanks,
Karl

On Fri, Sep 21, 2012 at 10:17 AM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Thanks - have a good weekend.
>
> I will also withhold my vote for this RC until this is ironed out.
> What I'm worried about is that all of the startup/shutdown model
> changes might have impacted ManifoldCF running on Resin, so I think it
> is essential we wait until this is resolved before declaring any
> release candidate "done".
>
> Karl
>
>
> On Fri, Sep 21, 2012 at 10:12 AM, Erlend Garåsen
> <[EMAIL PROTECTED]> wrote:
>>
>> I have created a ticket and attached _simplereport__jsp.java.
>>
>> I will catch a train early tomorrow morning up to the mountains and will
>> therefore be unavailable for a couple of days. I can investigate this
>> further on Monday.
>>
>> Happy weekend to you all!
>>
>>
>> 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

Please vote +1 to release ManifoldCF 1.0, RC1.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC1

Fixes since RC0:

CONNECTORS-532
CONNECTORS-533
CONNECTORS-536
CONNECTORS-537

Karl

Examined the distribution for leakage of files that shouldn't be
there, ran ant rat-sources, and ran all tests.

+1 from me.

Karl

On Fri, Sep 21, 2012 at 3:48 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Please vote +1 to release ManifoldCF 1.0, RC1.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC1
>
> Fixes since RC0:
>
> CONNECTORS-532
> CONNECTORS-533
> CONNECTORS-536
> CONNECTORS-537
>
> Karl

On 21.09.12 20.55, Karl Wright wrote:

> I see what has happened here.  You unregistered the connectors before
> you deleted the job.  That basically meant that the job cleanup can't
> take place until the connector(s) it requires are registered again.

That's correct, and I also see the problem now. I forgot to install the
Filesystem connector before I did the configuration import (normally we
do not use this connector, but I installed one as a part of a test I did).

After I installed it, I do not longer get an NPE.

Maybe our routines for upgrading MCF need to be changed. We want to be
sure that these connectors do not need new fields in the database tables
due to changed/new functions. Therefore I thought this was the safest
approach. First we export the configuration, then we uninstall all
connectors by using the executecommand script, then deleting the tables
by performing an "agents.Uninstall" command, then reinstall everything
and finally import the configuration.

Still I cannot delete my jobs since their statuses are "cleaning up".
And the reason is because I didn't delete my jobs prior to executing
"crawler.UnRegisterAll"?

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

Hi, please see below:

On Mon, Sep 24, 2012 at 9:59 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
> On 21.09.12 20.55, Karl Wright wrote:
>
>> I see what has happened here.  You unregistered the connectors before
>> you deleted the job.  That basically meant that the job cleanup can't
>> take place until the connector(s) it requires are registered again.
>
>
> That's correct, and I also see the problem now. I forgot to install the
> Filesystem connector before I did the configuration import (normally we do
> not use this connector, but I installed one as a part of a test I did).
>
> After I installed it, I do not longer get an NPE.
>

ok, that is good.

> Maybe our routines for upgrading MCF need to be changed. We want to be sure
> that these connectors do not need new fields in the database tables due to
> changed/new functions.

This should happen automatically if you simply reregister the
connector.  You do not need to unregister it, I am pretty sure.

 Therefore I thought this was the safest approach.
> First we export the configuration, then we uninstall all connectors by using
> the executecommand script, then deleting the tables by performing an
> "agents.Uninstall" command, then reinstall everything and finally import the
> configuration.
>

You definitely do not need to do all that.  Just re-register the
crawlerAgent and the connectors.  It should automatically upgrade
database tables when you do that.

> Still I cannot delete my jobs since their statuses are "cleaning up". And
> the reason is because I didn't delete my jobs prior to executing
> "crawler.UnRegisterAll"?
>

Once you register the missing connectors again, and have the agents
process running, the job should delete.  If this is not happening it
may just take a few minutes for things to wake up, but it should pick
up where it left off.

If it doesn't seem to recover, it may be time to look in the database
to see what the status is of all the connectors.  When you unregister
and reregister a connector, it goes through the jobs that depend on
the connector and changes their state.  If there is something wrong
with that logic then the connector will be registered but the job will
still be in the "unregistered" state.

I'll try to reproduce this situation here sometime this evening, to be
sure that everything recovers the way it is supposed to.

Karl

>
> 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

I found a problem building the SharePoint connector with Maven
(CONNECTORS-538), but I resolved this issue.
I tested other functionalities and it seems all ok.

So I think that if we build another RC, this time it could be ok :)

Piergiorgio

2012/9/23 Karl Wright <[EMAIL PROTECTED]>

> Examined the distribution for leakage of files that shouldn't be
> there, ran ant rat-sources, and ran all tests.
>
> +1 from me.
>
> Karl
>
> On Fri, Sep 21, 2012 at 3:48 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> > Please vote +1 to release ManifoldCF 1.0, RC1.  The release artifact
> > can be found at:
> >
> > http://people.apache.org/~kwright/apache-manifoldcf-1.0
> >
> > There is also an SVN tag at:
> >
> > https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC1
> >
> > Fixes since RC0:
> >
> > CONNECTORS-532
> > CONNECTORS-533
> > CONNECTORS-536
> > CONNECTORS-537
> >
> > Karl
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

I think this is serious enough for a new RC.

But first, let's try to be sure there aren't any other major issues...

Karl

On Mon, Sep 24, 2012 at 10:11 AM, Piergiorgio Lucidi
<[EMAIL PROTECTED]> wrote:
> I found a problem building the SharePoint connector with Maven
> (CONNECTORS-538), but I resolved this issue.
> I tested other functionalities and it seems all ok.
>
> So I think that if we build another RC, this time it could be ok :)
>
> Piergiorgio
>
> 2012/9/23 Karl Wright <[EMAIL PROTECTED]>
>
>> Examined the distribution for leakage of files that shouldn't be
>> there, ran ant rat-sources, and ran all tests.
>>
>> +1 from me.
>>
>> Karl
>>
>> On Fri, Sep 21, 2012 at 3:48 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
>> > Please vote +1 to release ManifoldCF 1.0, RC1.  The release artifact
>> > can be found at:
>> >
>> > http://people.apache.org/~kwright/apache-manifoldcf-1.0
>> >
>> > There is also an SVN tag at:
>> >
>> > https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC1
>> >
>> > Fixes since RC0:
>> >
>> > CONNECTORS-532
>> > CONNECTORS-533
>> > CONNECTORS-536
>> > CONNECTORS-537
>> >
>> > Karl
>>
>> --
>> Piergiorgio Lucidi
>> http://www.open4dev.com
>>
>>

On 24.09.12 16.09, Karl Wright wrote:

>> Maybe our routines for upgrading MCF need to be changed. We want to be sure
>> that these connectors do not need new fields in the database tables due to
>> changed/new functions.
>
> This should happen automatically if you simply reregister the
> connector.  You do not need to unregister it, I am pretty sure.

Thanks. This makes our upgrading routines far more easier. I will update
our routine document right away.

>> Still I cannot delete my jobs since their statuses are "cleaning up". And
>> the reason is because I didn't delete my jobs prior to executing
>> "crawler.UnRegisterAll"?
>>
>
> Once you register the missing connectors again, and have the agents
> process running, the job should delete.  If this is not happening it
> may just take a few minutes for things to wake up, but it should pick
> up where it left off.
>
> If it doesn't seem to recover, it may be time to look in the database
> to see what the status is of all the connectors.  When you unregister
> and reregister a connector, it goes through the jobs that depend on
> the connector and changes their state.  If there is something wrong
> with that logic then the connector will be registered but the job will
> still be in the "unregistered" state.

Great. The Agent process is always running on our test server with a
cron job checking its status every day. I can check again tomorrow in
case the jobs have been deleted.

I will install RC1 and vote later this week.

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

On 24.09.12 16.45, Erlend Gar�sen wrote:

>> This should happen automatically if you simply reregister the
>> connector.  You do not need to unregister it, I am pretty sure.
>
> Thanks. This makes our upgrading routines far more easier. I will update
> our routine document right away.

Then I guess the following is also unnecessary to do prior to an upgrade?

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.UnRegisterAllOutputs

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.UnRegisterAll

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.Uninstall

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

Yes, this is all unneeded and superfluous.  Worse, it loses state between upgrades.

Karl

-----Original Message-----
From: ext Erlend Garåsen [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2012 10:51 AM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] Release Apache ManifoldCF 1.0, RC0

On 24.09.12 16.45, Erlend Garåsen wrote:

>> This should happen automatically if you simply reregister the
>> connector.  You do not need to unregister it, I am pretty sure.
>
> Thanks. This makes our upgrading routines far more easier. I will
> update our routine document right away.

Then I guess the following is also unnecessary to do prior to an upgrade?

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.UnRegisterAllOutputs

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.UnRegisterAll

$MCF_HOME/processes/script/executecommand.sh
org.apache.manifoldcf.agents.Uninstall

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

Please vote +1 to release ManifoldCF 1.0, RC2.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC2

Fixes since RC1:

CONNECTORS-538
CONNECTORS-539

Karl

I checked things out and did find a problem - see CONNECTORS-539.  I
resolved that issue, and tried out the scenario I think you were
running into, and everything worked just as expected.

I've spun another RC now (RC2).  Here's hoping that it will work as advertised.

Karl
On Mon, Sep 24, 2012 at 10:09 AM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Hi, please see below:
>
> On Mon, Sep 24, 2012 at 9:59 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>> On 21.09.12 20.55, Karl Wright wrote:
>>
>>> I see what has happened here.  You unregistered the connectors before
>>> you deleted the job.  That basically meant that the job cleanup can't
>>> take place until the connector(s) it requires are registered again.
>>
>>
>> That's correct, and I also see the problem now. I forgot to install the
>> Filesystem connector before I did the configuration import (normally we do
>> not use this connector, but I installed one as a part of a test I did).
>>
>> After I installed it, I do not longer get an NPE.
>>
>
> ok, that is good.
>
>> Maybe our routines for upgrading MCF need to be changed. We want to be sure
>> that these connectors do not need new fields in the database tables due to
>> changed/new functions.
>
> This should happen automatically if you simply reregister the
> connector.  You do not need to unregister it, I am pretty sure.
>
>  Therefore I thought this was the safest approach.
>> First we export the configuration, then we uninstall all connectors by using
>> the executecommand script, then deleting the tables by performing an
>> "agents.Uninstall" command, then reinstall everything and finally import the
>> configuration.
>>
>
> You definitely do not need to do all that.  Just re-register the
> crawlerAgent and the connectors.  It should automatically upgrade
> database tables when you do that.
>
>> Still I cannot delete my jobs since their statuses are "cleaning up". And
>> the reason is because I didn't delete my jobs prior to executing
>> "crawler.UnRegisterAll"?
>>
>
> Once you register the missing connectors again, and have the agents
> process running, the job should delete.  If this is not happening it
> may just take a few minutes for things to wake up, but it should pick
> up where it left off.
>
> If it doesn't seem to recover, it may be time to look in the database
> to see what the status is of all the connectors.  When you unregister
> and reregister a connector, it goes through the jobs that depend on
> the connector and changes their state.  If there is something wrong
> with that logic then the connector will be registered but the job will
> still be in the "unregistered" state.
>
> I'll try to reproduce this situation here sometime this evening, to be
> sure that everything recovers the way it is supposed to.
>
> Karl
>
>>
>> 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

Hi,

example-proprietary works fine.
multiprocess-example works fine.

multiprocess-example-proprietary doesn't work
by running ./start-webapps.sh
It seems that dist/web-proprietary/war/mcf-api-service.war doesn't include mcf-api-servlet.jar

./start-webapps.sh
:
:
6154 [main] INFO org.eclipse.jetty.server.handler.ContextHandler - started o.e.j.w.WebAppContext{/mcf-api-service,file:/private/var/folders/zL/zL4dWIVoEbCRSASf1T8R5++++TI/-Tmp-/jetty-0.0.0.0-8345-mcf-api-service.war-_mcf-api-service-any-/webapp/},/Users/abe/Desktop/RC/apache-manifoldcf-1.0/dist/multiprocess-example-proprietary/./../web-proprietary/war/mcf-api-service.war
6155 [main] WARN org.eclipse.jetty.servlet.Holder -
java.lang.ClassNotFoundException: org.apache.manifoldcf.apiservlet.APIServlet
:
:
6156 [main] WARN /mcf-api-service - unavailable
javax.servlet.UnavailableException: org.apache.manifoldcf.apiservlet.APIServlet
at org.eclipse.jetty.servlet.Holder.doStart(Holder.java:91)

I'll open Jira.

Regards,
Shinichiro Abe

On 2012/09/25, at 8:41, Karl Wright wrote:

> Please vote +1 to release ManifoldCF 1.0, RC2.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC2
>
> Fixes since RC1:
>
> CONNECTORS-538
> CONNECTORS-539
>
> Karl

Hmm, I don't see that here.
Karl
On Mon, Sep 24, 2012 at 9:54 PM, Shinichiro Abe
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> example-proprietary works fine.
> multiprocess-example works fine.
>
> multiprocess-example-proprietary doesn't work
> by running ./start-webapps.sh
> It seems that dist/web-proprietary/war/mcf-api-service.war doesn't include mcf-api-servlet.jar
>
> ./start-webapps.sh
> :
> :
> 6154 [main] INFO org.eclipse.jetty.server.handler.ContextHandler - started o.e.j.w.WebAppContext{/mcf-api-service,file:/private/var/folders/zL/zL4dWIVoEbCRSASf1T8R5++++TI/-Tmp-/jetty-0.0.0.0-8345-mcf-api-service.war-_mcf-api-service-any-/webapp/},/Users/abe/Desktop/RC/apache-manifoldcf-1.0/dist/multiprocess-example-proprietary/./../web-proprietary/war/mcf-api-service.war
> 6155 [main] WARN org.eclipse.jetty.servlet.Holder -
> java.lang.ClassNotFoundException: org.apache.manifoldcf.apiservlet.APIServlet
> :
> :
> 6156 [main] WARN /mcf-api-service - unavailable
> javax.servlet.UnavailableException: org.apache.manifoldcf.apiservlet.APIServlet
>         at org.eclipse.jetty.servlet.Holder.doStart(Holder.java:91)
>
> I'll open Jira.
>
> Regards,
> Shinichiro Abe
>
> On 2012/09/25, at 8:41, Karl Wright wrote:
>
>> Please vote +1 to release ManifoldCF 1.0, RC2.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC2
>>
>> Fixes since RC1:
>>
>> CONNECTORS-538
>> CONNECTORS-539
>>
>> Karl
>

Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3

Fixes since RC2:

CONNECTORS-540

Interesting.

Anyway, it seems that things are going a lot more better with RC3 on
Resin. I will test it more properly this week and vote as soon as possible.

Erlend

On 25.09.12 01.48, Karl Wright wrote:
> I checked things out and did find a problem - see CONNECTORS-539.  I
> resolved that issue, and tried out the scenario I think you were
> running into, and everything worked just as expected.
>
> I've spun another RC now (RC2).  Here's hoping that it will work as advertised.
>
> Karl
>
>
> On Mon, Sep 24, 2012 at 10:09 AM, Karl Wright <[EMAIL PROTECTED]> wrote:
>> Hi, please see below:
>>
>> On Mon, Sep 24, 2012 at 9:59 AM, Erlend Gar�sen <[EMAIL PROTECTED]> wrote:
>>> On 21.09.12 20.55, Karl Wright wrote:
>>>
>>>> I see what has happened here.  You unregistered the connectors before
>>>> you deleted the job.  That basically meant that the job cleanup can't
>>>> take place until the connector(s) it requires are registered again.
>>>
>>>
>>> That's correct, and I also see the problem now. I forgot to install the
>>> Filesystem connector before I did the configuration import (normally we do
>>> not use this connector, but I installed one as a part of a test I did).
>>>
>>> After I installed it, I do not longer get an NPE.
>>>
>>
>> ok, that is good.
>>
>>> Maybe our routines for upgrading MCF need to be changed. We want to be sure
>>> that these connectors do not need new fields in the database tables due to
>>> changed/new functions.
>>
>> This should happen automatically if you simply reregister the
>> connector.  You do not need to unregister it, I am pretty sure.
>>
>>   Therefore I thought this was the safest approach.
>>> First we export the configuration, then we uninstall all connectors by using
>>> the executecommand script, then deleting the tables by performing an
>>> "agents.Uninstall" command, then reinstall everything and finally import the
>>> configuration.
>>>
>>
>> You definitely do not need to do all that.  Just re-register the
>> crawlerAgent and the connectors.  It should automatically upgrade
>> database tables when you do that.
>>
>>> Still I cannot delete my jobs since their statuses are "cleaning up". And
>>> the reason is because I didn't delete my jobs prior to executing
>>> "crawler.UnRegisterAll"?
>>>
>>
>> Once you register the missing connectors again, and have the agents
>> process running, the job should delete.  If this is not happening it
>> may just take a few minutes for things to wake up, but it should pick
>> up where it left off.
>>
>> If it doesn't seem to recover, it may be time to look in the database
>> to see what the status is of all the connectors.  When you unregister
>> and reregister a connector, it goes through the jobs that depend on
>> the connector and changes their state.  If there is something wrong
>> with that logic then the connector will be registered but the job will
>> still be in the "unregistered" state.
>>
>> I'll try to reproduce this situation here sometime this evening, to be
>> sure that everything recovers the way it is supposed to.
>>
>> Karl
>>
>>>
>>> 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
--
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

Below my activity:

- tested the binary distribution using the CMIS Connector
- tried to build from source using Ant and Maven
- tested the generated binary in the same way
- checked signatures

+1 from me

Piergiorgio

2012/9/25 Karl Wright <[EMAIL PROTECTED]>

> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>
> Fixes since RC2:
>
> CONNECTORS-540
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

Ran tests, checked package contents.

+1 from me.

Karl

On Tue, Sep 25, 2012 at 12:51 PM, Piergiorgio Lucidi
<[EMAIL PROTECTED]> wrote:
> Below my activity:
>
> - tested the binary distribution using the CMIS Connector
> - tried to build from source using Ant and Maven
> - tested the generated binary in the same way
> - checked signatures
>
> +1 from me
>
> Piergiorgio
>
> 2012/9/25 Karl Wright <[EMAIL PROTECTED]>
>
>> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>>
>> Fixes since RC2:
>>
>> CONNECTORS-540
>>
>> --
>> Piergiorgio Lucidi
>> http://www.open4dev.com
>>
>>

I  checked examples.

+1 from me.

Shinichiro Abe

On 2012/09/26, at 5:50, Karl Wright wrote:

> Ran tests, checked package contents.
>
> +1 from me.
>
> Karl
>
> On Tue, Sep 25, 2012 at 12:51 PM, Piergiorgio Lucidi
> <[EMAIL PROTECTED]> wrote:
>> Below my activity:
>>
>> - tested the binary distribution using the CMIS Connector
>> - tried to build from source using Ant and Maven
>> - tested the generated binary in the same way
>> - checked signatures
>>
>> +1 from me
>>
>> Piergiorgio
>>
>> 2012/9/25 Karl Wright <[EMAIL PROTECTED]>
>>
>>> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
>>> can be found at:
>>>
>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>
>>> There is also an SVN tag at:
>>>
>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>>>
>>> Fixes since RC2:
>>>
>>> CONNECTORS-540
>>>
>>> --
>>> Piergiorgio Lucidi
>>> http://www.open4dev.com
>>>
>>>

+1

- Downloaded binary release (tar.gz) and deployed on Caucho Resin (Linux
64 bit Java 1.6). Tried different commands from executecommand.sh
(including export and import of configuration data using
encryption/clear text). Crawled around 6000 documents using the web
crawler and sent them to Solr for indexing.
- Downloaded the source (tar.gz) on OS X (64 bit Java 1.6). Ran ant
test, ant doc (and viewed the build content with Firefox( and ant build.
- Started MCF with Jetty from dist/example and dist/multiprocess-example
(HSQLDB).

Erlend

On 25.09.12 12.17, Karl Wright wrote:
> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>
> Fixes since RC2:
>
> CONNECTORS-540
>
--
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

Has anyone tried to deploy the combined war on any application server?

I should have written a test for it clearly but it was a rather late addition.

Karl
On Wed, Sep 26, 2012 at 5:48 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> +1
>
> - Downloaded binary release (tar.gz) and deployed on Caucho Resin (Linux 64
> bit Java 1.6). Tried different commands from executecommand.sh (including
> export and import of configuration data using encryption/clear text).
> Crawled around 6000 documents using the web crawler and sent them to Solr
> for indexing.
> - Downloaded the source (tar.gz) on OS X (64 bit Java 1.6). Ran ant test,
> ant doc (and viewed the build content with Firefox( and ant build.
> - Started MCF with Jetty from dist/example and dist/multiprocess-example
> (HSQLDB).
>
> Erlend
>
>
> On 25.09.12 12.17, Karl Wright wrote:
>>
>> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>>
>> Fixes since RC2:
>>
>> CONNECTORS-540
>>
>
>
> --
> 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

I did deploy the combined war file on Resin, but without knowing the
purpose of it. For me it sounds like it includes all the three other
packages.

Anyway, documentation is missing:
"If you built ManifoldCF using ant, then the ant build will have
constructed *three war files* ..."

I can test this war file more properly if I get some basic information
about it.

Erlend

On 26.09.12 12.47, Karl Wright wrote:
> Has anyone tried to deploy the combined war on any application server?
>
> I should have written a test for it clearly but it was a rather late addition.
>
> Karl
>
>
> On Wed, Sep 26, 2012 at 5:48 AM, Erlend Gar�sen <[EMAIL PROTECTED]> wrote:
>>
>> +1
>>
>> - Downloaded binary release (tar.gz) and deployed on Caucho Resin (Linux 64
>> bit Java 1.6). Tried different commands from executecommand.sh (including
>> export and import of configuration data using encryption/clear text).
>> Crawled around 6000 documents using the web crawler and sent them to Solr
>> for indexing.
>> - Downloaded the source (tar.gz) on OS X (64 bit Java 1.6). Ran ant test,
>> ant doc (and viewed the build content with Firefox( and ant build.
>> - Started MCF with Jetty from dist/example and dist/multiprocess-example
>> (HSQLDB).
>>
>> Erlend
>>
>>
>> On 25.09.12 12.17, Karl Wright wrote:
>>>
>>> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
>>> can be found at:
>>>
>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>
>>> There is also an SVN tag at:
>>>
>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>>>
>>> Fixes since RC2:
>>>
>>> CONNECTORS-540
>>>
>>
>>
>> --
>> 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
--
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

I didn't do documentation (or tests) because it is experimental at this point.

It replaces ALL of manifoldcf in one war.  So it is exactly like the
single-process example (and would use the same properties.xml) but
deployable as a war.  Does this help?

Karl
On Wed, Sep 26, 2012 at 8:21 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> I did deploy the combined war file on Resin, but without knowing the purpose
> of it. For me it sounds like it includes all the three other packages.
>
> Anyway, documentation is missing:
> "If you built ManifoldCF using ant, then the ant build will have constructed
> *three war files* ..."
>
> I can test this war file more properly if I get some basic information about
> it.
>
> Erlend
>
>
> On 26.09.12 12.47, Karl Wright wrote:
>>
>> Has anyone tried to deploy the combined war on any application server?
>>
>> I should have written a test for it clearly but it was a rather late
>> addition.
>>
>> Karl
>>
>>
>> On Wed, Sep 26, 2012 at 5:48 AM, Erlend Garåsen <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
>>> +1
>>>
>>> - Downloaded binary release (tar.gz) and deployed on Caucho Resin (Linux
>>> 64
>>> bit Java 1.6). Tried different commands from executecommand.sh (including
>>> export and import of configuration data using encryption/clear text).
>>> Crawled around 6000 documents using the web crawler and sent them to Solr
>>> for indexing.
>>> - Downloaded the source (tar.gz) on OS X (64 bit Java 1.6). Ran ant test,
>>> ant doc (and viewed the build content with Firefox( and ant build.
>>> - Started MCF with Jetty from dist/example and dist/multiprocess-example
>>> (HSQLDB).
>>>
>>> Erlend
>>>
>>>
>>> On 25.09.12 12.17, Karl Wright wrote:
>>>>
>>>>
>>>> Please vote +1 to release ManifoldCF 1.0, RC3.  The release artifact
>>>> can be found at:
>>>>
>>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>>
>>>> There is also an SVN tag at:
>>>>
>>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC3
>>>>
>>>> Fixes since RC2:
>>>>
>>>> CONNECTORS-540
>>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> 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

On 26.09.12 14.39, Karl Wright wrote:
> I didn't do documentation (or tests) because it is experimental at this point.
>
> It replaces ALL of manifoldcf in one war.  So it is exactly like the
> single-process example (and would use the same properties.xml) but
> deployable as a war.  Does this help?

Sure! I will test it withing 24 hours, probably later today.

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

Hm, it seems that Resin manages to restore the three applications even
though I delete the three war files and the path where they are built.
This makes it a little bit more difficult to test.

I haven't restarted Resin, only the instance where MCF is running since
other applications are running on the same server. I have asked someone
with better server skills and Resin knowledge.

Erlend

On 26.09.12 15.02, Erlend Gar�sen wrote:
> On 26.09.12 14.39, Karl Wright wrote:
>> I didn't do documentation (or tests) because it is experimental at
>> this point.
>>
>> It replaces ALL of manifoldcf in one war.  So it is exactly like the
>> single-process example (and would use the same properties.xml) but
>> deployable as a war.  Does this help?
>
> Sure! I will test it withing 24 hours, probably later today.
>
> 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

Usually application servers unpack the war somewhere.  Unless you
remove the place where it is unpacked you will continue to have the
applications even after the war is gone.

Karl

On Wed, Sep 26, 2012 at 11:52 AM, Erlend Garåsen
<[EMAIL PROTECTED]> wrote:
>
> Hm, it seems that Resin manages to restore the three applications even
> though I delete the three war files and the path where they are built. This
> makes it a little bit more difficult to test.
>
> I haven't restarted Resin, only the instance where MCF is running since
> other applications are running on the same server. I have asked someone with
> better server skills and Resin knowledge.
>
> Erlend
>
>
> On 26.09.12 15.02, Erlend Garåsen wrote:
>>
>> On 26.09.12 14.39, Karl Wright wrote:
>>>
>>> I didn't do documentation (or tests) because it is experimental at
>>> this point.
>>>
>>> It replaces ALL of manifoldcf in one war.  So it is exactly like the
>>> single-process example (and would use the same properties.xml) but
>>> deployable as a war.  Does this help?
>>
>>
>> Sure! I will test it withing 24 hours, probably later today.
>>
>> 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

Yes, I know, Karl, but I'm actually deleting the places where they are
unpacked. I will get back to this as soon as I have spoken to my
colleague. I will find out why tomorrow after our Solr meeting.

If I get a reply this evening, I will try to do a new test from home.

Erlend

On 26.09.12 17.55, Karl Wright wrote:
> Usually application servers unpack the war somewhere.  Unless you
> remove the place where it is unpacked you will continue to have the
> applications even after the war is gone.
>
> Karl
>
> On Wed, Sep 26, 2012 at 11:52 AM, Erlend Gar�sen
> <[EMAIL PROTECTED]> wrote:
>>
>> Hm, it seems that Resin manages to restore the three applications even
>> though I delete the three war files and the path where they are built. This
>> makes it a little bit more difficult to test.
>>
>> I haven't restarted Resin, only the instance where MCF is running since
>> other applications are running on the same server. I have asked someone with
>> better server skills and Resin knowledge.
>>
>> Erlend
>>
>>
>> On 26.09.12 15.02, Erlend Gar�sen wrote:
>>>
>>> On 26.09.12 14.39, Karl Wright wrote:
>>>>
>>>> I didn't do documentation (or tests) because it is experimental at
>>>> this point.
>>>>
>>>> It replaces ALL of manifoldcf in one war.  So it is exactly like the
>>>> single-process example (and would use the same properties.xml) but
>>>> deployable as a war.  Does this help?
>>>
>>>
>>> Sure! I will test it withing 24 hours, probably later today.
>>>
>>> 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
--
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

The reason why Resin restores the application is due to a new feature in
version 4 and is related to clustering functionality. Resin stores all
versions of an application (war) in a local Git repository, which means,
it is able to restore an application if it has been deleted:
http://www.caucho.com/resin-4.0/admin/clustering-overview.xtp#DeployingApplicationstoaCluster

Since I'm going to Amsterdam tomorrow morning, I don't want to change
anything in Resin right now in case I break something (other apps are
running on the same server).

I tried to deploy the combined war on Tomcat, but then I couldn't
connect to our PostgreSQL server because it seems to have a new SSL
certificate I haven't installed into my local keystore.

I guess ut is possible to configure HSQLDB, but I'm afraid that my time
is running out. Sorry.

Erlend

On 26.09.12 18.00, Erlend Gar�sen wrote:
>
> Yes, I know, Karl, but I'm actually deleting the places where they are
> unpacked. I will get back to this as soon as I have spoken to my
> colleague. I will find out why tomorrow after our Solr meeting.
>
> If I get a reply this evening, I will try to do a new test from home.
>
> Erlend
>
> On 26.09.12 17.55, Karl Wright wrote:
>> Usually application servers unpack the war somewhere.  Unless you
>> remove the place where it is unpacked you will continue to have the
>> applications even after the war is gone.
>>
>> Karl
>>
>> On Wed, Sep 26, 2012 at 11:52 AM, Erlend Gar�sen
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Hm, it seems that Resin manages to restore the three applications even
>>> though I delete the three war files and the path where they are
>>> built. This
>>> makes it a little bit more difficult to test.
>>>
>>> I haven't restarted Resin, only the instance where MCF is running since
>>> other applications are running on the same server. I have asked
>>> someone with
>>> better server skills and Resin knowledge.
>>>
>>> Erlend
>>>
>>>
>>> On 26.09.12 15.02, Erlend Gar�sen wrote:
>>>>
>>>> On 26.09.12 14.39, Karl Wright wrote:
>>>>>
>>>>> I didn't do documentation (or tests) because it is experimental at
>>>>> this point.
>>>>>
>>>>> It replaces ALL of manifoldcf in one war.  So it is exactly like the
>>>>> single-process example (and would use the same properties.xml) but
>>>>> deployable as a war.  Does this help?
>>>>
>>>>
>>>> Sure! I will test it withing 24 hours, probably later today.
>>>>
>>>> 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
>
>
--
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

I wrote a test for it here.  Unfortunately, it fails because the war
does not include some key classes.

I think even though this is an experimental feature, this is
sufficient to cause a new RC.  Does anyone disagree?

Karl
On Thu, Sep 27, 2012 at 11:35 AM, Erlend Garåsen
<[EMAIL PROTECTED]> wrote:
>
> The reason why Resin restores the application is due to a new feature in
> version 4 and is related to clustering functionality. Resin stores all
> versions of an application (war) in a local Git repository, which means, it
> is able to restore an application if it has been deleted:
> http://www.caucho.com/resin-4.0/admin/clustering-overview.xtp#DeployingApplicationstoaCluster
>
> Since I'm going to Amsterdam tomorrow morning, I don't want to change
> anything in Resin right now in case I break something (other apps are
> running on the same server).
>
> I tried to deploy the combined war on Tomcat, but then I couldn't connect to
> our PostgreSQL server because it seems to have a new SSL certificate I
> haven't installed into my local keystore.
>
> I guess ut is possible to configure HSQLDB, but I'm afraid that my time is
> running out. Sorry.
>
> Erlend
>
>
> On 26.09.12 18.00, Erlend Garåsen wrote:
>>
>>
>> Yes, I know, Karl, but I'm actually deleting the places where they are
>> unpacked. I will get back to this as soon as I have spoken to my
>> colleague. I will find out why tomorrow after our Solr meeting.
>>
>> If I get a reply this evening, I will try to do a new test from home.
>>
>> Erlend
>>
>> On 26.09.12 17.55, Karl Wright wrote:
>>>
>>> Usually application servers unpack the war somewhere.  Unless you
>>> remove the place where it is unpacked you will continue to have the
>>> applications even after the war is gone.
>>>
>>> Karl
>>>
>>> On Wed, Sep 26, 2012 at 11:52 AM, Erlend Garåsen
>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>> Hm, it seems that Resin manages to restore the three applications even
>>>> though I delete the three war files and the path where they are
>>>> built. This
>>>> makes it a little bit more difficult to test.
>>>>
>>>> I haven't restarted Resin, only the instance where MCF is running since
>>>> other applications are running on the same server. I have asked
>>>> someone with
>>>> better server skills and Resin knowledge.
>>>>
>>>> Erlend
>>>>
>>>>
>>>> On 26.09.12 15.02, Erlend Garåsen wrote:
>>>>>
>>>>>
>>>>> On 26.09.12 14.39, Karl Wright wrote:
>>>>>>
>>>>>>
>>>>>> I didn't do documentation (or tests) because it is experimental at
>>>>>> this point.
>>>>>>
>>>>>> It replaces ALL of manifoldcf in one war.  So it is exactly like the
>>>>>> single-process example (and would use the same properties.xml) but
>>>>>> deployable as a war.  Does this help?
>>>>>
>>>>>
>>>>>
>>>>> Sure! I will test it withing 24 hours, probably later today.
>>>>>
>>>>> 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
>>
>>
>>
>
>
> --
> 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

Please vote +1 to release ManifoldCF 1.0, RC4.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC4

Fixes since RC3:

CONNECTORS-544
(also added example scripts to run the combined webapp)

Ran all tests, tried the combined war, tried single-process example
and multiprocess example.

+1 (and I really hope this is the last RC for this release)

Karl

On Thu, Sep 27, 2012 at 5:30 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Please vote +1 to release ManifoldCF 1.0, RC4.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC4
>
> Fixes since RC3:
>
> CONNECTORS-544
> (also added example scripts to run the combined webapp)

Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5

Fixes since RC4:

CONNECTORS-545

Fixes since RC3:

CONNECTORS-544

I'm trying to start a crawl before I have to run to the airport. I just
discovered that MCF recrawls the same host over and over again when it
returns result code 500:
09-28-2012 11:40:11.024 fetch
http://foreninger.uio.no/go/oslo_open_2012_no.php
500

It's just not this document, but several others returning the same HTTP
result code.

Meanwhile, the following is filling up my log:
FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
String index out of range: -1
java.lang.StringIndexOutOfBoundsException: String index out of range: -1

I'm pretty sure they are related to each other.

I will end this job before I leave because I'm afraid that MCF will try
to fetch these documents over and over again during this weekend.

Erlend

On 28.09.12 09.58, Karl Wright wrote:
> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>
> Fixes since RC4:
>
> CONNECTORS-545
>
> Fixes since RC3:
>
> CONNECTORS-544
>
--
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

Documents: 5826
Active: 3
Processed: 5826.

It's these three documents which are crawled over and over again.

I'm ending this job now because I'm pretty sure it will never stop.

Erlend

On 28.09.12 11.49, Erlend Gar�sen wrote:
>
> I'm trying to start a crawl before I have to run to the airport. I just
> discovered that MCF recrawls the same host over and over again when it
> returns result code 500:
> 09-28-2012 11:40:11.024     fetch
> http://foreninger.uio.no/go/oslo_open_2012_no.php
>      500
>
> It's just not this document, but several others returning the same HTTP
> result code.
>
> Meanwhile, the following is filling up my log:
> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
> String index out of range: -1
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> I'm pretty sure they are related to each other.
>
> I will end this job before I leave because I'm afraid that MCF will try
> to fetch these documents over and over again during this weekend.
>
> Erlend
>
> On 28.09.12 09.58, Karl Wright wrote:
>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>
>> Fixes since RC4:
>>
>> CONNECTORS-545
>>
>> Fixes since RC3:
>>
>> CONNECTORS-544
>>
>
>
--
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

-1.
A java.lang.StringIndexOutOfBoundsException and a never-ending job sound
like a blocker to me.

The response header of:
http://foreninger.uio.no/go/oslo_open_2012_no.php

Date: Fri, 28 Sep 2012 10:08:34 GMT
Server: Apache/2.2.22 (Unix)
X-Powered-By: PHP/5.3.10
X-UA-Compatible: IE=EmulateIE7
Content-Length: 0
Connection: close
Content-Type: text/html

500 Internal Server Error

I will be unavailable until Monday evening, but I might be able to check
my email before then.

Another thing. I'm not able to build MCF with Maven (mvn clean install
-Dmaven.test.skip):

  Failed to execute goal on project mcf-filesystem-connector: Could not
resolve dependencies for project
org.apache.manifoldcf:mcf-filesystem-connector:jar:1.0: Could not find
artifact org.apache.manifoldcf:mcf-pull-agent:jar:tests:1.0 in ...

I ran mvn-bootstrap.sh before I tried to build. I even ran the following:
mvn install:install-file -Dfile=lib/commons-httpclient.jar
-DgroupId=commons-httpclient -DartifactId=commons-httpclient-mcf
-Dversion=3.1  -Dpackaging=jar

Erlend

On 28.09.12 11.58, Erlend Gar�sen wrote:
>
> Documents: 5826
> Active: 3
> Processed: 5826.
>
> It's these three documents which are crawled over and over again.
>
> I'm ending this job now because I'm pretty sure it will never stop.
>
> Erlend
>
> On 28.09.12 11.49, Erlend Gar�sen wrote:
>>
>> I'm trying to start a crawl before I have to run to the airport. I just
>> discovered that MCF recrawls the same host over and over again when it
>> returns result code 500:
>> 09-28-2012 11:40:11.024     fetch
>> http://foreninger.uio.no/go/oslo_open_2012_no.php
>>      500
>>
>> It's just not this document, but several others returning the same HTTP
>> result code.
>>
>> Meanwhile, the following is filling up my log:
>> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
>> String index out of range: -1
>> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>>
>> I'm pretty sure they are related to each other.
>>
>> I will end this job before I leave because I'm afraid that MCF will try
>> to fetch these documents over and over again during this weekend.
>>
>> Erlend
>>
>> On 28.09.12 09.58, Karl Wright wrote:
>>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>>> can be found at:
>>>
>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>
>>> There is also an SVN tag at:
>>>
>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>>
>>> Fixes since RC4:
>>>
>>> CONNECTORS-545
>>>
>>> Fixes since RC3:
>>>
>>> CONNECTORS-544
>>>
>>
>>
>
>
--
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

Hi Erlend,

This is expected behavior.  ManifoldCF is designed to retry on errors
that mean potential server problems for a period of time and then give
up.  The logic here is that 500 may well mean the server is down but
will be rebooted or whatever.  It retries every N minutes until M
minutes have elapsed.  For a 500 error, I believe it's every 5 minutes
for either 6 or 12 hours.

Karl
On Fri, Sep 28, 2012 at 5:49 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> I'm trying to start a crawl before I have to run to the airport. I just
> discovered that MCF recrawls the same host over and over again when it
> returns result code 500:
> 09-28-2012 11:40:11.024         fetch
> http://foreninger.uio.no/go/oslo_open_2012_no.php
>         500
>
> It's just not this document, but several others returning the same HTTP
> result code.
>
> Meanwhile, the following is filling up my log:
> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed: String
> index out of range: -1
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> I'm pretty sure they are related to each other.
>
> I will end this job before I leave because I'm afraid that MCF will try to
> fetch these documents over and over again during this weekend.
>
> Erlend
>
>
> On 28.09.12 09.58, Karl Wright wrote:
>>
>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>
>> Fixes since RC4:
>>
>> CONNECTORS-545
>>
>> Fixes since RC3:
>>
>> CONNECTORS-544
>>
>
>
> --
> 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

"Meanwhile, the following is filling up my log:
FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
String index out of range: -1
java.lang.StringIndexOutOfBoundsException: String index out of range: -1"

This is indeed a problem I agree we should fix, but in order to do
that I need a stack trace.  It is not clear at all that it is related
to the 500 error you described before, but it could be.  I will create
a ticket for it though.
Karl

On Fri, Sep 28, 2012 at 5:49 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> I'm trying to start a crawl before I have to run to the airport. I just
> discovered that MCF recrawls the same host over and over again when it
> returns result code 500:
> 09-28-2012 11:40:11.024         fetch
> http://foreninger.uio.no/go/oslo_open_2012_no.php
>         500
>
> It's just not this document, but several others returning the same HTTP
> result code.
>
> Meanwhile, the following is filling up my log:
> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed: String
> index out of range: -1
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> I'm pretty sure they are related to each other.
>
> I will end this job before I leave because I'm afraid that MCF will try to
> fetch these documents over and over again during this weekend.
>
> Erlend
>
>
> On 28.09.12 09.58, Karl Wright wrote:
>>
>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>
>> Fixes since RC4:
>>
>> CONNECTORS-545
>>
>> Fixes since RC3:
>>
>> CONNECTORS-544
>>
>
>
> --
> 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

OK, I will give you a stack trace in the beginning of next week.

I will start the crawler once more and check the results when I'm back
and change my vote then if it is ok.

Erlend

On 28.09.12 13.26, Karl Wright wrote:
> "Meanwhile, the following is filling up my log:
> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
> String index out of range: -1
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1"
>
> This is indeed a problem I agree we should fix, but in order to do
> that I need a stack trace.  It is not clear at all that it is related
> to the 500 error you described before, but it could be.  I will create
> a ticket for it though.
> Karl
>
> On Fri, Sep 28, 2012 at 5:49 AM, Erlend Gar�sen <[EMAIL PROTECTED]> wrote:
>>
>> I'm trying to start a crawl before I have to run to the airport. I just
>> discovered that MCF recrawls the same host over and over again when it
>> returns result code 500:
>> 09-28-2012 11:40:11.024         fetch
>> http://foreninger.uio.no/go/oslo_open_2012_no.php
>>          500
>>
>> It's just not this document, but several others returning the same HTTP
>> result code.
>>
>> Meanwhile, the following is filling up my log:
>> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed: String
>> index out of range: -1
>> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>>
>> I'm pretty sure they are related to each other.
>>
>> I will end this job before I leave because I'm afraid that MCF will try to
>> fetch these documents over and over again during this weekend.
>>
>> Erlend
>>
>>
>> On 28.09.12 09.58, Karl Wright wrote:
>>>
>>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>>> can be found at:
>>>
>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>
>>> There is also an SVN tag at:
>>>
>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>>
>>> Fixes since RC4:
>>>
>>> CONNECTORS-545
>>>
>>> Fixes since RC3:
>>>
>>> CONNECTORS-544
>>>
>>
>>
>> --
>> 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
--
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

CONNECTORS-547 (index out of bounds)
CONNECTORS-548 (cannot build with maven)

Karl

On Fri, Sep 28, 2012 at 7:26 AM, Karl Wright <[EMAIL PROTECTED]> wrote:
> "Meanwhile, the following is filling up my log:
> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed:
> String index out of range: -1
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1"
>
> This is indeed a problem I agree we should fix, but in order to do
> that I need a stack trace.  It is not clear at all that it is related
> to the 500 error you described before, but it could be.  I will create
> a ticket for it though.
> Karl
>
> On Fri, Sep 28, 2012 at 5:49 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>>
>> I'm trying to start a crawl before I have to run to the airport. I just
>> discovered that MCF recrawls the same host over and over again when it
>> returns result code 500:
>> 09-28-2012 11:40:11.024         fetch
>> http://foreninger.uio.no/go/oslo_open_2012_no.php
>>         500
>>
>> It's just not this document, but several others returning the same HTTP
>> result code.
>>
>> Meanwhile, the following is filling up my log:
>> FATAL 2012-09-28 11:42:32,112 (Worker thread '29') - Error tossed: String
>> index out of range: -1
>> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>>
>> I'm pretty sure they are related to each other.
>>
>> I will end this job before I leave because I'm afraid that MCF will try to
>> fetch these documents over and over again during this weekend.
>>
>> Erlend
>>
>>
>> On 28.09.12 09.58, Karl Wright wrote:
>>>
>>> Please vote +1 to release ManifoldCF 1.0, RC5.  The release artifact
>>> can be found at:
>>>
>>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>>
>>> There is also an SVN tag at:
>>>
>>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC5
>>>
>>> Fixes since RC4:
>>>
>>> CONNECTORS-545
>>>
>>> Fixes since RC3:
>>>
>>> CONNECTORS-544
>>>
>>
>>
>> --
>> 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

Please vote +1 to release ManifoldCF 1.0, RC6.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC6

Fixes since RC5:

CONNECTORS-547
CONNECTORS-548 (documentation fix)

Fixes since RC4:

CONNECTORS-545

Fixes since RC3:

CONNECTORS-544

Exercised it as I have before, and added postgresql and mysql tests.

+1

Karl

On Fri, Sep 28, 2012 at 9:38 AM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Please vote +1 to release ManifoldCF 1.0, RC6.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC6
>
> Fixes since RC5:
>
> CONNECTORS-547
> CONNECTORS-548 (documentation fix)
>
> Fixes since RC4:
>
> CONNECTORS-545
>
> Fixes since RC3:
>
> CONNECTORS-544

-1 from me.

I found an issue on the CMIS Connector (CONNECTORS-549), I'm committing the
patch to fix the problem.
We need another RC.

Piergiorgio

2012/9/28 Karl Wright <[EMAIL PROTECTED]>

> Please vote +1 to release ManifoldCF 1.0, RC6.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC6
>
> Fixes since RC5:
>
> CONNECTORS-547
> CONNECTORS-548 (documentation fix)
>
> Fixes since RC4:
>
> CONNECTORS-545
>
> Fixes since RC3:
>
> CONNECTORS-544
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

Please vote +1 to release ManifoldCF 1.0, RC7.  The release artifact
can be found at:

http://people.apache.org/~kwright/apache-manifoldcf-1.0

There is also an SVN tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7

Fixes since RC6:

CONNECTORS-549

Fixes since RC5:

CONNECTORS-547
CONNECTORS-548 (documentation fix)

Fixes since RC4:

CONNECTORS-545

Fixes since RC3:

CONNECTORS-544

+1 from me:

- checked signatures
- crawling against a CMIS repository
- tried to build using Maven and Ant

Piergiorgio

2012/9/30 Karl Wright <[EMAIL PROTECTED]>

> Please vote +1 to release ManifoldCF 1.0, RC7.  The release artifact
> can be found at:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>
> There is also an SVN tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7
>
> Fixes since RC6:
>
> CONNECTORS-549
>
> Fixes since RC5:
>
> CONNECTORS-547
> CONNECTORS-548 (documentation fix)
>
> Fixes since RC4:
>
> CONNECTORS-545
>
> Fixes since RC3:
>
> CONNECTORS-544
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

Ran all tests, just to be sure nothing got messed up.  +1 from me.

Karl

On Sun, Sep 30, 2012 at 11:34 AM, Piergiorgio Lucidi
<[EMAIL PROTECTED]> wrote:
> +1 from me:
>
> - checked signatures
> - crawling against a CMIS repository
> - tried to build using Maven and Ant
>
> Piergiorgio
>
> 2012/9/30 Karl Wright <[EMAIL PROTECTED]>
>
>> Please vote +1 to release ManifoldCF 1.0, RC7.  The release artifact
>> can be found at:
>>
>> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>
>> There is also an SVN tag at:
>>
>> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7
>>
>> Fixes since RC6:
>>
>> CONNECTORS-549
>>
>> Fixes since RC5:
>>
>> CONNECTORS-547
>> CONNECTORS-548 (documentation fix)
>>
>> Fixes since RC4:
>>
>> CONNECTORS-545
>>
>> Fixes since RC3:
>>
>> CONNECTORS-544
>>
>> --
>> Piergiorgio Lucidi
>> http://www.open4dev.com
>>
>>

On 28.09.12 13.31, Erlend Gar�sen wrote:

> OK, I will give you a stack trace in the beginning of next week.

Do you still need the stack trace? If you do, I need to adjust the log
level and/or change the source code in order to print it out.

I'm still a little bit worried about how MCF deals with 500 server
errors since the job I started last Friday is still running. It retries
and retries the three documents I previously mentioned.

Is it really a normal behaviour that MCF retries the same document every
fourth second after the last attempt and continues do do this (perhaps)
thousand times? MCF has probably retried these documents in four days
now. I doubt this is normal behaviour.

The job should end in the middle of the day on Saturday, and now it's
Tuesday.

I will test the latest RC after these issues have been clarified.

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

No stack trace needed.  If you read the rest of the mail, you will
note that I was able to reproduce the issue using the URL you had
provided.  There have been two RC's since; we are on RC7 now.

Karl
On Tue, Oct 2, 2012 at 4:38 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
> On 28.09.12 13.31, Erlend Garåsen wrote:
>
>> OK, I will give you a stack trace in the beginning of next week.
>
>
> Do you still need the stack trace? If you do, I need to adjust the log level
> and/or change the source code in order to print it out.
>
> I'm still a little bit worried about how MCF deals with 500 server errors
> since the job I started last Friday is still running. It retries and retries
> the three documents I previously mentioned.
>
> Is it really a normal behaviour that MCF retries the same document every
> fourth second after the last attempt and continues do do this (perhaps)
> thousand times? MCF has probably retried these documents in four days now. I
> doubt this is normal behaviour.
>
> The job should end in the middle of the day on Saturday, and now it's
> Tuesday.
>
> I will test the latest RC after these issues have been clarified.
>
> 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

Karl, you wrote: "I was able to reproduce the exception here using your
URL.  It is indeed a bug in how it handles the 500 error."

OK, then I guess that the StringIndexOutOfBoundsException *was* related
to the 500 server issue ("It is not clear at all that it is related
to the 500 error you described before, but it could be.").

To clarify another thing: These three documents are fetched over and
over again every fourth second (in four days). I was mentioning this in
case we had another issue.

I'm just trying to clarify this before I deploy RC7 as I wrote.

Anyway, I will deploy RC7 now and start my job once more.

Erlend

On 02.10.12 11.03, Karl Wright wrote:
> No stack trace needed.  If you read the rest of the mail, you will
> note that I was able to reproduce the issue using the URL you had
> provided.  There have been two RC's since; we are on RC7 now.
>
> Karl
>
>
> On Tue, Oct 2, 2012 at 4:38 AM, Erlend Gar�sen <[EMAIL PROTECTED]> wrote:
>> On 28.09.12 13.31, Erlend Gar�sen wrote:
>>
>>> OK, I will give you a stack trace in the beginning of next week.
>>
>>
>> Do you still need the stack trace? If you do, I need to adjust the log level
>> and/or change the source code in order to print it out.
>>
>> I'm still a little bit worried about how MCF deals with 500 server errors
>> since the job I started last Friday is still running. It retries and retries
>> the three documents I previously mentioned.
>>
>> Is it really a normal behaviour that MCF retries the same document every
>> fourth second after the last attempt and continues do do this (perhaps)
>> thousand times? MCF has probably retried these documents in four days now. I
>> doubt this is normal behaviour.
>>
>> The job should end in the middle of the day on Saturday, and now it's
>> Tuesday.
>>
>> I will test the latest RC after these issues have been clarified.
>>
>> 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
--
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

Hi,

'ant all' command yields:

BUILD FAILED
/manifoldcf/tags/release-1.0-RC7/build.xml:2529: A zip file cannot include itself

Ahmet
--- On Sun, 9/30/12, Karl Wright <[EMAIL PROTECTED]> wrote:

> From: Karl Wright <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] Release Apache ManifoldCF 1.0, RC7
> To: [EMAIL PROTECTED]
> Date: Sunday, September 30, 2012, 9:40 PM
> Ran all tests, just to be sure
> nothing got messed up.  +1 from me.
>
> Karl
>
> On Sun, Sep 30, 2012 at 11:34 AM, Piergiorgio Lucidi
> <[EMAIL PROTECTED]>
> wrote:
> > +1 from me:
> >
> > - checked signatures
> > - crawling against a CMIS repository
> > - tried to build using Maven and Ant
> >
> > Piergiorgio
> >
> > 2012/9/30 Karl Wright <[EMAIL PROTECTED]>
> >
> >> Please vote +1 to release ManifoldCF 1.0,
> RC7.  The release artifact
> >> can be found at:
> >>
> >> http://people.apache.org/~kwright/apache-manifoldcf-1.0
> >>
> >> There is also an SVN tag at:
> >>
> >> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7
> >>
> >> Fixes since RC6:
> >>
> >> CONNECTORS-549
> >>
> >> Fixes since RC5:
> >>
> >> CONNECTORS-547
> >> CONNECTORS-548 (documentation fix)
> >>
> >> Fixes since RC4:
> >>
> >> CONNECTORS-545
> >>
> >> Fixes since RC3:
> >>
> >> CONNECTORS-544
> >>
> >> --
> >> Piergiorgio Lucidi
> >> http://www.open4dev.com
> >>
> >>
>

The ant build hasn't changed in this regard, but maybe ant has.
Here's the code:

    <target name="create-source-zip" depends="set-version">
      <zip destfile="apache-manifoldcf-${release-version}-src.zip"
update="false">
        <zipfileset dir="." prefix="apache-manifoldcf-${release-version}">
...
          <exclude name="/apache-manifoldcf-*"/>
        </zipfileset>
      </zip>
    </target>

This used to exclude the zip from itself.  What version of ant are you using?

Karl

On Tue, Oct 2, 2012 at 2:30 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 'ant all' command yields:
>
> BUILD FAILED
> /manifoldcf/tags/release-1.0-RC7/build.xml:2529: A zip file cannot include itself
>
> Ahmet
>
>
> --- On Sun, 9/30/12, Karl Wright <[EMAIL PROTECTED]> wrote:
>
>> From: Karl Wright <[EMAIL PROTECTED]>
>> Subject: Re: [VOTE] Release Apache ManifoldCF 1.0, RC7
>> To: [EMAIL PROTECTED]
>> Date: Sunday, September 30, 2012, 9:40 PM
>> Ran all tests, just to be sure
>> nothing got messed up.  +1 from me.
>>
>> Karl
>>
>> On Sun, Sep 30, 2012 at 11:34 AM, Piergiorgio Lucidi
>> <[EMAIL PROTECTED]>
>> wrote:
>> > +1 from me:
>> >
>> > - checked signatures
>> > - crawling against a CMIS repository
>> > - tried to build using Maven and Ant
>> >
>> > Piergiorgio
>> >
>> > 2012/9/30 Karl Wright <[EMAIL PROTECTED]>
>> >
>> >> Please vote +1 to release ManifoldCF 1.0,
>> RC7.  The release artifact
>> >> can be found at:
>> >>
>> >> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>> >>
>> >> There is also an SVN tag at:
>> >>
>> >> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7
>> >>
>> >> Fixes since RC6:
>> >>
>> >> CONNECTORS-549
>> >>
>> >> Fixes since RC5:
>> >>
>> >> CONNECTORS-547
>> >> CONNECTORS-548 (documentation fix)
>> >>
>> >> Fixes since RC4:
>> >>
>> >> CONNECTORS-545
>> >>
>> >> Fixes since RC3:
>> >>
>> >> CONNECTORS-544
>> >>
>> >> --
>> >> Piergiorgio Lucidi
>> >> http://www.open4dev.com
>> >>
>> >>
>>

Oh, and by the way, I used "ant image" to create the release, which
calls the "create-source-zip" target.  So it's still working for me
just fine.  Hmmm.

Karl

On Tue, Oct 2, 2012 at 2:41 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> The ant build hasn't changed in this regard, but maybe ant has.
> Here's the code:
>
>     <target name="create-source-zip" depends="set-version">
>       <zip destfile="apache-manifoldcf-${release-version}-src.zip"
> update="false">
>         <zipfileset dir="." prefix="apache-manifoldcf-${release-version}">
> ...
>           <exclude name="/apache-manifoldcf-*"/>
>         </zipfileset>
>       </zip>
>     </target>
>
> This used to exclude the zip from itself.  What version of ant are you using?
>
> Karl
>
>
>
> On Tue, Oct 2, 2012 at 2:30 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> 'ant all' command yields:
>>
>> BUILD FAILED
>> /manifoldcf/tags/release-1.0-RC7/build.xml:2529: A zip file cannot include itself
>>
>> Ahmet
>>
>>
>> --- On Sun, 9/30/12, Karl Wright <[EMAIL PROTECTED]> wrote:
>>
>>> From: Karl Wright <[EMAIL PROTECTED]>
>>> Subject: Re: [VOTE] Release Apache ManifoldCF 1.0, RC7
>>> To: [EMAIL PROTECTED]
>>> Date: Sunday, September 30, 2012, 9:40 PM
>>> Ran all tests, just to be sure
>>> nothing got messed up.  +1 from me.
>>>
>>> Karl
>>>
>>> On Sun, Sep 30, 2012 at 11:34 AM, Piergiorgio Lucidi
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>> > +1 from me:
>>> >
>>> > - checked signatures
>>> > - crawling against a CMIS repository
>>> > - tried to build using Maven and Ant
>>> >
>>> > Piergiorgio
>>> >
>>> > 2012/9/30 Karl Wright <[EMAIL PROTECTED]>
>>> >
>>> >> Please vote +1 to release ManifoldCF 1.0,
>>> RC7.  The release artifact
>>> >> can be found at:
>>> >>
>>> >> http://people.apache.org/~kwright/apache-manifoldcf-1.0
>>> >>
>>> >> There is also an SVN tag at:
>>> >>
>>> >> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0-RC7
>>> >>
>>> >> Fixes since RC6:
>>> >>
>>> >> CONNECTORS-549
>>> >>
>>> >> Fixes since RC5:
>>> >>
>>> >> CONNECTORS-547
>>> >> CONNECTORS-548 (documentation fix)
>>> >>
>>> >> Fixes since RC4:
>>> >>
>>> >> CONNECTORS-545
>>> >>
>>> >> Fixes since RC3:
>>> >>
>>> >> CONNECTORS-544
>>> >>
>>> >> --
>>> >> Piergiorgio Lucidi
>>> >> http://www.open4dev.com
>>> >>
>>> >>
>>>

> This used to exclude the zip from itself.  What version
> of ant are you using?

Apache Ant(TM) version 1.8.2 compiled on June 3 2011

Mine is:
C:\wip\mcf\trunk>which ant
c:\ant\apache-ant-1.8.4\bin/ant.bat

Are you running on Windows, or Linux?

Karl

On Tue, Oct 2, 2012 at 2:54 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
>> This used to exclude the zip from itself.  What version
>> of ant are you using?
>
> Apache Ant(TM) version 1.8.2 compiled on June 3 2011

> Are you running on Windows, or Linux?

I am using Mac OS X 10.7.5

Ahmet

Can you try changing the <exclude .../> clause I noted earlier to
remove the leading "/" from "/apache-manifoldcf-*", and see if that
works?

I'd hesitate to spin a new kit here unless there's evidence there's a
viable fix.

Karl

On Tue, Oct 2, 2012 at 3:01 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
>
>> Are you running on Windows, or Linux?
>
> I am using Mac OS X 10.7.5
>
> Ahmet

> Can you try changing the <exclude
> .../> clause I noted earlier to
> remove the leading "/" from "/apache-manifoldcf-*", and see
> if that
> works?

Yes that worked. Later on I upgraded to Ant version 1.8.4, it didn't helped.

Ok - this is likely a windows/linux difference then.

I'll have to try it out on my linux system when I get home to be sure
I catch all the pertinent cases.

In any case, I'm not sure this is worth a respin, since the place it
fails is building a distribution zip.  Does everyone agree?
Karl
On Tue, Oct 2, 2012 at 3:22 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
>> Can you try changing the <exclude
>> .../> clause I noted earlier to
>> remove the leading "/" from "/apache-manifoldcf-*", and see
>> if that
>> works?
>
> Yes that worked. Later on I upgraded to Ant version 1.8.4, it didn't helped.

CONNECTORS-550 is the ticket.

Karl

On Tue, Oct 2, 2012 at 3:26 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Ok - this is likely a windows/linux difference then.
>
> I'll have to try it out on my linux system when I get home to be sure
> I catch all the pertinent cases.
>
> In any case, I'm not sure this is worth a respin, since the place it
> fails is building a distribution zip.  Does everyone agree?
> Karl
>
>
> On Tue, Oct 2, 2012 at 3:22 PM, Ahmet Arslan <[EMAIL PROTECTED]> wrote:
>>> Can you try changing the <exclude
>>> .../> clause I noted earlier to
>>> remove the leading "/" from "/apache-manifoldcf-*", and see
>>> if that
>>> works?
>>
>> Yes that worked. Later on I upgraded to Ant version 1.8.4, it didn't helped.

> In any case, I'm not sure this is worth a respin, since the
> place it
> fails is building a distribution zip.  Does everyone agree?

+1
* Crawled against SharePoint 2010 Repository connection (library and list)
* ran "ant all"
* ran "mvn install/packge -Dmaven.test.skip=true"

Here is my +1 for RC7

Ahmet

+1 from me.

- Downloaded apache-manifoldcf-1.0-bin.tar.gz and deployed on Resin
4/Linux. Crawled around 6000 documents.
- Downloaded apache-manifoldcf-1.0-src.tar.gz and built on OS X.
- Built with Maven 3.0.4 and Ant 1.8.2
- Built documentation (ant doc) and verified the content
- Started MCF on Jetty and registered a Solr Output Connector from both
multiprocess-example and example.

By the way, I got the following error while running mvn clean install
java.lang.UnsupportedOperationException: Entity deletion by key is not
supported. It's related to the Alfresco connector. The complete stack
trace, which was also shown in the console, is shown below.  It's just a
minor issue and does not affect the build.

WARN org.eclipse.jetty.servlet.ServletHandler -
/alfresco/download/direct/workspace/SpacesStore/ed4f2ac6-279a-4a89-a541-9970f8a66812/testdata2.txt
java.lang.UnsupportedOperationException: Entity deletion by key is not
supported
at
org.alfresco.repo.cache.lookup.EntityLookupCache$EntityLookupCallbackDAOAdaptor.deleteByKey(EntityLookupCache.java:202)
at
org.alfresco.repo.cache.lookup.EntityLookupCache.deleteByKey(EntityLookupCache.java:639)
at
org.alfresco.repo.domain.node.AbstractNodeDAOImpl.addNodeAspects(AbstractNodeDAOImpl.java:1987)
at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProperties(DbNodeServiceImpl.java:526)
at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProperties(DbNodeServiceImpl.java:439)
at
org.alfresco.repo.node.db.DbNodeServiceImpl.addAspect(DbNodeServiceImpl.java:736)
at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.alfresco.repo.tenant.MultiTNodeServiceInterceptor.invoke(MultiTNodeServiceInterceptor.java:104)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy10.addAspect(Unknown Source)
at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.alfresco.repo.service.StoreRedirectorProxyFactory$RedirectorInvocationHandler.invoke(StoreRedirectorProxyFactory.java:215)
at $Proxy11.addAspect(Unknown Source)
at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.alfresco.repo.node.MLPropertyInterceptor.invoke(MLPropertyInterceptor.java:303)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.alfresco.repo.node.MLPropertyInterceptor.invoke(MLPropertyInterceptor.java:303)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.alfresco.repo.node.NodeRefPropertyMethodInterceptor.invoke(NodeRefPropertyMethodInterceptor.java:135)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.alfresco.repo.node.NodeRefPropertyMethodInterceptor.invoke(NodeRefPropertyMethodInterceptor.java:135)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy10.addAspect(Unknown Source)
at
org.alfresco.repo.configuration.ConfigurableServiceImpl.makeConfigurable(ConfigurableServiceImpl.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy212.makeConfigurable(Unknown Source)
at org.alfresco.web.bean.repository.User$1.execute(User.java:228)
at org.alfresco.web.bean.repository.User$1.execute(User.java:219)
at
org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:325)
at
org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:232)
at
org.alfresco.web.bean.repository.User.getUserPreferencesRef(User.java:218)
at org.alfresco.web.bean.repository.User.getPreferences(User.java:200)
at
org.alfresco.web.bean.repository.PreferencesServic

Four +1's, >72 hours. Vote passes!

I'll have the candidate available for download within the next few hours.
Karl

On Wed, Oct 3, 2012 at 5:36 AM, Erlend Garåsen <[EMAIL PROTECTED]> wrote:
>
> +1 from me.
>
> - Downloaded apache-manifoldcf-1.0-bin.tar.gz and deployed on Resin 4/Linux.
> Crawled around 6000 documents.
> - Downloaded apache-manifoldcf-1.0-src.tar.gz and built on OS X.
> - Built with Maven 3.0.4 and Ant 1.8.2
> - Built documentation (ant doc) and verified the content
> - Started MCF on Jetty and registered a Solr Output Connector from both
> multiprocess-example and example.
>
> By the way, I got the following error while running mvn clean install
> java.lang.UnsupportedOperationException: Entity deletion by key is not
> supported. It's related to the Alfresco connector. The complete stack trace,
> which was also shown in the console, is shown below.  It's just a minor
> issue and does not affect the build.
>
> WARN org.eclipse.jetty.servlet.ServletHandler -
> /alfresco/download/direct/workspace/SpacesStore/ed4f2ac6-279a-4a89-a541-9970f8a66812/testdata2.txt
> java.lang.UnsupportedOperationException: Entity deletion by key is not
> supported
>         at
> org.alfresco.repo.cache.lookup.EntityLookupCache$EntityLookupCallbackDAOAdaptor.deleteByKey(EntityLookupCache.java:202)
>         at
> org.alfresco.repo.cache.lookup.EntityLookupCache.deleteByKey(EntityLookupCache.java:639)
>         at
> org.alfresco.repo.domain.node.AbstractNodeDAOImpl.addNodeAspects(AbstractNodeDAOImpl.java:1987)
>         at
> org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProperties(DbNodeServiceImpl.java:526)
>         at
> org.alfresco.repo.node.db.DbNodeServiceImpl.addAspectsAndProperties(DbNodeServiceImpl.java:439)
>         at
> org.alfresco.repo.node.db.DbNodeServiceImpl.addAspect(DbNodeServiceImpl.java:736)
>         at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at
> org.alfresco.repo.tenant.MultiTNodeServiceInterceptor.invoke(MultiTNodeServiceInterceptor.java:104)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy10.addAspect(Unknown Source)
>         at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.alfresco.repo.service.StoreRedirectorProxyFactory$RedirectorInvocationHandler.invoke(StoreRedirectorProxyFactory.java:215)
>         at $Proxy11.addAspect(Unknown Source)
>         at sun.reflect.GeneratedMethodAccessor276.invoke(Unknown Source)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at
> org.alfresco.repo.node.MLPropertyInterceptor.invoke(MLPropertyInterceptor.java:303)
>         at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

Vote +1 to release Apache ManifoldCF 1.0.1, RC0.  You can find a tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC0

The artifact can be downloaded from:

http://people.apache.org/~kwright/apache-manifoldcf-1.0.1

This patch release fixes the critical bug CONNECTORS-551.  It also
includes updated how-to-build-and-deploy documentation
(CONNECTORS-546).

Thanks,
Karl

Ran tests and checked documentation.

+1 from me.

Karl

On Sat, Oct 13, 2012 at 6:16 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Vote +1 to release Apache ManifoldCF 1.0.1, RC0.  You can find a tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC0
>
> The artifact can be downloaded from:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0.1
>
> This patch release fixes the critical bug CONNECTORS-551.  It also
> includes updated how-to-build-and-deploy documentation
> (CONNECTORS-546).
>
> Thanks,
> Karl

Vote +1 to release Apache ManifoldCF 1.0.1, RC1.  You can find a tag at:

https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC1

The artifact can be downloaded from:

http://people.apache.org/~kwright/apache-manifoldcf-1.0.1

This patch release fixes the critical bug CONNECTORS-551.  It also
includes updated how-to-build-and-deploy documentation
(CONNECTORS-546).  Finally, it includes a fix for the maven build problem
described in CONNECTORS-555.

Thanks,
Karl

Downloaded artifacts, looked for leakage of maven "target"
directories, and tried a maven build, which worked.

+1 from me.

Karl

On Mon, Oct 15, 2012 at 7:34 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> Vote +1 to release Apache ManifoldCF 1.0.1, RC1.  You can find a tag at:
>
> https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC1
>
> The artifact can be downloaded from:
>
> http://people.apache.org/~kwright/apache-manifoldcf-1.0.1
>
> This patch release fixes the critical bug CONNECTORS-551.  It also
> includes updated how-to-build-and-deploy documentation
> (CONNECTORS-546).  Finally, it includes a fix for the maven build problem
> described in CONNECTORS-555.
>
> Thanks,
> Karl

- executed integration tests
- checked signatures
- crawled a CMIS repository

+1 from me

PJ

2012/10/16 Karl Wright <[EMAIL PROTECTED]>

> Downloaded artifacts, looked for leakage of maven "target"
> directories, and tried a maven build, which worked.
>
> +1 from me.
>
> Karl
>
> On Mon, Oct 15, 2012 at 7:34 PM, Karl Wright <[EMAIL PROTECTED]> wrote:
> > Vote +1 to release Apache ManifoldCF 1.0.1, RC1.  You can find a tag at:
> >
> > https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC1
> >
> > The artifact can be downloaded from:
> >
> > http://people.apache.org/~kwright/apache-manifoldcf-1.0.1
> >
> > This patch release fixes the critical bug CONNECTORS-551.  It also
> > includes updated how-to-build-and-deploy documentation
> > (CONNECTORS-546).  Finally, it includes a fix for the maven build problem
> > described in CONNECTORS-555.
> >
> > Thanks,
> > Karl
>
> --
> Piergiorgio Lucidi
> http://www.open4dev.com
>
>

Hello,

* ran 'ant clean all'
* ran 'ant test'
* ran 'mvn clean install -DskipITs'
* ran 'mvn clean package -DskipITs'

Here is my +1

Ahmet

--- On Tue, 10/16/12, Piergiorgio Lucidi <[EMAIL PROTECTED]> wrote:

> From: Piergiorgio Lucidi <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] Release Apache ManifoldCF 1.0.1, RC1
> To: [EMAIL PROTECTED]
> Date: Tuesday, October 16, 2012, 12:09 PM
> - executed integration tests
> - checked signatures
> - crawled a CMIS repository
>
> +1 from me
>
> PJ
>
> 2012/10/16 Karl Wright <[EMAIL PROTECTED]>
>
> > Downloaded artifacts, looked for leakage of maven
> "target"
> > directories, and tried a maven build, which worked.
> >
> > +1 from me.
> >
> > Karl
> >
> > On Mon, Oct 15, 2012 at 7:34 PM, Karl Wright <[EMAIL PROTECTED]>
> wrote:
> > > Vote +1 to release Apache ManifoldCF 1.0.1,
> RC1.  You can find a tag at:
> > >
> > > https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.0.1-RC1
> > >
> > > The artifact can be downloaded from:
> > >
> > > http://people.apache.org/~kwright/apache-manifoldcf-1.0.1
> > >
> > > This patch release fixes the critical bug
> CONNECTORS-551.  It also
> > > includes updated how-to-build-and-deploy
> documentation
> > > (CONNECTORS-546).  Finally, it includes a fix
> for the maven build problem
> > > described in CONNECTORS-555.
> > >
> > > Thanks,
> > > Karl
> >
> > --
> > Piergiorgio Lucidi
> > http://www.open4dev.com
> >
> >
>

Please vote on whether to release the 0.3 version of the Apache
ManifoldCF Solr 4.x plugin, RC0.  This release simply fixes the
following:

(1) It builds against the tagged 4.0.0 final release of Lucene/Solr
(2) It fixes the test infrastructure to be compatible with late
changes made to Lucene/Solr 4.0.0 testing code

The artifact can be downloaded from:

http://people.apache.org/~kwright/apache-manifoldcf-solr-4.x-plugin-0.3
.  There is also a tag in svn, at
https://svn.apache.org/repos/asf/manifoldcf/integration/solr-4.x/tags/release-0.3-RC0
.